Testing With EAP

Whether a test includes RADIUS, Diameter or IPSec with IKEv2, you can optionally use the Extensible Authentication Protocol (EAP) to authenticate the MN with a AAA Server. EAP provides a framework that can support many different authentication methods over various transport protocols between the Network Access Server (NAS) and the MN. The NAS performs a screening function, validating the message composition of responses from the MN and forwarding the MN's credentials on to a AAA Server for final authentication and authorization. EAP messages can be carried in the payload of either RADIUS or Diameter messages. Since EAP devices can support different authentication methods, a negotiation mechanism enables the MN and the AAA Server to agree upon the authentication method that will be used when the two devices support at least one common method.

The following authentication methods are supported by the test system:

MD5 — Supported by all EAP devices, MD5 is similar to CHAP challenge authentication.
EAP-SIM — Subscriber Identity Module (SIM) authentication used in GSM networks.
EAP-AKA — Authentication and Key Agreement (AKA) authentication used in CDMA2000 and UMTS networks.
EAP-MSCHAPv2 — Microsoft version of the Challenge-handshake authentication protocol (CHAP), version 2, used for AAA RADIUS client and server testing.
EAP-TLS — Authentication using pre-shared keys or digital certificates and Transport Level Security (TLS).
EAP-GTC — EAP-GTC provides two-factor authentication to avoid common password-based security vulnerabilities, such as exposure of passwords to third parties.

In general, the NAS sends an Identity request to the MN, indicating the authentication method preferred by the AAA Server, the MN responds with its identity, and the authentication proceeds with a series of request/response transactions. If the MN does not support the method requested by the NAS, it replies with a NAK message, informing the NAS of the types of authentication methods it supports. If the MN and AAA Server both support a common method, the NAS repeats the Identity request until a method supported by both the MN and the AAA server is found. The AAA Server may send a Notification message containing a message that may be displayed to the end user, "password will expire in 10 seconds" for example, at any time after a response message.

The sections below show simple, successful message flows between the MN, NAS, and AAA Server for the different authentication methods. Depending on the type of test, a NAS may be an MN servicing node SUT (GGSN or HA), an LAC SUT, or a Security Gateway (when EAP is used with Data IPSec). For simplicity, RADIUS messages are shown for the NAS-AAA interface.

MD5

As stated above, MD5 authentication is similar to the CHAP challenge method with MD5 encryption used by PPP.

The NAS begins the process by sending an EAP Identity request to the MN, indicating that the MD5 method will be used. If the MN supports MD5, it returns the MN's User Name in an Identity response.

The NAS encapsulates the Identity response in a RADIUS Access Request message that it sends to the AAA Server. If the AAA Server validates the user name, it returns an EAP MD5 Challenge encapsulated in an Access Challenge message.

The NAS extracts the MD5 Challenge and forwards it to the MN in an EAP Request, and the MN replies with the encrypted Password in an EAP Response message.

The NAS encapsulates the challenge response in a second Access Request sent to the AAA Server. If the challenge value is valid, the AAA Server responds with an Access Accept and the NAS sends an EAP Success message to the MN.

EAP-SIM

EAP-SIM is used exclusively by GSM networks and uses a challenge-response model that provides two-way authentication — the MN verifies the identity of the network using a shared key pre-provisioned in the SIM and the network verifies the identity of the MN.

The NAS begins the process by sending an EAP Identity request to the MN, indicating that the SIM method will be used. If the MN supports SIM, it returns the MN's User Name, typically an IMSI, in an Identity response.

The NAS encapsulates the Identity response in a RADIUS Access Request message that it sends to the AAA Server. If the AAA Server validates the user name, it returns an EAP SIM/Start encapsulated in an Access Challenge message. The SIM/Start contains a list of EAP-SIM versions supported by the server.

The NAS extracts the SIM/Start and sends it to the MN in an EAP Request. The MN replies with a SIM/Start in an EAP Response that contains the SIM version selected by the MN and a random number nonce.

The NAS encapsulates the SIM/Start response in a second Access Request sent to the AAA Server. The server obtains GSM triplets and derives the key values that will be used in the challenge and calculates a Message Authentication Code (MAC) using the nonce received in the SIM/Start response. The challenge values and MAC are sent to the NAS with a SIM/Challenge encapsulated in an Access Challenge message.

The NAS extracts the SIM/Challenge and sends it to the MN in an EAP Request. The MN calculates a MAC using the nonce that it sent to the server and compares it to the MAC received in the challenge, verifying the identity of the AAA Server. It then responds with a SIM/Challenge containing a new MAC value that encompasses the expected response values received in the server's challenge.

The NAS encapsulates the SIM/Challenge response in a final Access Request message sent to the AAA Server. The server validates the MAC and, if valid, responds with an EAP Success encapsulated in an Access Accept message. The NAS forwards the EAP Success message to the MN.

Fast Re-Authentication

The network may require that the MN is periodically re-authenticated to refresh the master session key. EAP-SIM provides a mechanism to perform re-authentication with a reduced set of messages. When re-authentication is used, the AAA Server includes an identity value to be used by the MN for re-authentication in the SIM/Challenge or SIM/Start message.

As with full authentication, the process begins with an Identity request sent to the MN, and the MN replies with an Identity response including the re-authentication identity provided by the AAA Server. If the server validates the re-authentication identity and agrees to use fast re-authentication, it sends a SIM/Re-authentication request to the MN that includes a nonce and a fresh MAC and may include an identity to be used by the MN for the next re-authentication. The MN validates the MAC and replies with a SIM/Re-authentication response. If the AAA Server validates the MN's response, it replies with an EAP Success message.

EAP-AKA

EAP-AKA can be used in CDMA2000 and UMTS networks. It also provides two-way authentication using a shared key and a challenge-response model.

The NAS begins the process by sending an EAP Identity request to the MN, indicating that the SIM method will be used. Alternatively, the NAS may send an AKA Identity message, specifying the type of identity it wishes the MN to return. If the MN supports SIM, it returns the MN's User Name, typically an IMSI or NAI, in an Identity response.

The NAS encapsulates the Identity response in a RADIUS Access Request message that it sends to the AAA Server. If the AAA Server validates the user name, it obtains an authentication vector from the network and uses those values to calculate an authentication token and a MAC. The server encapsulates an AKA Challenge containing the random seed value used in calculations, the token, and the MAC in an Access Challenge message sent to the NAS.

The NAS extracts the AKA Challenge and sends it to the MN in an EAP Request. The MN calculates a token using the random value received in the challenge and validates the server's identity. It then replies with an AKA Challenge containing a new MAC and a challenge response.

The NAS encapsulates the AKA Challenge response in a second Access Request message sent to the AAA Server. The server validates the MAC to ensure packet integrity and validates the challenge response to authenticate the MN and responds with an EAP Success encapsulated in an Access Accept message. The NAS forwards the EAP Success message to the MN.

Fast Re-Authentication

The network may require that the MN is periodically re-authenticated to refresh the master session key. EAP-AKA provides a mechanism to perform re-authentication with a reduced set of messages. When re-authentication is used, the AAA Server includes an identity value to be used by the MN for re-authentication in the AKA Challenge message.

As with full authentication, the process begins with an Identity request sent to the MN, and the MN replies with an Identity response including the re-authentication identity provided by the AAA Server. If the server validates the re-authentication identity and agrees to use fast re-authentication, it sends an AKA Re-authentication request to the MN that includes a nonce and a fresh MAC and may include an identity to be used by the MN for the next re-authentication. The MN validates the MAC and replies with an AKA Re-authentication response. If the AAA Server validates the MN's response, it replies with an EAP Success message.

EAP-MSCHAPv2

The Microsoft version of the Challenge-handshake authentication protocol (CHAP) version 2 (MSCHAPv2), can be used for AAA RADIUS client and server testing.

The NAS begins the process by sending an EAP Identity request to the MN, indicating that the MSCHAPv2 method will be used. If the MN supports MSCHAPv2, it returns the MN's User Name in an Identity response.

The NAS encapsulates the Identity response in a RADIUS Access Request message that it sends to the AAA Server. If the AAA Server validates the user name, it returns an EAP MSCHAPv2 Challenge encapsulated in an Access Challenge message.

The NAS extracts the MSCHAPv2 Challenge and forwards it to the MN in an EAP Request, and the MN replies with the encrypted Password in an EAP Response message.

EAP-TLS

EAP with Transport Level Security (TLS) provides a way for a client and a server to authenticate each other through the use of either digital certificates or pre-shared keys. TLS is made up of two protocols: the TLS Handshake Protocol which performs authentication, cipher suite negotiation, key exchange, and error reporting, and the TLS Record Protocol which rides above a reliable transport protocol and encrypts higher layer protocols, including the Handshake protocol, using the methods decided on during the handshake process. An example message flow for a full handshake using digital certificates is shown to the right.

The AAA Server notifies the NAS in the first Access Challenge message that EAP-TLS will be used, and the handshake process begins with a Client Hello message from the MN. Hello messages contain the capabilities of each peer — protocol version, cipher suite, and compression method — a random value generated by each peer, and the session ID.

The server responds with a single packet containing the following messages:

A Server Hello, describing the AAA Server's capabilities.
The server's Certificate.
If the server's certificate is only for signing, it also sends a Server Key Exchange message that contains a public key.
A Certificate Request, requesting a certificate from the NAS.
A Server Hello Done, terminating the sequence.

The MN responds with a packet containing the following:

A Certificate in reply to the server's request.
A Client Key Exchange, containing the shared secret or enough information for the server to formulate a matching secret.
If the MN's certificate has signing capability, it explicitly verifies the certificate with a Certificate Verify message that contains a hash of all hello messages sent and received by the MN through the Client Key Exchange message.
The MN notifies the server of the cipher suite and keys it will use in subsequent messages with a Change Cipher Spec.
A Handshake message that is encrypted as specified in the Change Cipher Spec message.

The server completes the handshake by replying with its own Change Cipher Spec and Handshake packet that uses the negotiated keys and algorithms. After the MN confirms receipt of the handshake, the server responds with an EAP Success message.

EAP-GTC Authentication Protocol

EAP-GTC (Generic Token Card) (RFC 2284), enables the exchange of clear-text authentication credentials across the network. Since one-time passwords generated by token cards are not vulnerable to replay attacks, EAP-GTC can be used by itself. EAP-GTC is typically used inside a TLS tunnel created by TTLS or PEAP to provide server authentication in wireless environments.

PEAP

The Protected Extensible Authentication Protocol (PEAP) is a member of the EAP protocol family, and uses Transport Level Security (TLS) to create an encrypted channel between an authenticating PEAP client and a PEAP authenticator. PEAP does not specify an authentication method, but provides additional security for the other EAP authentication protocols, which can operate through the TLS-encrypted channel provided by PEAP. PEAP version 0 (Microsoft PEAP) supports only EAP-MSCHAPv2. PEAP version 1 (general PEAP implementation) supports MD5, EAP-SIM, EAP-AKA, and EAP-MSCHAPv2.

Test Support

If you will be using digital certificates, the test server must be provisioned with private key and certificate files.

Learn more about using digital certificates

The following cipher suites are supported with certificates:

TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA

The following cipher suites are supported with pre-shared keys:

TLS_PSK_WITH_3DES_EDE_CBC_SHA
TLS_PSK_WITH_AES_128_CBC_SHA
TLS_PSK_WITH_AES_256_CBC_SHA

Pairwise Master Key (PMK) generation is optional.