Bug 1698532 - [RFE] Provide auto-auth-retry option for 802.1x connection when connection fails
Summary: [RFE] Provide auto-auth-retry option for 802.1x connection when connection fails
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: NetworkManager
Version: 8.0
Hardware: x86_64
OS: Linux
Target Milestone: rc
: 8.2
Assignee: Beniamino Galvani
QA Contact: Desktop QE
Depends On:
Blocks: 1755139 1738635
TreeView+ depends on / blocked
Reported: 2019-04-10 14:25 UTC by Steffen Froemer
Modified: 2020-05-05 18:52 UTC (History)
15 users (show)

Fixed In Version: NetworkManager-1.22.0-0.1.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-04-28 16:52:36 UTC
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)
test script (3.47 KB, application/x-shellscript)
2019-09-17 20:27 UTC, Beniamino Galvani
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 5050891 0 None None None 2020-05-05 18:52:23 UTC
Red Hat Product Errata RHBA-2020:1847 0 None None None 2020-04-28 16:53:54 UTC

Description Steffen Froemer 2019-04-10 14:25:43 UTC
1. Proposed title of this feature request
[RFE] Provide auto-auth-retry option for 802.1x connection when connection fails

3. What is the nature and description of the request?
The 802.1x connection is used for network access control of clients. If the client is not able to authenticate, it will fall back to a 	limited-access network.
This could happen during infrastructure outage, where the authentication will fail and the limited-access connection chosen. If the infrastructure is back again, the client should automatically check if authentication is possible and upgrade to 802.1x authenticated connection

4. Why does the customer need this? (List the business requirements here)
To cover infrastructure outage and automatically re-authenticate

5. How would the customer like to achieve this? (List the functional requirements here)
If a client that has chosen a non 802.1x authenticated connection should continue to try authenticating and if possible upgrade to a 802.1x authenticated connection.

6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.

With following network configuration, the outage of RADIUS server should degrade the connection to 'lan_eth0' and when the RADIUS server is back online, the conenction 'lan_eth0_nac' will be used again without manual interaction.



    nmcli connection add \
        type ethernet \
        ifname $ifname \
        con-name lan_${ifname} \
        connection.autoconnect yes \
        connection.autoconnect-priority 0 \
        ipv4.method auto \
        ipv4.ignore-auto-dns yes \
        ipv4.may-fail yes \
        ipv4.never-default no \
        ipv6.method ignore \
        ipv6.may-fail yes 

    nmcli connection add \
        type ethernet \
        ifname $ifname \
        con-name lan_${ifname}_nac \
        connection.autoconnect yes \
        connection.autoconnect-priority 50 \
        ipv4.method auto \
        ipv4.ignore-auto-dns no \
        ipv4.may-fail yes \
        ipv4.never-default no \
        ipv6.method ignore \
        ipv6.may-fail yes \
        802-1x.identity "$(hostname -s)" \
        802-1x.eap tls \
        802-1x.ca-cert "/etc/wpa_supplicant/CA-Certs.pem" \
        802-1x.client-cert "/etc/wpa_supplicant/${FQDN}.crt" \
        802-1x.private-key "/etc/wpa_supplicant/${FQDN}.key" \
        802-1x.private-key-password-flags 4 \
        802-1x.auth-timeout 10 \
        connection.auth-retries 1

7. Is there already an existing RFE upstream or in Red Hat Bugzilla?

8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?

9. Is the sales team involved in this request and do they have any additional input?

10. List any affected packages or components.

11. Would the customer be able to assist in testing this functionality if implemented?

Comment 4 Steffen Froemer 2019-04-10 14:38:21 UTC
In best case, while the connection is upgraded, established connections should survive.

Comment 5 Beniamino Galvani 2019-04-15 09:20:19 UTC
Perhaps NM should implement a 802.1x.fallback-noauth option that allows to fall back to unauthenticated access when authentication fails. Windows has a similar option: https://social.technet.microsoft.com/Forums/getfile/1233569 . Related discussion: https://bugzilla.gnome.org/show_bug.cgi?id=723084

When the authentication fails, NM would keep retrying periodically to upgrade to an authenticated access.

Comment 6 Steffen Froemer 2019-04-17 14:18:32 UTC
Maybe an option would be, to build some junction between non-authorized, limited network connection and appropriate authenticated connection.
This might provide some more security, to only fall back to connections, which are wanted to use.

Just as an idea. Is there a way to get this discussion in [1] to get more speed? I see it's very old and such feature is still not existing. Only the timeout was improved, which is totally related to this request.

[1]: https://bugzilla.gnome.org/show_bug.cgi?id=723084

Comment 8 Beniamino Galvani 2019-06-19 13:46:23 UTC

we are currently evaluating different approaches to implement this

In the first, a new 'optional' boolean property is added to the 802-1x
setting. When it is set to true, the failure of 802.1X doesn't cause a
connection failure. Instead, upon failure NM continues with activation
and keeps wpa_supplicant alive. If the supplicant is able to complete
authentication later, NM restarts DHCP to guarantee a fresh address is
obtained for the authenticated network. Since it makes sense to have
different firewall zones for authenticated and non-authenticated
networks we would probably need also a new '802-1x.fallback-zone'

In the second approach two profiles are defined, one for the
authenticated network and one for the unauthenticated one; the first
profile references the second one in the '802-1x.fallback-connection'
property. When the first connection fails to authenticate, NM swaps
the settings in the current ActiveConnection with the ones from the
second profile and reapplies them without tearing the device
down. When doing it, it also keeps the supplicant alive so that the
swap can done again later if the authentication succeeds.

These profile swaps are something new and they need core changes that
might not be trivial to implement. The advantage of this second
approach is that it becomes possible to define different settings
(like the firewall zone, or IP configuration) for the two
connections. But perhaps from a user point of view it is simpler to
just set an 802-1x.optional=yes flag instead of defining two profiles.

I will update you when there are news regarding the development of
this feature.

Comment 9 Steffen Froemer 2019-06-19 14:14:46 UTC

this sounds really interesting. I looking forward to get some news.


Comment 11 Beniamino Galvani 2019-07-12 14:51:35 UTC

in the support cases attached to this bz, the customer mentions that
running wpa_supplicant alone without NM on the interface lets the
client connect to network even if the authentication server is
temporarily down, as the client is put in a limited-access network.

I have a few questions regarding this setup. Does the limited-access
network use a different DHCP server than the authenticated one? If so,
what happens after the infrastructure is restored, does the client
have to wait the lease expiration to get a valid address in the
authenticated network?

Also, how does the switch completes authentication when the
authentication server is not available? I tried this locally and I see
the switch performs 3 authentication attempts, each returning a
failure, and afterwards it sends an EAP-success, putting the client
into a separate VLAN. But since I couldn't find any documentation in
standards about this behavior, I'm wondering if it is implemented in
the same way by all vendors.

Would it be possible to ask the customer to provide a packet capture
of the authentication and DHCP phases when using wpa_supplicant alone
during the outage? And, if possible, also a capture of what happens
when the infrastructure comes up again.


Comment 13 Steffen Froemer 2019-08-12 07:35:04 UTC
Hey Beniamino,

I've talked with my customer, and beside the questions from your side totally make sense, they are not applicable to their environment.
If the client is unauthenticated, it's basically impossible to do anything. The connection is limited to a few basic protocols like DHCP, ICMP and DNS. Anything else is blocked by infrastructure (switch).
If there is an outage of Authentication service, e.g. RADIUS, it will be out of scope. The only thing, which matter is if 802.1x available, NetworkManager should try to authenticate. If there is nothing like this available, stay at "fallback"-connection and try to authenticate from time to time.

Does it make sense?


Comment 14 Beniamino Galvani 2019-08-26 14:00:53 UTC
Hi Steffen,

I have prepared a RFC branch [1] that adds a new 'optional' property
to the 802-1x setting. When it is set to TRUE, NM will not fail the
activation upon authentication timeout or failure, and will instead
continue, leaving wpa_supplicant running. wpa_supplicant tries to 
reauthenticate every 60 seconds.

I think should address the customer's needs, please let me know

[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/249

Comment 20 Beniamino Galvani 2019-09-17 20:27:20 UTC
Created attachment 1615997 [details]
test script

Comment 34 Dennis Schridde 2019-11-20 09:08:35 UTC
Is see that this is Fixed In Version: NetworkManager-1.22.0-0.1.el8.  Will the fix become available in Fedora 31, too?

Comment 35 Beniamino Galvani 2019-11-20 10:08:52 UTC
(In reply to Dennis Schridde from comment #34)
> Is see that this is Fixed In Version: NetworkManager-1.22.0-0.1.el8.  Will
> the fix become available in Fedora 31, too?

Yes, it is already in F31 (NetworkManager-1.20.6-1.fc31).

Comment 38 Beniamino Galvani 2019-12-12 16:24:48 UTC
Hi Vlad,

connection.auth-retries is the number of retries with a new password supplied by a secret agent. If there is no agent (i.e. no '--ask') the activation fails after the first attempt (after 20 seconds).

Ideally the reproducer for this RFE would be similar to the script attached to this bz. But if it is too complicated, we can check that when setting 802-1x.optional=yes and there is no authenticator, the connection is established after the timeout period.

Comment 39 Vladimir Benes 2020-01-08 16:11:13 UTC
test @8021x_auto_auth_retry_with_backup_network added

Comment 41 errata-xmlrpc 2020-04-28 16:52:36 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.