Cisco Systems 3.3 Manual De Usuario
10-3
User Guide for Cisco Secure ACS for Windows Server
78-16592-01
Chapter 10 System Configuration: Authentication and Certificates
About Certification and EAP Protocols
About the EAP-TLS Protocol
EAP and TLS are both IETF RFC standards. The EAP protocol carries initial
authentication information, specifically EAPOL (the encapsulation of EAP over
LANs as established by IEEE 802.1X). TLS uses certificates both for user
authentication and for dynamic ephemeral session key generation. The EAP-TLS
authentication protocol uses the certificates of Cisco Secure ACS and of the
end-user client, enforcing mutual authentication of the client and of Cisco Secure
ACS. For more detailed information on EAP, TLS, and EAP-TLS, refer to the
following IETF RFCs:
authentication information, specifically EAPOL (the encapsulation of EAP over
LANs as established by IEEE 802.1X). TLS uses certificates both for user
authentication and for dynamic ephemeral session key generation. The EAP-TLS
authentication protocol uses the certificates of Cisco Secure ACS and of the
end-user client, enforcing mutual authentication of the client and of Cisco Secure
ACS. For more detailed information on EAP, TLS, and EAP-TLS, refer to the
following IETF RFCs:
,
, and
EAP-TLS authentication involves two elements of trust. The first element of trust
is when the EAP-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 certification authority (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. 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.
is when the EAP-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 certification authority (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. 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 Cisco Secure ACS
self-signed certificate capability. Depending on the end-user client involved, the
CA certificate for the CA that issued the Cisco Secure 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
installing the root certificate CA signature. When such external validation of
certificate legitimacy is not required, you can use the Cisco Secure ACS
self-signed certificate capability. Depending on the end-user client involved, the
CA certificate for the CA that issued the Cisco Secure 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 requires support from both the end client and the AAA client. An
example of an EAP-TLS client includes the Microsoft Windows XP operating
system; EAP-TLS-compliant AAA clients include Cisco 802.1x-enabled switch
platforms (such as the Catalyst 6500 product line) and Cisco Aironet Wireless
solutions. To accomplish secure Cisco Aironet connectivity, EAP-TLS generates
a dynamic, per-user, per-connection, unique session key.
example of an EAP-TLS client includes the Microsoft Windows XP operating
system; EAP-TLS-compliant AAA clients include Cisco 802.1x-enabled switch
platforms (such as the Catalyst 6500 product line) and Cisco Aironet Wireless
solutions. To accomplish secure Cisco Aironet connectivity, EAP-TLS generates
a dynamic, per-user, per-connection, unique session key.