On Nov 12, 2018, at 3:29 PM, michael-dev <michael-dev@xxxxxxxxxxxxx> wrote:\ > I cannot reproduce this. But I'm seeing issues with an empty anonymous_identity as well. > > Testing against FreeRadius 2.2.9, I'm getting The same code and error message is in subsequent versions of FreeRADIUS, too. Let's discuss this in more detail, as the background isn't trivial. > So basically FreeRadius disregards empty string (identity len = zero) or strings starting with null byte. 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. 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. 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. 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. 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]. 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. 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. 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" > 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. Alan DeKok. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
