This entry in our Cisco ISE blog series expands on the previous entry, Authenticate all the things! Some of the vernacular we established in that entry will be repeated here, but not explained. So, if you haven’t had a chance to read that one yet, go ahead, we’ll wait right here for you! In this entry, we take a closer look at the EAP authentication types we see most commonly deployed as a part of a Wired and Wireless network 802.1X deployment.
EAP Authentication Identities
As suggested by the previous blog, Authenticate all the things!, an endpoint provides its network access credential to the authentication server (by way of the authenticator) in order to authenticate itself to the network. The type of authentication credential presented will depend upon the configuration of the supplicant software running on the endpoint device. Some of the configuration parameters implemented on the supplicant define the EAP authentication type for a given network adapter (the network adapter could be wired or wireless). In order to provide useful implementation details, the scope of this blog is limited to the most common EAP types deployed on the most common endpoint OS used by our customers, Microsoft Windows.
Microsoft Windows OS is unique (in a good way!) in regards to how they have chosen to implement their 802.1X identities. Unlike any other operating system, Microsoft Windows provides the ability to use a unique authentication credential for the machine (when no user is logged into Windows) and a separate, user specific authentication credential for the user who is logged into Windows.
This is excellent for a few reasons.
Number One!
A logged-out Windows OS does not need the same access to the network that a user logged-in to the Windows OS does. A logged-out Windows OS typically only requires access to a handful of Active Directory domain services in order to receive GPO settings/updates and to process user logins to the domain. On the other hand, a logged-in user of Windows will need that and much, much more. With separate machine and user credentials we have an inherent ability to make a distinction between a logged-in user’s network session versus a logged-out machines network session and provide the appropriate (principle of least privilege) access to the network!
Number Two!
Since the Windows OS machine account is able to access the network and connect to Active Directory domain services even before a user logs in, this means that when a user logs in, they will be able to process their login against the domain controllers (instead of cached account) and user level GPO settings/updates can be applied.
Number Three!
As every user login/authentication to the network is preceded by a computer login/authentication to the network. This introduces the ability for network administrators to write a network access security policy that requiring that users are only granted access to the network if, and only if, they are logging in from a domain-joined computer that has previously logged-in (successfully) to the network! More on the mechanics of this later.
Selecting an EAP Type
This is not an exhaustive list of EAP types for Microsoft Windows, but what follows will be on the short list for your deployment. The big question to ponder is what type of authentication credential do you want to use in your deployment; certificate based or username/password based? Certificates credentials are more secure than usernames/password credentials (these are still secure, but not as secure). Usernames/password credentials are much easier to implement and maintain than certificate credentials. If you don’t already have an PKI system deployed, your barrier to entry for 802.1X is higher for certificate based vs. username/password-based credentials. In the end your organization will determine if you value better security or simplified operations more when making this decision. Here is the decision tree and the resulting EAP type!
These EAP types, EAP-TLS and MSCHAP-V2, are referred to as inner EAP types or tunneled EAP types. As this implies, there are outer EAP types that can tunnel these inner EAP types. Why would I want to put an EAP tunnel around my inner EAP credential? Security - got to have it. Give me more, give me more. In the case of EAP-TLS, the outer EAP tunnel can be considered optional due to the strong cryptographic technologies it employs, however, many high security environments still add the extra EAP tunnel layer for extra protection. For MSCHAP-V2, older cryptographic technologies are used and as such all EAP deployments use an outer EAP tunnel with a strong cryptographic posture to delivery the MSCHAP-V2 credentials safely to their destination (the authentication server). Outer EAP tunnels can even be used to pass completely unencrypted inner EAP credentials securely to the authentication server. As a best practice, we recommend the use of an outer EAP tunnel regardless of your decision to use EAP-TLS or MSCHAP-V2.
The EAP Tunnel
As it currently stands, there is only one industry standard EAP tunnel type implemented by the native 802.1X supplicant software embedded with the major operating systems; Protected EAP or PEAP. With PEAP, the outer EAP tunnel is encrypted using TLS by way of the authentication server certificate. You can think of this secure tunnel being established in much the same way that your secure tunnel is established to your online banking website. When you connect to your banks website, the website presents its security certificate, if your browser trusts the issuer of the bank website certificate, an encrypted tunnel to the website is established and you continue onto enter your credentials. In this analogy, the credentials you enter into your bank website are analogous to the inner EAP credentials in 802.1X. The major takeaway here is that even if you choose to deploy MSCHAP-V2 with usernames/passwords, you’ll still have at least one certificate that needs to be issued to the authentication server that all of your EAP supplicants trust.
Non-Native Supplicants
As mentioned above, PEAP is the only industry standard EAP tunnel type implemented with the native 802.1X supplicant from major operating system vendors, however there is another proprietary option out there in the form of EAP-FAST. I typically nudge my clients away from making use of EAP-FAST, not because of what it brings to the table as an EAP technology (IMHO, it is the most capable EAP method), but because of the fact that it requires a non-native 802.1X supplicant software (AnyConnect Network Access Manager) that is required to be deployed in place of the operating systems native supplicant. This can present certain challenges for pre-provisioning the supplicant software (XML based configuration file needs to be pushed) vs. using the native supplicant on Windows which already has a central provisioning hook into your Active Directory domain’s GPO. A third-party supplicant also presents unique challenges when a need arises to update the supplicant software. If not meticulously considered, you may run into the old chicken and egg problem where your software delivery platform doesn’t have access to the endpoint and vice-versa to upgrade the supplicant because the upgrade process was initiated before the supplicant established a network connection. This problem is not present when using the native supplicants as they are always upgraded with a OS update or patch, which is inherently timed to coincide with an OS reboot. So why would anyone use a non-native supplicant? Because, we all want the Holy Grail.
The Holy Grail
The most common request we get from our enterprise customers when deploying 802.1X:
“We need to ensure that users only get (full) network access when logging in from a corporate issued, domain-joined PC.”
Although Microsoft did us a solid in this regard in the way that they separated the 802.1X identities of the computer and the user (see above) in Windows, they did not provide the mechanism for an 802.1X authentication server to determine that a Windows 802.1X user authentication request was coming from a Windows computer that had previous successful 802.1X login. Cisco solved this problem by implementing EAP-Chaining as part of their proprietary EAP-FAST method. Essentially what happens is a cookie/token is issued to the supplicant that represents the computers successful 802.1X login and that cookie/token is then included as a part of the users 802.1X authentication. Therefore, if a user presents their 802.1X credentials along with the token/cookie representing the computers successful 802.1X authentication, the authentication server (Cisco ISE) has definitive information that the holy grail condition has been satisfied. While there is a standardized version of EAP-FAST completed in the form of EAP-TEAP, major operating system vendors have yet to incorporate it into their native supplicants as of the time of this writing. So, that’s why some customers choose to deploy non-native 802.1X supplicant software even in light of some of the operational challenges they can present. There is another way, though not near as great, but can be a decent stop-gap measure if you want the holy grail without the administrative overhead/complexity of the non-native 802.1X supplicant. MAR!
Machine Access Restrictions (MAR)
If you are willing to live with all of the caveats that exist with MAR, it can be a good option to keep you on a native supplicant and be able to glue a user authentication to a previous machine authentication until a more appropriate solution (EAP-TEAP) is available in the native OS 802.1X supplicants. MAR is a Cisco proprietary solution (only works with Cisco ACS/Cisco ISE as the 802.1X authentication server) that stores a local cache of the Windows computer MAC addresses that have successfully authenticated 802.1X. This cache has a lifetime assigned to it (two hours by default) that can be administratively adjusted. When a user 802.1X authentication comes in, Cisco ISE compares the MAC address in the authentication requires for a match in the MAR cache. If a match exists, then we can validate that the login is coming from a previously authenticated Windows computer.
What’s Next?
In our next entry to this series, we’ll take a closer look provisioning your Windows OS native supplicants for the two EAP types discussed in this entry; EAP-TLS and EAP-MSCHAP-V2.
Written By: Dominic Zeni, LookingPoint Consulting Services SME - CCIE #26686
If you are interested in LookingPoint installing ISE into your network, feel free to contact us here!
