Specifications

Cisco Systems, Inc.
All contents are Copyright © 1992–2002 Cisco Systems, Inc. All rights reserved. Important Notices and Privacy Statement.
Page 7 of 42
the private key (Amazon.com) is able to decrypt the message. Using this method, a user can validate that Amazon is
a legitimate key holder for a given digital certificate. However, trusting that someone is in possession of a digital
certificate only provides a name/key-pair binding.
4.1.2.2 Second Element of Trust: Certification Authority
The second element of trust in PKI is the involvement of the certification authority server. Continuing our
Amazon.com example, the customer also needs to verify that Amazon is really the entity he or she is communicating
with. A third party is needed to validate the identity of Amazon. For this we have the signature of the authority (the
certification-authority entity) that issued the certificate to Amazon.
If the customer trusts the certification authority that issued the certificate to Amazon, the user is able to check
Amazon’s certificate and validate that it is Amazon. The Web browser is configured with a list of trusted root
certification authorities. This list is known as a certificate trust list (CTL). Any certificate in this list (that is, the
certificate of a root certification authority) is automatically trusted by the client. Also note that a certificate of a
trusted root certification authority is self-signed. This is like a passport seal on your passport. You trust the passport
because you trust the preparation and identity checking that the passport office made when creating that passport.
You trust digital certificates by installing the root certification authority signature for the same reasons.
Thecertificateisvalidated using thepublic-privatekeypairsofthecertificationauthority. If you trust the certification
authority, then you trust this certification authority’s certificate. The certification authority’s certificate includes the
certification authority’s public key. In the certificate issued by the certification authority to Amazon, a portion of the
certificate is encrypted using the certification authority’s private key. When the user receives Amazon’s certificate (in
the SSL handshake), the Web browser decrypts the encrypted part of the certificate using the certification authority’s
public key. For example, the certification authority might encrypt this message: “This certificate was issued to
Amazon.com.Itisvalidfrom1/1/1995to31/12/2015.TheURLusedby Amazon.com is ‘www.amazon.com’...”The
encrypted portion of the message contains information about the certificate such as the name of the holder of the
certificate, the period for which the certificate is valid, the URL of the holder of the certificate, and so on. Upon
completion of the SSL handshake, a user knows he or she is communicating with Amazon.
A new session key is dynamically generated during the SSL handshake. This key is valid for this session only. At the
end of SSL handshake, a secured encrypted tunnel is established to Amazon using the session key. (This encryption
is symmetric, which is faster and less CPU-intensive than asymmetric encryption.)
4.2 EAP-TLS Model
This section discusses EAP-TLS authentication protocol in detail. EAP-TLS is based on SSL Version 3.0. In EAP-TLS,
the SSL handshake is performed over EAP, whereas, on the Internet, the SSL handshake is conducted through
Transmission Control Protocol (TCP). Thus, the difference between the SSL handshake in the Amazon example and
in EAP-TLS is the transportation layer in which the SSL messages are exchanged.
Note: As with most technologies, EAP has its own terminology for common ideas. In EAP the end user’s machine
is known as the supplicant, the access point is known as the authenticator, and the RADIUS server is known as
the authentication server.