B-29
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
AppendixB Authentication in ACS 5.4
EAP-FAST
•PAC Migration from ACS 4.x, pageB-29
Key Distribution Algorithm
The common seed-key is a relatively large and a completely random buffer th at is generated by the
primary ACS server. The seed-key is generated only once during installation, or it can be ma nually
regenerated by an administrator. The seed-key should rarely be replaced, because if you change
seed-key, of all the previous master-keys and PACs would automatically be deactivated.
The seed-key is generated by using a FIPS approved RNG generator that exists in the runtime
cryptographic module (CryptoLib). The ACS primary server management determines when t o generate
the seed-key, and communicates with the ACS runtime to request a new seed-key to be generated.
The size of the seed-key may vary and should consist of at least 64 bytes (512 bit). A larger seed might
have some performance implication as each master-key derivation is dependant on it subs equently.
At any given time, a single seed-key should be used by each ACS server and the primary ACS server
should ensure to distribute the latest seed-key to all the servers. Old seed-keys must discarded.
The seed-key contains critical cryptographic sensitive information. Disclosing the seed-key information
would expose the entire EAP-FAST PAC mechanism to a large set of possible identity vulnerabilities.
Because of that, the mechanism which transports the seed-key between the primary and the secondary
ACS servers must be fully secured. Further security measures must be taken with respect to storing the
seed-key in the data-base. The seed-key should be protected with the strongest means of security.
EAP-FAST PAC-Opaque Packing and Unpacking
When the server generates a new PAC, it must derive the master-key to be used. When the server accepts
a new PAC the same algorithm should be used for deriving the master-key with some additional
verification used to prevent possible attacks on the master-key scheme. The derivation calculation may
be skipped if the master-key was already placed in the cache in the past.
Revocation Method
You can revoke all PACs and all Master-Keys. For this type of extensive revocation, all you need to do
is to revoke the seed-key and replace it by a new one.
Having only a single seed-key to be used in the system facilitates implementation.
PAC Migration from ACS 4.x
Although the configuration can be migrated from 4.x, the PACs themselves, as being stored only in
supplicants, may still be issued from versions as far back as ACS 3.x. ACS 5.4 accepts PACs of all types
according to migrated master-keys from versions 4.x and onwards, and re-issues a new 5.0 PAC, similar
to the proactive PAC update for EAP-FAST 5.0.
When ACS 5.4, accepts a PAC from either ACS 3.x or 4.x, it decrypts and authenticates the PAC
according to the 4.x master-key that was migrated from ACS 4.x configuration. The decryption and
handling of this type of PAC is similar to the way the ACS 4.x PAC was handled.
The migration process involves converting the following data-items:
•EAP-FAST A-ID of ACS (Authority ID). The parameter replaces the deployment's A-ID of ACS 5.4.