Compatibility problems with wired 802.1x

Compatibility problems with wired 802.1x

[Diego Santa Cruz]

[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]

Hi,

I have been attempting to use ead do wired 802.1x authentication and I am having problems with an HP V1910-48G switch (admittedly an old switch).

The problem I see is that the switch never responds to the EAPOL packets sent by ead. Investigating I saw that the protocol version in the EAPOL packets sent by ead is set to 802.1X-2004 (2) but in the unsolicited packets the switch sends it is set to 802.1X-2001 (1).

I am new to 802.1X but I went through the specs and as I understand the switch should respond even if it receives an EAPOL version higher that what it uses, but this switch does not.

Looking through the ead sources I think the new 802.1X-2004 features are not used, so I went ahead and changed ead to send 802.1X-2001 (1) in its packets, and voilà it now works!

Is there any reason that the packets sent by ead use version 802.1X-2004? If not I can send a patch to change it to always use 802.1X-2001. I suspect it is safer to use the older version of the standard, as switches implementing 802.1X-2004 surely work with 802.1X-2001.

Also, I see ead does not manipulate the link state and mode of the interface, I would have expected it to put the interface into dormant mode and the link state changed between up and dormant depending on the authenticated state (like iwd does for WLAN links). Is there any reason for this? I guess one could be the support of guest or auth-fail VLANs in some switches.

Best,

Diego
--
Diego Santa Cruz, PhD
Technology Architect
spinetix.com


[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 3897 bytes --]

RE: Compatibility problems with wired 802.1x

[Diego Santa Cruz]

[-- Attachment #1: Type: text/plain, Size: 3838 bytes --]

Hi Denis,

> -----Original Message-----
> From: Denis Kenzior <denkenz@gmail.com>
> Sent: 25 April 2020 05:04
> To: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>; iwd(a)lists.01.org
> Subject: Re: Compatibility problems with wired 802.1x
> 
> Hi Diego,
> 
> <snip>
> 

Sorry for the (very) late reply, I just noticed this message sitting in my Junk folder... I have you whitelisted now.

> >> Hmm, its been a while since I looked into ead.  On the iwd side we
> >> default to replying with the same protocol version as the request, but
> >> looks like ead does indeed hard-code 2004 as the version.
> >>
> >
> > In ead context I think there is not always something to reply to, the
> EAPPOL-Start message is sent unsolicited, so there is no request to look at to
> get the version. That may explain why it is hardcoded.
> 
> Yes, with WiFi it is a bit simpler because 95% of the time the AP sends
> us a RequestIdentity right away with a protocol version set.  So we just
> use that one.  However, there have been instances where even this
> strategy fails.  For example, Time Warner / Spectrum hotspots send a
> RequestIdentity with 2004 version, but refuse to process any packets
> unless they're sent with 2001 version.  We do send EAPOL-Start with 2001
> in iwd, but for some reason ead uses 2004.
> 

Ah! I guess the adage "do whatever Windows does" ensures best compatibility, probably that the AP QA is often like "if it works with Windows then all is good" despite the Wi-Fi alliance efforts. Well now ead uses 2001 so I hope that works out well with all switches.

> <snip>
> 
> >> Yes, indeed it should.  I suspect the reason is that it sort of just
> >> happened to work even when the operstate wasn't set properly, but this
> >> should be fixed.
> >>
> >
> > I have second thoughts about this. At least in the switch I am playing with, it
> can be configured so that an unauthenticated supplicant is put into a guest
> VLAN and one which fails authentication into an auth-fail VLAN (but my guess
> is that this is pretty common functionality). If ead were to put the link into
> dormant state until authentication succeeded it would mean daemons that
> look at the link's running flag would not attempt to communicate before
> authentication succeeded (e.g., DHCP client), thus loosing the possibility to
> use the guest or auth-fail VLAN.
> 
> This area is tricky and not very well documented (on Linux and in
> general)  At least according to
> https://www.kernel.org/doc/Documentation/networking/operstates.txt,
> dhcp
> daemons expect the supplicant to take the interface out of dormant mode
> as a hint that DHCP requests can now be sent.  So ideally,
> EAP-RequestIdentity should trigger the interface going into OPER_DORMANT
> mode.  And EAP-Success should trigger it going into OPER_UP.
> 
> But, the complication is that there are implementations that send
> RequestIdentity / reply to EAPoL-Start only after the initial DHCP
> Discover has been sent out.  This is a big reason why we think it makes
> sense to put dhcp right into ead eventually.
> 
> I suspect ead will need to try to auto-detect (or have the user
> configure) if this 'guest-vlan' type scenario is supported.  And if it
> isn't, leave the interface in OPER_DORMANT state.
> 

As far as I have been able to test the current situation in ead works well in practice, so I am not sure adding complexity (implementation and configuration) to handle setting the interface into dormant state and back up is probably not needed. We will be including ead in the next firmware release for our products to add 802.1x support so it will get wider testing, I will come back if we notice any problems. 

Best,
Diego

-- 
Diego Santa Cruz, PhD
Technology Architect
spinetix.com

Re: Compatibility problems with wired 802.1x

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 2605 bytes --]

Hi Diego,

<snip>

>> Hmm, its been a while since I looked into ead.  On the iwd side we
>> default to replying with the same protocol version as the request, but
>> looks like ead does indeed hard-code 2004 as the version.
>>
> 
> In ead context I think there is not always something to reply to, the EAPPOL-Start message is sent unsolicited, so there is no request to look at to get the version. That may explain why it is hardcoded.

Yes, with WiFi it is a bit simpler because 95% of the time the AP sends 
us a RequestIdentity right away with a protocol version set.  So we just 
use that one.  However, there have been instances where even this 
strategy fails.  For example, Time Warner / Spectrum hotspots send a 
RequestIdentity with 2004 version, but refuse to process any packets 
unless they're sent with 2001 version.  We do send EAPOL-Start with 2001 
in iwd, but for some reason ead uses 2004.

<snip>

>> Yes, indeed it should.  I suspect the reason is that it sort of just
>> happened to work even when the operstate wasn't set properly, but this
>> should be fixed.
>>
> 
> I have second thoughts about this. At least in the switch I am playing with, it can be configured so that an unauthenticated supplicant is put into a guest VLAN and one which fails authentication into an auth-fail VLAN (but my guess is that this is pretty common functionality). If ead were to put the link into dormant state until authentication succeeded it would mean daemons that look at the link's running flag would not attempt to communicate before authentication succeeded (e.g., DHCP client), thus loosing the possibility to use the guest or auth-fail VLAN.

This area is tricky and not very well documented (on Linux and in 
general)  At least according to 
https://www.kernel.org/doc/Documentation/networking/operstates.txt, dhcp 
daemons expect the supplicant to take the interface out of dormant mode 
as a hint that DHCP requests can now be sent.  So ideally, 
EAP-RequestIdentity should trigger the interface going into OPER_DORMANT 
mode.  And EAP-Success should trigger it going into OPER_UP.

But, the complication is that there are implementations that send 
RequestIdentity / reply to EAPoL-Start only after the initial DHCP 
Discover has been sent out.  This is a big reason why we think it makes 
sense to put dhcp right into ead eventually.

I suspect ead will need to try to auto-detect (or have the user 
configure) if this 'guest-vlan' type scenario is supported.  And if it 
isn't, leave the interface in OPER_DORMANT state.

Regards,
-Denis

RE: Compatibility problems with wired 802.1x

[Diego Santa Cruz]

[-- Attachment #1: Type: text/plain, Size: 3356 bytes --]

Hi Denis,

> From: Denis Kenzior <denkenz@gmail.com>
> Sent: 25 April 2020 04:49
> To: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>; iwd(a)lists.01.org
> Subject: Re: Compatibility problems with wired 802.1x
> 
> Hi Diego,
> 
> On 4/27/20 4:52 AM, Diego Santa Cruz wrote:
> > Hi,
> >
> > I have been attempting to use ead do wired 802.1x authentication and I
> > am having problems with an HP V1910-48G switch (admittedly an old
> switch).
> >
> > The problem I see is that the switch never responds to the EAPOL packets
> > sent by ead. Investigating I saw that the protocol version in the EAPOL
> > packets sent by ead is set to 802.1X-2004 (2) but in the unsolicited
> > packets the switch sends it is set to 802.1X-2001 (1).
> 
> Hmm, its been a while since I looked into ead.  On the iwd side we
> default to replying with the same protocol version as the request, but
> looks like ead does indeed hard-code 2004 as the version.
> 

In ead context I think there is not always something to reply to, the EAPPOL-Start message is sent unsolicited, so there is no request to look at to get the version. That may explain why it is hardcoded.

> >
> > I am new to 802.1X but I went through the specs and as I understand the
> > switch should respond even if it receives an EAPOL version higher that
> > what it uses, but this switch does not.
> >
> 
> Yes, it should.
> 
> > Looking through the ead sources I think the new 802.1X-2004 features are
> > not used, so I went ahead and changed ead to send 802.1X-2001 (1) in its
> > packets, and voilà it now works!
> >
> > Is there any reason that the packets sent by ead use version
> > 802.1X-2004? If not I can send a patch to change it to always use
> > 802.1X-2001. I suspect it is safer to use the older version of the
> > standard, as switches implementing 802.1X-2004 surely work with 802.1X-
> 2001.
> 
> There's really no particular reason.  And I pretty much concur that
> using 2001 is likely the safest choice for compatibility /
> interoperability reasons.  If you want to send a patch, I can take it in.

Good, I'll send a patch shortly.

> 
> >
> > Also, I see ead does not manipulate the link state and mode of the
> > interface, I would have expected it to put the interface into dormant
> > mode and the link state changed between up and dormant depending on
> the
> > authenticated state (like iwd does for WLAN links). Is there any reason
> > for this? I guess one could be the support of guest or auth-fail VLANs
> > in some switches.
> >
> 
> Yes, indeed it should.  I suspect the reason is that it sort of just
> happened to work even when the operstate wasn't set properly, but this
> should be fixed.
> 

I have second thoughts about this. At least in the switch I am playing with, it can be configured so that an unauthenticated supplicant is put into a guest VLAN and one which fails authentication into an auth-fail VLAN (but my guess is that this is pretty common functionality). If ead were to put the link into dormant state until authentication succeeded it would mean daemons that look at the link's running flag would not attempt to communicate before authentication succeeded (e.g., DHCP client), thus loosing the possibility to use the guest or auth-fail VLAN.

Best,
Diego
 
> Regards,
> -Denis

Re: Compatibility problems with wired 802.1x

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 2212 bytes --]

Hi Diego,

On 4/27/20 4:52 AM, Diego Santa Cruz wrote:
> Hi,
> 
> I have been attempting to use ead do wired 802.1x authentication and I 
> am having problems with an HP V1910-48G switch (admittedly an old switch).
> 
> The problem I see is that the switch never responds to the EAPOL packets 
> sent by ead. Investigating I saw that the protocol version in the EAPOL 
> packets sent by ead is set to 802.1X-2004 (2) but in the unsolicited 
> packets the switch sends it is set to 802.1X-2001 (1).

Hmm, its been a while since I looked into ead.  On the iwd side we 
default to replying with the same protocol version as the request, but 
looks like ead does indeed hard-code 2004 as the version.

> 
> I am new to 802.1X but I went through the specs and as I understand the 
> switch should respond even if it receives an EAPOL version higher that 
> what it uses, but this switch does not.
> 

Yes, it should.

> Looking through the ead sources I think the new 802.1X-2004 features are 
> not used, so I went ahead and changed ead to send 802.1X-2001 (1) in its 
> packets, and voilà it now works!
> 
> Is there any reason that the packets sent by ead use version 
> 802.1X-2004? If not I can send a patch to change it to always use 
> 802.1X-2001. I suspect it is safer to use the older version of the 
> standard, as switches implementing 802.1X-2004 surely work with 802.1X-2001.

There's really no particular reason.  And I pretty much concur that 
using 2001 is likely the safest choice for compatibility / 
interoperability reasons.  If you want to send a patch, I can take it in.

> 
> Also, I see ead does not manipulate the link state and mode of the 
> interface, I would have expected it to put the interface into dormant 
> mode and the link state changed between up and dormant depending on the 
> authenticated state (like iwd does for WLAN links). Is there any reason 
> for this? I guess one could be the support of guest or auth-fail VLANs 
> in some switches.
> 

Yes, indeed it should.  I suspect the reason is that it sort of just 
happened to work even when the operstate wasn't set properly, but this 
should be fixed.

Regards,
-Denis