Chapter 3

Authentication Methods

Abstract

This chapter provides an overview of the different options available for authenticating users/endpoints in ISE as well as pros/cons and important considerations for each different method. Each method also includes a step-by-step description of the process to aid in troubleshooting and give readers a clearer understanding of what ISE is doing.

Keywords

authentication

MAB

802.1x

EAP

CWA

While configuring and designing your environment it’s important to keep in mind that there are a few different authentication methodologies you’re going to be using. Each of these methodologies have advantages and disadvantages and are useful in different scenarios depending on the specific functionality you’re trying to achieve.

As we go through these please do take note that all of these methodologies are agnostic of the physical media that they could potentially be running on. This means that in these cases they may be either wired or wireless-type authentication methodologies. Also, the authentication communications generally happen between the client and the ISE policy node. The network access device (NAD; e.g. switch or Wireless LAN Controller (WLC) or Adaptive Security Appliance (ASA)) is participating in the communication in that it will transmit data back and forth, but it isn’t necessarily an active participant and may have limited knowledge as to what is happening between the client and the server, especially if the traffic is encrypted as part of the security design.

The most basic authentication methodology that is used in ISE is MAC Authentication Bypass (MAB). Before MAB was available, when you wanted to configure your network for 802.1x authentication, you had very limited options in allowing an intelligent way to authenticate devices that did not support 802.1x authentication, like printers, and other noninteractive devices. The most popular and effective method was to not configure authentication on switchports that were connected to devices that didn’t support authentication. Sometimes, VLAN access control list (VACL)-type MAC filtering provided some additional security, but it was hardly robust and didn’t provide easy centralized logging or authorization.

MAB was a feature originally developed by Cisco in order to provide network administrators the ability to authenticate devices just with their MAC address to resolve this issue. You could then create a list of MAC addresses you’d like to allow on your network without doing 802.1 x authentications, have a consistent edge switchport configuration, and maintain centralized control of your edge.

The authentication process in this case is very simple.

When the switchport learns the MAC address of the device on the port (through a broadcast for Dynamic Host Configuration Protocol (DHCP) and/or Address Resolution Protocol (ARP)), the MAB process may start:

Endpoint	NAD	ISE
Packet to allow NAD to learn MAC→
	RADIUS Access-Request→ Username: MAC Password: MAC (encrypted)
		←RADIUS Access-Accept/Access-Reject Authorization results (VLAN, downloadable access control list (dACL))
	RADIUS Accounting-Request→ Start
		←RADIUS Accounting-Response

It’s really that simple. The NAD provides the MAC to the ISE server, and the server accepts or rejects the MAC address.

While MAB is useful, there are very few people who are going to be deploying ISE without 802.1x. Also, configuring and designing 802.1x is much more complicated, partly because the authentication methodologies provided by methodologies are so diverse and flexible. There are three Extensible Authentication Protocol (EAP) methods we’re going to go over here because they’re by far the most common and useful methodologies in the field. EAP is the protocol that happens over Ethernet between the client and the switch (configured on the client ultimately). The most common methods are as follows:

• Protected EAP (PEAP)/Microsoft version of the Challenge-Handshake Authentication Protocol (MS-CHAPv2)

• EAP Transport Layer Security (EAP-TLS)

• EAP Flexible Authentication via Secure Tunneling (EAP-FAST)

PEAP is a really popular EAP methodology. If asked, we would take a guess and say that PEAP is the most widely deployed EAP method. Almost every deployment uses PEAP for some use even if it’s not the primary authentication methodology.

While PEAP specifically provides only an outer method of server authentication with multiple possible inner methods, the most common are the MS-CHAPv2 methods. PEAP also supports inner methods:

• TLS

• EAP Generic Token Card (EAP-GTC)

MS-CHAPv2 is popular because it’s well supported with Microsoft Active Directory (AD) as the backend authentication source, and it doesn’t require a lot of complicated client configuration or design. Clients simply need to be configured to pass a username/password back up to the RADIUS server.¹

The PEAP/MS-CHAPv2 flow is summarized like the following:

Endpoint	NAD	ISE
EAP-Start→
	←EAP-Request/Identity
EAP-Response/Identity→ (username)
	RADIUS Access-Request→
		←RADIUS Access-Challenge Requests authentication methodology
	←EAP Challenge
EAP-Response→ PEAP TLS Client Hello
		←EAP-Response TLS Server Hello, server certificate
	←TLS Tunnel Build→
		←RADIUS Request/Identity
EAP-Response/Identity→ MS-CHAPv2 credential
		←RADIUS Access-Accept/ Access-Reject Authorization results (VLAN, dACL)
	RADIUS Accounting-Request→ Start
		←RADIUS Accounting-Response

When working with PEAP, it’s important to look at each step in the event of an authentication failure. Common reasons for PEAP authentication to fail include:

• Client cannot validate the server certificate.

• Client doesn’t have the trusted chain to verify that the certificate is valid.

• Server certificate has expired.

• Signature check has failed.²

• Server rejects the client credential.

• Client password is incorrect or has expired.

• Authorization of the user fails.

• Client does not response to EAP-Identity request.³

• Directory doesn’t respond to password lookup in time.⁴

EAP-TLS, also a very popular methodology for authentication, is considered the gold standard. It has a very similar authentication flow to PEAP in that the server certificate is validated, but rather than username/password being used as the client credential a certificate is used (some call this mutual certificate authentication).⁵

The EAP-TLS flow is summarized like the following:

Endpoint	NAD	ISE
EAP-Start→
	←EAP-Request/Identity
EAP-Response/Identity→ (username)
	RADIUS Access-Request→
		←RADIUS Access-Challenge Requests authentication methodology
	←EAP Challenge
EAP-Response→ EAP-TLS Client Hello
		←EAP-Response TLS Server Hello, server certificate
	←TLS Tunnel Build→
		←RADIUS Request/Identity
	←EAP-Request/Identity
EAP-Response/Identity→ Client Certificate
	RADIUS Response→
		←RADIUS Access-Accept/Access-Reject Authorization results (VLAN, dACL)
	RADIUS Accounting-Request→ Start
		←RADIUS Accounting-Response

When working with EAP-TLS, it’s important to look at each step in the event of an authentication failure. Common reasons for EAP-TLS authentication to fail include:

• Client cannot validate the server.

• Client doesn’t have the trusted chain to verify that the certificate is valid.

• Server certificate has expired.

• Signature check has failed.

• Server cannot validate the client.

• Server doesn’t have the trusted chain to verify that the client certificate is valid.

• Client certificate has expired.

• Signature check has failed.

• Client certificate has wrong key usages.

• Authorization of client fails.

The wrong key usage issue mentioned is an important one to consider. If a client (laptop, phone, etc.) has multiple certificates it could potentially select for use for EAP-TLS authentication, it’s the responsibility of the supplicant to choose which certificate to utilize. If the client selects a certificate that cannot be properly processed by your ISE policy, this will cause an AuthC or AuthZ failure. We highly recommend reducing the number of certificates that are installed on clients where possible. Some supplicants make this easier. For example, the Apple iOS supplicant can have the certificate installed on the profile. Android allows for specific certificates to be selected on a wireless local area network (WLAN) configuration. Also the AnyConnect Network Access Manager (NAM) can help in the selection of certificates on Windows PCs.

EAP-FAST is a methodology that is not dissimilar to PEAP in its deployment, but the mechanics of how it works are different. EAP-FAST intrudes cryptographic files that provide additional functionality and flexibility to authentications; these files are called Protected Access Credentials (PACs).

The history of EAP-FAST is that it was developed by Cisco after Lightweight Extensible Authentication Protocol (LEAP) was determined to be too insecure to be feasible to many customers’ implementations and at the time PEAP authentication wasn’t widely available. The idea was to make an authentication methodology as simple to deploy as LEAP and as secure as PEAP. In reality when you look at the protocol, it’s possible to make EAP-FAST as insecure as LEAP if you’re not careful.⁶

The deployment of EAP-FAST can be a daunting protocol for the uninitiated because of its use of PACs. PACs have to be provisioned by the RADIUS server (ISE) to the clients to utilize EAP-FAST. There are three methods of PAC provisioning:

• Manually:

• PAC files are specifically and manually installed on a client.

• Without authentication (anonymous in-band):

• PAC files are provisioned by the server without validating the server certificate.

• With authentication (authenticated in-band):

• Server identity is validated and a TLS tunnel is created before any PAC provisioning occurs.

It’s possible to use the first two without issues if your deployment will tolerate limitations, but there are deployment issues:

• Manual: It can be labor intensive to manually provision certificates to create individual PAC files for each machine/user you wish to authenticate and then install those everywhere they need to go. This is nuts; no one really does this.

• Anonymous in-band: It’s possible, since PAC provisioning occurs without TLS server authentication. This provides an attack vector for attackers to harvest client credentials similar to PEAP authentication attacks. This may be mitigated to some extent on wired deployments because in-band snooping may be physically challenging, but, regardless, anonymous in-band provisioning is not generally recommended.

For these reasons, we highly recommend authenticated in-band PAC provisioning as the only suitable methodology wirelessly. On wired networks where snooping is less of a risk anonymous in-band provisioning is plausible but you’d want to design your authentication conditions and results to ensure that anonymous in-band provisioning would not occur over wireless medium.

Without going into an incredible amount of detail into how the cryptography works, which for most IT guys isn’t relevant, let’s go over how PACs are created and their purpose. PACs are simply secrets generated by ISE used to generate a TLS tunnel between the client and the ISE in order to facilitate security for the inner method of client authentication. ISE generates a master PAC at the time of installation and periodically through the life of the deployment (by default once a week). ISE will provision an authenticated user or computer a PAC file generated from the master PAC. When the master PAC outlives its Time to Live (TTL), a user is provisioned a new PAC on its next successful authentication.⁷

In the provisioning and establishment of that mutual cryptographic authentication, the same inner methodologies that PEAP provides can be utilized by EAP-FAST. What is the point of EAP-FAST in modern deployments? Great question.

In our world deploying ISE, Cisco has extended EAP-FAST to allow multiple tunneled authentication inner credentials (EAP-Chaining) to allow both the user and the computer authentication to happen in one single authentication transaction. We’ll go over EAP-Chaining in Chapter 12.

Here is an overview of an EAP-FAST exchange with authenticated in-band PAC provisioning:

Endpoint	NAD	ISE
EAP-Start→
	←EAP-Request/Identity
EAP-Response/Identity→ (username)
	RADIUS Access-Request→
		←RADIUS Access-Challenge Requests authentication methodology
	←EAP Challenge
EAP-Response→ EAP-FAST TLS Client Hello
		←EAP-Response TLS Server Hello, server certificate
	←TLS Tunnel Build→
		←RADIUS Request/EAP Payload TLV/EAP Inner Method Challenge
EAP-Response→ Inner Method Response (response with both username and password)
		← EAP-Request/EAP-FAST-MS-CHAPv2 (success)
EAP-Response→ EAP-FAST-MS-CHAPv2 (success)
	←PAC provision→
		←EAP-Success
	RADIUS Accounting-Request→ Start
		←RADIUS Accounting-Response

Once a PAC has been provisioned, subsequent authentications can reuse the previously provisioned PACs making authentication more efficient. Here is a summary of that flow:

Endpoint	NAD	ISE
EAP-Start→
	←EAP-Request/Identity
EAP-Response/Identity→ (username)
	RADIUS Access-Request→
		←RADIUS Access-Challenge Requests authentication methodology
	←EAP Challenge
EAP-Response→ EAP-FAST TLS Client Hello (client sends PAC)
		←EAP-Response TLS Server Hello, Server PAC
	←TLS Tunnel Build→
		←RADIUS Request/Identity
EAP-Response/Identity→ MS-CHAPv2 credential
		←RADIUS Access-Accept/Access-Reject Authorization results (VLAN, dACL)
	RADIUS Accounting-Request→ Start
		←RADIUS Accounting-Response

When working with EAP-FAST, because username/password-type authentication is what is in use, common failure types are very similar to PEAP. Common reasons for EAP-FAST authentication to fail include:

• Client cannot validate the server certificate.

• Client doesn’t have the trusted chain to verify that the certificate is valid.

• Server certificate has expired.

• Signature check has failed.

• Server rejects the client credential.

• Client password is incorrect or has expired.

• Authorization of the user fails.

• Client does not response to EAP-Identity request.

• Directory doesn’t respond to password lookup in time.

ISE also provides for robust client authentication via web authentication. The most common and robust functionality provided by ISE is called central web authentication (CWA). The “central” part of the authentication refers to the fact that ISE is providing the website for the authentication and that part of the functionality is centralized. A legacy feature called local web authentication (“LWA”) refers to local in that the web authentication occurred on the NAD (switch or WLC).⁸

In CWA a MAB operation is actually used, but rather than the station being directly authorized, a web page is presented to the client for authentication. The client is required to pop up a browser and enter a username/password. If that authentication is successful, the ISE policy node will issue a CoA⁹ to the NAD to remove the requirement for web authentication redirection, and then allowing the client network access. It’s important to note that while other methodologies don’t require direct IP communication between the client and the ISE policy node, CWA does require the client to authenticate directly through the web browser and as such all other network requirements for that browser to work must be met. The client has to have an IP address, it has to resolve the ISE node, and it has to have a functioning web browser. Presuming those requirements are met, here is a summary of CWA authentication:

Endpoint	NAD	ISE
Packet to allow NAD to learn MAC→
	RADIUS Access-Request→ Username: MAC Password: MAC (encrypted)
		←RADIUS Access-Accept/ Access-Reject Authorization results: web authentication URL (ISE policy node), redirect access control list (ACL), dACL (if IOS)
	RADIUS Accounting-Request→ Start
		←RADIUS Accounting-Response
	NAD applies ACL and redirects URL to switchport in case of wired authentication, or client association in the case of WLC
Web browser open: request web page→
	←Web redirect packet changing URL to ISE Policy Services Node (PSN)
Client browser to ISE PSN→
		←ISE PSN web page response
Client authenticates with username/password in browser→
		←RADIUS CoA Request: reauthenticate
	RADIUS CoA-ACK→
	RADIUS Access-Request→ Username: MAC Password: MAC (encrypted)
		←RADIUS Access-Accept/ Access-Reject Authorization results (dACL)

You’ll notice that the CoA type requested is reauthentication. This is because when ISE reauthenticates this endpoint, it knows that the web authentication was just successful and it’s changing that endpoint’s authorization and no longer requires it to have the web authentication redirect in place.

When you’re having difficulty with configuring CWA, there are a few different common issues to look at:

• Client cannot validate the server certificate.

• Client doesn’t have the trusted chain to verify that the certificate is valid.

• Server certificate has expired.

• Signature check has failed.

• The client cannot connect to the ISE policy node.

• Client doesn’t have an IP.

• Client is unable to resolve the ISE PSN hostname used for authentication.

• Access control prevents access to the ISE policy node (dACL, firewall policy, or airspace ACL are all possible issues).

• Server rejects the client credential.

• Client password is incorrect or has expired.

• Authorization of the user fails.

---

¹ There is a glaring disadvantage of PEAP that is largely the result of supplicant design by device manufacturers. Due to the broad lack of server certificate validation enforcement by mobile devices, it’s often easy to attack PEAP-configured clients with rogue wireless networks. If you’d like to know the mechanics of this, we invite you to Google around and you’ll surely find examples of how this works. If you’re going to securely use PEAP as your authentication method, it’s crucial to ensure your clients are properly validating the server certificates.

² The certificate signature check failure could be because the certificate is actually invalid, or the client’s configuration is configured in such a way that the CA used to generate the server certificate isn’t used.

³ In wireless 802.1x authentication deployments you’ll see lots of error messages where the client doesn’t respond, or doesn’t respond in time, or has any number of other error conditions. This is normal. Clients can be roaming, have poor supplicant software, or are out of range of Wi-Fi. Just because you’re seeing lots of weird dot1x errors accumulating that look like EAP problems doesn’t necessarily mean anything is actually wrong.

⁴ An issue to keep in mind is that if your directory takes a really long time to authenticate the user’s password, the authentication could time out. This happens occasionally to me in the field. Your options in this case are a couple fold: Make AD respond faster or increase your timeouts so AD can respond in time.

⁵ Because mutual certificate authentication is used, you will negate some of the risk that AD will not respond in time because there isn’t necessarily an authentication dependency outside of ISE (no username/password lookup in a directory). For this reason certificate authentication is very efficient.

⁶ LEAP is a depreciated authentication methodology. We’re not going to go over it. If you have it out there, it’s time to move on to something else.

⁷ A specific point here must be noted that the identity provided by the PAC must match the identity provided by the inner method; otherwise authentication will fail.

⁸ LWA is generally depreciated in most modern deployments and we won’t be directly addressing it.

⁹ CoA is really a lot of the magic behind many of the advanced ISE features available to us. It’s discussed in RFC 5176 for reference. Get used to seeing and using CoA.