Subject: [Emu] Working Group Last Call for draft-ietf-emu-chbind-04.txt

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 4 Dec 2009 12:12:30 -0800

This is an announcement of working group last call for the Channel
Bindings draft: draft-ietf-emu-chbind-04.  Please send comments to the
list by December 18, 2009.  When proposing changes to the document it is
helpful to provide some sample text.  Also if you have reviewed the
document and found no issues it is appropriate to send a message to the
list indicating your approval.  

The URL for the document is
http://www.ietf.org/id/draft-ietf-emu-chbind-04.txt

Cheers,

Joe

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 5 Dec 2009 12:59:12 -0800

> This is an announcement of working group last call for the Channel
Bindings draft: draft-ietf-emu-chbind-04.  Please send comments to the list
by December 18, 2009.  When proposing 
> changes to the document it is helpful to provide some sample text.  Also
if you have reviewed the document and found no issues it is appropriate to
send a message to the list indicating 
> your approval.  

Not that I want to slow things down any further, but this seems like a
particularly bad time to issue a WGLC.  May I suggest either waiting until
after the New Year or extending the Last Call period until the middle of
January?

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 6 Dec 2009 12:02:31 +0200

Hi,

IMHO this document is not ready to be advanced, at least not as Standards Track.

The document is extremely abstract: it defines the problem statement very well, but then keep its options open when describing the solution. The fact that the document has an empty IANA section is a strong hint that it is not really defining a protocol.

This can be resolved either of two ways:

- Change it to Informational, and add text to clarify that the document is *not* defining a protocol (despite the title of Sec. 5), but rather presents the problem and proposes several alternative solution strategies.

- Or extend it to really define a protocol. In which case you need to answer some simple questions like:
	* Is this taking place at the EAP level? The SAP level? Is it a new EAP method? Should it be built into each and every new EAP method?
	* How does it apply to the few existing EAP methods that can accommodate it today?
	* How are the actual TLVs represented/encoded?

BTW, just defining the TLV formats (and IANA numbers) for EAP methods would serve the community well: looking at the IANA registry for EAP-GPSK, there's a "protected payload" defined (http://www.iana.org/assignments/eap-gpsk-parameters/eap-gpsk-parameters.xhtml#eap-gpsk-parameters-2). But nobody ever bothered defining *any* specific payloads for channel bindings.

Thanks,
	Yaron
> 
> ----------------------------------------------------------------------
> 
> Date: Fri, 4 Dec 2009 12:12:30 -0800
> From: "Joseph Salowey (jsalowey)" <[email-masked]>
> Subject: [Emu] Working Group Last Call for
> 	draft-ietf-emu-chbind-04.txt
> To: <[email-masked]>
> Message-ID:
> 	<AC1CFD94F59A264488DC2BEC3E890DE5093AAD03@xmb-sjc-
> 225.amer.cisco.com>
> Content-Type: text/plain;	charset="us-ascii"
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 4 Dec 2009 13:11:26 -0800 (PST)
> From: "Dan Harkins" <[email-masked]>
> Subject: Re: [Emu] Issue #7: Password Authentication
> To: "Joseph Salowey (jsalowey)" <[email-masked]>
> Cc: [email-masked]
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain;charset=iso-8859-1
> 
> 
>   Hi Joe,
> 
>   I like your suggestion. Using "EAP server" would satisfy my concern.
> 
>   thanks,
> 
>   Dan.
> 
> On Fri, December 4, 2009 11:56 am, Joseph Salowey (jsalowey) wrote:
> > OK good points.  I can see the problem with the authentication server
> > wording.  I think EAP server is more correct in this case as it leaves
> > deployment options open.   Is the text OK if we change Authentication
> > Server to EAP server in this paragraph?
> >
> > Joe
> >
> >> -----Original Message-----
> >> From: Alan DeKok [mailto:[email-masked]]
> >> Sent: Friday, December 04, 2009 10:00 AM
> >> To: Joseph Salowey (jsalowey)
> >> Cc: Dan Harkins; [email-masked]
> >> Subject: Re: [Emu] Issue #7: Password Authentication
> >>
> >> Joseph Salowey (jsalowey) wrote:
> >> > This section is about transporting clear text usernames and
> >> passwords
> >> > within the tunnel, so password transport requirement needs
> >> to stay.
> >> > I'm fine with more accurate text for describing the attacks.  I
> >> > propose the following text:
> >> >
> >> > "The tunnel method MUST support transporting clear text
> >> username and
> >> > password to the authentication server.  It MUST NOT reveal
> >> information
> >> > about the username and password to parties in the
> >> communication path
> >> > between the peer and the EAP Server.  The advantage any
> >> attacker gains
> >> > against the tunneled method when employing a username and
> >> password for
> >> > authentication MUST be through interaction and not computation. "
> >>
> >>   The first sentence refers to "authentication server", while
> >> the second  uses "EAP server".  I suggest using "EAP server"
> >> for both, as it is used elsewhere in the document, too.
> >>
> >>   Alan DeKok.
> >>
> >
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
> 
> 
> End of Emu Digest, Vol 47, Issue 7
> **********************************
> 
> Scanned by Check Point Total Security Gateway.