GNOME Bugzilla – Bug 723084
Wired 802.1x: add option to make 802.1x optional [patch included]
Last modified: 2020-11-12 14:28:16 UTC
Hi everyone, If Network Manager (NM) is configured to use 802.1x for an Ethernet connection but the Ethernet port of the machine is not configured for 802.1x, then establishing the connection fails currently. This is a great default from a security perspective but in some scenarios a hindrance or even unwanted. Road warrior scenario: A company that provides laptops for their users and uses 802.1x to secure their Ethernet connections would require to setup and explain two connection profiles to their users. They need a 802.1x-enabled connection profile that users have to use within the company. They need a non-802.1x connection profile that users have to use outside of the company. Network Access Control (NAC) scenario: A company can use 802.1x to secure their Ethernet connections depending on various data - for an instance the health status - collected of a machine. If something is wrong with a machine, access to the network can be denied. If network access is denied there is usually a need to remediate a machine from this state and this often requires network access - for an instance to install required updates. So often the NAC implementation allows unauthenticated access to a remediation network but for this 802.1x needs to be disabled. This has also been discussed on the Network Manager mailing list: https://mail.gnome.org/archives/networkmanager-list/2013-August/msg00085.html The attached patch introduces the 802.1x 'optional' option which allows to make 802.1x optional for Ethernet connections. The default value of 'optional' is false which represents the current NM behavior. If 'optional' is set to true NM tries first 802.1x for each connection attempt and if the 802.1x auth fails it retries stage 2 without the 802.1x configuration. In the road warrior scenario only one connection profile would be needed as 802.1x is tried by default and if it fails (non-corp) it falls back to a non-802.1x connection. In the NAC scenario a machine that got network access denied would be able to connect automatically to a remediation network. In my tests it took about 30 seconds to get a network connection if I tried to use a 802.1x-enabled connection profile with 'optional=1' on a non-802.1x Ethernet port. The 30 seconds are mainly because of the 25 second timeout in supplicant_interface_init of nm-device-ethernet.c. Please let me know what you think of this patch. Best, Michael Schaller
Created attachment 267285 [details] [review] nm-802-1x-optional.patch
Just realized that I've cc'ed the wrong Dan. Sorry Dan Williams. Welcome Dan Winship.
Friendly ping.
(In reply to comment #3) > Friendly ping. All of the NM developers are really busy with work-related (ie, RHEL) bugs right now. This bug will get looked at when we have more time to work on upstream bugs, but I can't say for sure when that will be.
Dan, first of all thank you for the reply and the explanation. Do you have by chance a rough ETA when things will calm down?
Thanks for the patch! A couple comments: I'm hesitant to go with this specific solution, because it means that the profile that specifies 802.1x could be connected without actually using 802.1x, and clients that might depend on that would now assume that the network was secure when it really wasn't. Furthermore, the wrong firewall rules could be applied when connected to an unprotected network. Is the contention that it's confusing for users to have two ethernet profiles, one for eg "Google-secure" and one for "insecure"? I do see the argument there, but assuming they are named well enough, it might be useful for users to see they are on two networks, and we also have the ability to set firewall zones independently for each of the two networks. Would the following proposal be acceptable instead? 1) add the ability to sniff for 802.1x Identity EAP-Request packets on the wire to detect when you're connected to an 802.1x network. This would only be enabled when there were 802.1x connection profiles defined, to ensure that users without 802.1x didn't take the sniffing delay. We want this functionality *anyway* for the ability to auto-detect which wired network you're connected to when you plug in the cable (opt-in of course) based on ARP or seen MAC addresses. 2) if NM saw 802.1x Identity EAP-Request packets (either directly or in response to an NM-initiated EAPOL-Start packet), NM would try the 802.1x connection. If NM didn't, NM would not try the 802.1x connection (unless it was higher priority) but would fall back to a normal unsecured connection, suitable for the remediation network. What do you think?
Hi Dan, First of all thank you for replying. ^^ Let me first answer to your comments: Regarding clients relying on 802.1x to ensure that there is an authenticated connection: We also have this concern and that is why the patch uses as default value 'false' for the 'optional' option. With this default value someone has to make the conscious decision to make 802.1x optional for a specific connection config. Regarding firewall rules: Yes, this is a valid point. We had no differing firewall rules between 802.1x and non-802.1x connections in mind. I could see that some people might want this... :-/ Regarding your proposal: First of all this sounds very interesting! But I'm also still unsure how that should exactly work. To my knowledge an 802.1x auth has to be tried to actually know if a port is secured via 802.1x. So would NM just send an EAPOL-Start frame and wait a specific timeout before it determines if a 802.1x or non-802.1x connection config has to be applied? How would that work with WPA supplicant? Do all switches handle one EAPOL-Start frames from NM and another one from WPA supplicant gracefully? Also please do tell me more about connection config priorities. So far I don't know of any priorities. Is this a planned feature? If so do you have a bug number for me? Lastly this proposal might lack one point that is very important to us. The current patch to make 802.1x optional always tries 802.1x first and if it fails for whatever reason it tries again without the 802.1x part of the config. This is important to us as we use it as a fallback in case the 802.1x part of the config is invalid. One case we are worried about in which the 802.1x part of the config is invalid is when the client cert got revoked or expired. In this case a machine would try 802.1x, fail and then retry without 802.1x and the switch would put the machine on a remediation VLAN where the owner of the machine can request a new client cert. Would this specific scenario work with your proposal and connection config priorities?
(In reply to comment #7) > Hi Dan, > > First of all thank you for replying. ^^ > Let me first answer to your comments: > > Regarding clients relying on 802.1x to ensure that there is an authenticated > connection: > We also have this concern and that is why the patch uses as default value > 'false' for the 'optional' option. With this default value someone has to make > the conscious decision to make 802.1x optional for a specific connection > config. > > > Regarding firewall rules: > Yes, this is a valid point. We had no differing firewall rules between 802.1x > and non-802.1x connections in mind. I could see that some people might want > this... :-/ It's not just about firewall rules though; it's about things like file sharing or chat programs or really anything that might want to know that a connection is authenticated. The way it currently is, those client apps can watch for the connection UUID and be confident that if that connection is activated, they are on a "trusted" network. If the 'optional' property were implemented, this wouldn't be possible without more fully inspecting the connection attributes, which, while possible, is a lot more code for clients to care about. > Regarding your proposal: > First of all this sounds very interesting! > > But I'm also still unsure how that should exactly work. To my knowledge an > 802.1x auth has to be tried to actually know if a port is secured via 802.1x. > So would NM just send an EAPOL-Start frame and wait a specific timeout before > it determines if a 802.1x or non-802.1x connection config has to be applied? Either the switch must initiate the EAPOL exchange when it senses a link, in which case we know that we can use 802.1x, or the client (ie, NetworkManager) must initiate the exchange, and if we get a timely reply (which is almost always immediate) we know we're using 802.1x. In both cases, we know pretty quickly that we're able to use 802.1x and what the MAC address of the authenticator (ie, the switch) is. Which we can then use to pick an 802.1x connection to start. > How would that work with WPA supplicant? Do all switches handle one EAPOL-Start > frames from NM and another one from WPA supplicant gracefully? For now, NM would construct the EAP frame itself and send that without the supplicant being involved, since it's about as easy as an ARP. If the switch ignored frames from the client, then we would expect the switch to initiate the EAP session, otherwise there wouldn't be any way to do 802.1x with the switch! (or, the switch isn't configured for 802.1x, and thus we time out and fall back to a non-802.1x connection). > Also please do tell me more about connection config priorities. So far I don't > know of any priorities. Is this a planned feature? If so do you have a bug > number for me? Yes, it's a planned feature that we're in the process of discussing here: https://bugzilla.gnome.org/show_bug.cgi?id=580018 > Lastly this proposal might lack one point that is very important to us. The > current patch to make 802.1x optional always tries 802.1x first and if it fails > for whatever reason it tries again without the 802.1x part of the config. This > is important to us as we use it as a fallback in case the 802.1x part of the > config is invalid. One case we are worried about in which the 802.1x part of > the config is invalid is when the client cert got revoked or expired. In this > case a machine would try 802.1x, fail and then retry without 802.1x and the > switch would put the machine on a remediation VLAN where the owner of the > machine can request a new client cert. > > Would this specific scenario work with your proposal and connection config > priorities? You bring up a good point and we should make sure this will still work. I believe it would, and the machine would be set up as such: 1) Two connections would be defined: one for 802.1x and one for unauthenticated 2) The 802.1x connection is assigned a higher priority, and thus it always gets tried first (this part not yet implemented) 3) The EAPOL probing (and/or the priority) would obviously start 802.1x first 4) The 802.1x connection would fail and be retried once or twice before NetworkManager decides to fall back to other connections as the 802.1x connection has failed multiple times. This should happen fairly quickly. 5) The unauthenticated connection would then be tried, and it would succeed, and the process would stop Does that sound OK? There's obviously room to optimize this process too, once the code is in rough shape. I'd love to spend help map out a more concrete plan here, if you're still up for doing some more patches? Thanks!
(In reply to comment #8) Sorry for the delay with my answer. > It's not just about firewall rules though; it's about things like file sharing > or chat programs or really anything that might want to know that a connection > is authenticated. The way it currently is, those client apps can watch for the > connection UUID and be confident that if that connection is activated, they are > on a "trusted" network. If the 'optional' property were implemented, this > wouldn't be possible without more fully inspecting the connection attributes, > which, while possible, is a lot more code for clients to care about. > I absolutely agree. Out of curiosity... Do you know of any programs/tools that actually do something like this and for what they use the data? > Either the switch must initiate the EAPOL exchange when it senses a link, in > which case we know that we can use 802.1x, or the client (ie, NetworkManager) > must initiate the exchange, and if we get a timely reply (which is almost > always immediate) we know we're using 802.1x. In both cases, we know pretty > quickly that we're able to use 802.1x and what the MAC address of the > authenticator (ie, the switch) is. Which we can then use to pick an 802.1x > connection to start. > What do you have in mind regarding picking a connection based on the MAC address? I'm wondering how the MAC address is helpful for this as in bigger buildings there will be several 802.1x protected switches and so depending on where someone connects the MAC address will differ but the connection config won't. > For now, NM would construct the EAP frame itself and send that without the > supplicant being involved, since it's about as easy as an ARP. If the switch > ignored frames from the client, then we would expect the switch to initiate the > EAP session, otherwise there wouldn't be any way to do 802.1x with the switch! > (or, the switch isn't configured for 802.1x, and thus we time out and fall back > to a non-802.1x connection). > I guess this should be fine as in reality frames could get lost and would be retransmitted. Switches would need to be able to handle the case of multiple start frames anyway. ;-) > Yes, it's a planned feature that we're in the process of discussing here: > > https://bugzilla.gnome.org/show_bug.cgi?id=580018 > Thanks. Very interesting! > You bring up a good point and we should make sure this will still work. I > believe it would, and the machine would be set up as such: > > 1) Two connections would be defined: one for 802.1x and one for unauthenticated > > 2) The 802.1x connection is assigned a higher priority, and thus it always gets > tried first (this part not yet implemented) > > 3) The EAPOL probing (and/or the priority) would obviously start 802.1x first > How many milliseconds would you use as timeout? > 4) The 802.1x connection would fail and be retried once or twice before > NetworkManager decides to fall back to other connections as the 802.1x > connection has failed multiple times. This should happen fairly quickly. > I doubt that this would happen quickly as NM and WPAs don't talk very well with each other and so NM usually relies on its pesky WPAs timeout of 25 seconds to determine if WPAs failed. (nm-device-ethernet.c: priv->supplicant.con_timeout_id = g_timeout_add_seconds (25, supplicant_connection_timeout_cb, self);) I guess it would be a lot better and faster if NM would use WPAs's DisconnectReason: http://hostap.epitest.fi/cgit/hostap/commit/wpa_supplicant/dbus/dbus_new.c?id=0bb1e425b553f05adbc9df9e7ff92c0284e7e8f6 > 5) The unauthenticated connection would then be tried, and it would succeed, > and the process would stop > > Does that sound OK? There's obviously room to optimize this process too, once > the code is in rough shape. I'd love to spend help map out a more concrete > plan here, if you're still up for doing some more patches? > This sounds like a very good and also straightforward proposal. I would like to send patches but my concern is bug #580018 as it needs to be resolved beforehand. Unfortunately it seems this bug is in an early state and there is no concrete plan yet on how to implement connection priorities... What do you think about the state of bug #580018? > Thanks! Thanks to you too for discussing this. ^^
(In reply to comment #9) > (In reply to comment #8) > > Either the switch must initiate the EAPOL exchange when it senses a link, in > > which case we know that we can use 802.1x, or the client (ie, NetworkManager) > > must initiate the exchange, and if we get a timely reply (which is almost > > always immediate) we know we're using 802.1x. In both cases, we know pretty > > quickly that we're able to use 802.1x and what the MAC address of the > > authenticator (ie, the switch) is. Which we can then use to pick an 802.1x > > connection to start. > > > What do you have in mind regarding picking a connection based on the MAC > address? I'm wondering how the MAC address is helpful for this as in bigger > buildings there will be several 802.1x protected switches and so depending on > where someone connects the MAC address will differ but the connection config > won't. I'd envision it as a list of MAC addresses which could be populated by either the administrator or which could be added to automatically if the 802.1x authentication succeeds. An additional approach could be to always start an 802.1x exchange with PEAP/TLS/TTLS and retrieve the certificate, which we could then match to an existing 802.1x connection. > > You bring up a good point and we should make sure this will still work. I > > believe it would, and the machine would be set up as such: > > > > 1) Two connections would be defined: one for 802.1x and one for unauthenticated > > > > 2) The 802.1x connection is assigned a higher priority, and thus it always gets > > tried first (this part not yet implemented) > > > > 3) The EAPOL probing (and/or the priority) would obviously start 802.1x first > > > How many milliseconds would you use as timeout? I think I'd start with 500 or 1000, but I really don't have a good idea. We'd have to do some experiments, and when we get to that point your input would be very helpful! > > 4) The 802.1x connection would fail and be retried once or twice before > > NetworkManager decides to fall back to other connections as the 802.1x > > connection has failed multiple times. This should happen fairly quickly. > > > I doubt that this would happen quickly as NM and WPAs don't talk very well with > each other and so NM usually relies on its pesky WPAs timeout of 25 seconds to > determine if WPAs failed. > (nm-device-ethernet.c: priv->supplicant.con_timeout_id = g_timeout_add_seconds > (25, supplicant_connection_timeout_cb, self);) > > I guess it would be a lot better and faster if NM would use WPAs's > DisconnectReason: > http://hostap.epitest.fi/cgit/hostap/commit/wpa_supplicant/dbus/dbus_new.c?id=0bb1e425b553f05adbc9df9e7ff92c0284e7e8f6 Yes, NM already reads that value but doesn't do anything with it right now, besides logging it. However, it looks like that property is only relevant for WiFi. What might be more relevant here is the "EAP" signal, which includes some status and parameters. I haven't looked into that in much detail, but we could also use this to determine hard EAP failures (like CA certificate validation failures, stuff like that) long before 25s. > > 5) The unauthenticated connection would then be tried, and it would succeed, > > and the process would stop > > > > Does that sound OK? There's obviously room to optimize this process too, once > > the code is in rough shape. I'd love to spend help map out a more concrete > > plan here, if you're still up for doing some more patches? > > > This sounds like a very good and also straightforward proposal. I would like to > send patches but my concern is bug #580018 as it needs to be resolved > beforehand. Unfortunately it seems this bug is in an early state and there is > no concrete plan yet on how to implement connection priorities... What do you > think about the state of bug #580018? I or somebody will start working on it quite soon, so we should certainly start having a discussion about what things we're all looking for out of it.
Bug 580018 is done; what next? We are also looking at 802.1x wired auth, and having NM *try* 802.1x and fall back to non-authenticated without manual intervention is going to be quite important for client usability. The current mode of "if you can't authenticate {to,} the network then don't connect" might have uses in esoteric cases for secure servers, but not for most NetworkManager users I suspect.
Has this progressed after 2014? I am currently testing 802.1x in our wired network. We have a large environment with Windows, OS X and Linux computers and many of them are laptops that are also used outside our premises. Currently we have a working configuration for the managed Windows and OS X clients so that they will transparently authenticate to our network (using stored credentials) but will also work in networks without authentication (hotels etc). I have not succeeded in this using NetworkManager on Linux. This is actually a major usability issue in our environment. I tried stacking configuration profiles with autoconnect using the priority from bug 580018 mentioned here, but having to wait through several 25sec timeouts to connect to any wired network that is not using 802.1x is not usable in production.
I have pushed some commits to branch bg/802-1x-auth-timeout to make the authentication timeout configurable and better handle the autoconnect-retries property. With these changes it is possible now to have a short fallback interval between the 802.1x and the non-authenticated connection. Please review.
lgtm. Pushed two commits.
Branch bg/802-1x-auth-timeout rebased on current master.
branch lgtm.
LGTM
Merged to master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=7e79e913ad11e2c9247e840cd5cc5b2eccce25ab
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).