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

[Yaron Sheffer <[e-mail]>]

Hi Katrin,

Thanks for your (slightly delayed :-) response.

Your reply clears up much that I was confused about, but OTOH, it also justifies some of my confusion:

Draft-clancy-emu-aaapay-03 is referenced only once in the document, and in a highly noncommittal way:

	"AAA Payloads" defined in [I-D.clancy-emu-aaapay] proposes a mechanism to carry this information.

In addition, the draft should be cited normatively, if it is indeed essential to implementing this protocol. Obviously, it would block this document, but this document cannot be implemented in its absence anyway. And presumably, it (or is there now an alternative?) would have to become a WG document first.

So even when the draft is clarified a lot, it should not proceed to publication as a Standards Track RFC without the other parts of the jigsaw.

Thanks,
	Yaron

> -----Original Message-----
> From: Hoeper Katrin-QWKN37 [mailto:[e-mail]]
> Sent: Tuesday, March 02, 2010 17:57
> To: Yaron Sheffer; [e-mail]
> Subject: RE: [Emu] Working Group Last Call for draft-ietf-emu-chbind-
> 04.txt
> 
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Yaron Sheffer
> > Sent: Sunday, December 06, 2009 4:03 AM
> > To: [e-mail]
> > 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)" <[e-mail]>
> > > Subject: [Emu] Working Group Last Call for
> > > 	draft-ietf-emu-chbind-04.txt
> > > To: <[e-mail]>
> > > 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" <[e-mail]>
> > > Subject: Re: [Emu] Issue #7: Password Authentication
> > > To: "Joseph Salowey (jsalowey)" <[e-mail]>
> > > Cc: [e-mail]
> > > Message-ID:
> > > 	<[e-mail]>
> > > 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:[e-mail]]
> > > >> Sent: Friday, December 04, 2009 10:00 AM
> > > >> To: Joseph Salowey (jsalowey)
> > > >> Cc: Dan Harkins; [e-mail]
> > > >> 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
> > > [e-mail]
> > > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/emu
> 
> Scanned by Check Point Total Security Gateway.