Table Of Contents
Certificate-Based Authentication
PEAP and EAP-TLS Authentication
Introduction
Revised: March 27, 2006, OL-9069-01The CiscoWorks Wireless LAN Solution Engine (WLSE) Express AAA Server supports several Extensible Authentication Protocol (EAP) methods that use Rabin-Shamir-Adelmann (RSA) certificates and private keys. Currently, the supported mechanisms are Protected EAP (PEAP) versions 0 and 1 and EAP-Transport Level Security (TLS). Each of these protocols requires the administrator to perform certain preparation and configuration steps before they can be used. Typically these steps involve generation of one or more RSA certificates and private keys which are then made available to WLSE-Express using the graphical user interface (GUI).
The first part of the configuration process, generating certificates and private keys, can be somewhat complex depending on the tools used and the requirements placed on the certificate content and hierarchy. Certificate manipulation tools differ widely in their capabilities, style, and usability features. Few of the tools are automated and many of them require you to be knowledgeable about the Public Key Infrastructure (PKI) technologies involved. Local security policy, which can vary significantly by organization, typically specifies certain requirements and constraints placed on certificates and private keys. PEAP and EAP-TLS also impose some additional requirements on the certificates intended for their use.
The second part of the process, configuring WLSE Express with the certificates and private keys, is fairly simple and uses common procedures for the different EAP methods. Most of the challenge involved in configuring WLSE PEAP and EAP-TLS mechanisms exists in the first part of the process, generating the proper certificates and private keys. Since that activity is variable based on the tools used and is also influenced by external factors (primarily local security policy) a single general-purpose user guide cannot possibly document it in detail.
This document describes a typical configuration using two commonly available PKI tools, OpenSSL and Windows 2000 Server Certificate Authority. With a good understanding of the fundamental steps involved and the ability to experiment with a working installation, the WLSE administrator should be able to manage more complex configurations.
The section PKI and RSA Certificates, provides information necessary for a basic understanding of RSA certificates and private keys and how they are used by PEAP and EAP-TLS. Subsequent sections show detailed steps for generating certificates and private keys and configuring WLSE Express with them.
Acronyms
This document uses the following terms and acronyms.
PKI and RSA Certificates
This section provides a basic understanding of Public Key Infrastructure (PKI) and Rabin-Shamir-Adelmann (RSA) certificates.
PKI Basics
Public Key Infrastructure (PKI) is an extremely large and complex subject area. This section provides a brief outline of the essential information related to RSA certificates and keys to help you understand subsequent sections. Administrators having little or no prior experience with PKI are strongly recommended to seek out additional references that provide more substance such as Internet Request for Comments (RFCs), Internet-Drafts, technical books including those from Cisco Press, and other product manuals, and listings of frequently asked questions (FAQs).
PKI refers to a conceptual infrastructure (or model) for managing information related to public key cryptography. Public key cryptography is a security technology that uses keys that come in matched pairs. Each key pair consists of a widely distributed public key and a private key that is secret and closely protected by its owner. Information encrypted using the public key can only be decrypted using the matched private key (for example, by the key pair owner). This is the difference between public key encryption and conventional secret key cryptography where a single key is used for both encryption and decryption.
It is also possible to encrypt information using the private key that can then only be decrypted using the public key (the reverse of the scheme mentioned above). This technique can be used for creating digital signatures which are useful for proving data origin and integrity.
Public Key Distribution
One of the primary goals of public key cryptography is to solve the key distribution problem which is fundamental to most cryptographic technologies. This refers to the difficulty of securely distributing, storing, and managing keys needed to decrypt sensitive information. Public key cryptography solves this problem by defining a public key that can be distributed freely without protection. Only the corresponding private key must be kept secret, but that is typically not difficult because it is usually stored locally (close to point of origin) and rarely transferred.
Public Key Verification
Since public keys can be freely distributed, they can be placed in directories or databases for ease of access, or stored in local computer registries, or sent in e-mail messages. However, there is still a security problem with distributing and storing public keys. Although they do not need to be kept secret, they still need to be integrity protected and verified by their users Otherwise, an attacker could possibly substitute a bogus public key in place of the actual key (in a directory, for example) that would permit decryption of sensitive information intended for the original key owner. In fact, the attacker might be able to impersonate the actual key owner without detection. Therefore, public keys must somehow be authenticated prior to use.
PKI solves this problem by using digital signatures. As mentioned earlier, a digital signature can be created by encrypting some information (or a derivative of it) with a private key. Anyone can verify the digital signature by decrypting it with the corresponding public key. An attempt to alter the original information would cause the verification process to fail (decryption would yield an incorrect value) and therefore be easily detected. Digital signatures are analogous to conventional pen and paper signatures used to authenticate documents.
Therefore, to authenticate a public key, it can be digitally signed using another key pair. The public key used to verify the digital signature is known as a verification key. Verification keys are frequently pre-distributed and locally stored.
Certificates
Public key distribution and verification are very common operations in PKI-based systems. To promote interoperability, standards have been created to describe the precise format and encoding rules for signed public keys as well as details of the algorithms used for signing and verification. The data structure containing a signed public key is called a certificate. Certificates contain the value of the public key itself as well as additional information that describes the key and its intended purpose, identifies its owner and signer, and assists in verification, etc.
X.509
The most commonly used commercial standard is X.509 Version 3 (X.509v3) from the X.509 set of recommendations, although several standards exist for specifying certificate formats and operations.
The X.509v3 structure has two parts: a fairly rigid fixed part that contains common fields and a second part for optional fields known as extensions. A large number of optional extensions have been defined for a variety of purposes and certificate structures can be quite complex. To facilitate processing, many applications define a certificate profile which specifies the allowable field and extension content and whether extensions are mandatory, optional, or require special processing rules. Table 1-2 shows the X.509v3 certificate fields with some typical values.
Note
In this document, the term certificate implies X.509v3 certificate.
RSA Algorithm
Several different types of public keys exist. A key's type implies its general structure and the algorithms used with it. One of the most common types is known as RSA, for the initials of its three inventors (Rabin-Shamir-Adelmann). The RSA algorithm is based on the computational difficulty of factoring large numbers. This document will focus exclusively on RSA keys and certificates.
To better understand how RSA certificates are used, you need to understand how RSA digital signatures work. Earlier it was mentioned that signing was accomplished by encrypting the source data with the private key. However, the RSA algorithm is extremely compute-intensive and performs poorly for bulk data encryption. For this reason, RSA is usually constrained to operate on only small amounts of data at a time. To sign efficiently, the source data is digested using a special algorithm into a small fixed-length value (typically 128-160 bits) that is encrypted instead of the source data. To verify the signature, the digest value is independently computed and compared with the decrypted value.
A digest algorithm is similar to a cyclical redundancy check (CRC) but with special cryptographic properties. MD5 (128 bits) and SHA-1 (160 bits) are two of the most common digest algorithms used with RSA. A digest algorithm takes an arbitrary amount of input and produces a unique, fixed-length output.
RSA Signing and Verification
Given the description of an RSA algorithm, digital signing can be described as follows:
Step 1
Step 2
Step 3
Signature verification can be described as follows:
Step 1
Step 2
Step 3
Step 2 of signature verification implies that the verifier is able to locate the public key that corresponds to the private key used to sign the certificate. The certificate's Issuer field usually contains the name of the entity that issued (or signed) the certificate. That information (sometimes combined with extensions that contain additional key identification information) can be used to help find the appropriate key.
Certificate Hierarchies
Normally, the public key used to verify a certificate is itself packaged in a certificate. This implies that certificates are organized into chains and that verification is a recursive process. Certificate chains are frequently hierarchical and tree-shaped. The root of the hierarchy is the most trusted certificate; since it does not have a signer, it signs itself. The root certificate usually signs one or more intermediate certificates which might then sign additional intermediate certificates until the final certificate in the chain is reached.
Certificate hierarchies are typically composed of three types of certificates:
•
•
•
Local certificate stores are frequently organized around the types of certificates they contain. For example, web browsers usually contain one or more separate certificate folders for people, intermediate CA certificates, and root certificates.
While intermediate and end-entity certificates can be verified using the next higher certificate in the chain, the root certificate has no high certificate and cannot be verified (since it signs itself). Root certificates are always trusted implicitly and might also be verified using some out of band means. Web browsers and other applications typically bundle one or more root and intermediate certificates with the product, and trust in the root certificates is established by way of product installation.
Certificate Authorities
The organizational entity that issues certificates is known as a Certificate Authority (CA). Certificates used to sign other certificates are called CA certificates. In the hierarchy described above, levels 1 (root) and 2 (intermediate) are CA certificates and level 3 (end-entity) is not. Certificates used by servers and clients are end-entity certificates while certificates above them in the hierarchy are CA certificates. The WLSE Express can use either level 3 certificates from an external CA which must be uploaded to the server or its own self-signed (root) certificate.
Certificate Lifecycle
Good security practice dictates that keys be time-limited and subject to eventual expiration and possible renewal. This limits the potential exposure of keys that have been compromised or weakened by technological advance. Each certificate contains a pair of date-time fields that define its valid lifetime. The validity period must be checked during verification and expired certificates are considered invalid.
Certificates experience a life cycle similar to the following:
1.
2.
3.
4.
5.
6.
7.
8.
There are also mechanisms for revoking a certificate at any time during its life prior to its normal expiration. This might be useful, for example, if the private key has been compromised. Revocation status checking is beyond the scope of this document.
Certificate Encoding
X.509v3 specifies that certificates are encoded using ASN.1, a language for describing arbitrary information in a machine-independent fashion (conceptually similar to XML). ASN.1 is both a notation for describing data and a specification for how it should be encoded at the bit level. Tools are available for automatically converting data to and from ASN.1 form, given its ASN.1 description.
Several different encoding rules have been defined for ASN.1 to suit various purposes. The Basic Encoding Rules (BER) is the original ASN.1 encoding rule set that uses a Tag-Length-Value (TLV) encoding style. X.509v3, however, specifies that certificates are encoded using the Distinguished Encoding Rules (DER). The advantage of DER is that it eliminates ambiguity—there is only one valid encoding possible for every data value and independently developed encoding tools will always produce identical output given the same input.
Another data format that is commonly used for certificates and keys is PEM, for Privacy Enhanced Mail, which was an early specification for secure email. PEM defines a transformation for representing binary information as text with special encapsulating tags to help identify the encoded data. Figure 1-1 shows an example of a PEM-encoded certificate.
Figure 1-1 PEM-Encoded Certificate
-----BEGIN CERTIFICATE-----MIICSDCCAbGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBeMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1NlYXR0bGUxHjAcBgNVBAoTFUludGVybmV0IFdpZGdldHMgSW5jLjEQMA4GA1UEAxMHUm9vdCBDQTAeFw0wNDExMDUyMzQ0MTNaFw0wNTExMDUyMzQ0MTNaMF0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQMA4GA1UEBxMHU2VhdHRsZTEeMBwGA1UEChMVSW50ZXJuZXQgV2lkZ2V0cyBJbmMuMQ8wDQYDVQQDEwZTZXJ2ZXIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANXdXewUehqIeA/GEMf5XBvprBBsayF1PFCEq5cBHO9Uj0rEEdcxyE8V6IYCHeNeaGtp7XQ4Z1NmBFqeJ8/fN5kTCaNTYvQsSNp6e7F804JQRgBxcHpa8a9wgXxcJaBj+x8NARpRCrE5W6fw40p4SK+xVnlvY0/FZTPXx3qYzGztAgMBAAGjFzAVMBMGA1UdJQQMMAoGCCsGAQUFBwMBMA0GCSqGSIb3DQEBBAUAA4GBAKjYQ1eQiHpkRmb0NIA4aUSgJ2hXPbG6RmuuyeUCfRftSuUC7cqdpEP6agkeaVGlUKZsHXOWjwrGR2R4nzvFxY0BK+7ZvijegykLBdpB73Jr8Wv3P4Ja/HLleqDLIH9oPYhDKMP9/AbWbaiqNrzqXcQPeIz8RrWfuDjKbdXJJ7ks-----END CERTIFICATE-----
Note
Many PC applications support an encoding format known as PKCS #12: Personal Information Exchange Syntax Standard (or simply PKCS12) which is one of the Public Key Cryptography Standards (PKCS) promoted by RSA Security Inc. PKCS is a set of specifications dealing with various aspects of public key cryptography. Many of the PKCS specifications have been accepted as industry standards and are now published as RFCs.
PKCS12 specifies a format for encoding certificates, keys, and other cryptographic information. Although PKCS12 is also based on ASN.1 it uses a completely different internal format and structure from X.509v3 and converting from one to the other requires a tool that understands both. Since PKCS12 is a binary format it cannot be processed with a text editor. A special tool that understands the PKCS12 syntax is required. On Windows PCs, files with a .P12 or .PFX extension are treated as PKCS12 content and opening them with Internet Explorer will invoke the certificate (and key) import wizard. (PKCS12 is sometimes referred to as PFX, a name for an older version of the standard.)
Table 1-3 shows three common certificate and key encoding standards you should be familiar with.
Table 1-3 Certificate and Key Encoding Standards
DER
Based on X.509v3 ASN.1 DER
PEM
Text encoding of ASN.1 DER information
PKCS12
Supported on the PC by .P12 and .PFX extensions
Certificate-Based Authentication
Public key systems such as RSA can also be used for authentication of people, computers, and other entities. A simple authentication protocol is for the client to pick a random number, sign it, and send the signature to the server. The server can authenticate the client by verifying its certificate and confirming the validity of the signature on the random number.
Since only the entity that possesses the private key corresponding to the certificate could have produced the signature, the server can be confident that the client is who it claims to be. The server can rely on CA and end-entity certificates stored locally, or the client can send the certificate chain (minus the root) along with the signature. To achieve mutual authentication, the roles can be reversed and the server can supply the client with a signed random number and its CA and end-entity certificates.
This protocol is far too simple and insecure to be practical; as stated it has a number of problems including lack of message replay protection and the issue of how to securely link the actual entity to the certificate it provided. However, it is conceptually similar to how actual protocols use RSA for authentication.
TLS Authentication
Transport Level Security (TLS) is a protocol for securely negotiating a session that can be used to exchange protected information. It supports a variety of different authentication mechanisms, one of which is selected during the negotiation phase.
When RSA is the selected mechanism, the client always authenticates the server. But as commonly deployed, the server typically does not authenticate the client (although it might). RSA authentication of the client with TLS is strictly optional and commonly not done. If the application requires client authentication, it will usually be performed as a separate step inside the secure session.
For example, when a user accesses an SSL-protected website using a browser, the SSL layer at the client computer will authenticate the web server using the CA certificates that were pre-installed in the local certificate store. When server authentication is successful and the session has been established, you might be asked to enter a name and password into a form thus effecting client authentication. The client's credentials (username and password in this case) are protected by the SSL session.
The reason for not authenticating the client with RSA is to avoid the requirement for distributing certificates and keys to each client device. Many system administrators believe that large-scale deployment of client certificates and keys is difficult and expensive to manage, and might even pose security risks.
PEAP and EAP-TLS Authentication
PEAP and EAP-TLS leverage the TLS protocol to provide strong mutual authentication and other services such as identity protection, session key derivation, and fast reconnect (session resumption).
PEAP is a 2-phase protocol; the first phase negotiates a TLS session with server authentication and optional client authentication, and the second phase executes another complete EAP conversation protected within the TLS session. The second, or "inner", EAP conversation is used to authenticate the client thereby eliminating the need for client-side certificates. Commonly used inner methods are EAP-GTC used with Cisco's implementation of the PEAP version 1 (PEAPv1) draft and EAP-MSCHAPv2 used with Microsoft's implementation of PEAP version 0 (PEAPv0) draft.
EAP-TLS is essentially identical to phase one of PEAP; there is no second phase or inner EAP conversation used by EAP-TLS so clients must be authenticated during TLS session negotiation using certificates.
