Stefan Winter wrote:
> 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.
That's worse than I remembered.
> 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.
I agree.
>> 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?
Forward anyways. It's what they do now. We can't mandate that 10^9
EAP supplicants upgrade. It's probably easier to fix the AAA
infrastructure to work with broken clients.
> 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.
Weird.
> 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.
That's just dumb. The way sane vendors deal with this is that they
allow the user to choose which identity to use. It's ridiculous for the
vendor to force a particular identity on the user / device.
> 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.
Yes. The RFCs are unfortunately silent on a wide variety of topics.
RFC 2865 even says:
The secret MUST NOT be empty (length 0) since this would allow
packets to be trivially forged.
Because I ran into a vendor who didn't allow admins to set a shared
secret... and always used a zero-length string. It *was* allowed in RFC
2158. I poked the RADIUS WG, and everyone was appalled.
>> I would add "or allow the provisioning of an EAP-Response/Identity
>> field independent form the EAP method user identifier"
>
> Well... that degree of freedom exists - outer ID *is* independent from
> the EAP method's user identifier.
The idea was to allow *provisioning* of the Response/Identity.
Automatically deriving it from the method-specific "user identity" is
just as bad as automatically using a 3GPP identity.
> Interesting thought, and a bit complex. I suggest we discuss this when
> the draft gets adopted in ... "some" working group. Suggestions welcome :-)
I'd support a "roaming inter-operations" WG. Some of the documents
now in RADEXT could move there, and maybe DIME. This document could
live there.
The goal for the WG would be to define inter-domain standards for
authentication, accounting, EAP, etc.
Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
