Problem with EAP Identity

[Michael Schwartzkopff-3]

Hi,


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"

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/[hidden email]"
(...)
Debug: (8)   State = 0x45e56b9d45e46617718e28efb749ef6f

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?


Thanks for any hints.

Mit freundlichen Grüßen,

--

[*] sys4 AG
 
https://sys4.de, [phone]
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



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan DeKok-2]

On Jan 12, 2021, at 8:29 AM, Michael Schwartzkopff <[hidden email]> 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/[hidden email]"
> (...)
> 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

[Kacper Wirski]

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

W dniu 12.01.2021 o 14:48, Alan DeKok pisze:

> On Jan 12, 2021, at 8:29 AM, Michael Schwartzkopff <[hidden email]> 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/[hidden email]"
>> (...)
>> 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

--
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast.
https://www.avast.com/antivirus

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Michael Schwartzkopff-3]

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 <[hidden email]> 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/[hidden email]"
>>> (...)
>>> 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, [phone]
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



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Kacper Wirski]

I enable MAC-auth only on switch ports that are used by 802.1x-unaware
devices.  802.1x makes most sense on ports that are facing clients and I
can easily distinguish which ports will be used with mac-auth and which
by 802.1x-aware, so I just skip the issue.

If you for some reason need to have MAB enabled on every switch port and
still connect 802.1x-aware device You can maybe try messing with
guest-vlan timeout  - you need to set a guest-vlan and
guest-vlan-period, but not too high value, so that it gives enough time
for the client to boot up and start sending EAP frames and authenticate,
without switch "taking matters in own hands" and going directly with MAB.

guest-vlan-period - The time, in seconds, for which the authenticator
waits to see if any EAPOL packets are received on a port before
authorizing the port and placing the port in the guest vlan (if
configured). The guest vlan timer is only relevant when guest vlan has
been configured on that specific port.

on edgemax switches with CLI it's something like:

configure

interface 0/1 [or other]

dot1x timeout guest-vlan-period 30

dot1x guest-vlan [some-vlan - it can be probably something bogus, just
for the guest-vlan-period to work.


But I'd rather recommend dedicating ports for MAB and just disable it on
everything else.

Also 802.1x in ubiquiti switches isn't perfect, but it's gotten way
better in recent updates and I had some good interactions with ubiquiti
support - even got some early alpha/beta patches to help with my
specific issues.

Regards,

Kacper

W dniu 12.01.2021 o 19:55, Michael Schwartzkopff pisze:

> 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 <[hidden email]> 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/[hidden email]"
>>>> (...)
>>>> 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,
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

--
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast.
https://www.avast.com/antivirus
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan DeKok-2]

On Jan 12, 2021, at 1:55 PM, Michael Schwartzkopff <[hidden email]> wrote:
> 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?

  Ubiquiti is generally pretty good, and responsive.  I've got a fair bit of their gear.

  But yes, it's a bug.  Once EAP starts, the User-Name *must not* change.  But it's OK to use a different User-Name for MAB and EAP.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html