Specifications

Cisco Systems, Inc.
All contents are Copyright © 1992–2002 Cisco Systems, Inc. All rights reserved. Important Notices and Privacy Statement.
Page 10 of 42
4.2.2.2 Server Trusting Client
Thispart will help you understand the concept of AAA server trust model. Specific configuration information is given
in Section 6 of this document.
To support EAP-TLS, the AAA server (for example, Cisco Secure ACS) must have a certificate. Either a public
certification authority or a private certification authority can be used to issue the AAA server certificate. The AAA
server will trust a client certificate that was issued from the same root certification authority that issued its certificate.
If a server certificate was issued from a public certification authority, a client holding a certificate issued from the
same root certification authority as the server is allowed in, provided that:
• The name in the certificate corresponds to the username
• The username was found in one of the databases that supports EAP-TLS.
For this reason, and to obtain the highest level of security, it is recommend that the certification authority issuing
both clients’ and server certificates be a private certification authority.
The AAA server (for example, the Cisco Secure ACS) usually contains a CTL. In the CTL, you can specify as many
certification authorities as you intend to trust. Any client holding a certificate issued from a certification authority in
the server CTL is allowed in, as long as the name in the certificate corresponds to the username and the username is
found in one of the databases that supports EAP-TLS.
Note: In the ACS, by default, the CTL is empty. (In Microsoft Windows,for Web browser usage, the CTL contains
the well-known public certification authorities by default.)
4.2.3 Session Key Derivation in EAP-TLS
Figure 4-4 illustrates how the session key is derived at the end of EAP-TLS authentication. As part of the TLS
handshake between the server and the client, the client generates a pre-master secret and encrypts it with the server’s
public key and sends the pre-master secret to the server. Another option would be to use Diffie-Hellman exchange to
derive the pre-master secret. The pre-master secret, server and client random values,and“master secret” string value
are used to generate a master secret per session. The pseudo-random function (PRF) used to generate the master
secret is defined in the TLS RFC (2246). EAP-TLS (RFC 2716) specifies how to derive the session key. The PRF is
used again along with master secret, client and server random values, and “client EAP encryption” string value to
generate the session keys, Message Authentication Code (MAC) keys and initialization values (for block ciphers
only). Note that both the client and the RADIUS server independently derive the session keys. However, the length
of the session key is determined by the authenticator (the access point) and is sent in the EAP-over-LAN key message
at the end of the EAP authentication to the client (Figure 4-2).