Yaron,

Thank you for your comments.

The intended status of the draft is "Standards track", i.e., the draft
should describe a channel binding solution and not only summarize the
problem and possible solution strategies.

The original draft contained both, a channel binding protocol and a
definition of containers for carrying the exchanged channel binding
information. It was decided early on that for clarity reasons and more
universal usage of these containers, it is better to have two separate
documents to cover both topics.

This is why we have <draft-ietf-emu-chbind-04> to describe the protocol
and <draft-clancy-emu-aaapay-03> to describe the containers. Recently
another draft <draft-cam-winget-eap-tlv-00> has been submitted that
describes EAP TLV containers.

For these reasons, I believe that such a container does *not* need to be
defined in the channel binding draft. It seems to be a much better
approach to use more general EAP containers that can carry channel
binding as well as other data.

To answer your other comments:
"Is this taking place at the EAP level?" Yes
"The SAP level?" No
"Is it a new EAP method?" No, it is an extension to EAP methods that can
be supported by some existing EAP methods and SHOULD be supported by all
new EAP methods.
"Should it be built into each and every new EAP method?" Yes, at least
it is a SHOULD requirement per WG consensus to support channel bindings.

"How does it apply to the few existing EAP methods that can accommodate
it today?" EAP methods that already support the exchange of channel
binding information can easily implement the protocol.

>From your questions, it is obvious that the draft needs to do a better
job to clearly answer the above questions.

Best regards,
Katrin

> -----Original Message-----
> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of
> Yaron Sheffer
> Sent: Sunday, December 06, 2009 4:03 AM
> To: emu@ietf.org
> Subject: Re: [Emu] Working Group Last Call for draft-ietf-emu-chbind-
> 04.txt
> 
> 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.
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu