9-8
Cisco IOS Software Configuration Guide for Cisco Aironet Access Points
OL-29225-01
Chapter 9 Configuring an Access Point as a Local Authenticator
Configuring a Local Authenticator
In this example, the local authenticator generates a PAC for the username joe, password-protects the file
with the password bingo, sets the PAC to expire in 10 days, and writes the PAC file to the TFTP server
at 10.0.0.5:
AP# radius local-server pac-generate tftp://10.0.0.5 joe password bingo expiry 10
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:
AP(config-radserv)# [no] eapfast authority id identifier
AP(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:
AP(config-radsrv)# [no] eapfast server-key primary {[auto-generate] | [ [0 | 7] key]}
AP(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.