Cisco Systems OL-6415-04 manual Configuring an Authority ID, Configuring Server Keys

Chapter 4 Configuring an Access Point as a Local Authenticator

Configure a Local Authenticator

Configuring an Authority ID

All EAP-FAST authenticators are identified by an authority identity (AID). The local authenticator sends its AID to an authenticating client, and the client checks its database for a matching AID. If the client does not recognize the AID, it requests a new PAC.

Use these commands to assign an AID to the local authenticator:

router(config-radserv)# [no] eapfast authority id identifier

router(config-radserv)# [no] eapfast authority info identifier

The eapfast authority id command assigns an AID that the client device uses during authentication.

Configuring Server Keys

The local authenticator uses server keys to encrypt PACs that it generates and to decrypt PACs when authenticating clients. The server maintains two keys, a primary key and a secondary key, and uses the primary key to encrypt PACs. By default, the server uses a default value as the primary key but does not use a secondary key unless you configure one.

When the local authenticator receives a client PAC, it attempts to decrypt the PAC with the primary key. If decryption fails with the primary, the authenticator attempts to decrypt the PAC with the secondary key if one is configured. If decryption fails, the authenticator rejects the PAC as invalid.

Use these commands to configure server keys:

router(config-radsrv)# [no] eapfast server-key primary {[auto-generate] [ [0 7] key]}

router(config-radsrv)# [no] eapfast server-key secondary [0 7] key

Keys can contain up to 32 hexadecimal digits. Enter 0 before the key to enter an unencrypted key. Enter 7 before the key to enter an encrypted key. Use the no form of the commands to reset the local authenticator to the default setting, which is to use a default value as a primary key.

Possible PAC Failures Caused by Access Point Clock

The local authenticator uses the access point clock to both generate PACs and to determine whether PACs are valid. However, relying on the access point clock can lead to PAC failures.

If your local authenticator access point receives its time setting from an NTP server, there is an interval between boot up and synchronization with the NTP server during which the access point uses its default time setting. If the local authenticator generates a PAC during that interval, the PAC might be expired when the access point receives a new time setting from the NTP server. If an EAP-FAST client attempts to authenticate during the interval between boot and NTP-synch, the local authenticator might reject the client’s PAC as invalid.

If your local authenticator does not receive its time setting from an NTP server and it reboots frequently, PACs generated by the local authenticator might not expire when they should. The access point clock is reset when the access point reboots, so the elapsed time on the clock would not reach the PAC expiration time.

Cisco Wireless ISR and HWIC Access Point Configuration Guide

4-10 OL-6415-04