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. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
