Cisco Systems OL-24201-01 manual PKI Authentication

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.

User Guide for Cisco Secure Access Control System 5.3

OL-24201-01 B-7