Problem with EAP Identity

[Michael Schwartzkopff]

On 12.01.21 18:18, Kacper Wirski wrote:
> I've seen similiar behaviour on some ubiquiti switches, when port had
> "MAC authentication bypass" enabled and connected client was 802.1x
> aware (e.g. windows PC with eap/peap).
>
> What would sometimes happen is that when client for whatever reason
> didn't provide identity fast enough (depending on switch timeouts for
> 802.1x), and port had mac-auth-bypass enabled ,switch goes on with
> MAC-auth (as seen in the first acces-requeste),  but then later
> connected client cathes on and sends it's reply to
> EAP-request-identity, so switch changes user-name.
>
> Maybe it's similar scenario? Check if MAC authentication bypass is
> enabled on Your switch's port or not (depending what You wish to
> achieve).
>
> Regards,
>
> Kacper
>

Yes, exactly the same vendor and scenario. So it seems to be a bug in
the switch software. Do you know if there is any chance to change the
timing behaviour of the switch, perhaps to wait longer for the host to
answer the 802.1x request?


> W dniu 12.01.2021 o 14:48, Alan DeKok pisze:
>> On Jan 12, 2021, at 8:29 AM, Michael Schwartzkopff <ms at sys4.de> wrote:
>>> I stumbled upon a strange behaviour of my switches. I want to configure
>>> 802.1x. In the first packet the Switch sends:
>>>
>>> Debug: (7) Received Access-Request Id 81 from x.x.x.46:36296 to
>>> x.x.x.154:1812 length 152
>>> Debug: (7)   User-Name = "3464A9D11215"
>>    That's weird.
>>
>>> The debug goes on:
>>>
>>> Debug: (7) eap: Peer sent packet with method EAP Identity (1)
>>> Debug: (7) eap: EAP session adding &reply:State = 0x45e56b9d45e46617
>>> Debug: (7)     modsingle[authenticate]: returned from eap (rlm_eap)
>>> Debug: (7)     [eap] = handled
>>>
>>> The next request from the switch is:
>>>
>>> Debug: (8) Received Access-Request Id 82 from x.x.x.46:36296 to
>>> x.x.x.154:1812 length 167
>>> Debug: (8)   User-Name = "host/test at xxx.xx"
>>> (...)
>>> Debug: (8)   State = 0x45e56b9d45e46617718e28efb749ef6f
>>    That's weirder.  :(
>>
>>> and then the RADIUS server complains:
>>>
>>> Debug: (8) eap: Previous EAP request found for state
>>> 0x45e56b9d45e46617,
>>> released from the list
>>> Debug: (8) eap: Identity does not match User-Name.  Authentication
>>> failed
>>> Debug: (8) eap: Failed in handler
>>>
>>> Can anyone explain what happens here? Does the switch change the
>>> User-Name within the RADIUS / EAP session? Is this a bug of the switch?
>>> Or does something other happen here?
>>    The switch is *supposed* to be sane.  See RFC 3579 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.
>>
>>    i.e. the switch is *not* supposed to change the User-Name in the
>> middle of an EAP session.
>>
>>    My $0.02 is to post the full debug output to check.  But also to
>> "name and shame" the switch vendor.  Then, throw it in the garbage
>> and buy one that works.
>>
>>    Alan DeKok.
>>
>>
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>

Mit freundlichen Grüßen,

-- 

[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20210112/c4e1d33d/attachment.sig>