Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method
draft-ietf-emu-eaptunnel-req-09

A number of acronyms need to be expanded on first use.

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.

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.

Support Lars' DISCUSS re: 2119 language

I support Lars' Discuss on RFC2119 language. I also found it very confusing.

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.