Skip to main content

Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method
RFC 6678

Yes

(Sean Turner)

No Objection

(Gonzalo Camarillo)
(Russ Housley)

Abstain

Lars Eggert

Note: This ballot was opened for revision 09 and is now closed.

Lars Eggert (was Discuss) Abstain

(Jari Arkko; former steering group member) (was Discuss) Yes

Yes (2010-12-02)
I support Lars' discuss, but I also think that the document is clear
with respect to what it is recommending, i.e., I'm not supportive of
Alexey's discuss.

(Sean Turner; former steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) No Objection

No Objection (2010-12-01)
A number of acronyms need to be expanded on first use.

(Alexey Melnikov; former steering group member) (was Discuss) No Objection

No Objection (2010-12-01)
3.1.  Password Authentication

   Many legacy systems only support user authentication with passwords.
   Some of these systems require transport of the actual username and
   password to the authentication server.  This is true for systems
   where the authentication server does not have access to the cleartext
   password or a consistent transform of the cleartext password.
   Example of such systems are one time password (OTP) systems and other

I don't think OTP systems require password in the clear, or at least not all of them.

   systems where the username and password are submitted to an external
   party for validation.

4.2.1.  TLS Requirements

   The tunnel based method MUST support TLS version 1.2 [RFC5246] and
   may support earlier versions to enable the possibility of backwards
   compatibility.

Just not SSL 2.0 :-).

4.5.  Requirements Associated with Carrying Username and Passwords

   This section describes the requirements associated with tunneled
   password authentication.  The password authentication mentioned here
   refers to user or machine authentication using a legacy password
   database or verifier, such as LDAP, OTP, etc.  These typically
   require the password in its original text form in order to
   authenticate the peer, hence they require the peer to send the clear
   text user name and password to the EAP server.

LDAP needs an Informative Reference.


4.5.2.  Internationalization

   The password authentication exchange MUST support user names and
   passwords in international languages.  It MUST support encoding of
   user name and password strings in UTF-8 [RFC3629] format.  The method
   MUST specify how username and password normalizations and/or
   comparisons is performed in reference to SASLPrep [RFC4013] or Net-
   UTF-8 [RFC5198].

Please add "or their replacement", as SASLPrepbis is going to be worked on in the Precis WG.

4.5.2.  Internationalization

   These numeric codes are not subject

Missing "to" after "subject".

   internationalization during transmission.

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ()

                            

(Peter Saint-Andre; former steering group member) No Objection

No Objection (2010-12-01)
1. In Section 3.9, a reference to RFC 5056 would be helpful with regard to channel binding.

2. In Section 3.9 and Section 4.6.3, it might be good to describe in a bit more how cryptographic binding is different from channel binding.

(Robert Sparks; former steering group member) No Objection

No Objection (2010-12-01)
Support Lars' DISCUSS re: 2119 language

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Stewart Bryant; former steering group member) No Objection

No Objection (2010-12-01)
I support Lars' Discuss on RFC2119 language. I also found it very confusing.

(Tim Polk; former steering group member) No Objection

No Objection (2010-12-02)
After reading the secdir review and various AD comments, I have come to the conclusion that diagrams and other
architectural information are necessary for this document to be widely useful.  I enter this as a comment, since the
primary audience for the document is the emu working group, and I expect that the participants are in rough agreement
about the architecture.  That is, adding the diagrams and architectural information will have limited utility for emu
itself (although we might identify some unknown disagreements in the process!)  The specification can serve its
main purpose as it stands - guide and focus the development of a standards track EAP tunnel method.

I leave to the authors, chairs, and sponsoring AD's discretion whether the working group has sufficient cycles or
energy to fill this gap.