Possible Pac Failures Caused By Access Point Clock - Allen-Bradley Stratix 5100 User Manual

Chapter 10 Configure an Access Point as a Local Authenticator
338
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
before the key to enter an unencrypted key.
0
• Enter 7 before the key to enter an encrypted key.
Use the form of the commands to reset the local authenticator to the default
no
setting, that is 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 starting up and synchronization with the
NTP server. During this interval, the access point uses its default time setting.
If the local authenticator generates a PAC during that interval, the PAC can 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
startup and NTP-synch, the local authenticator can reject the client's PAC as
invalid.
If your local authenticator does not receive its time setting from an NTP server
and it restarts frequently, PACs generated by the local authenticator can expire at
the right time. The access point clock is reset when the access point restarts, so
the elapsed time on the clock has not reached the PAC expiration time.
Rockwell Automation Publication 1783-UM006A-EN-P - May 2014