Bug 1129811 - [RFE] Implement 802.1x PEAP dual Machine and User Authentication
Summary: [RFE] Implement 802.1x PEAP dual Machine and User Authentication
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.2
Hardware: Unspecified
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Lubomir Rintel
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-13 17:39 UTC by Colin.Simpson
Modified: 2019-08-05 17:45 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Colin.Simpson 2014-08-13 17:39:00 UTC
RFE: Implement 802.1x PEAP dual Machine and User Authentication

A very common (even the recommended) method of implementing 802.1x authentication on corporate WiFi networks is to use PEAP requiring dual machine and user authentication. The machine authentication is often (for ease) via PEAP (EAP-MSCHAPv2) rather than EAP-TLS (which requires certs server setup (though Cisco says this can be used for Machine auth too)).

The reason for dual authentication is that it allows a company to ensure that to grant internal network access a device must be a company device and the user attempting to do so has a company account. 

We have made progress in understanding this. Though it's quite a cross component issue needing Active Directory, SSSD, WiFi and Network Manager.

The setup is commonly implemented with a Wireless controller authenticating via radius to Active Directory. Though I'm guessing this could be IPA.

From this thread:

http://community.arubanetworks.com/t5/ArubaOS-and-Controllers/802-1x-Machine-and-User-Authentication/td-p/8886

and Cisco. 

http://www.cisco.com/en/US/products/sw/secursw/ps2086/products_user_guide_chapter09186a0080205a52.html#wp803832

Basically it seems to be that a Windows machine does a machine auth (when associating), and gets added to a table on the wireless controller if successful. A Windows machines then leaves the network and rejoins with user credentials when a user logs in. This second WiFi associated is allowed only if it's in the machine authenticated table (from first associate)

From the thread:

- Default-Machine-Role = Whatever you want a computer with no user
logged into it to have access to. I would suggest allowing communication
to the domain controller, DHCP, DNS, and the like so that when the user does log on, they can run scripts and the like.

- Default-Dot1x-Role = Role for domain devices with domain users

Each of these roles will likely dump you into a different VLAN, or have different firewall rules applied.

Machine Boot -> Machine Auth -> Default-Machine-Role (Limited Network Access, auth servers etc) -> User logs in -> Default-Dot1x-Role (Full Network Access). 

I don't believe this is Aruba specific, as this looks like a Windows client method.

We managed to figure out how machine authentication works. Basically it's pretty trivial, it just a standard PEAP MSCHAPv2 (everything else is automatic in Network Manager when we tried this) wireless auth with a username of "host/FQDN", where FQDN is the fully qualified domain name of the host on the AD domain (e.g laptop1.redhat.com would be hostname laptop1 on redhat.com AD domain).

So a typical Windows wireless session we believe will look like:

1/ Machine boots

2/ Perform machine authentication to WiFi. This is associate using PEAP to the wireless using username "host/FQDN" with the machines password.

3/ If this is successful, the machine's MAC address is added to a table on the WiFi controller as having passed Machine Auth. The device is then dumped into the "Default-Machine-Role" allowing access to authentication servers and other things needed for a LAN user login.

4/ The user then logs in. The limited role "Default-Machine-Role" allows enough to allow things like LDAP lookups, obtaining Kerberos credentials TGT etc.

5/ The machine then uses, the users credentials to reassociate to the WiFi controller . If successful, and the machine MAC for this associate session matches a MAC in the table of hosts that have passed machine authentication, the machine is switched to "Default-Dot1x-Role". 

6/ The user now has full network access.

The machine password is just the AD password for the machine object. This isn't directly obtainable from a Kerberos keytab from the AD join (that I know of) but you can force a change of it using Winbind (if using that is what you are using as your AD joining tool), using "net changesecretpw" but this doesn't update the AD side (probably doable in AD users and computers then use this command to sync them), haven't tried. 

It was easier for us as we use Quest Authentication Services and it allows this to be updated to a new random password and output it (/opt/quest/bin/vastool -q -u host/ passwd -r -o). I'd imagine SSSD can do this somehow....

Now on Windows the machine password is storred in the hidden registry key HKLM\SECURITY\Policy\Secrets\$machine.ACC, but it's easy to extract. But I'm guessing that this is already in a hashed MS-CHAPv2 compatible form so can be pumped straight out to do machine auth, without having to store this password plain text. But I'm guessing here.

Standard Windows computers update their machine password monthly for security reasons, not sure if SSSD does (it probably should), so this password is pretty dynamic.

Once we had the machine password the machine passes Machine Auth for us on the Wireless controller using Network Manager, manually entering the "host/FQDN" as the username and the password as discussed.

My knowledge of this was bootstrapped by this article on wired 802.1x authentication, they used likewise AD connector but it was easy to figure out. 

http://ubuntuforums.org/showthread.php?t=2141567

The tricky things are:

1/ Is it possible (in the future) to get Network Manager to use the machine authentication at boot time and then do (switch to) user authentication at login for the WiFi. I have thought of a way this might work, would be to use the standard ifcfg files to do the machine auth (which should apply when the machine boots) then get the users Network Manager session to switch to the users credentials for auth. 

The issue with this is that if a user turns on WiFi in session (not at boot) the machine auth will never be tried. The real solution would be to allow network manager to perform this dual auth. 

2/ Storing the machine password in plain text isn't ideal (in the ifcfg files for example). Maybe storing this as Windows does as a MS-CHAPv2 (on a machine password change) is a way to do this, but the WiFi supplicant will need a way to take in the hased form. If this is indeed how Windows does this?

3/ It would be nice if PAM could be persuaded to pass the users username and password for the user auth piece of this dual authentication.

4/ For AD connection software, most people I guess will be directed to (and should be using) SSSD. So SSSD needs to have a way of passing the updated machine password to the WiFi setup for machine authentication. This is assuming the SSSD updates the machine password regularly, as I say if it doesn't it probably should. The commercial Quest software we use has a hook to allow you to run commands on machine password refreshes.

5/ Is there anyway to fully script a connection in network manager? i.e one way to workaround this issue for us is to spawn a script that can perform machine auth piece. There are post connection scripts but can you do pre-connection scripts? So if you hit this network in NM, it would run the script, which would do machine auth, then the GUI piece could perform the user auth. 

6/ Have other people not asked about this or needed this is in a corporate environment? I'm a bit surprised about that... this may also become more urgent as companies are looking to use 802.1x on physical ports and not just WiFi. 

All the encryption types requires are already in RHEL, it's just the linkage to machine auth and automatically performing this dual auth that makes this an issue.

Comment 1 Colin.Simpson 2014-08-13 17:41:51 UTC
I originally submitted this as a Fedora bug #862326

Comment 3 Dmitri Pal 2014-08-14 10:16:45 UTC
Colin,

Thanks a lot for a research and deep dive. However there is a a bit of clarity that I am missing here. So please bear with me a bit.

= Which use cases we want to support? =

There are several items here:
a) User - is user an AD user or IdM user?
b) Machine is machine expected to be in AD domain, IPA domain, IPA domain that trusts AD, all of the above or you do not care and leave up to us to tell the recommended approach?
c) Do you expect user to authenticate using user name and password or you also expect user to authenticate with a cert? Do you expect user to get a TGT as a result (I suspect yes based on the comments above)?
d) Do you expect that VPN is a 3rd party VPN like Cisco or you expect it to be an open source one that Red Hat delivers?
e) Do you expect the VPN and RADIUS server behind it to be a part of IdM domain or AD domain?

As you can see this creates quite a massive combination of potential use cases so it would be nice to understand which ones are the primary ones.

= Comments about the request =

SSSD uses Keytab. This is its "password". It is not rotated. We have an RFE but so far but it is not implemented yet. There was no pressing need so far. While it is a policy in AD domain we have discussed this aspect with MIT Kerberos gurus and they are confident that Keytabs can live for extended period of time without rotation without security risk so it is sort of precaution rather than a hard security requirement to rotate them.
    
SSSD can have a cert provisioned to it to identify the host if it is joined into IPA domain so this can be used to do the machine level authentication.

= Plans =

We have plans to allow better certificate management in IPA to provision certs for different purposes and differentiate certs we issue for hosts, VPN, mobile, puppet and so on. This is in work happening upstream.

One of the ideas that we are going to promote is ability to transition from Kerberos to Certs and back. It is already possible using certificates to have a Kerberos authentication (pkinit). One of the ideas we have is:
- Machine gets online and connects to the network using its cert
- User is prompted for an authentication (hopefully 2FA)
- SSSD talks to IdM using Kerberos over internet and sends 2FA credential to it.
Here are MIT projects that made it possible that IdM is implementing:
http://k5wiki.kerberos.org/wiki/Projects/HTTP_Transport
(FAST OTP implementation did not have a special page)
http://k5wiki.kerberos.org/wiki/Projects/OTPOverRADIUS
- IdM authenticates user over internet and gives him TGT
- IdM returns in the ticket or client (SSSD) connects to a service using service ticket to get a short lived cert that matches the TGT lifetime (or can be scoped to be shorter). As a result a cert is delivered to the client.
- SSSD uses the cert for VPN authentication rather than user name and password. 

This setup allows for AD and IdM users coming from a Linux system joining the IdM domain. This is the primary use case we thinks is worth addressing. However your answer to the questions below might augment this vision.

Thanks
Dmitri

Comment 4 Dmitri Pal 2014-08-14 10:19:34 UTC
And I forgot one more question: are we talking about a Linux machine or windows or something else?

We also have some interesting ideas about mobile devices, i.e how to get them on the network in a secure but manageable way. We have a POC for that.

Comment 5 Colin.Simpson 2014-08-14 13:50:38 UTC
Hopefully I can answer these...

= Which use cases we want to support? =

> There are several items here:
> a) User - is user an AD user or IdM user?

Okay the issue here is that this is a standard 802.1x mechanism for authenticating access to the network layer.

The deployment is usually AD <-> RADIUS <-> WiFi Controller <-> Client machine, so that will be what is in the field. But I'd guess there is no reason the backend of the RADIUS shouldn't be IdM (this is the new name for IPA server?). Allowing this dual authentication (or even just user authentication alone) to be via IPA. 

The basic deal is that all that has to happen is that for the user authentication piece to succeed is that the user needs to successfully authenticate using RADIUS (via the WiFi Controller). The backend authenticator is immaterial (IPA or AD or anything). 

> b) Machine is machine expected to be in AD domain, IPA domain, IPA domain    
> that trusts AD, all of the above or you do not care and leave up to us to 
> tell the recommended approach?

All of the above should work I'd guess with suitable trusts that RADIUS can see. Remember this interaction is purely happening in RADIUS to negotiate the network link layer (layer 2).

We only have AD here. But *THIS* RFE is purely a client issue, it doesn't need to know about the backend. As all interaction is layer 2 via a WiFi controller to the RADIUS (or some other authentication checker).

Like user authentication all that needs to happen for machine auth to succeed is that a username of "host/machinename.domain" with the machine's password as the password. Nothing comes back to the client in terms of a security token or anything. It just gains network connectivity.

c) Do you expect user to authenticate using user name and password or you also expect user to authenticate with a cert? Do you expect user to get a TGT as a result (I suspect yes based on the comments above)?

Nope, this is network connectivity, nothing else.

According to the CISCO document I linked it's possible to do machine authentication via certs (EAP-TLS) or via machine password (PEAPv0/EAP-MSCHAPv2). This isn't up to the client to choose though it's depends what was setup in the controller. 

We use PEAP (machine passwords) (strictly PEAPv0/EAP-MSCHAPv2)  . The reason we do (though wasn't up to me personally), and I think the reason the standard was written is that you don't need a PKI infrastructure (or certs for each client). You purely need server cert just to encrypt the interaction. Well so I remember reading somewhere....

The fact the machine password is used means you cannot perform a domain join on this network as you will not have a machine password to authenticate to the network link layer. 

You don't get a TGT out of this. The way a Windows client does this as maybe isn't clear from my original post. Once it passes machine authentication (at boot) to the WiFi (or 802.1x network) it gets dropped into a role (on the wireless controller) that allows access to the authentication and infrastructure services (DNS , DHCP etc) only. They then get an IP and can lookup auth servers etc. This then means when a user logs in they can get a TGT and look up stuff via LDAP etc etc. It's only then that a further network link layer negotiation happens (authentication via the users credentials (layer2)) to allow them access to the whole network. 

So the obtaining of TGT's and authentication is normal, as in no different from a non-802.1x network.

d) Do you expect that VPN is a 3rd party VPN like Cisco or you expect it to be an open source one that Red Hat delivers?

This is purely negotiating the network link, there is no VPN here.

e) Do you expect the VPN and RADIUS server behind it to be a part of IdM domain or AD domain?

Again no VPN. But basically as I said earlier. The RADIUS just needs to authenticate passwords whether person or machine ones. The client doesn't speak to radius it purely speaks to the WiFi controller. The controller speaks to radius (or some other auth system). This is invisible to the client.

To answer your latest question and basically summarize this. The point of this RFE is to replicate the Windows implementation of this standard (okay a standard worked out between MS and Cisco) but widely deployed....

RHEL has already all the necessary encryption and wireless authentication types necessary to implement this (the supplicant is fine). What is missing is a method of holding the machine's password somewhere that can be used automatically to pass the machine authentication and grabbing the users password (maybe via PAM) to pass the second stage, if using dual authentication. i.e the hard bit is already there.

Hopefully in WiFi expert in RH may know the details of this. It's not really a directory services issue but will probably need interaction with SSSD on the client side to make this clean.

The Wikipedia articles on these two may help:

http://en.wikipedia.org/wiki/IEEE_802.1X

http://en.wikipedia.org/wiki/Protected_Extensible_Authentication_Protocol

The good news is that there is a lot less to this than it looks, it's just the alphabet soup of this topic that makes it look complex....

Comment 6 Colin.Simpson 2014-09-09 11:05:15 UTC
What would help me in the short term (without a full solution) would be if someone could answer this question:

5/ Is there any way to fully script a connection in network manager? i.e one way to workaround this issue for us is to spawn a script that can perform machine auth piece. There are post connection scripts but can you do pre-connection scripts? So if you hit this network in NM, it would run the script, which would do machine auth, then the GUI piece could perform the user auth. 

Any thoughts on this?

Comment 8 David Halliwell 2015-10-28 18:21:10 UTC
We've hacked together a way to achieve this dual authentication.  It's pretty scrappy, but gets the job done.  Our method is documented here in case it's useful to anyone:  http://redirdevnull.blogspot.co.uk/

We use wpa_supplicant to perform the computer authentication when the system boots, and then NetworkManager takes over to do user authentication once the user has logged in.  Our machines are joined to AD using Dell's Quest software, so our scripts rely on Quest for things like grabbing the machine password.  I imagine this would be possible using sssd, but I haven't explored how.


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