IKE Overview

The IKE suite of protocols allows a pair of security gateways to:

• Dynamically establish a secure tunnel over which the security gateways can exchange tunnel and key information.
• Set up user-level tunnels or SAs, including tunnel attribute negotiations and key management. These tunnels can also be refreshed and terminated on top of the same secure channel.

IKE is based on the Oakley and Skeme key determination protocols and the ISAKMP framework for key exchange and security association establishment. IKE provides:

• Automatic key refreshing on configurable timeout
• Support for public key infrastructure (PKI) authentication systems
• Antireplay defense

IKE is layered on UDP and uses UDP port 500 to exchange IKE information between the security gateways. Therefore, UDP port 500 packets must be permitted on any IP interface involved in connecting a security gateway peer.

The following sections expand on the IKE functionality available for the router.

Main Mode and Aggressive Mode

IKE phase 1 negotiations are used to establish IKE SAs. These SAs protect the IKE phase 2 negotiations. IKE uses one of two modes for phase 1 negotiations: main mode or aggressive mode. The choice of main or aggressive mode is a matter of tradeoffs. Some of the characteristics of the two modes are:

• Main mode
  • Protects the identities of the peers during negotiations and is therefore more secure.
  • Enables greater proposal flexibility than aggressive mode.
  • Is more time consuming than aggressive mode because more messages are exchanged between peers. (Six messages are exchanged in main mode.)
• Aggressive mode
  • Exposes identities of the peers to eavesdropping, making it less secure than main mode.
  • Is faster than main mode because fewer messages are exchanged between peers. (Three messages are exchanged in aggressive mode.)
  • Enables support for fully qualified domain names (FQDNs) when the router uses preshared keys.

The next section describes aggressive mode in more detail.

Aggressive Mode Negotiations

During aggressive mode phase 1 negotiations, the E Series router behaves as follows:

• When the router is the initiator, the router searches all policy rules to find those that allow aggressive mode. The router then selects the rule with the highest priority and uses the rule to initiate phase 1 negotiations. If there are no policy rules with aggressive mode allowed, the router selects the highest-priority rule that allows main mode.
• When the router is the responder, the negotiation depends on what the initiator proposes, as well as what is configured in the policy rules.

Table 13 outlines the possible combinations of initiator proposals and policy rules. As indicated, allowing aggressive mode in a policy rule allows negotiation to take place no matter what the initiator requests.

The router responds to phase 1 negotiations with the highest-priority policy rule that matches the initiator. A match means that all parameters, including the exchange type, match.

IKE Policies

An IKE policy defines a combination of security parameters to be used during the IKE SA negotiation. IKE policies are configured on both security gateway peers, and there must be at least one policy on the local peer that matches a policy on the remote peer. Failing that, the two peers are not able to successfully negotiate the IKE SA, and no data flow is possible.

IKE policies are global to the router. Every ISM on a router uses the same set of policies when negotiating IKE SAs. The agreed-on IKE SA between the local system and a remote security gateway may vary, because it depends on the IKE policies used by each remote peer. However, the initial set of IKE policies the router uses is always the same and independent of which peer the router is negotiating with.

During negotiation, the router might skip IKE policies that require parameters that are not configured for the remote security gateway with which the IKE SA is being negotiated.

You can define up to ten IKE policies, with each policy having a different combination of security parameters. A default IKE policy that contains default values for every policy parameter is available. This policy is used only when IKE policies are not configured and IKE is required.

The following sections describe each of the parameters contained in an IKE policy.

Priority

Priority allows better (more secure) policies to be given preference during the negotiation process. However, every IKE policy is considered secure enough to secure the IKE SA flow.

During IKE negotiation, all policies are scanned, one at a time, starting from the highest-priority policy and ending with the lowest-priority policy. The first policy that the peer security gateway accepts is used for that IKE session. This procedure is repeated for every IKE session that needs to be established.

Encryption

A specific encryption transform can be applied to an IKE policy. The supported encryption algorithms are:

• DES
• 3DES

Hash Function

A specific hash function can be applied to an IKE policy. The supported ones are:

• MD5
• SHA-1

IKE also uses an authentication algorithm during IKE exchanges. This authentication algorithm is automatically set to the HMAC version of the specified hash algorithm. Therefore, you cannot have the hash function set to MD5 and the authentication algorithm set to HMAC-SHA.

Authentication Mode

As part of the IKE protocol, one security gateway needs to authenticate the other security gateway to make sure that the IKE SA is established with the intended party. The ERX 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.

  For more information, see Configuring Digital Certificates.

• Preshared keys

  With preshared key authentication mode, the same secret string (similar to a password) must be configured on both security gateways before the gateways can authenticate each other. It is not advisable to share a preshared key among multiple pairs of security gateways, because it reduces the key's security level.

  The router allows preshared keys to be up to 256 ASCII alphanumeric characters.

Diffie-Hellman Group

An IKE policy must specify which Diffie-Hellmann group is used during the symmetrical key generation phase of IKE. The following Diffie-Hellmann groups are supported:

• Group 1 (768-bit)
• Group 2 (1024-bit)
• Group 5 (1536-bit)

Lifetime

Like a user SA, an IKE SA does not last indefinitely. Therefore, the router allows you to specify a lifetime parameter for an IKE policy. The timer for the lifetime parameter begins when the IKE SA is established using IKE.

IKE SA Negotiation

As the initiator of an IKE SA, the router sends its IKE policies to the remote peer. If the peer has an IKE policy that matches the encryption, hash, authentication method, and Diffie-Hellmann group settings, the peer returns the matching policy. The peers use the lesser lifetime setting as the IKE SA lifetime. If no match is found, the IKE SA fails, and a log alarm is generated.

As the responder of an IKE negotiation, the router receives all IKE policies from a remote security gateway. The router then scans its own list of IKE policies to determine whether a match exists, starting from the highest priority. If it finds a match, that policy is successfully negotiated. Again, the lifetime is negotiated to the lesser of the two lifetimes, and failures are logged.

Generating Private and Public Key Pairs

When any of the public key methods for authenticating remote security gateways is used, the system must have at least one valid pair of public or private keys. Therefore, the system provides a facility by which it can generate public and private key pairs for itself.

The private key is used only by the system itself. It is never exchanged with any other nodes. When generated, the private key is securely stored internally to the system in nonvolatile memory. Access to the private key is never given, not even to a system administrator or to a network management system.

The public key is used in either of the following scenarios:

• A network administration system or system administrator can retrieve it so that it can be entered into remote security gateways with which the system needs to establish an IKE SA.
• It can be given to CAs so that they can properly sign it. From there, the public key is distributed to remote security gateways that can handle a PKI.

The public/private key pair as provided by the system supports the RSA standard (512, 1024, or 2048 bits).

The public/private key pair is a global system attribute, regardless of how many ISMs exist in the system. Only one set of keys is available at any given time.