Cisco Acs 5x User Guide

							B-11
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix B      Authentication in ACS 5.3
  EAP-TLS
There are two types of certificate generation:
Self signing certificate generation — ACS supports generation of an X.509 certificate and a 
PKCS#12 private key. The passphrase used to encrypt the private key in the PKCS#12 automatically 
generates stronger passwords, and the private key is hidden in the local certificate store.
You can select the newly generated certificate for immediate use for HTTPS Management protocol, 
for TLS-related EAP protocols, or both. 
Certificate request generation—ACS supports generation of a PKCS#10 certificate request with a 
PKCS#12 private key. The request is downloaded through the Web interface and should be formatted 
with PEM representation with a REQ extension. 
The passphrase used to encrypt the private key in the PKCS#12 automatically generates stronger 
passwords, and the private-key is hidden in the ACS database. You can download the request file to 
be signed offline by the RA. 
After the RA signs the request, you can install the returned signed certificate on ACS and bind the 
certificate with its corresponding private key. The binding of certificate and its private key is 
automatic. 
After binding the signed certificate with the private key, you can mark this certificate for immediate 
use for HTTPS Management protocol, for TLS-related EAP protocols, or both. 
Related Topics
Configuring CA Certificates, page 8-68
Configuring Certificate Authentication Profiles, page 8-73
EAP-TLS Flow in ACS 5.3, page B-13
Exporting Credentials
You can export a general trust certificates, an ACS server certificate with or without private keys, and 
previously generated certificates requests from the certificate stores. You cannot export the request for 
a private-key. You can download certificates file with a .CER extension. The file format is not changed 
from the format that is imported into ACS.
You can download the public certificate as a regular certificate with .CER extension for ACS server 
certificates, that also contain a private key. The file format is retained. 
You can export a public request to re-issue a certificate request to an RA, for certificate-requests. The 
request is downloaded with an REQ extension and is formatted identically to the format that it was 
generated by.
Only administrators with the highest administrator privileges can export the certificate private key and 
its password. A warning about the security implications of such an action is conveyed twice, to approve 
the export operation. 
After this double check, the private-key files can be downloaded as a .PVK extension, and the private-key 
password can be downloaded as a .PWD extension. The private-key file format is retained.  
						

							B-12
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix B      Authentication in ACS 5.3
  EAP-TLS
Credentials Distribution
All certificates are kept in the ACS database which is distributed and shared between all ACS nodes. The 
ACS server certificates are associated and designated for a specific node, which uses that specific 
certificate.
Public certificates are distributed along with the private keys and the protected private key passwords by 
using the ACS distributed mechanism. ACS implements a method of protection to prevent a private-key 
to be used by other servers other than the one to which the private-key is designated to. This protection 
mechanism applies only to encrypted private-keys.
The PKI policy for private keys is that private keys are not supposed to be usable by other entities which 
are not associated with the ACS server to which they are designated to. ACS supports cryptographic 
protection of the private-keys to prevent possible use outside of the ACS server machine to which they 
are designated to. 
Hardware Replacement and Certificates
When hardware fails, a new node is used for replacing a malfunctioning node. The malfunctioning nodes 
certificates are removed from the distributed database of the primary server, and the new nodes 
certificates are then being passed to the primary to be associated with the newly replaced node.
This process of certificate changing is conducted as part of the hardware replacement process when the 
new node registered to the domain, The certificate distribution is based on the server’s IP address.
Securing the Cryptographic Sensitive Material
There are several types of PKI-related keys that are stored in the ACS database. These keys have different 
cryptographic storage requirements that must comply to SEC-RCV-CRED-2 which is part of the Cisco 
security baseline. These requirements include:
Public keys that usually reside in a certificate may be stored plain open as they are used to pass on 
the clear text to clients and contain only public keys. 
Private keys must be stored encrypted as PKCS#12 by using a relatively strong password.
The password for the PKCS#12 private-keys must be stored in the ACS database. Since the ACS 
database is encrypted, this does not pose a serious security concern. ACS 5.3 distributes the entire 
database between all the ACS servers. 
ACS encrypts the private-key passwords by using a password that exists only for the machine, thus 
preventing possible use of the private-keys by other machines. The private-key password key is 
maintained in /opt/CSCOacs/config/prikeypwd.key on the ACS file-system. 
Other certificate repositories such as the tomcat key-store should have the same properties as the ACS 
database. Private-keys are encrypted by a password that is kept secured in the database. 
						

							B-13
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix B      Authentication in ACS 5.3
  EAP-TLS
Private Keys and Passwords Backup
The entire ACS database is distributed and backed-up on the primary ACS along with all the certificates, 
private-keys and the encrypted private-key-passwords. The private-key-password-key of the primary 
server is also backed up with the primarys backup. 
Other secondary ACS private-key-password-keys are not backed-up. Backups are encrypted and also can 
pass relatively secured in and out of the ACS servers. The private keys in backups are protected by the 
PKCS#12 and the backup file encryption. The passwords that are used to open the PKCS#12 private-keys 
are protected with the backup encryption.
EAP-TLS Flow in ACS 5.3
An EAP-TLS server exchanges data with a client by using packets based on the EAP Request and 
response packets; the packets are extended by specific EAP-TLS data. ACS acts as the EAP-TLS server, 
and uses the Open Secure Sockets Layer (OpenSSL) library to process the TLS conversation. The ACS 
EAP-TLS server produces 128-bit MPPE send and receive keys that are used for encrypted 
communication between the client and server. 
The ACS EAP-TLS server sends MPPE keys to the client in vendor-specific RADIUS attribute (26) by 
using vendor code Microsoft (311), and attributes MS-MPPE-Send-Key (16) and MS-MPPE-Recv-Key 
(17).
Figure B-2 shows the EAP-TLS processing flow between the host, network device, and ACS EAP-TLS 
server.
Figure B-2 EAP-TLS Flow 
1A host connects to the network. The network device 
sends an EAP Request to the host.2The host sends an EAP Response to the network device; 
the network device embeds the EAP packet that it 
received from the host into a RADIUS Access-Request 
and sends it to ACS.
3ACS negotiates the EAP method for authentication. The 
server and client must reach agreement to use EAP-TLS 
(EAP Request method 13) during EAP method 
negotiation to instantiate EAP-TLS authentication.4The client (host) and server (ACS) exchange certificates; 
this exchange involves several messages. 
EAP-TLS authentication is successful after the client and 
server have authenticated each other, and each side is 
aware that the other side has authenticated them.
5ACS returns an EAP Success (or EAP Failure) message 
to the host and returns a RADIUS Access-Accept (or 
RADIUS Access-Reject) that includes session keys to the 
network device.
X.25 Host
Host
Network deviceACS EAP-TLS
server 1
2
3
4
5
204584 
						

							B-14
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix B      Authentication in ACS 5.3
  PEAPv0/1
NoteAll communication between the host and ACS goes through the network device.
EAP-TLS authentication fails if the:
Server fails to verify the client’s certificate, and rejects EAP-TLS authentication. 
Client fails to verify the server’s certificate, and rejects EAP-TLS authentication. 
Certificate validation fails if the:
–Certificate has expired.
–Server or client cannot find the certificate issuer.
–Signature check failed.
The client dropped cases resulting in malformed EAP packets. 
EAP-TLS also supports the Session Resume feature. ACS supports the EAP-TLS session resume feature 
for fast reauthentication of a user who has already passed full EAP-TLS authentication. If the EAP-TLS 
configuration includes a session timeout period, ACS caches each TLS session for the duration of the 
timeout period. 
When a user reconnects within the configured EAP-TLS session timeout period, ACS resumes an 
EAP-TLS session, and the user reauthenticates by a TLS handshake only, without a certificate 
comparison.
Related Topics
Types of PACs, page B-22
User Certificate Authentication, page B-6
PEAPv0/1
This section contains the following topics:
Overview of PEAP, page B-15
EAP-MSCHAPv2, page B-30
ACS 5.3 supports these PEAP supplicants: 
Microsoft Built-In Clients 802.1x XP (PEAPv0 only)
Microsoft Built-In Clients 802.1x Vista (PEAPv0 only)
Microsoft Built-In Clients 802.1x Windows 7
CSSC v.4.0 
CSSC v.5
Funk Odyssey access client (latest version)
Intel Supplicant 12.4.x 
						

							B-15
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix B      Authentication in ACS 5.3
  PEAPv0/1
Overview of PEAP
PEAP is a client-server security architecture that you use to encrypt EAP transactions, thereby protecting 
the contents of EAP authentications. PEAP uses server-side public key certificates to authenticate the 
server.
It then creates an encrypted SSL/TLS tunnel between the client and the authentication server. The 
ensuing exchange of authentication information to authenticate the client is then encrypted and user 
credentials are safe from eavesdropping.
PEAP is similar to EAP-TLS but uses a different client authentication method. PEAP provides 
authentication, by using server certificates, a TLS tunnel and client authentication through that 
encrypted tunnel. Unlike EAP-TLS, PEAP requires the client to use another EAP type, like 
EAP-MSCHAPv2. 
PEAP authentications always involve two phases: 
In phase1, the end-user client authenticates ACS. This action requires a server certificate and 
authenticates ACS to the end-user client, ensuring that the user or machine credentials sent in phase 
two are sent to a AAA server that has a certificate issued by a trusted CA. The first phase uses a TLS 
handshake to establish an SSL tunnel between the end-user client and the AAA server.
NoteDepending on the end-user client involved, the CA certificate for the CA that issued the ACS 
server certificate is likely to be required in local storage for trusted root CAs on the end-user 
client computer.
In the second phase, ACS authenticates the user or machine credentials by using an EAP 
authentication protocol. The SSL tunnel that was created in phase1 protects the EAP authentication. 
The inner-method authentication type that is negotiated during phase 2 can be either 
EAP-MSCHAPv2, EAP-GTC or EAP-TLS. The combination of the outer PEAP method with a 
specific inner EAP method is denoted using brackets (); for example, PEAP(EAP-MSCHAPv2) or 
PEAP(EAP-GTC).
An improvement in security that PEAP offers is identity protection. This improvement is the 
potential for protecting the username in all PEAP transactions. After phase one of PEAP, all data is 
encrypted, including username information that is usually sent in clear text.
The Microsoft PEAPv0 client does not provide identity protection; the Microsoft PEAPv0 client 
sends the username in clear text in phase one of PEAP authentication.
In ACS 5.3, PEAP is encapsulated in RADIUS protocol. Inner-method EAP messages are encapsulated 
in an EAP-TLV method. 
Supported PEAP Features
This section contains the following topics:
Server Authenticated and Unauthenticated Tunnel Establishment Modes, page B-16
Fast Reconnect, page B-16
Session Resume, page B-16
Protected Exchange of Arbitrary Parameters, page B-16 
						

							B-16
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix B      Authentication in ACS 5.3
  PEAPv0/1
Server Authenticated and Unauthenticated Tunnel Establishment Modes
Tunnel establishment helps prevent an attacker from injecting packets between the client and the 
network access server (NAS) or, to allow negotiation of a less secure EAP method. The encrypted TLS 
channel also helps prevent denial of service attacks against the ACS.
A client EAP message is always carried in the RADIUS Access-Request message, and the server EAP 
message is always carried in the RADIUS Access-Challenge message. The EAP Success message is 
always carried in RADIUS Access-Accept message. 
The EAP Failure message is always carried in the RADIUS Access-Reject message. The clients PEAP 
message may cause the RADIUS clients message to drop unless the policy component is configured 
otherwise.
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 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.  
						

							B-17
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix B      Authentication in ACS 5.3
  PEAPv0/1
PEAP Flow in ACS 5.3
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 B-17
Authenticating with MSCHAPv2, page B-18
Figure B-3 shows the PEAP processing flow between the host, access point, network device, and ACS 
EAP-TLS server.
Figure B-3 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.
1After creating a logical link, the wireless AP sends an 
EAP-Request/Identity message to the wireless client. 2The wireless client responds with an 
EAP-Response/Identity message that contains the 
identity (user or computer name) of the wireless client. 
3The 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. 4ACS sends an EAP-Request/Start PEAP message to the 
wireless client. 
5The wireless client and ACS exchange a series of TLS 
messages through which the cipher suite for the TLS 
channel is negotiated. In ACS 5.3, the client certificate is 
not used in PEAP.6At 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.  
						

							B-18
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix B      Authentication in ACS 5.3
  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 B-35
Configuring PEAP Settings, page 18-3
EAP-FAST
This section contains the following topics:
Overview of EAP-FAST, page B-18
EAP-FAST Flow in ACS 5.3., page B-26
EAP-FAST PAC Management, page B-27
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. 1ACS sends an EAP-Request/Identity message. 2The wireless client responds with an 
EAP-Response/Identity message that contains the 
identity (user or computer name) of the wireless client. 
3ACS sends an EAP-Request/EAP-MSCHAPv2 challenge 
message that contains a challenge string. 4The 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. 
5ACS 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. 6The wireless client responds with an 
EAP-Response/EAP-MSCHAPv2 acknowledgment 
message, indicating that the ACS response was correct. 
7ACS sends an EAP-Success message.  
						

							B-19
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix B      Authentication in ACS 5.3
  EAP-FAST
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.
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 B-23.) 
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 B-35.
NotePhase zero is optional and PACs can be manually provided to end-user clients. (See Manual 
PAC Provisioning, page B-24.) 
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 B-35.
Phase one and phase two are subsequent parts of the same EAP-FAST conversation.  
						

							B-20
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix B      Authentication in ACS 5.3
  EAP-FAST
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:
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 servers 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.3
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.3 supports EAP-FAST versions 1 and 1a.
This section contains the following topics:
About Master-Keys, page B-21
About PACs, page B-21
Provisioning Modes, page B-22
Types of PACs, page B-22