On Nov 20, 2018, at 9:23 AM, Jouni Malinen <j@xxxxx> wrote:
>
> On Mon, Nov 12, 2018 at 04:11:49PM -0500, Alan DeKok wrote:
>> RFC 3748 Section 5.1 allows empty identities, but forbids identities which are terminated with a zero byte.
>>
>> RFC 5281 (TTLS) suggests that empty identities are not to be used. But they are not forbidden. Other EAP RFCs have similar text.
>
> I'm not sure I'd interpret this RFC as suggesting that empty identity
> not be used in the initial EAP-Response/Identity. That anonymous
> identity can be empty or "anonymous" or either of those with "@realm"
> postfix to help routing to the correct authentication server.
Sure. RFC5281 is more recommending that non-empty identities *should* be used. And by implication, empty identities shouldn't be used.
> RFC 7542
> is actually recommending empty username part to be used here with
> "@realm" in preference over "anonymous@realm".
Yes. As the author, I'm somewhat familiar with that. :)
The downside is that RFC7542 entirely missed the issue of EAP allowing empty identities. So while RFC752 recommends "@realm", it doesn't really say that empty identities are bad.
>> RFC 3579 (EAP over RADIUS) has the following text in Section 2.1:
>>
>> In order to permit non-EAP aware RADIUS proxies to forward the
>> Access-Request packet, if the NAS initially sends an
>> EAP-Request/Identity message to the peer, the NAS MUST copy the
>> contents of the Type-Data field of the EAP-Response/Identity received
>> from the peer into the User-Name attribute and MUST include the
>> Type-Data field of the EAP-Response/Identity in the User-Name
>> attribute in every subsequent Access-Request.
>
> So wouldn't that mandate the NAS to copy the EAP-Response/Identity value
> (i.e., an empty string) into the User-Name attribute? The EAP client is
> clearly providing that as the response in this particular case..
Yes. However... RFC 2865 forbids attributes from being empty. They MUST contain a value.
So using an empty string for User-Name is forbidden. Which means that the NAS has to put *something* into the User-Name attribute.
>> It follows with:
>>
>> If the NAS initially sends an EAP-Request for an
>> authentication method, and the peer identity cannot be determined
>> from the EAP-Response, then the User-Name attribute SHOULD be
>> determined by another means. As noted in [RFC2865] Section 5.6, it
>> is recommended that Access-Requests use the value of the
>> Calling-Station-Id as the value of the User-Name attribute.
>
> Please note that this is referring to the case where EAP-Identity
> exchange is not used, i.e., the NAS starts with an actual EAP
> authentication method immediately and as such, there is no
> EAP-Response/Identity message. This is not what this thread is
> discussing (or well, I guess there could be a NAS that does this and
> wpa_supplicant should be able to handle it, but this kind of NAS setup
> is really rare for Wi-Fi.. I'm not aware of any such deployment).
Sure. However, as User-Name cannot be empty, then the only sane thing a NAS can do is to use the Calling-Station-Id, as noted above.
Any other value would be worse, IMHO.
We have conflicting standards here. So it's really impossible to be compliant to them all. The only remaining choice is to do the least insane thing.
>>> I went to my Wifi admin and looked into the debug log on the access
>>> point with him. Surprisingly my client was trying to authenticate with
>>> the clients MAC address as the username.
>
> If this is really happening because of the EAP client sending an
> EAP-Response/Identity with zero length payload, I'd claim the NAS or
> RADIUS proxy (or whatever decided to convert a zero length value to MAC
> address) is not following what RFC 3579 says in chapter 2.1. Sure, it
> might try to follow the RADIUS RFC instead and the vendor being stuck
> with selecting which MUST requirement to not comply with..
Exactly.
>> One reason for this suggestion is that RFC 2865 forbids the use of zero-length attributes. i.e. and empty EAP-Identity *cannot* result in the create of a RADIUS packet with an empty User-Name. Instead, that User-Name *must* exist, and *must* contain something.
>
> This is a bit misleading since RFC 2865 Chapter 5 does not actually
> forbid zero-length attributes ("The Value field is zero or more
> octets"). However, it does have a constraint on string and text type of
> attributes to be 1-253 octets and "Text/strings of length zero (0) MUST
> NOT be sent; omit the entire attribute instead". (In addition, Chapter
> 5.1 describes the User-Name attribute explicitly with "one or more
> octets".) This constraint seems unnecessary and a bit unfortunate in the
> protocol, but anyway, it is clearly there in the RFC.
I'm not sure there's any utility in allow zero-length attributes in RADIUS. The RADIUS WG has had extensive discussion on that topic for almost 20 years. The consensus is that no one could think of compelling use-cases.
> This combination of EAP and RADIUS RFCs is a bit problematic since it
> looks clear that the RFCs mandate EAP-Response/Identity value to be
> copied into the RADIUS User-Name attribute while the former allows 0
> length and the latter does not. No matter what you do, you'll end up
> being non-compliant with one or more of these RFCs if zero length value
> is indeed used..
That;'s the problem.
>> Further. RFC 7542 (NAI) describes the issue of anonymous identities and EAP. Section 2.4 of that document suggests that if anonymity is desired, then an identity of "@realm" is used. e.g. "@example.com", and not "anonymous" or "anonymous@xxxxxxxxxxx"
>
> This can get interesting if one of the authentication proxies ends up
> stripping realms and moving from "@example.com" to "". I'm not sure
> whether anyone deploys such rules in RADIUS proxies, but if so, the
> recommended anonymous identity encoding would end up converted into an
> empty string and not complying with RADIUS User-Name attribute
> requirements.
RFC 7542 also suggests that stripping realms is wrong. It was common 20 years ago. I can't recall any wide-spread usage in the last 10 years. Everyone just relies on realm routing being set up by AAA admins, and not by end users.
> Please note that this thread is discussing the username privacy case
> (i.e., anonymous_identity="", identity="something-nonempty" in
> wpa_supplicant configuration). The anonymous_identity is used only with
> EAP-Identity while all EAP authentication methods get that nonempty
> identity. This is not incompatible with most EAP methods.
RFC 3748 (EAP) mandates that implementations (and likely EAP methods) allow empty identities. Most method-specific EAP types give specific suggestions for outer identities, and using an empty one isn't considered.
So it's really "theoretically compatible, but in practice not used".
> That RADIUS
> side of the issue can be a different story, though. However, even for
> that, the User-Name attribute value should not really be used for actual
> authentication; instead, the identity determined through an EAP
> authentication method specific mechanism should be used (e.g., EAP-TTLS
> phase 2 identity exchange or EAP-AKA identity message exchange).
Yes. That's a concept which has to be slowly drilled into RADIUS admins. I've been doing that for a long time.
Recent releases of FreeRADIUS (~5 years) do inner/outer identity checks. If the identities are incompatible, it complains.
e.g. outer "bob", and inner "doug". Or outer "@example.com", and inner "bob@xxxxxxxxxxx". There is just no good reason for that kind of thing.
> In
> other words, even if the empty EAP-Response/Identity value were replaced
> with the MAC address in User-Name, authentication should still work as
> long as the EAP method uses an internal mechanism for determining the
> real user identity (which is the recommended way of defining EAP
> authentication methods).
Yes. That is the case. And, the default configuration for most RADIUS servers.
Alan DeKok.
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
