Table of Contents
Advertisement
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
Chapter 4
Configuring an Access Point as a Local Authenticator
OL-6415-04
Advertisement
Table of Contents
