Re: [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt

[Alan DeKok <[e-mail]>]

  Some comments:

Section 3:

   ... EAP-
   Response/Identity does not carry encoding information itself, so a
   conversion between a non-UTF-8 encoding and UTF-8 is not possible for
   the AAA entity doing the EAP-Response/Identity to User-Name copying.

  I'm unsure about this.  The EAP-Response/Identity field is *supposed*
to be UTF-8.  So if it's not, the supplicant is non-compliant, and
anything can happen.

  I think the recommendation here for EAP to RADIUS gateways (e.g.
Access Points) is to do as little translation as possible.  They should
just copy the Identity blob into the User-Name attribute.

  The next paragraph does explain why this is a problem, but the quoted
text above seems misleading to me.  The AAA entity *can* copy the
EAP-Response/Identity to User-Name.  It's just data, so that copying is
always possible.


   Consequence: If an EAP method's username is not encoded in UTF-8, and

  I would suggest "user identifier", to avoid confusion with User-Name.

   the EAP peer verbatimly uses that method's notion of a username for
   its EAP-Response/Identity field, then the AAA entity is forced to
   violate its own specification because it has to, but can not use
   UTF-8 for its own User-Name attribute.  This jeopardizes the
   subsequent EAP authentication as a whole; request routing may fail or
   lead to a wrong destinationi, or the AAA payload may be discarded by
   the recipient due to the malformedness of the User-Name attribute.


  That is all true.  I would note that the EAP-Response/Identity field
does *not* have to be taken from the EAP methods user identifier field.
 They can be completely different.

  That should be noted here.  Where the EAP methods user identifier
field is *not* UTF-8, the supplicant MUST provide a UTF-8 compatible
string for the EAP-Response/Identity field.  How it gets that string is
implementation dependent. :(

Section 4:

   Where usernames between configured EAP types in an EAP peer differ,
   the EAP peer can not rely on the EAP type negotiation mechanism alone
   to provide useful results.  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 usernames
   from the entire set of configured EAP types before declaring final
   authentication failure.

  I see why this can be necessary, but it's ugly.

   EAP peers need to maintain state on the encoding of the usernames
   which are used in their locally configured EAP types.  When
   constructing an EAP-Response/Identity from that username information,
   they SHOULD (re-)encode that username 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
   should also be (re-)encoded in UTF-8 encoding before being put into
   the EAP-Response/Identity.

 I would add "or allow the provisioning of an EAP-Response/Identity
field independent form the EAP method user identifier"

Section 5

  It may be worth noting that supplicants should try the most secure EAP
methods first (i.e. ones with anonymous outer identity).  If those fail,
they should proceed to more insecure methods.  This prevents leakage.

  Also, supplicants could cache information about successful
authentications.  If the system appears to be "the same" as one where
EAP method X previously worked, it makes sense to start off with EAP
method X.

  How the supplicant determines that this is "the same" system is a
subject for discussion.

  Alan DeKok.