Hi,
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.
Unfortunately, that is not how I read the EAP spec. RFC3748 section 5.1
on the Identity packet does not mention UTF-8 for the *Response* at all.
It mentions that the *request* MAY contain displayable text, which needs
to be UTF-8 if present.
For response, no encoding is mandated. The RFC even mentions weirdnesses
such as an intermediate NUL character followed by various options -
but only notes them, they are not forbidden. The use of such a construct
breaks the UTF-8 requirement.
I totally agree that anything besides UTF-8 in the Response is a bad
idea, and these days hopefully a seldom find - but it should be said
someplace that it's outright forbidden.
Which reminds me that my text speaks of SHOULD NOT in the
recommendations (given that I've preliminarily aimed for BCP status, I
found a MUST NOT not to be fitting; but maybe it is more spot on
nontheless).
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.
And do what if they find that the blob is not UTF-8? Drop the packet?
Forward anyway?
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.
Sure; but you create a malformed packet with it - so everybody who
consumes that data is at a gamble.
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.
Sure, no problem.
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.
Will do (the completely different content would be the outer identity).
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. :(
Yes, that's why I wrote the (somewhat hollow) statement that it needs
to maintain state of the encoding used. How it does that... no spec can
mandate.
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.
I totally agree that it's ugly. Adding Note: That is ugly. to the spec
doesn't provide much added value though :-)
I feel strong about stating the problem though. We had an actual
real-life support case from a device manufacturer whose handset
customers couldn't use eduroam and the manufacturer said our RADIUS
infrastructure is broken, because it always rejects before they can even
try the configured EAP-TTLS that the user sets.
It was totally unthinkable for them that someone would not have a
business relationship with 3GPP and that always trying the same 3GPP
user identifier when starting EAP would lead nowhere.
After a lot of explaining and escalation to some senior engineering, we
could make that clear, and the firmware got a fix. Having this described
in an RFC to point to will certainly help if such states of mind pop up
again someplace in the future.
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
