B-7
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix B Authentication in ACS 5.3
EAP-TLS
•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 8-69.
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.
Related Topics
•Configuring CA Certificates, page 8-68
•Certificate-Based Network Access, page 4-9

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.