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)" <jsalowey@cisco.com>
> Subject: [Emu] Working Group Last Call for
> 	draft-ietf-emu-chbind-04.txt
> To: <emu@ietf.org>
> Message-ID:
> 	<AC1CFD94F59A264488DC2BEC3E890DE5093AAD03@xmb-sjc-
> 225.amer.cisco.com>
> Content-Type: text/plain;	charset="us-ascii"
> 
> 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
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 4 Dec 2009 13:11:26 -0800 (PST)
> From: "Dan Harkins" <dharkins@lounge.org>
> Subject: Re: [Emu] Issue #7: Password Authentication
> To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
> Cc: emu@ietf.org
> Message-ID:
> 	<356e783c475bc4bfd423f50e6b5a4302.squirrel@www.trepanning.net>
> 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:aland@deployingradius.com]
> >> Sent: Friday, December 04, 2009 10:00 AM
> >> To: Joseph Salowey (jsalowey)
> >> Cc: Dan Harkins; emu@ietf.org
> >> 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
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
> 
> 
> End of Emu Digest, Vol 47, Issue 7
> **********************************
> 
> Scanned by Check Point Total Security Gateway.