[Contents] [Prev] [Next] [Index] [Report an Error]

# IKE Authentication with Digital Certificates

As part of the IKE protocol, one security gateway needs to authenticate another security gateway to make sure that IKE SAs are established with the intended party. The router supports two authentication methods:

- Digital certificates (using RSA algorithms)

  For digital certificate authentication, an initiator signs message interchange data using his private key, and a responder uses the initiator's public key to verify the signature. Typically, the public key is exchanged via messages containing an X.509v3 certificate. This certificate provides a level of assurance that a peer's identity—as represented in the certificate—is associated with a particular public key. E-series routers provide both an offline (manual) and an online (automatic) process when using digital certificates.

- Preshared keys

  With preshared key authentication, the same secret must be configured on both security gateways before the gateways can authenticate each other.

The following sections provide information about digital certificates. For information about using preshared keys, see IKE Overview .

You can also use public keys for RSA authentication without having to obtain a digital certificate. For details, see IKE Authentication Using Public Keys Without Digital Certificates .

## Signature Authentication

The following are key steps for using public key cryptography to authenticate a peer. These steps are described in more detail in the following sections.

1. Generating a private/public key pair

   Before the router can place a digital signature on messages, it requires a private key to sign, and requires a public key so that message receivers can verify the signature.

2. Obtaining a root CA certificate

   The router requires at least one root CA certificate to send to IKE peers and also to verify that a peer's certificate is genuine.

3. Obtaining a public key certificate

   The router requires at least one public key certificate, which binds the router identity to its public key. The CA verifies the identity represented on the certificate and then signs the certificate. The router sends the certificate to IKE peers during negotiations to advertise the router public key.

4. Authenticating the peer

   As part of IKE negotiations, the router receives its peer's digital signature in a message exchange. The router must verify the digital signature by using the peer's public key. The public key is contained in the peer's certificate, which often is received during the IKE negotiation. To ensure that the peer certificate is valid, the router verifies its digital signature by using the CA public key contained in the root CA certificate. The router and its IKE peer require at least one common trusted root CA for authentication to work.

Generally, only Step 4 is required each time a phase 1 negotiation happens. The first three steps are required only if keys are compromised or router certificates require renewal.

## Generating Public/Private Key Pairs

The ERX router needs at least one valid pair of public/private keys whenever it uses any of the public key methods for authenticating an IKE peer. The ERX router can generate its own public/private key pairs. The public/private key pair supports the RSA standard (1024 or 2048 bits).

The private key is used only by the ERX router. It is never exchanged with any other nodes. It is used to place a digital signature on IKE authentication messages. When generated, it is securely stored internally to the ERX router in nonvolatile storage (NVS). Access to the private key is never allowed, not even to a system administrator or a network management system. Private key storage includes protection mechanisms to prevent improper private key usage, including encryption with 3DES using a unique internally generated key. The key is also tied to SRP-specific data to prevent swapping flash disks between routers.

The public key is used in the generation of the router certificate request, which is sent to a CA. Based on the certificate request, the CA generates a public key certificate for the E-series router.

The router public/private key pair is a global system attribute. It does not matter how many IPSec Service modules (ISMs) exist in the router; only one set of keys is available at any given moment. The private/public key pair applies across all virtual routers and is persistent across reloads and booting to factory defaults.

## Obtaining a Root CA Certificate

The ERX router enables the use of either a manual or automatic method to download the root CA's self-signed certificate. The standards supported for obtaining root CAs are X.509v3, base64, and basic-encoding-rules (BER)–encoded certificates.

In the manual method, an operator obtains the root CA certificate, typically through a Web browser, and copies the certificate file to the E-series router so that the router can use it as part of IKE negotiations.

In the automatic method, the router uses SCEP and HTTP to authenticate with the CA and retrieve the certificate. The requested root CA certificate is automatically downloaded to the router.

| Note: You cannot view certificate files by their filenames if the files were created by online enrollment. However, the certificate information will appear in the output for show commands.

## Obtaining a Public Key Certificate

After the public key is generated, the router must obtain a public key certificate from a CA, a process called certificate enrollment. The procedure to obtain public keys depends on whether the offline or online digital certificate process is being used.

The standards supported for certificate enrollment are PKCS #10 certificate requests, PKCS #7 responses, and X.509v3 certificates. For manual enrollment, certificates are encoded in base64 (MIME) so that the files are easily transferred through cut-and-paste operations and e-mail.

### Offline Certificate Enrollment

Offline certificate enrollment works as follows:

1. An operator generates a certificate request by supplying identity information.
2. The ERX router creates a certificate request file and makes it available to the operator.
3. The operator supplies the certificate request file to a CA for approval, typically by copying and pasting the file to a Web page.
4. The CA approves the request and generates a certificate.
5. The operator copies the certificate file onto the ERX router so that it can be used for IKE negotiations.

### Online Certificate Enrollment

Online certificate enrollment works as follows:

| Note: The ERX router must have a root CA certificate for the specified CA before online certificate enrollment.

- The router uses SCEP and HTTP to enroll with the specified CA and retrieve the certificate that the router uses in IKE negotiations.

## Authenticating the Peer

The ERX router validates X.509v3 certificates from the peer by confirming that the ID payload passed in IKE matches the identifiers in the peer certificate. The router also verifies that the signature is correct, based on the root CA public key.

The ERX router also validates the certificate based on its time window, so correct UTC time on the router is essential. In addition to the certificate checks, the router confirms that message data received from the peer has the correct signature based on the peer's public key as found in its certificate. After the IKE authentication is done, quick-mode negotiation of SAs can proceed.

## Verifying CRLs

You can control how the router handles CRLs during negotiation of IKE phase 1 signature authentication. Both the offline and online digital certificate processes enable you to verify CRLs.

To verify CRLs in the offline certificate process, you must copy CRL files that are published by CAs to the ERX router. Using the ipsec crl command, you can control how the router handles CRLs during negotiation of IKE phase 1 signature authentication.

In the online certificate method you use the crl command to control CRL verification. The router uses HTTP to support CRL verification when the CRL distribution point that appears in the certificate has an http://name Uniform Resource Indicator (URI) format.

The ipsec crl and crl commands have three possible settings:

- Ignored—Allows negotiations to succeed even if a CRL is invalid or the peer's certificate appears in the CRL; this is the most lenient setting.
- Optional—If the router finds a valid CRL, the router uses it.
- Required—Requires a valid CRL, and the certificates belonging to the E-series router or the peer must not appear in the CRL; this is the strictest setting.

Based on the CRL setting, you can expect the phase 1 IKE negotiations to succeed or fail depending on the following conditions:

- CRL OK—The certificate revocation list is present for the CA and valid (not expired).
- CRL expired—The CRL is present on the ERX router but is expired.
- Missing CRL—There is no CRL on the router for the CA.
- Peer Cert revoked—The CRL contains the peer certificate.
- ERX Cert revoked—The CRL contains the E-series router's certificate.

Table 15 presents how the CRL setting affects the outcome of IKE phase 1 negotiations. It lists common problem conditions such as ERX Cert revoked.

Table 15: Outcome of IKE Phase 1 Negotiations

|  | CRL Setting |
--- | --- | --- | ---
Condition | Ignored | Optional | Required
CRL OK | Succeed | Succeed | Succeed
CRL expired | Succeed | Succeed | Fail
Missing CRL | Succeed | Succeed | Fail
Peer Cert revoked | Succeed | Fail | Fail
ERX Cert revoked | Succeed | Fail | Fail

## File Extensions

Table 16 describes the file extensions that the ERX routers use for digital certificates that are created by the offline process.

During the online digital certificate process, the certificate files are kept in NVS in hidden areas and are not visible to users (the files do not appear when you enter a dir shell command). Use the show commands to display information for the online certificate files. The router's private keys are similarly hidden from users.

Table 16: File Extensions (Offline Configuration)

File Extension | Description
--- | ---
.crq | Used for certificate request files that are generated on the ERX router and taken to CAs for obtaining a certificate.
.cer | Used for public certificate files. The public certificates for root CAs and the router public certificates are copied to the ERX router. They are automatically recognized as belonging to the ERX router or CA by certificate subject name and issuer name (in a CA they are the same). The ERX router supports multiple CAs.
.crl | Used for certificate revocation lists that are obtained offline from CAs and copied to the ERX router. CRLs indicate which certificates from a particular CA are revoked.

## Certificate Chains

In a basic CA model, there is a single CA from which the ERX router obtains the root CA certificates and the router's public key certificates. The E-series router also supports CA hierarchies, which consist of a top-level root CA and one or more sub-CAs (also called issuing CAs).

In a CA hierarchy, the router obtains its public key certificates and the CA certificate from a sub-CA. The sub-CA's certificate is signed by the root CA.

This process creates a certificate chain of trust in which the E-series router must verify all certificates in the chain until the router reaches a trusted CA, such as the root CA. For example, if the router receives traffic from a peer with a certificate signed by a sub-CA, the router first verifies the sub-CA's signature on the peer's certificate, then verifies the sub-CA's certificate, which is signed by the trusted root CA.

The ERX router supports CA hierarchies consisting of the root CA and one level of sub-CAs. When using a CA hierarchy, the router authenticates and enrolls for its public certificate with the sub-CA. When you use the show ipsec ike-certificates command, the root CA and sub-CA certificates are listed as CA certificates, and the router's public certificates are signed by the sub-CA.

[Contents] [Prev] [Next] [Index] [Report an Error]