Cisco Acs 57 User Guide

							5   
Authentication in ACS 5.7
EAP-TLS
Overview of EAP-MD5
EAP Message Digest 5-(EAP-MD5) provides one-way client authentication. The server sends the client a random 
challenge. The client proves its identity by hashing the challenge and its password with MD5. EAP-MD5 is vulnerable to 
dictionary attacks when it is used over an open medium. 
This is because hackers are able to see the challenge and response. Since no server authentication occurs, it is also 
vulnerable to falsification.
Related Topics
Host Lookup, page 12
Overview of Agentless Network Access, page 11
EAP- MD5 Flow in ACS 5.7
ACS supports EAP-MD5 authentication against the ACS internal identity store. Host Lookup is also supported when using 
the EAP-MD5 protocol. See Host Lookup, page 12.
Related Topics
Authentication Protocol and Identity Store Compatibility, page 32
Overview of Agentless Network Access, page 11
EAP-TLS
This section contains the following topics:
Overview of EAP-TLS, page 5
EAP-TLS Flow in ACS 5.7, page 12
Overview of EAP-TLS
EAP-TLS is one of the methods in the EAP authentication framework, and is based on the 802.1x and EAP architecture. 
Components involved in the 802.1x and EAP authentication process are the: 
Host—The end entity, or end user’s machine.
AAA client—The network access point.
Authentication server—ACS. 
The EAP-TLS standard is described in:
RFC 2716—PPP EAP-TLS Authentication Protocol
RFC 3079—Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)
This section contains the following topics:
User Certificate Authentication, page 6
PKI Authentication, page 7
The host must support EAP-TLS authentication. The access point must support the EAP authentication process in the 
802.1x environment (the access point is not aware of the EAP authentication protocol type). 
						

							6
Authentication in ACS 5.7
 
EAP-TLS
Related Topics
Configuring CA Certificates, page 83
Certificate-Based Network Access, page 8
ACS and Cisco Security Group Access, page 21
EAP-TLS Flow in ACS 5.7, page 12
User Certificate Authentication
EAP-TLS is a mutual authentication method for certificate-based authentication; the client and server authenticate each 
other by using digital certificates. Certificates must meet specific requirements on the server and client for successful 
authentication. EAP and TLS are Internet Engineering Task Force (IETF) RFC standards. 
The EAP protocol carries initial authentication information, specifically the encapsulation of EAP over LANs (EAPOL) as 
established by IEEE 802.1x. TLS uses certificates for user authentication and dynamic ephemeral session key generation.
After the peer is authenticated and a session is created, the information is cached on ACS for a certain amount of time. 
The session can be re-established by using the EAP-TLS session state and the session ticket resume, without an 
additional certificate exchange. 
ACS 5.7 maintains the server certificate and private key in files on the ACS server, which it uses during EAP-TLS 
processing. You can choose the certificate authorities (CAs) that can be trusted to sign on client certificates. 
EAP-TLS authentication involves two elements of trust: 
The EAP-TLS negotiation establishes end-user trust by validating, through RSA signature verifications, that the user 
possesses a keypair that a certificate signs.
This process verifies that the end user is the legitimate keyholder for a given digital certificate and the corresponding 
user identification in the certificate. However, trusting that a user possesses a certificate only provides a 
username-keypair binding. 
Using a third-party signature, usually from a CA, that verifies the information in a certificate. This third-party binding 
is similar to the real-world equivalent of the stamp on a passport.
You trust the passport because you trust the preparation and identity-checking that the particular country’s passport 
office made when creating that passport. You trust digital certificates by installing the root certificate CA signature.
Some situations do not require this second element of trust that is provided by installing the root certificate CA signature. 
When such external validation of certificate legitimacy is not required, you can use the ACS self-signed certificate 
capability. 
Depending 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. For more information, see Adding 
a Certificate Authority, page 84.
EAP-TLS-compliant AAA clients include: 
Cisco 802.1x-enabled switch platforms (such as the Catalyst 6500 product line)
Cisco Aironet Wireless solutions
To accomplish secure Cisco Aironet connectivity, EAP-TLS generates a dynamic, per-user, per-connection, unique 
session key.
ACS 5.7 now supports certificate name constraint extension. It accepts client certificates whose issuers contain the 
name constraint extension. It checks the client certificates for CA and sub-CA certificates. This extension defines a name 
space for all subject names in the subsequent certificates in a certificate path. It applies to both the subject distinguished  
						

							7   
Authentication in ACS 5.7
EAP-TLS
name and the subject alternative name. These restrictions are applicable only when the specified name form is present 
in the client certificate. The ACS authentication fails if the client certificate is excluded or not permitted by the 
namespace.
Related Topics
Configuring CA Certificates, page 83
Certificate-Based Network Access, page 8
PKI Authentication
EAP-TLS uses public key infrastructures (PKI) concepts: 
A host requires a valid certificate to authenticate to the LAN network. 
The AAA server requires a server certificate to validate its identity to the clients. 
The certificate-authority-server infrastructure issues certificates to the AAA server(s) and the clients. 
An SSL/TLS tunnel authentication is conducted by both peers and is initiated by the client. In ACS, the tunnel can be 
either authenticated by:
both peers
either one 
neither client or host
A tunnel that is constructed without an authentication is considered an anonymous tunnel, and is usually constructed by 
the Diffie-Hellman key exchange protocol. ACS supports the SSL/TLS session resume feature for TLS. ACS maintains 
the tunnel keys and cipher used to establish the tunnel communication in the cache for each session. Fetching an old 
session is based on the session ID which is unique for each client.
You can configure the timeout for each session in the cache, for each protocol individually. The lifetime of a session is 
measured from the beginning of the conversation and is determined when the TLS session is created.
ACS supports establishment of a tunnel from a commonly shared key known to the client and the server for the EAP-FAST 
protocol. The key that is securely agreed upon between the two peers is used to derive a shared tunnel TLS-master-key 
that is used to open a tunnel. This mechanism involves a shorter TLS negotiation.
An anonymous Diffie-Hellman tunnel relates to the establishment of a completely anonymous tunnel between a client 
and a server for cases where none of the peers authenticates itself. ACS runtime supports anonymous Diffie-Hellman 
tunnels for EAP-FAST with a predefined prime and a predefined generator of two. There is no server authentication 
conducted within anonymous Diffie-Hellman tunnel cipher-suites.
An authenticated Diffie-Hellman tunnel is similar to an anonymous Diffie-Hellman tunnel. The additional factor of the 
authenticated Diffie-Hellman tunnel is that peer authentication is conducted through an RSA certificate. ACS supports 
Authenticated-Diffie-Hellman tunnels for EAP-FAST where the server authenticates by using its own certificate.
Additional client authentications are conducted within the tunnel by using other protocols, such as EAP-MSCHAPv2 or 
EAP-GTC for the inner EAP method.
Related Topics
Configuring Local Server Certificates, page 16
Configuring CA Certificates, page 83
Configuring Certificate Authentication Profiles, page 89 
						

							8
Authentication in ACS 5.7
 
EAP-TLS
PKI Credentials
This section contains the following topics:
PKI Usage, page 8
Fixed Management Certificates, page 8
Importing Trust Certificates, page 8
Exporting Credentials, page 10
PKI Usage
ACS supports using certificates for various PKI use cases. The main use case is the EAP-TLS protocol, where the PKI is 
used to authenticate not only the server, but also the client (PEAP and EAP-FAST also make use of certificates for server 
authentication, but do not perform client authentication). Other protocols which use the PKI credentials are LDAPS, 
HTTPS Management protocol, SSH, and SFTP.
For TLS related EAP protocols, a single local certificate is used to authenticate the server for all the TLS related EAP 
protocols. You can pick the certificate to use from any of the certificates containing a private-key in the Local Certificate 
store.
For other protocols, such as HTTPS, SFTP, and SSH, and for the message-bus ActiveMQ authentication, a single 
certificate should be configured to authenticate ACS. You can pick the certificate to use from any of the certificates 
containing a private-key in the Local Certificate store. You can configure the same local certificate for the TLS-related 
EAP protocols and for HTTPS Management protocol. 
For HTTPS, SFTP, SSH and ActiveMQ, an auto-generated self-signed certificates can be used as the means for server 
authentication. 
Fixed Management Certificates
ACS generates and uses self-signed certificates to identify various management protocols such as the Web browser, 
HTTPS, ActiveMQ SSH, and SFTP.
Self-signed certificates are generated when ACS is installed and are maintained locally in files outside of the ACS 
database. You cannot modify or export these certificates. You can, however, assign imported certificates to management 
interfaces.
Importing Trust Certificates
ACS supports PEM or DER formatted X509 certificate files. You can add a trust certificate to the trust certificate store. 
ACS verifies that an imported certificate complies with the X509 format and does not perform any hierarchical certificate 
signature verification. ACS also supports the Microsoft proprietary private key format.
You can mark the acquired certificate for immediate trust for TLS related EAP protocols as the EAP CTL. The trust 
certificate store does not allow for duplicate trust certificates. These are the rules for rejecting certificates: 
Two certificates cannot have the same subject.
Two certificates cannot have the same issuer and the same serial-number. 
Acquiring Local Certificates
This topic describes the methods for ACS to acquire PKI credentials, and the ways that you can sets the public or private 
keys pairs to each ACS server in the ACS domain. 
An X509 certificate contains the credentials which include the public key, and a PKCS#12 [?10.1] that holds the private 
key protected with a password that goes with it. 
						

							9   
Authentication in ACS 5.7
EAP-TLS
The ACS domain may have more than a single ACS server; each domain should have its own set of PKI key pairs to 
identify itself through the appropriate interfaces. 
Some interfaces may require that the certificate that identifies ACS, contain the IP or FQDN of the ACS server, in its 
Common Name (CN) for better binding of the certificate to the IP of the server, for example, the HTTPS ACS server 
certificate which is used for the Web interface. 
For other interfaces, it may be possible to use a common certificate that can be shared between the servers, however, 
Cisco does not recommend that you use a common certificate. Each ACS PKI credentials may be obtained either from a 
self-signed certificate or a certificate signed by a common certificate authority (CA). 
For protocols that require the ACS identification, clients should be deployed with at least the lowest common certificate 
that dominates all the ACS servers certificates that are used to identify each ACS.
You can pick the PKI policy to be used in your organization and configure the PKI credentials for the ACS domain.
The configured certificate with its private-key should not be used outside the ACS machine 
Related Topics
Importing the ACS Server Certificate, page 9
Initial Self-Signed Certificate Generation, page 9
Certificate Generation, page 10
Importing the ACS Server Certificate
When you manually import and ACS server certificate you must supply the certificate file, the private key file, and the 
private key password used to decrypt the PKCS#12 private key. The certificate along with its private-key and 
private-key-password, is added to the Local Certificate store. For non-encrypted private-keys, the user supplied 
password may be ignored.
ACS supports PEM or DER formatted X509 certificate files. ACS verifies that an imported certificate complies with a the 
X509 format and does not perform any hierarchical certificate signature verification.
When importing a certificate, you can configure the certificate for protocol that require an ACS server certificate, such 
as TLS related EAP protocols and HTTPS Management protocol. 
Note: Only EAP and HTTPS Management protocols can be configured in ACS 5.7 for certificate-based authentication.
The input password and private-key, which are cryptographically sensitive information, are passed over the HTTPS 
channel. Using HTTPS with a non-authenticated server, for example, a self-signed certificate for HTTPS server 
authentication, is not a secure method of passing this sensitive information.
Related Topics
Importing Trust Certificates, page 8
Initial Self-Signed Certificate Generation, page 9
Certificate Generation, page 10
Initial Self-Signed Certificate Generation
An automatically generated, self-signed certificate is placed in the Local Certificate store for each ACS server. This 
certificate is used to identify ACS for TLS-related EAP protocols and for HTTPS Management protocols.
The self-signed certificate is generated with the CN equal to the machine’s hostname, as required for HTTPS certificates, 
and is generated when ACS is installed. 
						

							10
Authentication in ACS 5.7
 
EAP-TLS
Certificate Generation
You can generate ACS server certificates through the Web interface. The output of this process is a certificate or a 
certificate request and it’s corresponding private-key and password. The generated private-key is structured as 
PKCS#12 encrypted, by using a relatively strong automatically generated password based on at least 128 bit of 
randomness.
You can select any of these generated private-key lengths: 512, 1024, 2048 or 4096 bit. The certificate digest algorithm 
used by the ACS is SHA1 and SHA2 256-bit.
Note: You should install Windows XP SP3 to use SHA2 256-bit certificates as management certificates.
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 83
Configuring Certificate Authentication Profiles, page 89
EAP-TLS Flow in ACS 5.7, page 12
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.  
						

							11   
Authentication in ACS 5.7
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 node's certificates are 
removed from the distributed database of the primary server, and the new node's 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.7 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.
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 primary's 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. 
						

							12
Authentication in ACS 5.7
 
EAP-TLS
EAP-TLS Flow in ACS 5.7
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/CiscoSSL) 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 7 on page 12 shows the EAP-TLS processing flow between the host, network device, and ACS EAP-TLS server 
when the stateless session resume option is not used. 
Figure 7 EAP-TLS Flow 
Note: All 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.
X.25 Host
Host
Network deviceACS EAP-TLS
server 1
2
3
4
5
204584
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. 
						

							13   
Authentication in ACS 5.7
PEAPv0/1
—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 the EAP-TLS session and 
reauthenticates the user with TLS handshake only, without a certificate check. 
ACS 5.7 supports EAP-TLS session resumption without session state to be stored at the server. It also supports session 
ticket extension as described in RFC 5077. The ACS server creates a ticket and sends it to an EAP-TLS client. The client 
presents the ticket to ACS to resume a session.
The Stateless session resumption is supported in the distributed deployment, so that a session ticket issued by one node 
is accepted by another node. 
The entire ticket is authenticated over its fields using a MAC with a 128-bit authentication key. The fields are encrypted 
using AES-CBC with a 128-bit encryption key and IV that are found in the ticket. The ACS administrator configures a 
limited lifetime for the session ticket. 
Related Topics
Types of PACs, page 21
User Certificate Authentication, page 6
PEAPv0/1
This section contains the following topics:
Overview of PEAP, page 13
EAP-MSCHAPv2, page 27
ACS 5.7 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
Cisco AC 3.x
Funk Odyssey Access Client 4.0.2 and 5.x
Intel Supplicant 12.4.x
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. 
						

							14
Authentication in ACS 5.7
 
PEAPv0/1
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.
Note: Depending 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.7, PEAP is encapsulated in RADIUS protocol. Inner-method EAP messages are encapsulated in an EAP-TLV 
method. ACS also supports cryptobinding TLV extension in MS PEAP. In ACS 5.7, you have an option to deliberately 
enable PEAPv0 only for the legacy clients. 
Supported PEAP Features
This section contains the following topics:
Server Authenticated and Unauthenticated Tunnel Establishment Modes, page 14
Fast Reconnect, page 15
Session Resume, page 15
Protected Exchange of Arbitrary Parameters, page 15
Cryptobinding TLV Extension, page 15
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 client's PEAP message may 
cause the RADIUS client's message to drop unless the policy component is configured otherwise.