Cisco Systems CSACS3415K9 Manual De Usuario

Descargar
Página de 678
B-7
User Guide for Cisco Secure Access Control System 5.4
OL-26225-01
Appendix B      Authentication in ACS 5.4
  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 
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.4 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 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
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.