User guide

Odyssey Access Client User Guide
102  802.1X Authentication
Each certificate is issued by a certificate authority. By issuing a certificate, the
certificate authority warrants that the name in the certificate corresponds to the
certificate’s owner (much as a notary public guarantees a signature). The certificate
authority also has a certificate, which in turn is issued by a higher certificate
authority. At the top of this pyramid of certificates is the root certificate authority.
The root certificate authority is typically a well-known entity that people trust,
whose self-signed certificate is widely known. For example, Verisign and Thawte are
public root certificate authorities. Many corporations have set up their own private
root certificate authorities.
There is a date on which each certificate expires. Additionally, a certificate granting
authority can revoke a certificate. Expired or revoked certificates are not valid, but
certificates can be re-issued or renewed.
A set of certificates in sequence, including any intermediate certificate authorities
up to the root certificate authority is called a certificate chain. Certificate chains are
typically no more than several certificates in length. In many cases, a chain consists
of two certificates:
 An end entity certificate
 A root certificate
Certificates are well-suited for authentication from a security perspective. The
disadvantage of using certificates for authentication is that it is much harder to
provide certificates to users. This is because at any given enterprise, the number of
servers that might require certificates is relatively small, but the number of users
can be enormous. Providing certificates to each employee can be a daunting
management task and might require a level of administration that your company is
not prepared to undertake.
EAP-TLS
EAP-TLS is based on the TLS protocol that is widely used to secure web sites. It
requires that both the user and authentication server have certificates for mutual
authentication.
While EAP-TLS is cryptographically strong, it requires a certificate infrastructure
that maintains and supplies certificates to all network users.
EAP-TTLS
EAP-TTLS is designed to provide authentication that is cryptographically as strong
as EAP-TLS, while not requiring that each user be issued a certificate. Instead, only
the authentication servers require certificates.
EAP-TTLS authentication is performed using a password or other credentials.
Password-type credentials are transported in a securely encrypted “tunnel” that is
established using the server certificate. Within the EAP-TTLS tunnel, you can
employ any of a number of inner authentication protocols. With tunneled password
credentials, user authentication can be performed against the same security
database that is already in use on the corporate LAN. For example, Windows Active
Directory or an SQL or LDAP database might be used. See “TTLS Settings” on
page 60 and “Selecting an Inner Authentication Protocol” on page 48 for more
information about configuring inner protocols for tunneled authentication.