Cisco Acs 57 User Guide

							15   
Authentication in ACS 5.7
PEAPv0/1
Fast Reconnect
When a session resumes, another method of decreasing the authentication time is to skip the inner method, also known 
as fast reconnect. After a tunnel is built, the authentication flow goes directly to exchange authentication information with 
a Result TLV Success (v0)/tunneled EAP Success message for successful authentication and an EAP Failure message in 
case of unsuccessful authentication. 
You can configure ACS to enable the fast reconnect option. After successful authentication, the client is able to perform 
a fast reconnect during a certain timeframe. PEAP fast reconnect reduces the delay in the time between an authentication 
request by a client and the response by ACS. 
Fast reconnect also allows wireless clients to move between access points without repeated requests for authentication, 
which reduces resource requirements for the client and the server.
The user identity and the protocol used for user authentication (inner method) should be cached along with the TLS 
session to allow fast reconnect.
Session Resume
ACS supports a session resume feature for PEAP-authenticated user sessions. When this feature is enabled, ACS caches 
the TLS session that is created during phase one of PEAP authentication, provided that the user successfully 
authenticates in phase two of PEAP.
If a user needs to reconnect and the original PEAP session has not timed out, ACS uses the cached TLS session, resulting 
in faster PEAP performance and a lessened AAA server load.
ACS stores the session in the cache after a successful full authentication. A client may try to resume the same session 
during a specific timeframe. A server certificate is not presented and the tunnel is built by using the session information 
from the OpenSSL/CiscoSSL session cache. The authentication flow then goes directly to the inner method. 
If a client attempts to perform session resume but the timeout elapsed, ACS reverts to the full authentication flow.
You can configure the session resume and timeout values. 
Protected Exchange of Arbitrary Parameters
TLV tuples provide a way to exchange arbitrary information between the peer and ACS within a secure channel. 
Cryptobinding TLV Extension
The cryptobinding TLV extension in MS PEAP authentication is used to ensure that both the EAP peer (client) and the 
EAP server (ACS) are participating in the inner and outer EAP authentications of the PEAP authentication. 
This cryptobinding process takes place as a two-way handshake between the PEAP server and PEAP peer. It consists 
of two messages, which include the cryptobinding request that is sent from a PEAP server to the PEAP peer and the 
cryptobinding response that is sent back from the PEAP peer to the PEAP server. This feature is implemented in ACS as 
primary for the MS Win 7 supplicant. 
The TLV contains a compound MAC that is calculated using the following: PRF based on HMAC-SHA1-160 with TLV body 
as input data, a key derived from the PEAP tunnel key, and the inner method as session key. ACS verifies that the 
cryptobinding response TLV is received from the client. If the compound MAC is not equal to the expected data, then 
ACS fails the conversation. Cryptobinding is available for all inner methods. Cryptobinding is restricted to PEAPv0, 
because there are differences in protected termination flow. Cryptobinding is also applicable for PEAP session resume 
and fast reconnect. Some supplicants may not support cryptobinding TLV. If you send a cryptobinding TLV to a supplicant 
that does not support cryptobinding, then the supplicant does not provide a proper cryptobinding response. This 
improper response is considered to be an error on ACS and is accompanied with a PEAP_CRYPTOBINDING_FAILED 
message.  
						

							16
Authentication in ACS 5.7
 
PEAPv0/1
PEAP Flow in ACS 5.7
The PEAP protocol allows authentication between ACS and the peer by using the PKI-based secure tunnel establishment 
and the EAP-MSCHAPv2 protocol as the inner method inside the tunnel. The local certificate can be validated by the 
peer (server-authenticated mode) or not validated (server-unauthenticated mode).
This section contains:
Creating the TLS Tunnel, page 16
Authenticating with MSCHAPv2, page 17
Figure 8PEAP Processing Flow, page 16 shows the PEAP processing flow between the host, access point, network 
device, and ACS EAP-TLS server.
Figure 8 PEAP Processing Flow
Creating the TLS Tunnel
The following describes the process for creating the TLS tunnel:
271629
Phase 1
Phase 2
User authentication credentials are sent
through TLS Tunnel again using EAP.Client authenticates the server certificate.
TLS Tunnel is created
Client gets network accessAP gets encryption keys
RADIUS Server authenticates
to user repository.
1 After creating a logical link, the wireless AP sends an 
EAP-Request/Identity message to the wireless client.2 The wireless client responds with an 
EAP-Response/Identity message that contains the 
identity (user or computer name) of the wireless 
client.
3 The wireless AP sends the EAP-Response/Identity 
message to ACS. From this point on, the logical 
communication occurs between ACS and the wireless 
client by using the wireless AP as a pass-through 
device. 4 ACS sends an EAP-Request/Start PEAP message to 
the wireless client. 
5 The wireless client and ACS exchange a series of TLS 
messages through which the cipher suite for the TLS 
channel is negotiated. In ACS 5.7, the client certificate 
is not used in PEAP.6 At the end of the PEAP negotiation, ACS has 
authenticated itself to the wireless client. Both nodes 
have determined mutual encryption and signing keys 
(by using public key cryptography, not passwords) 
for the TLS channel.  
						

							17   
Authentication in ACS 5.7
EAP-FAST
Authenticating with MSCHAPv2
After the TLS tunnel is created, follow these steps to authenticate the wireless client credentials with MSCHAPv2: 
At the end of this mutual authentication exchange, the wireless client has provided proof of knowledge of the correct 
password (the response to the ACS challenge string), and ACS has provided proof of knowledge of the correct password 
(the response to the wireless client challenge string). The entire exchange is encrypted through the TLS channel created 
in PEAP. 
Related Topics
Authentication Protocol and Identity Store Compatibility, page 32
Configuring PEAP Settings, page 3
EAP-FAST
This section contains the following topics:
Overview of EAP-FAST, page 17
EAP-FAST Flow in ACS 5.7., page 24
EAP-FAST PAC Management, page 25
Overview of EAP-FAST
The EAP Flexible Authentication via Secured Tunnel (EAP-FAST) protocol is a new, publicly accessible IEEE 802.1x EAP 
type that Cisco developed to support customers that cannot enforce a strong password policy and want to deploy an 
802.1x EAP type that does not require digital certificates. 
EAP-FAST supports a variety of user and password database types, password change and expiration, and is flexible, 
easy to deploy, and easy to manage. For more information about EAP-FAST and comparison with other EAP types, see:
http://www.cisco.com/en/US/products/hw/wireless/ps430/
products_qanda_item09186a00802030dc.shtml.
EAP-FAST is a client-server security architecture that encrypts EAP transactions with a TLS tunnel. While similar to PEAP 
in this respect, it differs significantly in that EAP-FAST tunnel establishment is based on strong secrets that are unique 
to users.1 ACS sends an EAP-Request/Identity message. 2 The wireless client responds with an 
EAP-Response/Identity message that contains the 
identity (user or computer name) of the wireless 
client.
3 ACS sends an EAP-Request/EAP-MSCHAPv2 
challenge message that contains a challenge string.4 The wireless client responds with an 
EAP-Response/EAP-MSCHAPv2 Response 
message that contains the response to the ACS 
challenge string and a challenge string for ACS.
5 ACS sends an EAP-Request/EAP-MSCHAPv2 success 
message, which indicates that the wireless client 
response was correct and contains the response to the 
wireless client challenge string.6 The wireless client responds with an 
EAP-Response/EAP-MSCHAPv2 acknowledgment 
message, indicating that the ACS response was 
correct.
7 ACS sends an EAP-Success message. 
						

							18
Authentication in ACS 5.7
 
EAP-FAST
These secrets are called Protected Access Credentials (PACs), which ACS generates by using a master key known only 
to ACS. Because handshakes based on shared secrets are intrinsically faster than handshakes based on PKI, EAP-FAST 
is the fastest of the advanced EAP protocols (including EAP-TLS and PEAP) that establish a TLS connection to encrypt 
the traffic between the supplicant and ACS. No certificate management is required to implement EAP-FAST.
EAP-FAST occurs in three phases:
Phase zero—Unique to EAP-FAST, phase zero is a tunnel-secured means of providing an EAP-FAST end-user client 
with a PAC for the user requesting network access. (See Automatic In-Band PAC Provisioning, page 21.) 
Providing a PAC to the end-user client is the sole purpose of phase zero. The tunnel is established based on an 
anonymous Diffie-Hellman key exchange for Anonymous In-band provisioning. Authenticated In-band provisioning 
uses other cipher suites. 
If EAP-MSCHAPv2 or EAP-GTC authentication succeeds, ACS provides the user with a PAC. To determine which 
databases support EAP-FAST phase zero, see Authentication Protocol and Identity Store Compatibility, page 32.
Phase zero is optional and PACs can be manually provided to end-user clients. (See Manual PAC Provisioning, 
page 22.) 
The Allow Anonymous In-Band PAC provisioning option provides an end-user client with a PAC by using EAP-FAST 
phase zero. If this check box is checked, ACS establishes a secured connection with the end-user client for the 
purpose of providing the client with a new PAC.
This option allows an anonymous TLS handshake between the end-user client and ACS (EAP-MSCHAPv2 and 
EAP-GTC are used as inner methods.)
The Allow Authenticated In-Band PAC provisioning option provisions an end-user client with a PAC by using 
EAP-FAST phase zero with TLS server-side authentication. This option requires that you install a server certificate.
In general, phase zero of EAP-FAST does not authorize network access. However, if you choose the Accept Client 
on Authenticated Provisioning option, ACS sends a RADIUS Access-Accept (containing an EAP Success) at the end 
of a successful phase zero PAC provisioning, and the client is not forced to reauthenticate again. 
This option can be enabled only when the Allow Authenticated In-Band PAC Provisioning option is also enabled.
Phase one—In phase one, ACS and the end-user client establish a TLS tunnel based on the PAC that the end-user 
client presents. This phase requires that the end-user client has been provided a PAC for the user who is attempting 
to gain network access and that the PAC is not expired. The means by which PAC provisioning has occurred is 
irrelevant; you can use automatic or manual provisioning.
Phase two—In phase two, ACS authenticates the user’s credentials from within the protected TLS tunnel that was 
constructed in phase one, using EAP-MSCHAPv2 or EAP-GTC as the inner EAP method. To determine which 
databases support EAP-FAST phase two, see Authentication Protocol and Identity Store Compatibility, page 32.
Phase one and phase two are subsequent parts of the same EAP-FAST conversation. 
EAP-FAST can protect the username in all EAP-FAST transactions. ACS does not perform user authentication based on 
a username that is presented in phase one, however, whether the username is protected during phase one depends on 
the end-user client. 
If the end-user client does not send the real username in phase one, the username is protected. After phase one of 
EAP-FAST, all data is encrypted, including username information that is usually sent in clear text.
ACS supports password aging with EAP-FAST for users who are authenticated by Windows user databases. Password 
aging can work with phase zero or phase two of EAP-FAST. If password aging requires a user to change passwords 
during phase zero, the new password would be effective in phase two.
EAP-FAST Benefits
EAP-FAST provides the following benefits over other authentication protocols: 
						

							19   
Authentication in ACS 5.7
EAP-FAST
Mutual Authentication—The EAP server must be able to verify the identity and authenticity of the peer and the peer 
must be able to verify the authenticity of the EAP server.
Immunity to passive dictionary attacks—Many authentication protocols require a password to be explicitly provided, 
either as clear text or hashed, by the peer to the EAP server.
Immunity to man-in-the-middle (MitM) attacks—In establishing a mutually authenticated protected tunnel, the 
protocol must prevent adversaries from successfully interjecting information into the conversation between the peer 
and the EAP server.
Flexibility to enable support for many different password authentication interfaces such as MSCHAPv2 and GTC, and 
others—EAP-FAST is an extensible framework that allows support of multiple internal protocols by the same server.
Efficiency—When using wireless media, peers are limited in computational and power resources. EAP-FAST enables 
the network access communication to be computationally lightweight.
Minimization of the authentication server's per user authentication state requirements—With large deployments, it is 
typical to have many servers acting as the authentication servers for many peers. 
It is better for a peer to use the same shared secret to secure a tunnel much the same way it uses the username and 
password to gain access to the network. EAP-FAST facilitates the use of a single strong shared secret by the peer 
while enabling servers to minimize the per-user and device state it must cache and manage.
EAP-FAST in ACS 5.7
ACS supports in-band provisioning of the peer with a shared secret credential (PAC) based on PKI or ADHP (phase 0). 
Authentication of the peer and allowing the peer access to the network is implemented in phase 1 and phase 2.
ACS 5.7 supports EAP-FAST versions 1 and 1a.
This section contains the following topics:
About Master-Keys, page 19
About PACs, page 20
Provisioning Modes, page 20
Types of PACs, page 21
ACS-Supported Features for PACs, page 23
Master Key Generation and PAC TTLs, page 24
EAP-FAST for Allow TLS Renegotiation, page 24
About Master-Keys
EAP-FAST master-keys are strong secrets that ACS automatically generates and of which only ACS is aware. 
Master-keys are never sent to an end-user client. EAP-FAST requires master-keys for two purposes:
PAC generation—ACS generates PACs by using the active master-key. For details about PACs, see About PACs, 
page 20.
EAP-FAST phase one—ACS determines whether the PAC that the end-user client presents was generated by one 
of the master-keys it is aware of.
To  i n c re as e  t h e se c u r i t y  o f  E A P- FAST,  AC S  c h an g e s t h e m a st e r- key  t h at  i t  u s e s t o g en e r a te  PAC s.  AC S  u s e s M as te r  Key  
Generation Period values that you define to determine when it generates a new master-key and the age of all 
master-keys.  
						

							20
Authentication in ACS 5.7
 
EAP-FAST
An active master-key is the master-key used by ACS to generate PACs. The Master Key Generation Period setting 
determines the duration that a master-key remains active. At any time, only one master-key is active. For more 
information about how TTL values determine whether PAC refreshing or provisioning is required, see Master Key 
Generation and PAC TTLs, page 24.
About PACs
PACs are strong shared secrets that enable ACS and an EAP-FAST end-user client to authenticate each other and 
establish a TLS tunnel for use in EAP-FAST phase two. ACS generates PACs by using the active master-key and a 
username. 
PAC comprises:
PAC- Key—Shared secret bound to a client (and client device) and server identity.
PAC  Op aq ue—Opaque field that the client caches and passes to the server. The server recovers the PAC-Key and 
the client identity to mutually authenticate with the client.
PAC- I n f o—At a minimum, includes the Authority ID to enable the client to cache different PACs. Optionally, it includes 
other information such as the PACs expiration time.
An EAP-FAST end-user client stores PACs for each user accessing the network with the client. Additionally, a AAA server 
that supports EAP-FAST has a unique Authority ID. An end-user client associates a user’s PACs with the Authority ID of 
the AAA server that generated them. PACs remove the need for PKI (digital certificates). 
During EAP-FAST phase one, the end-user client presents the PAC that it has for the current user and Authority ID that 
ACS sends at the beginning of the EAP-FAST transaction. The means of providing PACs to end-user clients, known as 
PAC provisioning, are discussed in Automatic In-Band PAC Provisioning, page 21 and Manual PAC Provisioning, 
page 22.
Modifying the master key generation values does not affect already created PACs. Any modifications you make to the 
master key generation values specify the period when the next master keys are generated. 
Provisioning Modes
ACS supports out-of-band and in-band provisioning modes. The in-band provisioning mode operates inside a TLS 
tunnel raised by Anonymous DH or Authenticated DH or RSA algorithm for key agreement.
To minimize the risk of exposing the user’s credentials, a clear text password should not be used outside of the protected 
tunnel. Therefore, EAP-MSCHAPv2 or EAP-GTC are used to authenticate the user's credentials within the protected 
tunnel. The information contained in the PAC is also available for further authentication sessions after the inner EAP 
method has completed.
EAP-FAST has been enhanced to support an authenticated tunnel (by using the server certificate) inside which PAC 
provisioning occurs. The new cipher suites that are enhancements to EAP-FAST, and specifically the server certificate, 
are used. 
At the end of a provisioning session that uses an authenticated tunnel, network access can be granted because the 
server and user have authenticated each other. 
ACS supports the following EAP methods inside the tunnel for provisioning:
EAP-MSCHAPv2
EAP-GTC
By default, when you use EAP-MSCHAP inner methods, ACS allows authentication attempts up to the specified value 
you configured on the Service page inside the TLS tunnel if the initial authentication attempt fails. After the fourth failed 
authentication attempt inside the SSL tunnel, ACS terminates the EAP conversation, resulting in a RADIUS 
Access-Reject. 
						

							21   
Authentication in ACS 5.7
EAP-FAST
ACS supports issuing an out-of-band PAC file that allows you to generate a PAC that can be downloaded to ACS.
Types of PACs
ACS supports the following types of PACs: 
Tunnel v1 and v1a
SGA
Machine
Authorization
ACS provisions supplicants with a PAC that contains a shared secret that is used in building a TLS tunnel between the 
supplicant and ACS. ACS provisions supplicants with PACs that have a wider contextual use.
The following types of PACs are provisioned to ACS, as per server policies:
Tunnel/Machine PAC—Contains user or machine information, but no policy information. 
User Authorization PAC—Contains policy elements (for example, inner method used for user authentication). You 
can use the User Authorization PACs to allow a stateless server session to resume, as described in Session Resume, 
page 15.
The various means by which an end-user client can receive PACs are:
PAC provisioning—Required when an end-user client has no PAC. For more information about how master-key and 
PAC states determine whether PAC provisioning is required, see Master Key Generation and PAC TTLs, page 24.
The two supported means of PAC provisioning are:
—Automatic In-Band PAC Provisioning—Sends a PAC by using a secure network connection. For more 
information, see Automatic In-Band PAC Provisioning, page 21.
—Manual provisioning—Requires that you use ACS to generate a PAC file for the user, copy the PAC file to the 
computer that is running the end-user client, and import the PAC file into the end-user client. For more 
information, see Manual PAC Provisioning, page 22.
PAC refresh—Occurs based on the value you specify in the Proactive PAC Update When field. For more information 
about how master-key and PAC states determine whether a PAC is refreshed, see Master Key Generation and PAC 
TTLs, page 24.
PACs have the following two states, which the PAC TTL setting determines:
Active—A PAC younger than the PAC TTL is considered active and can be used to complete EAP-FAST phase one.
Expired—A PAC that is older than the PAC TTL is considered expired.At the end of EAP-FAST phase two, ACS 
generates a new PAC for the user and provides it to the end-user client.
Automatic In-Band PAC Provisioning
Automatic In-Band PAC Provisioning, which is the same as EAP-FAST phase zero, sends a new PAC to an end-user client 
over a secured network connection. Automatic In-Band PAC Provisioning requires no intervention of the network user or 
an ACS administrator, provided that you configure ACS and the end-user client to support Automatic In-Band PAC 
Provisioning.
Note: Given that ACS associates each user with a single identity store, the use of Automatic In-Band PAC Provisioning 
requires that EAP-FAST users be authenticated with an identity store that is compatible with EAP-FAST phase zero. For 
the databases with which ACS can support EAP-FAST phase zero and phase two, see Authentication Protocol and  
						

							22
Authentication in ACS 5.7
 
EAP-FAST
Identity Store Compatibility, page 32.
In general, phase zero of EAP-FAST does not authorize network access. In this general case, after the client has 
successfully performed phase zero PAC provisioning, the client must send a new EAP-FAST request in order to begin a 
new round of phase one tunnel establishment, followed by phase two authentication.
However, if you choose the Accept Client on Authenticated Provisioning option, ACS sends a RADIUS Access-Accept 
(that contains an EAP Success) at the end of a successful phase zero PAC provisioning, and the client is not forced to 
reauthenticate again. This option can be enabled only when the Allow Authenticated In-Band PAC Provisioning option is 
also enabled.
Because transmission of PACs in phase zero is secured by MSCHAPv2 authentication, when MSCHAPv2 is vulnerable to 
dictionary attacks, we recommend that you limit use of Automatic In-Band PAC Provisioning to initial deployment of 
EAP-FAST. 
After a large EAP-FAST deployment, PAC provisioning should be done manually to ensure the highest security for PACs. 
For more information about manual PAC provisioning, see Manual PAC Provisioning, page 22.
To control whether ACS performs Automatic In-Band PAC Provisioning, use the options on the Global System Options 
pages in the System Administration drawer. For more information, see EAP-FAST, page 17.
Manual PAC Provisioning
Manual PAC provisioning requires an ACS administrator to generate PAC files, which must then be distributed to the 
applicable network users. Users must configure end-user clients with their PAC files. 
You can use manual PAC provisioning to control who can use EAP-FAST to access your network. If you disable Automatic 
In-Band PAC Provisioning, any EAP-FAST user who is not provisioned with a PAC will not be able to access the network.
If your ACS deployment includes network segmentation, wherein a separate ACS controls access to each network 
segment, manual PAC provisioning enables you to grant EAP-FAST access on a per-segment basis. 
For example, if your company uses EAP-FAST for wireless access in its Chicago and Boston offices and the Cisco Aironet 
Access Points at each of these two offices are configured to use different ACSs, you can determine, on a per-employee 
basis, whether Boston employees visiting the Chicago office can have wireless access.
While the administrative overhead of manual PAC provisioning is much greater than that of automatic in-band PAC 
provisioning, it does not risk sending the PAC over the network. Although manually provisioning the PACs requires a lot 
of effort early on, in configuring many end-user clients during the initial deployment, this type of provisioning is the most 
secure means for distributing PACs. 
We recommend that, after a large EAP-FAST deployment, you manually perform PAC provisioning to ensure the highest 
security for PACs.
You can generate PAC files for specific usernames. You can also generate a PAC for a machine and provision the PAC 
manually to the client. 
The following parameters are required to create a PAC:
Specifying whether it is a user or machine PAC.
Identity stored in Internal Identity Store ID field.
PAC Time to Live (TTL).
PAC encryption on or off, and password for encryption.
The PAC could be encrypted with the specified password by using the RC4 or AES algorithm. The detailed decryption 
algorithm must be provided to the client to allow decryption of the manually received PAC data. 
						

							23   
Authentication in ACS 5.7
EAP-FAST
ACS-Supported Features for PACs
ACS 5.7 support these features for PACs.
Machine PAC Authentication
Machine PAC-based authentication allows the machine to gain restricted network access before user authentication.
Proactive PAC Update 
ACS proactively provides a new PAC to the client after successful authentication when a configured percentage of the 
PAC TTL remains. The tunnel PAC update is initiated by the server after the first successful authentication that is 
performed before the PAC expiration. 
The proactive PAC update time is configured for the ACS server in the Allowed Protocols Page. This mechanism allows 
the client to be always updated with a valid PAC.
Note: There is no proactive PAC update for Machine and Authorization PACs.
Accept Peer on Authenticated Provisioning
The peer may be authenticated during the provisioning phase.
PAC-Less Authentication
With PAC-less EAP-FAST Authentication, you can run EAP-FAST on ACS without issuing or accepting any tunnel or 
machine-generated PAC. The secure tunnel may be established by using a certificate rather than a PAC. Some PACs 
may be long-lived and not updated, which may cause authentication and security problems. 
When PAC-less EAP-FAST is enabled, requests for PACs are ignored. Authentication begins with EAP-FAST phase zero 
and all subsequent requests for PACs are ignored. The flow moves on to EAP-FAST phase two. ACS responds with a 
Success-TLV message, without a PAC. 
If a client attempts to establish a tunnel with a PAC, ACS responds with a PAC Invalid message. The tunnel establishment 
does not occur, and an Access-Reject is sent. The host or supplicant can reattempt to connect.
Anonymous phase zero, also known as ADHP is not supported for PAC-less authentication since the protocol does not 
support rolling over to phase two. PAC-less EAP-Fast supports configuration and does not require a client certificate.
Table 43 on page 23 displays the different types of PACs and the authentication and authorization methods you can use 
them for.
Ta b l e 4 3 PA C  R u l e s  S u m m a r y
PAC Type  Tunnel v1/v1a/SGA  Machine  Authorization
Provide PAC on request on 
provisioningYes Yes Provide PAC on request on 
provisioning.
Provide PAC on request on 
authenticationYes Yes Only if the PAC was not used in 
this authentication.
Proactive update Yes No  No
When PAC is expired Reject, try to fall on TLS 
fallback, provide a new PAC 
after successful 
authentication only (tunnel 
PAC ) .Reject, try to fall on TLS 
fallback, provide a new PAC 
after successful 
authentication only (machine 
PAC) .Reject and provide a new PAC 
after successful authentication 
only (authorization PAC).
Support ACS 3.x/4.x PACs For Tunnel PAC v1/v1a only Yes No 
						

							24
Authentication in ACS 5.7
 
EAP-FAST
Related Topics
About PACs, page 20
Provisioning Modes, page 20
Types of PACs, page 21
Master Key Generation and PAC TTLs, page 24
Master Key Generation and PAC TTLs
The values for master key generation and PAC TTLs determine their states, as described in About Master-Keys, page 19 
and Types of PACs, page 21. Master key and PAC states determine whether someone requesting network access with 
EAP-FAST requires PAC provisioning or PAC refreshing. 
Related Topics
About PACs, page 20
Provisioning Modes, page 20
Types of PACs, page 21
ACS-Supported Features for PACs, page 23
EAP-FAST for Allow TLS Renegotiation
You may be prompted to enter a password twice when you use an anonymous PAC provisioning schema. When you enter 
the password the first time, ACS provisions the PAC and sends an access-reject to the client. The client is then prompted 
to re-enter the password so that they will be able to authenticate and be granted access to the network. 
ACS checks for a TLS client handshake record. If it finds the TLS client handshake record, ACS will initiate a TLS 
renegotiation at the end of EAP-Fast phase zero, instead of rejecting the user’s request for access.
You should use this option with a Vista client when the host is using anonymous PAC provisioning. Vista client do not save 
the user password in the cache, so you are allowed to enter the password once. When this option is enabled, ACS 
initiates the TLS renegotiation request to the client at the end of EAP-FAST phase zero, instead of rejecting the access 
attempt after PAC provisioning.
EAP-FAST Flow in ACS 5.7.
Note: You must configure the end-user clients to support EAP-FAST. This procedure is specific to configuring ACS only.
Before You Begin
The steps in this procedure are a suggested order only. Enabling EAP-FAST at your site may require recursion of these 
steps or performing these steps in a different order.
For example, in this procedure, determining how you want to support PAC provisioning comes after configuring a user 
database to support EAP-FAST; however, choosing Automatic In-Band PAC Provisioning places different limits on user 
database support.
To enable ACS to perform EAP-FAST authentication:
1.Configure an identity store that supports EAP-FAST authentication. 
To determine which identity stores support EAP-FAST authentication, see Authentication Protocol and Identity Store 
Compatibility, page 32. For information about configuring identity stores, see Managing Users and Identity Stores, 
page 1
2.Determine master key generation and PAC TTL values.