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 system.
Main Mode and Aggressive Mode
IKE phase 1 negotiations are used to negotiate keys. The two IKE peers then use these keys to communicate securely during phase 2 negotiations. IKE uses several modes for phase 1 negotiations: main mode, aggressive mode, and quick mode. You can use main mode or aggressive mode to establish the initial secure tunnels between two security gateways. After that, quick mode can be used to establish and refresh user-level SAs.
The choice of main or aggressive mode is a matter of tradeoffs. Some of the characteristics of the two modes are:
- Protects the identities of the peers during negotiations and is therefore more secure.
- Allows greater proposal flexibility than aggressive mode.
- Is more time consuming than aggressive mode because more messages are exchanged between peers.
- Is faster than main mode.
- Exposes identities of the peers to eavesdropping, making it less secure than main mode.
Aggressive Mode Negotiations
During aggressive mode phase 1 negotiations, the ERX system behaves as follows:
- When the ERX system is the initiator, the system searches all policy rules to find those that allow aggressive mode. The system then selects the rule with highest priority and uses the rule to initiate phase 1 negotiation. If there are no policy rules with aggressive mode allowed, the system selects the highest-priority rule that allows main mode.
- When the ERX system is the responder, the negotiation depends on what the initiator proposes, as well as what is configured in the policy rules.
Table 11-6 outlines the possible combinations of initiator proposals and policy rules. As shown, allowing aggressive mode in a policy rule allows negotiation to take place no matter what the initiator requests.
The system 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 will not be able to successfully negotiate the IKE SA, and no data flow will be possible.
IKE policies are global to the system. Every IPSec service line module on a system 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 system uses is always the same and independent of which peer the system is negotiating with.
During negotiation, the system may 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. The fact still remains that 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:
Hash Function
A specific hash function can be specified to an IKE policy. The supported ones are:
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 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 system supports two authentication methods:
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 Chapter 12, Configuring Digital Certificates.
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 system allows preshared keys to be up to 256 characters composed of any ASCII alphanumeric character, except spaces.
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:
Lifetime
Like a user SA, an IKE SA should not last indefinitely. Therefore, the system 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. One minute before the IKE SA lifetime runs out, the system renegotiates the IKE SA, and new key material is established. By negotiating the SA before the lifetime expires, there is no interruption of processing the user SA.
IKE SA Negotiation
As the initiator of an IKE SA, the system 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 system receives all IKE policies from a remote security gateway. The system then scans its own list of IKE policies to check 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.