Chapter 8 Establishing Cisco Secure ACS System Configuration
Cisco Secure ACS Certificate Setup
8-70
User Guide for Cisco Secure ACS for Windows Server
78-14696-01, Version 3.1
Digital certificates are useful because they do not require the sharing of secrets
nor stored database credentials, can be scaled and trusted over large deployments,
and can serve as a method of authentication that is stronger and more secure than
shared secret systems. Mutual trust requires that Cisco Secure ACS have an
installed certificate that can be verified by end-user clients.
About the EAP-TLS Protocol
EAP and TLS are both IETF RFC standards. The EAP protocol, an improvement
over the point-to-point protocol (PPP), extends the network by providing new
methods for carrying initial authentication information, specifically, EAPOL (the
encapsulation of EAP over LANs as established by IEEE 802.1X).TLS provides
a way to use certificates for both user authentication and for dynamic ephemeral
session key generation. For more detailed information on EAP, TLS, and
EAP-TLS, refer to the following IETF RFCs:
PPP Extensible Authentication
Protocol (EAP) RFC 2284
,
The TLS Protocol RFC 2246
and
PPP EAP TLS
Authentication Protocol RFC 2716
.
A user who is authenticated using EAP-TLS can then be mapped to user or group
authorization information kept in the CiscoSecure user database, or in a Windows
2000 or generic LDAP Directory Server.
Also, to accomplish secure Cisco Aironet connectivity, EAP-TLS generates a
dynamic, per-user, per-connection, unique session key.
EAP-TLS requires support from both the end client and the AAA client. An
example of an EAP-TLS client includes the Windows XP operating system;
EAP-TLS compliant AAA clients include Cisco 802.1x-enabled switch platforms
(such as the Catalyst 6000 product line), and Cisco Aironet Wireless solutions. To
support EAP-TLS, Cisco Secure ACS must operate with an X.509 v3 digital
certificate.
TLS authentications require two elements of trust. The first element of trust is
when the TLS negotiation establishes end-user trust by validating, through RSA
signature verifications, that the user possesses a keypair signed by a certificate.
This verifies that the end user is the legitimate keyholder for a given digital
certificate and the corresponding user identification contained in the certificate.
However, trusting that a user possesses a certificate only provides a
username/keypair binding. The second element of trust is to use 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 seal on a passport.
