Authentication verifies user information to confirm user identity. Traditional authentication uses a name and a fixed password. This is the most popular, simplest, and least-expensive method of authentication. The disadvantage is that this information can be told to someone else, guessed, or captured. An approach that uses simple, unencrypted usernames and passwords is not considered a strong authentication mechanism, but it can be sufficient for low-authorization or low-privilege levels such as Internet access.
Secure Authentication Using Encrypted Passwords and Cryptographic Techniques
You should use encryption to reduce the risk of password capture on the network. Client and server access control protocols, such as RADIUS, encrypt passwords to prevent them from being captured within a network. However, RADIUS operates only between the authentication, authorization, and accounting (AAA) client and Cisco ISE. Before this point in the authentication process, unauthorized persons can obtain cleartext passwords such as in the following examples:
In the communication between an end-user client that dials up over a phone line
On an ISDN line that terminates at a network access server
Over a Telnet session between an end-user client and the hosting device
More-secure methods use cryptographic techniques, such as those used inside the Challenge Authentication Handshake Protocol (CHAP), one-time password (OTP), and advanced EAP-based protocols. Cisco ISE supports a variety of these authentication methods.
Authentication Methods and Authorization Privileges
A fundamental implicit relationship exists between authentication and authorization. The more authorization privileges that are granted to a user, the stronger the authentication should be. Cisco ISE supports this relationship by providing various methods of authentication.
RADIUS Protocol Support in Cisco ISE
RADIUS is a client/server
protocol through which remote-access servers communicate with a central server
to authenticate dial-in users and authorize their access to the requested
system or service. You can use RADIUS to maintain user profiles in a central
database that all remote servers can share. This protocol provides better
security, and you can use it to set up a policy that is applied at a single
administered network point.
RADIUS also functions as a
RADIUS client in Cisco ISE to proxy requests to a remote RADIUS server, and it
provides Change of Authorization (CoA) activities during an active session.
Cisco ISE supports RADIUS
protocol flow according to RFC 2865 and generic support for all general RADIUS
attributes as described in RFC 2865 and its extension. Cisco ISE supports
parsing of vendor-specific attributes only for vendors that are defined in the
Cisco ISE dictionary.
RADIUS interface supports the
following attribute data types that are defined in RFC 2865:
Text (Unicode Transformation
Network Access for Users
For network access, a host connects to the network device and requests to use network resources. The network device identifies the newly connected host, and, using the RADIUS protocol as a transport mechanism, requests Cisco ISE to authenticate and authorize the user.
Cisco ISE supports network access flows depending on the protocol that is transported over the RADIUS protocol.
RADIUS-based protocols that do not include EAP include the following:
Password Authentication Protocol (PAP)
Microsoft Challenge Handshake Authentication Protocol version 1 (MS-CHAPv1)
MS-CHAP version 2 (MS-CHAPv2)
RADIUS-Based Non-EAP Authentication Flow
This section describes RADIUS-based flow without EAP authentication. RADIUS-based flow with PAP authentication occurs in the following process:
A host connects to a network device.
The network device sends a RADIUS request (Access-Request) to Cisco ISE that contains RADIUS attributes that are appropriate to the specific protocol that is being used (PAP, CHAP, MS-CHAPv1, or MS-CHAPv2).
Cisco ISE uses an identity store to validate user credentials.
A RADIUS response (Access-Accept or Access-Reject) is sent to the network device that will apply the decision.
The following figure shows a RADIUS-based authentication without EAP.
PAP provides a simple method for users to establish their identity by using a two-way handshake. The PAP password is encrypted with a shared secret and is the least sophisticated authentication protocol. PAP is not a strong authentication method because it offers little protection from repeated trial-and-error attacks.
RADIUS-Based PAP Authentication in Cisco ISE
Cisco ISE checks the username and password pair against the identity stores, until it eventually acknowledges the authentication or terminates the connection.
You can use different levels of security concurrently with Cisco ISE for different requirements. PAP applies a two-way handshaking procedure. If authentication succeeds, Cisco ISE returns an acknowledgment; otherwise, Cisco ISE terminates the connection or gives the originator another chance.
The originator is in total control of the frequency and timing of the attempts. Therefore, any server that can use a stronger authentication method will offer to negotiate that method prior to PAP. RFC 1334 defines PAP.
Cisco ISE supports standard RADIUS PAP authentication that is based on the RADIUS UserPassword attribute. RADIUS PAP authentication is compatible with all identity stores.
The RADIUS-with-PAP-authentication flow includes logging of passed and failed attempts.
Challenge Handshake Authentication Protocol
CHAP uses a challenge-response mechanism with one-way encryption on the response. CHAP enables Cisco ISE to negotiate downward from the most-secure to the least-secure encryption mechanism, and it protects passwords that are transmitted in the process. CHAP passwords are reusable. If you are using the Cisco ISE internal database for authentication, you can use PAP or CHAP. CHAP does not work with the Microsoft user database. Compared to RADIUS PAP, CHAP allows a higher level of security for encrypting passwords when communicating from an end-user client to the AAA client.
Cisco ISE supports standard RADIUS CHAP authentication that is based on the RADIUS ChapPassword attribute. Cisco ISE supports RADIUS CHAP authentication only with internal identity stores.
Microsoft Challenge Handshake Authentication Protocol Version 1
Cisco ISE supports the RADIUS MS-CHAPv1 authentication and change-password features. RADIUS MS-CHAPv1 contains two versions of the change-password feature: Change-Password-V1 and Change-Password-V2.Cisco ISE does not support Change-Password-V1 based on the RADIUS MS-CHAP-CPW-1 attribute, and supports only Change-Password-V2 based on the MS-CHAP-CPW-2 attribute.The RADIUS MS-CHAPv1 authentication and change-password features are supported with the following identity sources:
Internal identity stores
Microsoft Active Directory identity store
Microsoft Challenge Handshake Authentication Protocol Version 2
The RADIUS MS-CHAPv2 authentication and change-password features are supported with the following identity sources:
Internal identity stores
Microsoft Active Directory identity store
RADIUS-Based EAP Protocols
EAP provides an extensible framework that supports various authentication types. This section describes the EAP methods supported by Cisco ISE and contains the following topics:
Simple EAP Methods
EAP-Message Digest 5
EAP Methods That Use Cisco ISE Server Certificate for Authentication
Apart from the methods listed above, there are EAP methods that use certificates for both server and client authentication.
RADIUS-Based EAP Authentication Flow
Whenever EAP is involved in the authentication process, the process is preceded by an EAP negotiation phase to determine which specific EAP method (and inner method, if applicable) should be used. EAP-based authentication occurs in the following process:
A host connects to a network device.
The network device sends an EAP Request to the host.
The host replies with an EAP Response to the network device.
The network device encapsulates the EAP Response that it received from the host into a RADIUS Access-Request (using the EAP-Message RADIUS attribute) and sends the RADIUS Access-Request to Cisco ISE.
Cisco ISE extracts the EAP Response from the RADIUS packet and creates a new EAP Request, encapsulates it into a RADIUS Access-Challenge (again, using the EAP-Message RADIUS attribute), and sends it to the network device.
The network device extracts the EAP Request and sends it to the host.
In this way, the host and Cisco ISE indirectly exchange EAP messages (transported over RADIUS and passed through the network device). The initial set of EAP messages that are exchanged in this manner negotiate the specific EAP method that will subsequently be used to perform the authentication.
The EAP messages that are subsequently exchanged are then used to carry the data that is needed to perform the actual authentication. If it is required by the specific EAP authentication method that is negotiated, Cisco ISE uses an identity store to validate user credentials.
After Cisco ISE determines whether the authentication should pass or fail, it sends either an EAP-Success or EAP-Failure message, encapsulated into a RADIUS Access-Accept or Access-Reject message to the network device (and ultimately also to the host).
The following figure shows a RADIUS-based authentication with EAP.
Extensible Authentication Protocol-Message Digest 5 (EAP-MD5) provides one-way client authentication. The server sends the client a random challenge. The client proves its identity in a response by encrypting the challenge and its password with MD5. Because a man in the middle could see the challenge and response, EAP-MD5 is vulnerable to dictionary attack when used over an open medium. Because no server authentication occurs, it is also vulnerable to spoofing. Cisco ISE supports EAP-MD5 authentication against the Cisco ISE internal identity store. Host Lookup is also supported when using the EAP-MD5 protocol.
Lightweight Extensible Authentication Protocol
Cisco ISE currently uses Lightweight Extensible Authentication Protocol (LEAP) only for Cisco Aironet wireless networking. If you do not enable this option, Cisco Aironet end-user clients who are configured to perform LEAP authentication cannot access the network. If all Cisco Aironet end-user clients use a different authentication protocol, such as Extensible Authentication Protocol-Transport Layer Security (EAP-TLS), we recommend that you disable this option.
If users access your network by using a AAA client that is defined in the Network Devices section as a RADIUS (Cisco Aironet) device, then you must enable LEAP, EAP-TLS, or both; otherwise, Cisco Aironet users cannot authenticate.
Protected Extensible Authentication Protocol
Protected Extensible Authentication Protocol (PEAP) provides mutual authentication, ensures confidentiality and integrity to vulnerable user credentials, protects itself against passive (eavesdropping) and active (man-in-the-middle) attacks, and securely generates cryptographic keying material. PEAP is compatible with the IEEE 802.1X standard and RADIUS protocol. Cisco ISE supports PEAP version 0 (PEAPv0) and PEAP version 1 (PEAPv1) with Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol (EAP-MS-CHAP), Extensible Authentication Protocol-Generic Token Card (EAP-GTC), and EAP-TLS inner methods. The Cisco Secure Services Client (SSC) supplicant supports all of the PEAPv1 inner methods that Cisco ISE supports.
Advantages of Using PEAP
Using PEAP presents these advantages: PEAP is based on TLS, which is widely implemented and has undergone extensive security review. It establishes a key for methods that do not derive keys. It sends an identity within the tunnel. It protects inner method exchanges and the result message. It supports fragmentation.
Supported Supplicants for the PEAP Protocol
PEAP supports these supplicants:
Microsoft Built-In Clients 802.1X XP
Microsoft Built-In Clients 802.1X Vista
Cisco Secure Services Client (SSC), Release 4.0
Cisco SSC, Release 5.1
Funk Odyssey Access Client, Release 4.72
Intel, Release 18.104.22.168
PEAP Protocol Flow
A PEAP conversation can be
divided into three parts:
Cisco ISE and the peer build
a TLS tunnel. Cisco ISE presents its certificate, but the peer does not. The
peer and Cisco ISE create a key to encrypt the data inside the tunnel.
The inner method determines
the flow within the tunnel:
EAP-MS-CHAPv2 inner method—EAP-MS-CHAPv2 packets travel inside
the tunnel without their headers. The first byte of the header contains the
type field. EAP-MS-CHAPv2 inner methods support the change-password feature.
You can configure the number of times that the user can attempt to change the
password through the Admin portal. User authentication attempts are limited by
EAP-GTC inner method—Both PEAPv0 and PEAPv1 support the
EAP-GTC inner method. The supported supplicants do not support PEAPv0 with the
EAP-GTC inner method. EAP-GTC supports the change-password feature. You can
configure the number of times that the user can attempt to change the password
through the Admin portal. User authentication attempts are limited by this
EAP-TLS inner method—The Windows built-in supplicant does not
support fragmentation of messages after the tunnel is established, and this
affects the EAP-TLS inner method. Cisco ISE does not support fragmentation of
the outer PEAP message after the tunnel is established. During tunnel
establishment, fragmentation works as specified in PEAP documentation. In
PEAPv0, EAP-TLS packet headers are removed, and in PEAPv1, EAP-TLS packets are
Extensible Authentication Protocol-type, length, value
(EAP-TLV) extension—EAP-TLV packets are transmitted unchanged. EAP-TLV packets
travel with their headers inside the tunnel.
There is protected
acknowledgment of success and failure if the conversation has reached the
The client EAP message is always carried in the RADIUS
Access-Request message, and the server EAP message is always carried in the
RADIUS Access-Challenge message. The EAP-Success message is always carried in
the RADIUS Access-Accept message. The EAP-Failure message is always carried in
the RADIUS Access-Reject message. Dropping the client PEAP message results in
dropping the RADIUS client message.
Cisco ISE requires acknowledgment of the EAP-Success or EAP-Failure
message during PEAPv1 communication. The peer must send back a PEAP packet with
empty TLS data field to acknowledge the receipt of success or failure message.
Extensible Authentication Protocol-Flexible Authentication via Secure Tunneling
Extensible Authentication Protocol-Flexible Authentication via Secure Tunneling (EAP-FAST) is an authentication protocol that provides mutual authentication and uses a shared secret to establish a tunnel. The tunnel is used to protect weak authentication methods that are based on passwords. The shared secret, referred to as a Protected Access Credentials (PAC) key, is used to mutually authenticate the client and server while securing the tunnel.
Benefits of EAP-FAST
EAP-FAST provides the following benefits over other authentication protocols:
Mutual authentication—The EAP server must be able to verify the identity and authenticity of the peer, and the peer must be able to verify the authenticity of the EAP server.
Immunity to passive dictionary attacks—Many authentication protocols require a password to be explicitly provided, either as cleartext or hashed, by the peer to the EAP server.
Immunity to man-in-the-middle attacks—In establishing a mutually authenticated protected tunnel, the protocol must prevent adversaries from successfully interjecting information into the conversation between the peer and the EAP server.
Flexibility to enable support for many different password authentication interfaces such as MS-CHAPv2, Generic Token Card (GTC), and others—EAP-FAST is an extensible framework that allows support of multiple internal protocols by the same server.
Efficiency—When using wireless media, peers are limited in computational and power resources. EAP-FAST enables the network access communication to be computationally lightweight.
Minimization of the per-user authentication state requirements of the authentication server—With large deployments, it is typical to have many servers acting as the authentication servers for many peers. It is also highly desirable for a peer to use the same shared secret to secure a tunnel much the same way that it uses the username and password to gain access to the network. EAP-FAST facilitates the use of a single, strong, shared secret by the peer, while enabling servers to minimize the per-user and device state that it must cache and manage.
The EAP-FAST protocol flow is always a combination of the following phases:
Provisioning phase—This is phase zero of EAP-FAST. During this phase, the peer is provisioned with a unique, strong secret that is referred to as the PAC that is shared between the Cisco ISE and the peer.
Tunnel establishment phase—The client and server authenticate each other by using the PAC to establish a fresh tunnel key. The tunnel key is then used to protect the rest of the conversation and provides message confidentiality and with authenticity.
Authentication phase—The authentication is processed inside the tunnel and includes the generation of session keys and protected termination.Cisco ISE supports EAP-FAST versions 1 and 1a.