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. RFC 7542
is actually recommending empty username part to be used here with
"@realm" in preference over "anonymous@realm".
> 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..
> 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).
> Which explains why the original poster saw this behavior:
>
> > 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..
> RFC 3580 discuss this topic in more detail:
>
> 3.1. User-Name
>
> In IEEE 802.1X, the Supplicant typically provides its identity via an
> EAP-Response/Identity message. Where available, the Supplicant
> identity is included in the User-Name attribute, and included in the
> RADIUS Access-Request and Access-Reply messages as specified in
> [RFC2865] and [RFC3579].
Again, this would include the case of anonymous_identity="" and zero
length username in EAP-Response/Identity.
> Alternatively, as discussed in [RFC3579] Section 2.1., the User-Name
> attribute may contain the Calling-Station-ID value, which is set to
> the Supplicant MAC address.
While this is for the case where EAP-Identity is not used.
> 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.
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..
> 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.
> > Maybe your AP or RADIUS infrastructure behaves similarely with empty identities?
>
> I wouldn't be surprised if other RADIUS servers behave the same way.
>
> I would suggest that using empty identities is technically allowed, but is a bad idea in practice. It can result in the behaviour seen above (MAC address sent as User-Name). And, it prevents proxying from working.
>
> So in short, don't use empty identities. While being technically compliant with EAP, they are likely incompatible with most EAP methods, and are definitely incompatible with RADIUS.
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. 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). 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).
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
