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)" <jsalo...@cisco.com>
> Subject: [Emu] Working Group Last Call for
> draft-ietf-emu-chbind-04.txt
> To: <emu@ietf.org>
> Message-ID:
> <ac1cfd94f59a264488dc2bec3e890de5093aa...@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" <dhark...@lounge.org>
> Subject: Re: [Emu] Issue #7: Password Authentication
> To: "Joseph Salowey (jsalowey)" <jsalo...@cisco.com>
> Cc: emu@ietf.org
> Message-ID:
> <356e783c475bc4bfd423f50e6b5a4302.squir...@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:al...@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
