Cisco Acs 57 User Guide

							25   
Authentication in ACS 5.7
EAP-FAST
For information about how master key generation and PAC TTL values determine whether PAC provisioning or PAC 
refreshing is required, see Master Key Generation and PAC TTLs, page 24.
3.Determine whether you want to use automatic or manual PAC provisioning. 
For more information about the two means of PAC provisioning, see Automatic In-Band PAC Provisioning, page 21, 
and Manual PAC Provisioning, page 22.
We recommend that you limit the use of Automatic In-Band PAC Provisioning to initial deployments of EAP-FAST, 
before you use manual PAC provisioning for adding small numbers of new end-user clients to your network and 
replacing PACs based on expired master keys.
4.Using the decisions during 2.Determine master key generation and PAC TTL values., page 24 and 3.Determine 
whether you want to use automatic or manual PAC provisioning., page 25, enable EAP-FAST in the Global Systems 
Options drawer. See EAP-FAST, page 17 for more information.
ACS is ready to perform EAP-FAST authentication.
Note: Inner-identity will not be logged when: 
the workstation not allowed error appears, the SSL Handshake fails, 
EAP-PAC is provisioned, and ACS receives an invalid PAC.
Related Topics
Managing Internal Identity Stores, page 4
Managing External Identity Stores, page 29
EAP-FAST PAC Management
The EAP-FAST master-key in ACS is used to encrypt or decrypt, sign and authenticate the PACs and PAC-Opaque's that 
are used by EAP-FAST to store server opaque data by a supplicant. EAP-FAST requires a distributed mechanism by 
which each server in the ACS domain is able to pack and unpack PACs securely, including those which were packed on 
a different server.
The EAP-FAST master-key must have a common secret that is known to all servers in the ACS domain. The master-key 
is periodically refreshed and keys are replaced securely and synchronized by all ACS servers.
In previous versions of ACS, the master-key was distributed by the ACS distribution mechanism and was replaced from 
time to time to improve the security of those keys. ACS 5.7 introduces a new scheme that provides simplicity, 
correctness, robustness, and security for master -key distribution.
The ACS EAP-FAST new distribution scheme contains a secure way of distributing the common seed-key, from which 
each ACS server can deterministically derive the same set of master-keys. Each PAC contains the information that the 
master-key was derived from, and each server can securely reconstruct the master-key that encrypted and signed the 
PAC.
This scheme improves the security by reducing the amount of cryptographic sensitive material that is transmitted. 
This section contains the following topics: 
Key Distribution Algorithm, page 26
EAP-FAST PAC-Opaque Packing and Unpacking, page 26
Revocation Method, page 26
PAC Migration from ACS 4.x, page 26 
						

							26
Authentication in ACS 5.7
 
EAP-FAST
Key Distribution Algorithm
The common seed-key is a relatively large and a completely random buffer that is generated by the primary ACS server. 
The seed-key is generated only once during installation, or it can be manually 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 RNG generator that exists in the runtime cryptographic module (CryptoLib). The 
ACS primary server management determines when to 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 dependent on it subsequently. 
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.7 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.7, 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.7.
A list of retired ACS 4.x master-keys. The list is taken from the ACS 4.x configuration and placed in a new table in 
ACS 5.7. Each migrated master-key is associated with its expected time of expiration. The table is migrated along 
with the master-key identifier (index) and the PAC's-cipher assigned to each key. 
						

							27   
Authentication in ACS 5.7
EAP Authentication with RADIUS Key Wrap
EAP Authentication with RADIUS Key Wrap
You can configure ACS to use PEAP, EAP-FAST and EAP-TLS authentication with RADIUS Key Wrap. ACS can then 
authenticate RADIUS messages and distribute the session key to the network access server (NAS). The EAP session key 
is encrypted by using Advanced Encryption Standard (AES), and the RADIUS message is authenticated by using 
HMAC-SHA-1.
Because RADIUS is used to transport EAP messages (in the EAP-Message attribute), securely authenticating RADIUS 
messages ensures securely authenticated EAP message exchanges. You can use RADIUS Key Wrap when PEAP, 
EAP-FAST and EAP-TLS authentication is enabled as an external authentication method. Key Wrap is not supported for 
EAP-TLS as an inner method (for example, for EAP-FAST or PEAP). 
RADIUS Key Wrap support in ACS uses three new AVPs for the cisco-av-pair RADIUS Vendor-Specific-Attribute (VSA); 
the TLV value of Cisco VSA is [26/9/1]):
Random-Nonce—Generated by the NAS, it adds randomness to the key data encryption and authentication, and links 
requests and response packets to prevent replay attacks.
Key—Used for session key distribution.
Message-Authenticator-Code—Ensures the authenticity of the RADIUS message, including the EAP-Message and 
Key attributes.
While using RADIUS Key Wrap, ACS enforces the use of these three RADIUS Key Wrap AVPs for message exchanges 
and key delivery. ACS will reject all RADIUS (EAP) requests that contain both RADIUS Key Wrap AVPs and the standard 
RADIUS Message-Authenticator attribute. 
To use RADIUS Key Wrap in PEAP, EAP-FAST and EAP-TLS authentications, you must enable the EAP authentication with 
RADIUS KeyWrap in the Network Devices and AAA Clients page or Default Network Device page. 
You must also define two shared secret keys for each AAA Client. Each key must be unique and be distinct from the 
RADIUS shared key. RADIUS Key Wrap does not support proxy functionality, and should not be used with a proxy 
configuration.
EAP-MSCHAPv2
Microsoft Challenge Handshake Authentication Protocol (MSCHAP v2) provides two-way authentication, also known as 
mutual authentication. The remote access client receives verification that the remote access server that it is dialing in to 
has access to the user's password.
This section contains the following topics:
Overview of EAP-MSCHAPv2, page 27
EAP- MSCHAPv2 Flow in ACS 5.7, page 28
Overview of EAP-MSCHAPv2
Some of the specific members of the EAP family of authentication protocols, specifically EAP-FAST and PEAP, support 
the notion of an “EAP inner method.” This means that another EAP-based protocol performs additional authentication 
within the context of the first protocol, which is known as the "EAP outer method."
One of the inner methods supported by the EAP-FAST and PEAP outer methods is EAP-MSCHAPv2, which is an 
adaptation of the MSCHAPv2 protocol that complies with the general framework established by EAP.
Using EAP-MSCHAPv2 as the inner EAP method facilitates the reuse of Microsoft directory technology (such as Windows 
Active Directory), with the associated database of user credentials for wireless authentication in the following contexts: 
						

							28
Authentication in ACS 5.7
 
CHAP
MSCHAPv2 for User Authentication, page 28
MSCHAPv2 for Change Password, page 28
Windows Machine Authentication Against AD, page 28
MSCHAPv2 for User Authentication
ACS supports the EAP-MSCHAPv2 authentication protocol as the inner method of EAP-FAST and PEAP. The protocol is 
an encapsulation of MSCHAPv2 into the EAP framework. Mutual authentication occurs against the configured credential 
database. 
The client does not send its password, but a cryptographic function of the password. Using EAP-MSCHAPv2 as the inner 
method of tunneling protocols, increases protection of secured communication. Every protocol message is encrypted 
inside the tunnel and server, and client challenges are not generated randomly but, derived from outer method 
cryptographic material. 
EAP-MSCHAPv2 is supported for AD and the ACS internal identity store.
MSCHAPv2 for Change Password
When you use EAP-MSCHAPv2 (as an EAP inner method) to authenticate a user whose password has expired, ACS 
sends a specific EAP-MSCHAPv2 failure notification to the client. The client can prompt the user for new password and 
then provide it to ACS inside the same conversation. 
The new password is encrypted with the help of the old one. When a user password is changed successfully, the new 
user password is stored in the credential database. 
EAP-MSCHAPv2 change password is supported for AD and ACS internal identity store.
Windows Machine Authentication Against AD
EAP-MSCHAPv2 can be used for machine authentication. EAP-MSCHAPv2 Windows machine authentication is the same 
as user authentication. The difference is that you must use the Active Directory of a Windows domain, since a machine 
password can be generated automatically on the machine and the AD, as a function of time and other parameters. The 
password generated cannot be stored in other types of credential databases.
EAP- MSCHAPv2 Flow in ACS 5.7
Components involved in the 802.1x and MSCHAPv2 authentication process are the: 
Host—The end entity, or end user’s machine.
AAA client—The network access point.
Authentication server—ACS. 
The MSCHAPv2 protocol is described in RFC 2759.
Related Topic
Authentication Protocol and Identity Store Compatibility, page 32
CHAP
CHAP uses a challenge-response mechanism with one-way encryption on the response. CHAP enables ACS to 
negotiate downward from the most secure to the least secure encryption mechanism, and it protects passwords that are 
transmitted in the process. CHAP passwords are reusable. 
						

							29   
Authentication in ACS 5.7
LEAP
If you are using the ACS internal database for authentication, you can use PAP or CHAP. CHAP does not work with the 
Windows user database. Compared to RADIUS PAP, CHAP allows a higher level of security for encrypting passwords 
when communicating from an end-user client to the AAA client.
LEAP
ACS currently uses LEAP only for Cisco Aironet wireless networking. If you do not enable this option, Cisco Aironet 
end-user clients who are configured to perform LEAP authentication cannot access the network. If all Cisco Aironet 
end-user clients use a different authentication protocol, such as EAP-TLS, we recommend that you disable this option.
Note: If users who access your network by using a AAA client that is defined in the Network Configuration section as a 
RADIUS (Cisco Aironet) device, then you must enable LEAP, EAP-TLS, or both; otherwise, Cisco Aironet users cannot 
authenticate.
Certificate Attributes
ACS parses the following client certificate’s attributes:
Certificate serial-number (in binary format)
Encoded certificate (in binary DER format)
Subject’s CN attribute
Subject’s O attribute (Organization)
Subject’s OU attribute (Organization Unit)
Subject’s L attribute (Location)
Subject’s C attribute (Country)
Subject’s ST attribute (State Province)
Subject’s E attribute (eMail)
Subject’s SN attribute (Subject Serial Number)
Issuer I attribute 
SAN (Subject Alternative Name)
You can define a policy to set the principle username to use in the TLS conversation, as an attribute that is taken from 
the received certificate.
The attributes that can be used as the principle username are:
Subject CN
Subject Serial-Number (SN)
SAN
Subject
SAN—Email
SAN—DNS 
						

							30
Authentication in ACS 5.7
 
Certificate Attributes
SAN—otherName
If the certificate does not contain the configured attribute, authentication fails.
Note: ACS 5.7 supports short hard-coded attributes and certificate attribute verification for the only the EAP-TLS 
protocol.
Certificate Binary Comparison
You can perform binary comparison against a certificate that ACS receives from an external identity store and determine 
the identity store's parameters that will be used for the comparison.
Note: In ACS 5.7, AD and LDAP are the only external identity stores that hold certificates.
ACS uses the configured principle username to query for the user's certificate and then perform binary comparison 
between the certificate received from external identity store and the one received from the client. The comparison is 
performed on a DER certificate format.
Rules Relating to Textual Attributes
ACS collects client certificate textual attributes and places them in the ACS context dictionary. ACS can apply any rule 
based policy on these attributes as with any rule attributes in ACS.
The attribute that can be used for rule verification are:
Subject's CN attribute
Subject's O attribute (Organization)
Subject's OU attribute (Organization Unit)
Subject's L attribute (Location)
Subject's C attribute (Country)
Subject's ST attribute (State Province)
Subject's E attribute (eMail)
Subject's SN attribute (Subject Serial Number)
Issuer I attribute 
SAN (Subject Alternative Name)
Subject
SAN—Email
SAN—DNS
SAN—otherName
Certificate Revocation
Every client certificate that ACS receives is verified with a Certificate Revocation List (CRL) according to a policy that is 
defined.
The CRL mechanism verifies whether or not you can still rely on a client certificate. This is done by checking the serial 
number of the certificate, and that of each member of the corresponding certificate chain, against a list of certificates 
that are known to have been revoked.  
						

							31   
Authentication in ACS 5.7
Machine Authentication
Possible reasons for revocation of a certificate include suspicion that the associated private key has been compromised 
or the realization that the certificate was issued improperly. If either of these conditions exist, the certificate is rejected.
ACS supports a static-CRL that contains a list of URLs used to acquire the CRL files that are configured in ACS database.
Note: ACS does not support delta CRLs in certificate revocation validation. 
You can configure a set of URLs used for CRL update for each trusted CA certificate,. By default, when adding a CA 
certificate, ACS automatically sets all the URLs stored in the certificate crlDistributionPoint as the initial static CRL for that 
CA. In most cases, the crlDistributionPoint is used to point to the CRL location used to revoke the CA certificate, but you 
can edit the URL to point to the CRL file issued by this CA. You can only configure a single HTTP based URL for each CA. 
You can configure the parameters for each CA, which will apply to all the URLs that are configured to the CA. ACS 
supports two download modes, one for periodic download, and the other for downloading the next CRL update just 
before the previous is about to expire. 
For the periodic download, you can define the download periods. 
For automatic downloading, you define the amount of time before the CRL file expires, should ACS download it. The 
CRL expiration time is taken from the CRL nextUpdate field. 
For both modes, if the download somehow fails, you can define the amount of time that ACS will wait before trying to 
redownload the CRL file.
ACS verifies that the downloaded CRL file is signed correctly by any one of the CAs in the trust store, for each 
downloaded CRL file and whether they are trusted. ACS uses the CRL file only if the signature verification passes. The 
verified CRL file replaces the previous CRL file issued by the same CA. 
Note: CRL files are not kept persistent, and should be re-downloaded when you restart ACS.
The configuration of URLs and their association to CA's is distributed to the entire ACS domain. The downloaded CRLs 
are not distributed and are autonomously populated in parallel in each ACS server.
Machine Authentication
ACS supports the authentication of computers that are running the Microsoft Windows operating systems that support 
EAP computer authentication. Machine authentication, also called computer authentication, allows networks services 
only for computers known to Active Directory. 
This feature is especially useful for wireless networks, where unauthorized users outside the physical premises of your 
workplace can access your wireless access points.
When machine authentication is enabled, there are three different types of authentications. When starting a computer, 
the authentications occur in this order:
Machine authentication—ACS authenticates the computer prior to user authentication. ACS checks the credentials 
that the computer provides against the Windows identity store. 
If you use Active Directory and the matching computer account in AD has the same credentials, the computer gains 
access to Windows domain services.
User domain authentication—If machine authentication succeeded, the Windows domain authenticates the user. If 
machine authentication failed, the computer does not have access to Windows domain services and the user 
credentials are authenticated by using cached credentials that the local operating system retains. 
In this case, the user can log in to only the local system. When a user is authenticated by cached credentials, instead 
of the domain, the computer does not enforce domain policies, such as running login scripts that the domain 
dictates. 
						

							32
Authentication in ACS 5.7
 
Authentication Protocol and Identity Store Compatibility
Note: If a computer fails machine authentication and the user has not successfully logged in to the domain by using the 
computer since the most recent user password change, the cached credentials on the computer will not match the new 
password. Instead, the cached credentials will match an older password of the user, provided that the user once 
successfully logged in to the domain from this computer.
User network authentication—ACS authenticates the user, allowing the user to have network connectivity. If the user 
exists, the identity store that is specified is used to authenticate the user. 
While the identity store is not required to be the Windows identity store, most Microsoft clients can be configured to 
automatically perform network authentication by using the same credentials used for user domain authentication. 
This method allows for a single sign-on.
Note: Microsoft PEAP clients may also initiate machine authentication whenever a user logs off. This feature prepares the 
network connection for the next user login. Microsoft PEAP clients may also initiate machine authentication when a user 
shuts down or restarts the computer rather than just logging off.
ACS supports EAP-TLS, EAP-FAST, PEAP (EAP-MSCHAPv2), and PEAP (EAP-GTC) for machine authentication. You can 
enable each separately on the Active Directory: General Page, which allows a mix of computers that authenticate with 
EAP-TLS, EAP-FAST, or PEAP (EAP-MSCHAPv2). 
Microsoft operating systems that perform machine authentication might limit the user authentication protocol to the same 
protocol that is used for machine authentication.
Related Topics
Microsoft AD, page 50
Managing External Identity Stores, page 29
Authentication Protocol and Identity Store Compatibility
ACS supports various authentication protocols to authenticate against the supported identity stores.
Table 44 on page 32 specifies non-EAP authentication protocol support.
Table 45 on page 33 specifies EAP authentication protocol support.
Table 44 Non-EAP Authentication Protocol and User Database Compatibility
Identity Store ASCII/PAP MSCHAPv1/MSCHAPv2 CHAP
ACS Yes Yes Yes
Windows AD Yes Yes No
LDAP Yes No No
RSA Identity 
StoreYe s N o N o
RADIUS 
Identity StoreYe s N o N o 
						

							33   
Authentication in ACS 5.7
Authentication Protocol and Identity Store Compatibility
Table 45 EAP Authentication Protocol and User Database Compatibility
Identity Store EAP-MD5 EAP-TLS1
1. In EAP-TLS authentication, the user is authenticated by cryptographic validation of the certificate. Additionally, ACS 5.7 optionally allows a 
binary comparison of the user’s certificate sent by the end-user client against the certificate located in the user’s record in the LDAP identity 
store.
PEAP-TLS2
2. In PEAP-TLS authentication, the user is authenticated by cryptographic validation of the certificate. Additionally, ACS 5.7 optionally allows a 
binary comparison of the user’s certificate sent by the end-user client against the certificate located in the user’s record in the LDAP identity 
store.
PEAP 
EAP-MSCHAP
v2EAP-FAST 
MSCHAPv2PEAP-GTC EAP-FAST
-GTC
ACS Yes Yes
3
3. ACS Identity Store cannot store the certificates.
Ye s Ye s Ye s Ye s Ye s
W i n d o w s  A D N o Ye s Ye s Ye s Ye s Ye s Ye s
LDAP No Yes Yes No No Yes Yes
RSA Identity 
StoreNo No No No No Yes Yes
RADIUS Identity 
StoreNo No No No No Yes Yes 
						

							34
Authentication in ACS 5.7
 
Authentication Protocol and Identity Store Compatibility