Re: wpa_supplicant uses MAC as username when connecting to PEAP/MSCHAPV2 network

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux