Document:Extensible Authentication Protocol Transport Layer Security
Central Data Systems Private Limited
#50, 27th Main, I Cross,
BTM Layout I Stage,
Bangalore – 560068
Extensible Authentication Protocol Transport Layer Security
WLAN security approach focuses on developing a framework for providing centralized authentication and dynamic key distribution. A proposal jointly submitted to the IEEE by Cisco Systems, Microsoft, and other organizations introduced an end-to-end framework using 802.1X and the EAP to provide this enhanced functionality. Central to this proposal are two main elements:
To support all popular operating systems, Cisco employees designed and implemented Lightweight Extensible Authentication Protocol (LEAP)—a network-EAP protocol based on 802.1x authentication framework—on Cisco Aironet® WLAN products and solutions. Microsoft's latest operating system, Windows XP, provides support for 802.1x (specifically EAP-TLS and EAP Message Digest 5 [MD5]). Thus, a variety of EAP authentication protocols can be used to authenticate users in today's WLAN networks
Either the Cisco Access Control Server (ACS) or the Cisco Access Registrar can be used for a combined LEAP and EAP-TLS protocol deployment in an enterprise network. Table 2-1 compares the characteristics of the widely available EAP protocols:
1 Note: Microsoft has announced EAP support for legacy operating systems in 2002 (Windows 2000, Windows NT 4, Windows 98, Windows 98 Second Edition, and Windows ME). Also, there are third-party EAP supplicants that provide support for EAP-TLS on various operating systems (Meetinghouse Data Communications EAP supplicant, for example).
As shown in Table 2-1, EAP MD5 does not support mutual authentication nor dynamic derivation of the Wired Equivalent Privacy (WEP) key, which are essential for WLAN networks. Therefore, Cisco recommends that you do not deploy EAP MD5 in a WLAN environment.
This document focuses on EAP-TLS authentication protocol rollout in WLAN networks. Section 3 further introduces the reader to the EAP/802.1x architecture. Section 4 discusses Public Key Infrastructure (PKI) and EAP-TLS authentication protocol. In Section 5, EAP-TLS deployment criteria are examined in detail. Section 6 provides details about the Validation Lab that was built to illustrate an example EAP-TLS rollout in a WLAN network. Section 7 provides EAP-TLS troubleshooting tips. Appendix A details the setup for Windows 2000 Server Certificate Services. Appendix B provides instructions for configuring EAP-TLS using demo certificates (for proof of concept testing).
EAP provides a standard mechanism for supporting various authentication methods over wired and wireless networks. An authentication, authorization, and accounting (AAA) client (also known as a network access server) such as an access point that supports EAP need not have any understanding of the specific EAP type used in the EAP authentication process. The network access server tunnels the authentication messages between the peer (user machine trying to authenticate) and the AAA server (such as the Cisco Secure ACS). The network access server is aware only of when the EAP authentication process starts and when it ends.
There are EAP types, such as LEAP and EAP-TLS, in which the authentication is mutual: server authenticates user, and user authenticates server. Mutual authentication is usually required in a WLAN environment. For a detailed discussion about designing...
EAP-TLS (RFC 2716) is using the TLS protocol (RFC 2246), which is the Internet Engineering Task Force's (IETF's) latest version of the Secure Socket Layer (SSL) protocol. TLS provides a way to use certificates for both user and server authentication and for dynamic session key generation.
EAP-TLS uses concepts of PKI. The following section introduces PKI and the concepts of certificates, certificate authorization, and validating user identity. A simple example of SSL usage that is familiar to most people will be examined briefly.
A Public Key Infrastructure (PKI) is a management system designed to administer asymmetrical cryptographic keys and public key certificates. It acts as a trusted component that guarantees the authenticity of the binding between a public key and security information, including identity, involved in securing a transaction with public key cryptography.
A certificate is a cryptographically signed structure, called the digital certificate, that guarantees the association between at least one identifier and a public key. It is valid for a limited period of time (called the validity period), for a specific usage, and under certain conditions and limitations described in a certificate policy. The authority that issues this certificate is called the certification authority.
A registration authority provides an interface to all the security management activities that require global coordination to provide a comprehensive and consistent view of security configuration. In its key management function, it registers users needing keys and certificates, collects information required to submit a certification or a revocation request, and connects certification authorities.
A certification authority issues and revokes certificates according to a certification policy. In general, a certification authority is a specialized component that works in an offline mode and is operated by a certification-authority operator according to a certification policy.
An end entity may be a certificate holder that is issued a certificate and can sign digital documents or a client that validates digital signatures and their certification path from a known public key of a trusted certification authority.
The initialization process consists of setting the necessary configuration for a PKI entity to communicate with other PKI entities. For example, the initialization of an end entity involves providing it with the public key certificate of a trusted certification authority. The initialization of a certification authority involves the generation of its key pair.
During the registration process, an end entity makes itself known to a certification authority through a registration authority before that certification authority issues a certificate. The end entity provides its name and other attributes to be included in its public key certificate(s) and the certification authority (or the registration authority, or both) verifies the correctness of the provided information.
The key pair generation for an end entity may either take place in its own environment or is done by the certification authority (or registration authority). If the key pair is not generated by the end entity itself, then the generated private key must be distributed to the end entity in a secure way (for example, through a secure key distribution protocol, or by using a physical token such as a smart card).
The certification process takes place at the certification authority. After verifying the correctness of the end entity's name and attributes (and that the end entity possess the corresponding private key), the certification authority issues a certificate for the end entity's public key. That certificate is then returned to the end entity or posted in a repository where it is publicly available, or both.
Every certificate is associated with two keys: a private key and a public key. Only the owner of the certificate knows the private key, whereas the public key (hence its name) is known to everyone. With this key pair, asymmetric encryption is used. A message that was encrypted with the private key can be decrypted only with its corresponding public key and vice versa. Continuing with the example, Amazon encrypts the messages with its private key, and the customer decrypts them using Amazon's public key. In this way, the customer can be sure that any information he or she decrypted with the public key was encrypted using the corresponding private key. In the same way, if one wants to send an encrypted message to Amazon, the message is encrypted using Amazon's public key. Only the holder of 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.
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.
The certificate is validated using the public-private key pairs of the certification authority. 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. It is valid from 1/1/1995 to 31/12/2015. The URL used by 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.)
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.
As opposed to the one-way, or server-side, authentication discussed in the Amazon.com example, EAP-TLS performs mutual SSL authentication. This requires both the supplicant (the end user's machine) and the authentication server (the RADIUS server) to have a certificate. In mutual authentication, each side is required to prove its identity to the other using its certificate and its private key. The procedure is the same explained in the Amazon example, but for both sides.
As previously mentioned, EAP-TLS authentication is based on 802.1x/EAP architecture. Components involved in the 802.1x/EAP authentication process are: supplicant (the end entity, or end user's machine), the authenticator (the access point), and the authentication server (back-end RADIUS server). The supplicant and the RADIUS server must support EAP-TLS authentication. The access point has to support the 802.1x/EAP authentication process. (The access point is not aware of the EAP authentication protocol type.)
In the client (for example, Microsoft Windows XP), you must configure one root certification authority. Using this root certification authority the client can validate the AAA server (for example, Cisco Secure ACS). For the XP client, no CTL exists. Specify one specific certification authority.
The certification authority you specify to trust can be public or private. If you decide to use a public root certification authority, it is important to understand that you have no control over it. An alternative is to use a private root certification authority for EAP-TLS deployment in your enterprise network. This allows you to build a PKI infrastructure based on a root certification authority sever and possibly several subcertification authority servers (as needed) to issue certificates to both the clients and the AAA servers. (A subcertification authority is a certification authority that is slaved to the root certification authority and unloads some of the burden of certificate processing.)
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.
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.
. 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.
This section details the system components that are required to roll out EAP-TLS in an enterprise network. Certificate requirements, both for the AAA server and the clients, are discussed in detail. Deployment issues, such as mixed EAP protocol deployment and AAA server scalability, are addressed in sections 5.3 and 5.4.
Microsoft XP (other clients for non-XP operating systems may be available)1
1 Note: Microsoft has announced EAP support for legacy operating systems in 2002 (Windows 2000, Windows NT® 4, Windows 98, Windows 98 Second Edition, and Windows ME). Also, there are third-party EAP supplicants that provide support for EAP-TLS on various operating systems (for example, Meetinghouse Data Communications EAP supplicant).
•The certificate has to be installed when the requested user is logged in to the machine. A personal certificate that will be installed when a different user is logged in will not be accessible by the requested user.
•The subject name in the certificate must correspond to the user account name (either a username or the user ID of the account). This account name has to exist in one of the databases that support EAP-TLS. If, for example, the user account name is "TME USER5" (first name=TME, last name= USER5), the cn part of subject name in the certificate has to be "TME USER5" Alternatively, as an example, if the account name is "eaptls1" (user ID is used instead of the username), the cn part of the subject name in the certificate has to be "eaptls1". The @domainName.xxx part, if it exists, is not used in comparison.
•The client must have the corresponding private key. To verify that the private key exists, view the general section of the certificate and verify that you see the following message: "You have a private key that corresponds to this certificate"
The Cisco Aironet access point passes through any EAP authentication type presented to it by a client. It is up to the authentication server (RADIUS server) to accept or reject the authentication type and respond accordingly. In the situation of EAP-TLS, the AAA/RADIUS server must be able to reject the presented authentication type and respond with the desired type.
For example, Cisco Secure ACS supports fallback from LEAP to EAP-TLS. By default, ACS initially employs LEAP authentication when a client initiates EAP authentication (only if the access point is configured for Cisco Aironet as the RADIUS network-access-server type). If the client is a LEAP client, LEAP is used. If it is not a LEAP client, the client sends an EAP negative-acknowledgment (NAK) message with the desired EAP type. If this type is EAP-TLS and the ACS is configured to do EAP-TLS, the ACS starts EAP-TLS.
The AAA server's scalability plays a role in EAP-TLS deployment. The number of EAP-TLS clients along with EAP-TLS authentications per second (both worst case and average scenarios) must be considered when assessing the appropriate scalability and availability for the AAA servers.
As an example, though formal testing on ACS using EAP-TLS has not been performed, informal testing indicates a performance reduction, when compared with LEAP, because of the increased computation requirements of PKI over LEAP. A 20-30 percent reduction can be expected. With this in mind, LEAP has tested to perform 40-60 authentications per second. With the maximum expected performance reduction, you can reasonably expend .7 x 60, or 42, authentications per second using EAP-TLS.
You can calculate the load on ACS by applying this formula: (session length)/(number of connections). Using a value of 25 connections per access point and a 10-minute (600-second) session timeout to force WEP rekeying, you get 600/25 = 24 seconds/connection, which translates into 1 transaction every 24 seconds, or 1/24 (0.042) transactions per second. Table 5-1 below shows the transaction requirements for ACS based on the number of fully loaded access points being supported by a single ACS system.
From this table we can see that a single ACS could support about 1,000 access points with a rekey time of 10 minutes. As the rekey time is extended, the number of access points that a ACS can support increases. Conversely, any decrease in rekey time or increase in number of users per AP results in an increase of TPS and a lowering in the number of access points that a ACS can support.
Note: You can use Table 5-2 to determine the scalability of other RADIUS servers using EAP-TLS if you know the maximum number of transactions per second the RADIUS server can support when running EAP-TLS.
From a practical standpoint, the RADIUS server should be inside the general network, preferably within a secure subnet designated for servers, such as Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), and so on. You should avoid requiring RADIUS requests to travel over WAN connections because of possible network delays and loss of connectivity.