Authentication Methods

Authentication is implemented using digital signatures. Digital signatures are most commonly created by taking some message text, such as information unique to a device or person, along with a key, through a hashing function. The digital signature is like the signature that you would use to sign a check, your fingerprint, or a retinal scan of your eye: it's something unique to you and no one else. Digital signatures are used to implement non-repudiation in VPNs: being able to prove, with certainty, the identity of a device.

The last part of this chapter on VPN technologies will cover authentication methods: how two peers can recognize that when they establish a connection to each other, they are really connecting to the associated peer and not someone pretending to be that peer. In this section I'll explore further how man-in-the-middle attacks occur and the types of authentication you can use to discover and prevent man-in-the-middle attacks.

Man-in-the-Middle Attacks

So that you have a better understanding of a man-in-the-middle attack, I'll use Figure 2-5 to illustrate how this attack occurs. In this example, PeerA wants to send data to PeerB. PeerA does a DNS lookup for PeerB's address, shown in Step 1. However, the attacker also sees the DNS request and sends a reply back to PeerA before the DNS server has a chance, shown in Steps 2 and 3. The IP address that the attacker sends is the attacker's own IP address. PeerA knows no better and assumes that when it uses the IP address in the DNS reply that it is sending traffic to PeerB; however, as shown in Step 4, the traffic actually is directed to the attacker.

This is a simple example of using spoofing of DNS replies. If the DNS server's reply was received before the attacker's, PeerA would connect to PeerB; however, a sophisticated hacker could use a session hijacking/re-routing attack to redirect traffic sent from PeerA to PeerB to the attacker himself, still pulling off the man-in-the-middle attack. Given this security problem, some type of authentication is required to allow PeerA and PeerB to verify their identities when communicating with each other. The next section will discuss different types of authentication that might solve this problem.

Authentication Solutions

With VPN implementations, you can use two types of authentication to verify a peer's identity:

• Device authentication

• User authentication

Device authentication is used with both site-to-site and remote access VPNs. With device authentication, either keying information is pre-shared to assist with the identification process, or it is acquired and verified when the devices need to communicate with each other via digital certificates. Pre-shared authentication can use either symmetric or asymmetric keys, whereas in-band authentication uses asymmetric keys with digital certificates.

User authentication is used only with remote access. With device authentication, the keying information typically is stored on the device. This can be a concern if the device is broken into or stolen, as could easily happen with a laptop or PC. Therefore, it is very common to see remote access VPNs use two methods of authentication: both device and user. User authentication normally uses pre-shared keys (a static password) or token card services (one-time passwords). The following sections will discuss these methods in more depth.

Device Authentication

All secure VPN implementations I have dealt with at least support device authentication. Device authentication authenticates the devices that are establishing a protected connection; however it does not authenticate the people who want to use the VPN connection. Therefore, device authentication is common in site-to-site VPNs, and is the first method of authentication in remote access VPNs.

Device authentication is most often accomplished using one of the three following methods:

• Pre-shared symmetric keys

• Pre-shared asymmetric keys

• Digital certificates

The following sections will discuss these three methods.

Pre-Shared Symmetric Keys

The most common method of authenticating devices is with pre-shared keys. Of the three methods mentioned in the last section, the configuration of pre-shared symmetric keys is the simplest.

With pre-shared symmetric key authentication, a single key is used to perform the authentication. This key is shared on two peers, out-of-band, before they need to establish a secured connection, and is saved locally on the devices. The authentication process will use an encryption algorithm or HMAC function for authentication.

With the encryption approach, each peer will take some identity information about themselves; for example, their IP address, hostname, serial number, or a combination of these things, along with the pre-shared symmetric key, and run them through an encryption algorithm. Then both sides will send both the original identity information, along with the output of the encryption algorithm, to the other peer. Each peer then takes the received encrypted identification information and decrypts it with the pre-shared symmetric key. If the received clear-text identity information matches the just-decrypted identity information, both peers can feel safe in assuming that the other device is who it says it is, because the encrypted information could be created only with the pre-shared key.

I'll now examine the use of HMAC functions and pre-shared symmetric keys for identity authentication. Each peer will take identity information about themselves, such as their IP address, hostname, serial number, or a combination of these things, along with the pre-shared symmetric key, and run them through an HMAC function. The output is called a digital signature. The signature, along with the input identification information, is sent to the remote peer. The remote peer will take the identification, along with the same pre-shared key, and run them through the same HMAC function. If the just-computed signature matches what the other peer sent, then it can be assumed that the same key was used to create the signature, and thus the peer who is making the connection must be who it says it is, and not an impostor.

Of the two methods, encryption is less likely to be used for identity authentication. Encryption is reversible: one device encrypts and the other decrypts. Because you must send the identity information along with the encryption, this tells an eavesdropping attacker one of the two inputs into the encryption algorithm, making it easier to determine what the encryption key is. HMAC functions, on the other hand, are one-way functions; so even if the hacker sees one of the two inputs into the HMAC function, such as the identity information, it doesn't help him to reverse the signature to determine the symmetric key used to create the signature and thus be able to spoof an identity.

Pre-Shared Asymmetric Keys

With a symmetric key, the same key is used for identification authentication, which is typically less secure than a process that uses two keys, as with asymmetric keys. With asymmetric keys, each side creates a public and private key combination. Each peer then, out-of-band, shares its public key, which is stored locally on the devices, with the remote peer.

For example, assume there are two devices, PeerA and PeerB. PeerA creates two keys, PubA and PrivA, and PeerB creates two keys, PubB and PrivB. Out-of-band, the two peers share their public keys with each other. At this point, PeerA has three keys: PubA, PrivA, and PubB. The same is true of PeerB: PubB, PrivB, and PubA. When performing authentication, a peer takes identity information about itself, along with its personal private key, and encrypts it, creating a signature. The peer then sends the identity information, along with the encrypted information, to the remote peer.

In my ongoing example, PeerA, for instance, takes its own identity information and the PrivA key and encrypts it. This is sent, in-band, to PeerB when the two peers want to establish a connection with each other. PeerB then uses PeerA's public key, PubA, to decrypt the signature and compare it with the sent identity information to verify PeerA's identity. If the identity information matches, PeerB recognizes that the only key that could have encrypted this was the corresponding key of PubA: PrivA.

One popular method of this implementation was developed by RSA Labs, called RSA encrypted nonces. Sometimes IPsec uses this method to perform device authentication between IPsec peers. With RSA encrypted nonces, the RSA public key encryption standard is used, which requires each peer to create a random number, called a nonce, and encrypt it with the other peer's public key. The encrypted nonce is sent to the peer with the corresponding private key, which is used to decrypt the encrypted nonce. The decrypted nonce is then used to compute an HMAC key. This is then used with an HMAC function to provide identity authentication by taking identity information, such as a hostname, and hashing it with the hash key and an HMAC function, resulting in a signature. The peer then shares the identity information and the signature, which can be verified by the remote peer.

Digital Certificates

Pre-shared keys are easy to configure for a small number of devices; however, for a large number of devices, they don't scale well. For example, you have nine peers pre-configured with pre-shared keys and you've just added a tenth device. You need to set up VPN connections from the other nine devices to the new device (fully meshed). Assume that you are using pre-shared symmetric keys. To ensure security, you would have to create a separate key for each set of peers. On the new device, you would need to configure all nine keys and on the other devices, the respected key to connect to the new device. Likewise, if you decided to implement asymmetric keying for authentication, each peer would need to create a new public/private key pair. On the new device, you would need to configure nine public keys, and on the other devices, the new peer's public key.

As you add more and more devices to your network that need to establish protected connections, the amount of configuration and management required increases exponentially. Therefore, it is uncommon to see the use of pre-shared keys for identity authentication in large VPN implementation solutions.

Pre-shared authentication methods have one problem: you must "pre-share" the keying information that is used for identity authentication. Therefore, a scalable solution should allow you to perform authentication, in-band, without having to pre-share information to each respective peer with which you wish to set up a protected connection.

To help you scale device authentication to a large number of devices and reduce the risk of a man-in-the-middle attack, the following sections of the chapter cover these topics:

• Definition of a digital certificate

• Standards and components

• Certificates: Acquiring them

• Certificates: Using them

Definition of a Digital Certificate

Certificates contain information to assist in the authentication process. Unlike pre-shared key authentication methods, certificates are not pre-shared. Instead, only when devices need to make connections with each other are certificates shared. Therefore, the hardest part is getting certificates on devicesyou don't have to configure other peer's certificates on your device.

A digital certificate is similar to an electronic version of a driver's license or passport: it can be used to authenticate a person's (or in this case, a device's) identity. Digital certificates are based on the use of asymmetric (public/private) keys, as are RSA encrypted nonces. You'll actually find many things on a digital certificate, which I discuss in depth in the "X.509 Certificates" section. However, three main things found on a digital certificate are a device's identity information, its public key, and its signature, created with its corresponding private key. Therefore, the necessary information to prove a device's identity is located in one place: its certificate. To authenticate a remote peer, you only need its digital certificate.

Of course, this presents a problem: how can you be sure when someone sends you a certificate that they are who they say they are? In other words, an attacker could generate a certificate and send this to you, pretending to be someone else. How can you detect this kind of masquerading attack?

This is where we draw a line between self-signed certificates and the use of a trusted third party, called a Certificate Authority, to provide a trusted source of certificate information. For example, if two peers generate their own self-signed certificates, you can't really verify the remote device's identity if they're masquerading as someone else. Therefore, a trusted certificate repository is necessary. This repository is called a Certificate Authority (CA). In this situation, the CA is a device trusted by all devices that want to use certificates. Then, when peers want to establish connections to each other and authenticate using certificates, they can use the CA as a trusted party to ensure that a masquerading attack isn't occurring, and that the peers you're connecting to are really who they say they are. I'll discuss CAs in more depth later in the "Certificate Authorities" section.

Standards and Components

Before I can begin discussing how a device gets a certificate and then uses it for authentication, I first need to discuss some of the standards and components used with certificate authentication. There are many standards and components used to implement an authentication scheme that uses certificates. The following sections will cover these in more depth.

Certificate Authorities

A CA performs a similar function to a notary. A notary verifies and validates a person's identity when that person signs a document. For example, to sign a mortgage for a bank, the bank will require that you prove your identity to ensure that they are lending money to the right person. A notary will validate your identity by examining a government identification you have, like a driver's license or passport; comparing not just your picture to what you look like, but also comparing your written signature on the mortgage with the signature on your government ID. The notary also will ensure that your ID is current by looking at the expiration date; because if your ID is expired, there might be some legal issue about your right to sign the document.

CAs perform the notary's role in the digital world. In one example, two peers, PeerA and PeerB, want to share information securely. Both peers generate public and private keys and share their public keys with each other. They can then use the remote peer's public key to encrypt information that is to be sent to the remote peer, and the remote peer can use its own private key to decrypt it. By now you're familiar with this process. However, what if there is an attacker, PeerC, who pretends to be PeerB. How can PeerA feel confident that when it uses the remote peer's public key that it belongs to PeerB, and not to some device, like PeerC, that is masquerading as PeerB?

To solve this issue, CAs use a hierarchical trust. The CA is the most trusted device and is the repository of certificates. All devices that want to communicate with each other in a secure fashion must obtain their certificates from the same trusted source. Then, when two peers from the CA's domain want to establish secure connections, they can use the CA to detect masquerading attacks: CAs can be used to check a device's identity. I'll discuss this process in more depth in the "Using Certificates" section later.

Public Key Infrastructure

The Public Key Infrastructure (PKI) includes the following components: policies, people, software, hardware, and processes needed to create, store, manage, share, and revoke certificates. There are two PKI models used in certificate implementations:

• Central

• Hierarchical

In a design where there is a single CA, this is referred to as a central authentication implementation, where all certificates can be created and verified from a single CA. Central CA models commonly are used in small networks where the devices are in the same geographic region.

Of course, in a large-scale deployment of certificates in an enterprise (probably global) network, the two devices that want to establish a secure connection might be using different CAs. In other words, there might be a CA in the USA for devices in North and South America, one in England for devices in Europe, one in Asia for devices in Japan and China, one in Australia for devices in the Pacific, and one in Africa for devices in Africa. If the certificates are from different CAs, how can there be a trust relationship between the two peers?

To solve this problem, a higher-level CA is used, with the two lower-level CAs of the two peers being subordinate to the higher-level CA. This is referred to as a hierarchical PKI model. The ability to create and validate certificates is delegated through a hierarchical chain of CAs. At the top of the hierarchy is the root CA, which is the most trusted device. The root CA creates certificates for the subordinate CAs. These CAs implicitly trust the root CA and can use the root CA to verify the identity of other CAs that they need to interact with. Likewise, the subordinate CAs can create certificates for devices, such as routers, PCs, and firewalls. If two devices need to validate each other's certificates, they can go up the chain of authority from a subordinate CA to the root CA, the device everyone trusts (this is done without actually talking directly to the CA in real time, but rather by using an algorithm in conjunction with the root/top-level CA certificates).

Given the two models, central and hierarchical, you'll notice that trust is never between two entities, like two PCs, but the trust is between a device and a CA, or a CA and a root CA. This presents a problem, though, if you're concerned about redundancy. If your CA (central) or root CA (hierarchical) fails, how can devices authenticate with a trusted source?

PKI uses Registration Authorities (RAs) to solve this problem. An RA is a device that can serve as a limited backup of a CA: it can hold existing certificates, but it cannot create or revoke them. Therefore, if a CA fails, devices in the network can still use the RA to validate each others' certificates. But until a failed CA is restored to an operational status, you won't be able to create new certificates, or revoke existing ones.

PKCS #10

The Public Key Cryptography Standards (PKCS) was an attempt by RSA Security, Inc. to standardize public key processes not covered by other standards. Of the PKCS standards, two play an important role with certificates: PKCS #10 and #7 (the latter of which is discussed later in the chapter).

PKCS #10 defines the actual information and format that a device needs to include and use when creating and requesting its personal certificate. The CA will then use this information to create the device's personal certificate, commonly called an identity certificate. The identity information that is sent in the PKCS #10 certificate request can include the following:

• Common Name or Distinguished Name (CN or DN) This is the name or identity of the device; this is required.

• Organizational Unit (OU) or Department This is the department the device is located in; this is optional.

• Organization (O) This is the name of the company the device is located in; this is optional.

• Locality (L) This is the city the device is located in; this is optional.

• State Province (SP) This is the state or province the device is located in; this is optional.

• Country This is the country the device is located in; this is optional.

• Subject Alternative Name (FQDN) This is the Fully Qualified Domain Name (FQDN) of the device; this is optional.

• Subject Alternative Name (E-mail Address) This is the e-mail address of the person responsible for the device; this is optional.

• Key Size This is the key size used to create the public/private key pair, which is typically either 512 bits in length, 768 bits, 1,024 bits, 2,048 bits, or even higher; this is required and usually defaults to 512 bits.

  Note

  1,024- and 2,048-bit keys for certificates are fairly common today. Unfortunately, some more security-conscious companies want certificates with 4,096-bit keys, but not all Cisco devices support this key size. To create a 4,096-bit key requires a hardware encryption accelerator, and not all hardware encryption cards or modules support 4,096-bit or higher key lengths.

  
  

• Public key This is the device's public key that other devices can use to verify this device's identity; this is required.

• Challenge Password This can be used by the CA to validate a device's request for a certificate and to revoke the certificate if this becomes necessary; this value is dependent on whether or not the CA is configured for challenges.

The preceding information is then signed by the device's private key and then the above information, along with the signature, is used to generate a certificate request. The device takes the PKCS #10 information and places it into an ASN.1 message format, which is then sent to the CA. The resulting information can be sent to the CA using either of the following two ways:

• In-band The PKCS #10 information is sent directly across the network to the CA; if the CA is set up to generate a certificate automatically, it will do so and send this back to the requestor. The standard that defines this process is the Simple Certificate Enrollment Protocol (SCEP), which is discussed later in the "Simple Certificate Enrollment Protocol (SCEP)" section.

• Out-of-band The PKCS #10 information is placed on a floppy or CD-ROM or in an e-mail message and sent to the administrator of the CA.

The PKCS #10 information is used by the CA to create the digital certificate for the requesting device.

X.509v3 Certificates

When a CA receives the PKCS #10 information, it will validate the request by the challenge, if implemented on the CA, in addition to decrypting the device's signature with the included public key. Assuming that the PKCS #10 information can be validated by both methods, or at least the latter, the CA can generate a certificate for the device.

The most common standard for creating certificates is the ITU-T X.509 standard. The X.500 system actually has never been fully developed by ITU-T, including X.509; IETF has taken the ITU-T standard and narrowed its definition for use in device authentication. This is specified in RFC 3280; however, most people commonly refer to this certificate implementation as X.509v3.

The CA, when issuing an identity certificate, will bind a public key to a particular certificate field, like the DN or Alternative Name (e-mail address or FQDN). Each certificate will contain the following information:

• Information supplied by the CA Identity of the CA who issued the certificate, a serial number unique within the CA's domain, the beginning and ending validity dates, the public key of the CA, the signature HMAC algorithm used by the CA to sign the certificate, and the location of the Certificate Revocation List (CRL); the CRL is discussed in the "Certificate Revocation List" section.

• Information from the device's PKCS #10 information The device's name and optionally other information included from the PKCS #10 information.

The CA then generates a random symmetric key and takes this key, the information from the device's PKCS #10, and information the CA supplied and runs all of this through an HMAC function. The CA then encrypts the HMAC symmetric key with its private key. The CA then places the signature hash value (the just created HMAC signature), the encrypted HMAC symmetric key, and the HMAC function used to create the HMAC signature on the device's identity certificate.

It is important to include the HMAC function on the certificate so that someone else can use the same function to verify the HMAC signature with the same HMAC symmetric key. This is shown in Figure 2-6. A device can use the CA's public key to decrypt the HMAC symmetric key and the device can then feed the certificate and HMAC key through the HMAC function to verify that the certificate is authentic. This process is shown in Figure 2-7. Given that the information on the certificate (such as the serial number) and the random HMAC symmetric key are different, every identity certificate will have a unique HMAC signature.

The CA's public key is not located on the identity certificate. In the "Certificates: Acquiring Them" section I'll show how the device acquires the CA's public key so that it can decrypt the hashed signature key to verify the authenticity of any certificate created by the CA.

PKCS #7

PKCS #7 is an RSA standard for signing and encrypting the identity certificate, which will then be sent to the device. This process is sometimes referred to as enveloping. The information (the X.509v3 certificate) is encrypted with the public key of the device for which the certificate is intended. The encrypted information, a file, is then sent by the CA to the device, which can then decrypt it with the device's corresponding private key. This allows the device to detect any tampering of the certificate or a man-in-the-middle attack. PKCS #7 has one interesting feature: it allows you to send multiple certificates in one request; for example, a root and identity certificate, or two or more identity certificates.

There are many ways the CA can envelop, or encode, the certificate besides using PKCS #7. Here is a list of the common file formats: .DER or .CER, .PEM (base-64), .P7B or .P7C (PKCS #7), .PFX or .P12 (PKCS #12). This file (containing the device's encrypted identity certificate) then needs to be sent, in-band or out-of-band, to the requesting device, which, in turn, needs to install the certificate locally (for example, in its flash, NVRAM, or disk drive).

Simple Certificate Enrollment Protocol (SCEP)

As I mentioned, the encoded identity certificate can be sent out-of-band or in-band. In the out-of-band approach, the device generates its PKCS #10 information and mails or e-mails this file to the CA administrator. The CA administrator then creates an X.509 identity certificate from this information and encodes it into a file, like the .P7C or .CER file, which would then be mailed or e-mailed back to the device. This process is not very scalable, especially if you have hundreds or thousands of devices that need identity certificates.

A more scalable approach is to use an in-band solution to acquire certificates. The Simple Certificate Enrollment Protocol (SCEP) uses PKCS #10 and #7 to request and acquire an identity certificate from a CA using an in-band process across an IP network. To use SCEP, the CA must be set up with the SCEP protocol. SCEP uses HTTP to share information between devices; you would have to configure the URL on the device to access the SCEP process on the CA. With SCEP, once you enter your PKCS #10 information and send it, via HTTP, to the CA, the CA will either manually or automatically generate a certificate for you and send this back, in a PKCS #7 format, via HTTP. This whole process can be completed in a handful of minutes compared to the out-of-band approach, making SCEP a more desirable option when you need to install certificates on many devices. In the "Acquiring Certificates" section we'll discuss the SCEP process in more depth.

Certificate Revocation Lists

A Certificate Revocation List (CRL) is a list of certificates that have been revoked by the CA. There are many reasons why you might need to revoke a certificate, including these common ones:

• The private key that the device uses for authentication with its identity certificate has been compromised.

• The identity certificate has been compromised.

• The device is no longer being used, and therefore the identity certificate is not needed.

• The identity certificate has expired and the device needs a new identity certificate.

• The security policy has changed, requiring longer (or shorter) keys for signature functions, thus requiring new public/private keys, a new signature, and a new identity certificate.

To ensure that not just anyone can revoke a certificate, a couple of methods are used to prove a person's identity when they call up the administrator of the CA to revoke a certificate: you don't want anyone to call up and be able to revoke certificates. Therefore the CA needs some method of verifying your identity. Of course, if the administrator personally knows you, then this is not an issue. But if you're using a public CA service, such as Verisign, they'll want some information. This is typically the original challenge password you could optionally enter in the PKCS #10 information when creating the certificate information for the CA. When you give the challenge password to the administrator, he'll verify it with what you originally sent via PKCS #10. If the challenge passwords match, the CA can feel comfortable about your identity and revoke your certificate; otherwise the administrator of the CA will assume that this might be a possible DoS attempt by an attacker and not revoke your certificate. An attacker might try to pretend to be you when talking to the CA administrator and cause the administrator to revoke your certificate. This would be bad for you, because if you would try to use this certificate for authentication functions, your device authentication would fail.

One of the concerns when using certificates for authentication is that when your device receives a certificate from a peer, how does your device know that the certificate is still valid and hasn't been revoked by the CA? This is especially important if the certificate or the keying information associated with the certificate has somehow been compromised. In this situation, the administrator of the CA can revoke the certificate. The list of revoked certificates is stored in the CRL, which contains a list of serial numbers of revoked certificates.

Of course, one easy way of dealing with this is that every time you authenticate to the peer, you download the peer's certificate from the peer and the CA. This can be a time-consuming process if done every hour. In other words, there is a delay in performing the re-authentication, and possibly rebuilding the VPN connection, every hour, which might affect traffic flow between the two devices.

Therefore, it is common that devices cache the peer's certificate locally in RAM. Again, the problem here is that if the certificate is revoked, your device somehow has to figure this out. This is where CRLs play a role. Your device can have the CRL cached locally and periodically check to ensure that it has the most up-to-date list of revoked certificates. Then, when your device needs to authenticate to a remote peer, and you have the remote peer's certificate in your local cache, you can just look up the serial number on the cached certificate and compare this to the list of serial numbers on the CRL. If there's a match, the peer's certificate has been revoked and you should re-request the peer's certificate from the peer and the CA; otherwise, you can use the existing certificate of the peer you have cached locally. If you are unsuccessful in obtaining a peer's new certificate, after being revoked, your device will reject the connection attempt.

To obtain the CRL, the device has to know the location, on the network, where this can be found. The most common place is to examine the CA's certificate (the root certificate) or the RA's certificate. The location will be specified in a URL-style syntax on these certificates. This reference is commonly referred to as a CRL distribution point (CRL DP). If you're not using SCEP, you would have to download the CRL manually and install it on your device.

SCEP can automatically download the CRL. The most common methods of downloading the CRL are HTTP, HTTPS, and Lightweight Directory Access Protocol (LDAP), but other methods might be supported, such as FTP. The most common methods I have seen are HTTP and LDAP. The supported download method or methods are all dependent on the CA product that is being used in the network and how it is configured. For example, if you are using HTTP to download the CRL, your device initiates an HTTP GET request to the server that has the CRL. If the certificate services are set up with LDAP, your device will have to perform an LDAP query to the LDAP service containing the CRL, which might require an additional authentication process. I'll discuss the use of CRLs in more depth in the "Using Certificates" section.

Acquiring Certificates

Now that you have a basic understanding of some of the components used with certificates, I'll discuss, in more depth, how certificates are obtained and used. First, I'll discuss how a device can obtain certificates and then how they are used for authentication functions.

To authenticate with certificates, all peers that wish to authenticate will need to obtain an identity certificate. This could be a self-generated, self-signed certificate, but there is still an issue of proving one's identity because the device might not be considered a trusted source. Therefore, most VPN implementations will use a CA as the trusted source. You'll need to obtain both a root and identity certificate from the CA. There are two approaches a device can use to accomplish this:

• File-based enrollment (out-of-band)

• Network-based enrollment (in-band, uses SCEP)

File-Based Enrollment

The file-based approach is more labor-intensive, but is common in situations where the CA device is a public CA; you're buying a certificate from a third-party company. This is common where the two peers come from two different networks and they want a neutral, trusted third party, like Verisign or Baltimore Technologies (which sell certificates).

To obtain a certificate, your device will need to create some information and package it into a PKCS #10 format and send this off to the CA. Your device will need to create a public/private key and will use the private key to sign the PKCS #10 information. In other words, the device uses the private key to create a signature from the PKCS #10 information and then the PKCS #10 information and the new signature are sent to the CA (actually, the signature is part of the PKCS #10 information the CA will receive). This was discussed earlier in the "PKCS #10" section.

The CA administrator receives the PKCS #10 information from a device and typically copies and pastes that information into its CA product. The CA software will then validate the device's signature in the PKCS #10 information with the device's included public key. Assuming that the signature can be validated, the CA can proceed to create an identity certificate.

The CA uses some of its own information, and some information from the device's PKCS #10 information, to generate an identity certificate. The CA will sign this certificate using its private key. This was discussed earlier in the "X.509 v3 Certificates" section. The certificates will then be encoded using one of two types: DER/CER (raw binary) or PEM (binary-64). You will need to notify the CA if your device supports only one of the two types, so that the CA administrator can use the correct encoding scheme. Optionally, the CA can use the PKCS #7 format method, which allows the CA to encapsulate both certificates in the same file. This would be similar to what ZIP allows you to do (put many files into one). Normally this method is not used in the file-based method.

The CA will then send two certificates to the device: the CA's certificate (root) and the device's new certificate (identity). These two certificates could be mailed to the administrator of the requesting device or electronically transmitted (like e-mail). These two certificates will need to be loaded onto the device.

The order of the installation of the two certificates on the device is very important: the root certificate must be installed first, and the identity certificate second. This is because all other certificates your device receives from this CA (from the same domain) will be validated using this stored root certificate. There are three items the device can check to determine the validity of any root certificate:

If your device can answer "yes" to all three of these answers, then the certificate is considered valid. If the device answers "no" to even one of the questions, the certificate is considered invalid and won't be used, causing authentication to fail. CRLs, in many instances, are optional; so the third step might not be performed if CRL checking is not enabled on the device. After installing the root certificate, you then need to install any RA certificates, and last, the device's identity certificate.

Assuming the root, identity, and RA certificates (if supported), are valid, you are ready to proceed using certificates for authenticating to other devices in the same domain of your CA.

Network-Based Enrollment

As I mentioned in the "Simple Certificate Enrollment Protocol (SCEP)" section earlier, the file-based (out-of-band) approach to obtain certificates is not very scalable. Therefore, if you're installing your own CA product, such as Microsoft's Certificate Server product (part of Microsoft Windows Server 2000 and 2003 Server and Advanced Server editions), then you'll probably use the network-based approach, that is, SCEP, to install certificates on your networking devices.

With SCEP enrollment, you will need to configure your device to interact with the CA. You will need to configure the name of the CA, which is probably a Fully Qualified Domain Name (FQDN), and the URL to interact with the CA via SCEP. The URL will use HTTP as a transport. Each CA product will use a different URL based on the back-end program that handles the SCEP process. For example, Microsoft's CA product would use the following URL:

http://FQDN_or_IP_address_of_CA_server/certsrv/mscep/mscep.dll

Other vendors' products will use a different URL.

There are two approaches your device can use with SCEP to obtain an identity certificate:

• Request and download the root certificate (and, possibly, RA certificates), then request and download the identity certificate. Both operations use PKCS #7.

• Simultaneously request and download both the root (and, possibly, RA certificates) and identity certificates, using PKCS #7 to encode both of them in the same message.

Which method your device uses depends on how the software is written for your VPN device. For example, the Cisco VPN 3000 concentrators, IOS routers, and PIX and ASA security appliances use the former approach, but the Cisco VPN software client (Versions 3.x and 4.x) uses the latter. In the following explanation of using SCEP to obtain an identity certificate, I'll assume that your device uses the latter approach, because the two processes are similar.

As in the file-based enrollment process, your device will need to create a public and private key. Then it will need to create some identity information, like a Common Name, and package it into a PKCS #10 format. One item that is typically configured is a challenge password. The challenge password can be used by the CA to validate the device's identity before granting a certificate. One concern, from the CA administrator's perspective, is that he wants to control who's actually allowed to be given a certificate; and as a CA administrator, you don't want to give just anyone a certificate. Therefore, you can use two approaches to control the certificate granting process:

• Challenge passwords

• Manual verification

The CA can be configured with a challenge password (symmetric pre-shared key) for a device. When the device wants to obtain a certificate, the device must enter the password associated with it that the CA administrator generates for the device. This can sometimes be tied to some other identity information, like the device's IP address or hostname. Therefore, for the device to successfully request a certificate, it must supply the same challenge password and, possibly, identity information.

In many instances the challenge password is a one-time password: it can be used only once to request a certificate. Using the challenge approach for certificate request authentication allows you to request and automatically receive a certificate without manual intervention from the CA administrator.

The challenge password serves a second purpose: it can be used to restrict the revocation of the certificate. In this instance, if someone wanted to revoke your device's certificate, they would need to know the challenge password your device initially used to obtain the certificate. Therefore, you should guard the challenge password carefully.

The CA can be configured to not automatically create a certificate for a device requesting it via SCEP; instead, the administrator of the CA would have to log into the CA, manually verify the request, and then grant or reject the request. In this situation, the device will poll the CA periodically until the certificate request is either granted or rejected.

In either of the two verification approaches, the CA will respond with one of three replies:

• Success The CA responds with the certificate(s) to the device.

• Failure The CA rejects the request, perhaps because of authentication issues (an incorrect challenge password) or SCEP interaction problems (your device and the CA are having SCEP compatibility issues).

• Pending the CA is set up for manual approval; in this case, the CA administrator will have to log in manually and grant or reject the certificate request.

When in a pending state, your device should re-contact the CA periodically to determine if the request was granted. Once granted, your device will request the root certificate, possibly the RA certificate(s), and its own identity certificate. Using PKCS #7, the CA can package all these certificates in one message and send them to your device. When your device receives them, it will install the root certificate first, the RA certificates (if any), and then your identity certificate. Your device will then use the root certificate to validate the RA and identity certificates.

Using Certificates

Once a device has a root and identity certificate, it can begin using them in the authentication process when establishing a VPN session to a remote peer. Thankfully, using certificates is actually much easier than obtaining them. There are three basic items a device will verify when performing the certificate authentication with a remote peer:

• Is the peer's identity certificate signed by a trusted CA and can this signature be verified with the locally stored public key on the root's (CA's) certificate?

• Is the certificate still within the beginning and ending validation time period?

• Is the certificate not listed on the CRL?

If the device can verify all of these and answer "yes" to each of these questions, then the device can be assured of the remote peer's identity and the authentication phase will pass. Checking CRLs, in many devices' implementations, is sometimes optional.

Here are the basic steps involved in the authentication process:

Once the authentication passes, the VPN implementation can proceed in its communication of establishing a connection or connections to transmit user traffic.

User Authentication

Most remote access VPNs use two forms of authentication:

• Device authentication

• User authentication

The following two sections will discuss how device and user authentication are commonly implemented in remote access VPNs.

Remote Access and Device Authentication

Most VPN implementations will use either pre-shared symmetric keys or certificates for device authentication. However, many VPN implementations add an additional feature to their remote access VPN implementations: the ability to put users into groups. By using this function, the VPN implementation can apply the same policies to the members of the group. For example, you might have a programming group and a sales group. You could assign different policies to these groups, such as access restrictions, based on their specific needs in your network. Therefore, the user device must provide some information concerning the group that it belongs to or wants to be associated with.

Pre-shared keys for device authentication in remote access VPNs are sometimes referred to as group keys because the user device supplies both a group name and the pre-shared key for the group. This is a derivation of the device pre-shared key method. With group pre-shared keys, each group would have a unique pre-shared key. And for a user to authenticate its device, its device would have to supply the correct group name and corresponding pre-shared key to authenticate to the network and have the correct policies applied to it. Sometimes this is referred to as wildcard keying, because all users in the group use the same key to authenticate their devices.

Certificates present a different issue. When performing device authentication with certificates, the device could supply the group it belongs to and the certificate. However, the more common approach is for the VPN implementation to use a field on the certificate to represent the group name; therefore, the user device doesn't have to supply this information, nor could the user try to access another group, because this is controlled by his installed identity certificate. In most VPN implementations, the OU (department) field is used, but this is vendor-specific. For instance, Cisco VPN gateway products allow you to define which field or fields are used for the group name value for remote access users.

Remote Access and User Authentication

Remote access connections raise one concern: the device authentication information is normally stored locally on a device, for example, a user's PC or laptop. If the user's laptop is stolen, or their PC is hacked into, the device authentication is now known to the outside party and can be used to successfully authenticate to your network.

On top of this, all people in the group, when using pre-shared keys, need to know the same key for the group: the more people that know the key, the less secure the solution becomes. And when people leave the group, you should change the key; but if the group membership is constantly changing, updating the key can become a hassle (in this case, the best solution is to use certificates for device authentication).

Therefore, because of the two issues I mentioned, remote access connections will typically combine device authentication with user authentication. User authentication allows a VPN implementation to prompt a user with a username and password that are unique to the user. In IPsec, XAUTH is an example of an implementation that provides user authentication for VPNs. Many VPN implementations do not allow the user to save this information on a PC or laptop; therefore, if your PC or laptop is broken into or stolen, this won't help someone break into your network via a remote access VPN session: the thief would only know the group name and password or have access to the device's certificate; he would still need to know the user name and password to successfully authenticate and bring up the VPN session.

And for network administrators that are concerned about using a static password for user accounts, many VPN implementations allow the use of one-time password (OTP) solutions, like token cards. With OTP, every time a user authenticates, a different password is used, making it practically impossible for an attacker to be able to guess a valid password for a user's account.