[radext] Review of draft-winter-radext-populating-eapidentity-01

[Bernard Aboba <[e-mail]>]

One of the fundamental assumptions of this document is that the EAP-Response/Identity is somehow determined from the method-specific identities.  This is not correct, as RFC 3748 Section 5.1 makes clear: 
 
      It is RECOMMENDED that the Identity Response be used primarily for
      routing purposes and selecting which EAP method to use.  EAP
      Methods SHOULD include a method-specific mechanism for obtaining
      the identity, so that they do not have to rely on the Identity
      Response.  Identity Requests and Responses are sent in cleartext,
      so an attacker may snoop on the identity, or even modify or spoof
      identity exchanges.  To address these threats, it is preferable
      for an EAP method to include an identity exchange that supports
      per-packet authentication, integrity and replay protection, and
      confidentiality.  The Identity Response may not be the appropriate
      identity for the method; it may have been truncated or obfuscated
      so as to provide privacy, or it may have been decorated for
      routing purposes.  Where the peer is configured to only accept
      authentication methods supporting protected identity exchanges,
      the peer MAY provide an abbreviated Identity Response (such as
      omitting the peer-name portion of the NAI [RFC2486]).  For further
      discussion of identity protection, see Section 7.3.
 
The above text makes it clear that the EAP-Response/Identity and method-specific Identities used within individual EAP methods are separate and distinct.  The method-specific identities need not be in NAI format, or encoded in UTF-8.  Therefore attempts to convert them to NAI format can frequently fail.  Also, the EAP-Response/Identity is frequently anonymous and is used to prevent a snooping attacker from obtaining the method-specific identities, which are typically encrypted.  For this reason and others described below, it is not advisable for EAP implementations to determine the EAP-Response/Identity based on the method-specific identities. 
 
Most EAP methods created subsequent to RFC 3748 have incorporated their own Identity Exchanges, and those methods are therefore not influenced by the EAP-Response/Identity.   Since the EAP-Response/Identity is distinct from the method-specific identity, the recommendations of Section 4 will not have an effect on EAP authentication, other than perhaps forcing the selection of a different EAP server:   
 
   If an EAP authentication gets rejected, the EAP peer SHOULD re-try the authentication using a
   different EAP-Response/Identity than before.  The EAP peer SHOULD try
   all user identifiers from the entire set of configured EAP types
   before declaring final authentication failure.
 
The advice has a number of major downsides.  Since most authentication failures will be due to mistyping the password, responding to an authentication failure by retrying all conceivable user identities will lead to major delays and very high levels of user annoyance.  By responding to an authentication failure by trying method-specific identities, implementations would divulge identity information that was designed to be kept secret, compromising privacy. Also, an implementation following this advice would utilize method-specific identities that may not be in the appropriate format or character encoding for an EAP-Response/Identity.  
 
   EAP peers need to maintain state on the encoding of the user
   identifiers which are used in their locally configured EAP types.
   When constructing an EAP-Response/Identity from that user identifier,
   they MUST (re-)encode that user identifier as UTF-8 and use the
   resulting value for the EAP-Response/Identity.  If the EAP type is
   configured for the use of anonymous outer identities, the desired
   outer identity MUST also be (re-)encoded in UTF-8 encoding before
   being put into the EAP-Response/Identity.
 
Since RFC 3748 makes it clear that the EAP-Response/Identity is not related to the method-specific identity, constructing the EAP-Response/Identity from the method-specific one is inadvisable.   The re-encoding described above may not be possible for a variety of reasons, including the fact that the method-specific identity need not be in NAI form at all.