The RADIUS protocol requires a secret to be shared between a client and a server. Shared secrets are used to verify that RADIUS messages are sent by a RADIUS enabled device that is configured with the same shared secret. Shared secrets also verify that the RADIUS message has not been modified in transit (message integrity). The message integrity is checked by including the Message Authenticator attribute in the RADIUS messages. This attribute is a Hash-based Message Authentication Code-Message Digest 5 (HMAC-MD5) of the entire radius message using the shared secret as the key. The shared secret is also used to encrypt some RADIUS attributes, such as User-Password and Tunnel-Password.

EAP-FAST is a publicly accessible IEEE 802.1X extensible authentication protocol type that is used to support customers who cannot enforce a strong password policy. EAP-FAST is used for the following reasons:

• Digital certificates are not required.
• A variety of database types for usernames and passwords are supported.
• Password expiration and change are supported.
• EAP-FAST is flexible, easy to deploy and manage.

Note	Lightweight Directory Access Protocol (LDAP) users cannot be automatically PAC provisioned and must be manually provisioned.

EAP-FAST comprises three basic phases:

• Phase 0 (optional): the PAC is initially distributed to the client.
• Phase 1: using the PAC, a secure tunnel is established.
• Phase 2: the client is authenticated via the secure tunnel.

The initial Phase 0 or auto-provisioning (also called in-band provisioning) component of EAP-FAST permits the secure distribution of the user PAC to each client. With some other authentication protocols, it is necessary to establish a network connection or manually install a file in order to distribute credentials to the user. Phase 0 in EAP-FAST permits a user PAC to be distributed to the client during an encrypted session after the user's credentials are authenticated. This user authentication uses a challenge-handshake protocol to authenticate the client and to validate the server response. This authentication mechanism guards against potential interception and reforwarding of provisioning requests for the purpose of intercepting a user PAC.

Note

Phase 0 is optional in EAP-FAST. PAC files may also be manually generated at the PAC server and distributed manually to client devices (this process is called manual or out-of-band provisioning). Because auto provisioning uses Microsoft Challenge Handshake Authentication Protocol Version 2 (MSCHAPv2), it may be necessary to use manual provisioning if you use a non-Microsoft-format database such as LDAP, which does not support MSCHAPv2 credentials.

The end result of Phase 0 is PAC distribution, not client authentication. After successful PAC distribution, the server issues an authentication failure to the access point and the user is disassociated from the network. Then the client reinitiates an EAP-FAST authentication with the network using the newly provisioned PAC and the user's credentials.

After the optional Phase 0, the actual EAP-FAST authentication starts with Phase 1. In the Phase 1 EAP-FAST authentication transaction, a secure tunnel is established between the user and the EAP-FAST-capable RADIUS server using the user's PAC credential with TLS protocol.

During the initial authentication request, the server sends its Authority ID (A-ID). The client selects the correct PAC from its storage by correlating the provided A-ID with its saved PACs and its respective PAC-Info fields.

Note	The client sends only the PAC-Opaque field to the server, not the PAC key. The server decrypts the PAC-Opaque field using its master key. As the server and client now share the PAC key, the PAC key is used to create the unique TLS tunnel for this client's authentication.

After the TLS tunnel is established using the PAC, user authentication credentials are passed securely using the Extensible Authentication Protocol-Generic Token Card (EAP-GTC) protocol within the encrypted tunnel to the RADIUS server (Phase 2).

Note	The client response is cryptographically bound to the EAP authentication success message. This prevents a Man-In-The-Middle (MITM) attack in which the attacker (client) attempts to provide a false response to the server in order to obtain the session key.

After the successful Phase 2 authentication of the client to the EAP-FAST server, a RADIUS Access-Accept message is passed to the access point (along with the master session key). An EAP success message is generated at the access point (as with other EAP authentication protocols). Upon receipt of the EAP-success packet, the client derives the session key using a complimentary algorithm used at the server to generate the session key passed to the access point. This key permits the client and access point to establish a unique session key using the defined encryption mechanism (Wi-Fi Protected Access (WPA) authentication key management, Cisco Centralized Key Management (CCKM), or standard 802.11 Wired Equivalent Privacy (WEP) keying.

The figure below shows an overview of EAP-FAST authentication.

The PAC is a unique shared credential used to mutually authenticate client and server. It is associated with a specific client username and a server A-ID. A PAC removes the need for Public Key Infrastructure (PKI) and digital certificates.

Creating a PAC consists of the following steps:

1. Server A-ID maintains a local key (master key) that is only known by the server.
2. When a client identity (I-ID) requests a PAC from the server, the server generates a randomly unique PAC key and PAC-Opaque field for this client.
3. The PAC-Opaque field contains the randomly generated PAC key along with other information such as user identity (I-ID) and key lifetime.
4. PAC Key, I-ID, and Lifetime in the PAC-Opaque field are encrypted with the master key.
5. A PAC-Info field that contains the A-ID is created.
6. The PAC is distributed or imported to the client automatically or manually.

Note	The server does not maintain the PAC or the PAC key, enabling the EAP-FAST server to be stateless.

The figure below describes the PAC's construction. A PAC consists of the PAC-Opaque, PAC Key and PAC-Info fields. The PAC-Info field contains the A-ID.

In Secure RADIUS, the PAC key is provisioned into each device during authentication to derive the shared secret. Since the RADIUS ACS does not store the PAC key for each device, the clients must also send an additional radius attribute containing the PAC-Opaque field, which is a variable length field that is sent to the server when the TLS tunnel is being established. The PAC-Opaque field can only be interpreted by the server to recover the required information for the server to validate the peer’s identity and authentication. For example, the PAC-Opaque field may include the PAC key and the PAC’s peer identity.

The PAC-Opaque field format and contents are specific to the PAC server on which it is issued. The RADIUS server obtains the PAC Key from the PAC-Opaque field and derives the shared secret the same way clients do. Secure RADIUS only modifies the way shared secret is derived and not its usage.

EAP-FAST offers two options to provision a client with a PAC:

• Automatic PAC provisioning (EAP-FAST Phase 0 or in-band PAC provisioning)
• Manual (out-of-band) PAC provisioning

Manual PAC provisioning generates the PAC file locally on the ACS server. With manual provisioning, the user credentials are supplied to the server to generate the PAC file for that user. This PAC must then be manually installed on the client device.

1.    enable

2.    configure terminal

3.    radius-server host ip-address auth-port port acct-port port {pac | key encryption-key}

Note	Automatic PAC Provisioning can also be triggered by Secure RADIUS when the server has no PAC or when an Access-Reject message is received from the Autonomous System (AS) says “PAC Expired”.