Internet Key Exchange (IKE)

Nov-22-1999

Sampo Savolainen
Department of Electrical and Communications Engineering
Helsinki University of Technology
Sampo.Savolainen@hut.fi

Abstract

Internet Key Exchange (IKE) is an automated protocol for establishing, negotiating, modifying, and deleting Security Associations (SAs) between two hosts in a network. SAs contains information to establish a secure connection between the parties on pre-defined manners. The IKE is based on the Internet Security Association and Key Management Protocol (ISAKMP), Oakley, SKEME. This paper gives a short introduction to the IKE.

Contents

1 Introduction

2 ISAKMP - Internet Security Association and Key Management Protocol

3 IKE - Internet Key Exchange

4 IKE Authentication methods

5 Oakley Groups

6 Security Considerations

7 Implementations

8 Conclusions

Abbreviations

References

1 Introduction

The IPsec protocol suite is used to provide privacy and authentication services at the IP layer. The base architecture for IPsec compliant systems is described on [1]. Secure Internet sessions need uni-directional Security Associations (SA) between the communicating parties. Security association describes what operations should be applied to a packet. The information that SA specifies: an authentication method, an encryption algorithm, encryption and authentication keys, a lifetime of the encryption key, a lifetime of the SA and a sequence number for replay prevention. Basicly all needed information to execute network security services.

Secure associations can be set manually or automatically. The automatic secure association management is required to make possible deployment of IPsec or when on-demand creation of SA is needed. Internet Key Exchange (IKE) [2] is automated protocol for SA management and it is meant for establishing, negotiating, modifying, and deleting SAs.

IKE is combination of the Internet Security Association and Key Management Protocol (ISAKMP) [3], Oakley [4], and SKEME [5]key exchange protocols. ISAKMP is a key exchange independent framework for authentication, SA management, and establishment, but it doesn't define them. Oakley defines series of key exchanges and services provided by each of them. Key exchanges are called modes. SKEME defines a key exchange which provides anonymity, repudiability, and fast key refreshment.

A domain of interpretation (DOI)[6] is needed to instantiate ISAKMP. The DOI defines naming of the identifiers, interpretation payload etc. Currently IPsec is the only DOI for ISAKMP.

2 ISAKMP - Internet Security Association and Key Management Protocol

ISAKMP defines the procedures for authenticating a communicating peers, creation and management of SA, key generation techniques, and threat mitigation.

The key creation and the authentication of the negotiators is meaningful to combine for achieving a proved identity of the key owning party.

The ISAKMP negotiation is divided into two separate phases. In the first phase ISAKMP SA is established between two entities to protect further negotiation traffic. In the second phase SA for some security protocol, for example IPsec, is negotiated and established. One ISAKMP SA can be used to establish many security associations for other protocols.

Two phases approach is chosen to allow establishing many SAs without need to start over for each communication, simpler second phase exchange, and to reduce cost of ISAKMP management by reducing need to go through costly re-authentication.

The roles of the negotiators might change between phases, either one could be an initiator of the second phase.

All the ISAKMP messages are made of a ISAKMP header and subsequent payloads. The ISAKMP header contains two cookies (initiator and responder) to protect the exchange from replay and denial-of-service attacks. The cookies are pieces of random information, which must be unique for each SA establishment. The cookies can be checked at first and a illegal message could be discarded without resource consuming calculations.

ISAKMP defines payloads for the needs of the implementations. The payloads are used for building ISAKMP messages. The payloads are constructed from the generic ISAKMP payload header and an implementation specific data. An example payload could be a security association payload, which made of a payload header and an implementation specific security association. The use of generic ISAKMP payload header allows ISAKMP to be extended. IKE utilizes ISAKMP payloads.

2.1 ISAKMP Exchanges

2.1.1 Base Exchange

The Base Exchange is designed to allow the Key Exchange and Authentication related information to be transmitted together. This reduces the number of round-trips at the expense of identity protection. Four messages are needed to accomplish the exchange. Identity protection is not provided because identities are established before a common shared secret has been established.

2.1.2 Identity Protection Exchange

The Identity Protection Exchange is designed to separate the Key Exchange information from the identity and authentication related information. A common share secret can be established before identification and authentication related information is exchanged and encryption provides protection of the communicating identities. The expense of the identity protection is two additional messages (totally six messages) when compared to the Base Exchange.

2.1.3 Authentication Only Exchange

The Authentication Only Exchange allows only Authentication related information to be transmitted. The benefit of this exchange is the ability to perform only authentication without the computational expense of computing keys. Only three messages are needed.

2.1.4 Aggressive Exchange

The Aggressive Exchange allows the Security Association, Key Exchange and Authentication related payloads to be transmitted together. Combining all this information into one message reduces the number of round-trips at the expense of not providing identity protection. There are three messages in the aggressive exchange.

2.1.5 Informational Exchange

The Informational Exchange is one-way transmittal that can be used for SA management. If the Informational Exchange occurs to the keying material exchange during an ISAKMP phase 1 there will be no protection for the Informational Exchange.

3 IKE - Internet Key Exchange

ISAKMP is just a framework for key management and exchange. IKE is one implementation of ISAKMP to be used with IPsec. The key exchange of IKE is based on the Diffie-Hellman cryptographic key exchange protocol [7]. Diffie-Hellman gets its security from the difficulty of calculating discrete logarithms in a finite field.

The detailed description of Diffie-Hellman algorithm can be found in [9].

3.1 Modes

The phases in the IKE are same as in the ISAKMP. In the first phase an IKE SA is negotiated to protect the second phase and in the second phase keying material is derived and shared policy is negotiated for non-IKE SAs, for example for TLS[8].

The roles of the negotiators may change between modes. The initiator of the first mode might be a responder of the second mode.

There are two modes to establish a phase one IKE SA: Main Mode and Aggressive Mode. Aggressive Mode is a bit faster, but it doesn't provide an identity protection when the Main Mode is based on ISAKMP's identity protection exchange and provides the protection of the identity. In the phase 2 the Quick Mode is used for establishing SAs for the IKE's clients. There is also the New Group Mode,which is not Phase 1 or Phase 2 mode. It is used for establishing a new Oakley Group for Diffie-Hellman key exchanges. More information about Oakley Groups is given in the section five.

The following notation is used on the next chapters:

3.1.1 Main Mode

The Main Mode is an exchange in the first phase of IKE/ISAKMP (The ISAKMP Identity Protection Exchange) the first two messages are used for negotiating the security policy for the exchange. The next two messages are used for the Diffie-Hellman keying material exchange. The last two messages are used for authenticating the peers with signatures or hashes and optional certificates. Last two authentication messages are encrypted with the previously negotiated key and the identities of the parties are protected from eavesdroppers.

Figure 1. Main Mode

3.1.2 Aggressive Mode

The Aggressive Mode is an exchange in the first phase of IKE/ISAKMP (The ISAKMP Aggressive Exchange) is like the Main Mode, but some messages are embedded to the others. The first message proposes the policy, and passes data for key-exchange, the nonce and some information for identification. The second message is a response which authenticates the responder and concludes the policy and key-exchange. At this point all the information for encryption key for the ISAKMP SA is exchanged and last the message could be encrypted, but doesn't have to be. The last message is used for authenticating the initiator and provides a proof of participation in the exchange. The identity of the responder could not be protected, but by encrypting the last message the identity of the initiator is protected.

Figure 2. Aggressive Mode

3.1.3 Quick Mode

The Quick Mode is used for and exchange in the second phase of IKE. An IKE SA is established in the first phase to protect the second phase's exchange by previously described Main or Aggressive Mode. The Quick Mode is used for negotiating SA and generating new keying material. All the payloads except ISAKMP header are encrypted. A Diffie-Hellman key exchange may be done to achieve perfect forward secrecy. Perfect forward secrecy and its relation to the Quick mode is described in details in the section six. Many SAs can be negotiated during one Quick Mode exchange. Either one of the parties might initiate the quick mode exchange in spite of who initiated the first phase.

Figure 3. Quick Mode

3.1.4 New Group Mode

The New Group Mode is used for negotiating a new group (modular exponentiation group MODP or elliptic curve) where to do Diffie-Hellman exchange. The MODPs defines group characteristics where to calculate Diffie-Hellman.

Even if New Group Mode exchange is not phase two exchange it must follow phase one exchange.

Figure 4 New Group Mode

4 IKE Authentication Methods

Four different authentication methods are allowed with the Main Mode and and Aggressive Mode: two public key encryption based authentication, digital signature, and pre-shared key. Authentication with a pre-shared key must be provided in the IKE implementation.

4.1 Authentication with Digital Signatures

The exchange is authenticated by applying negotiated signature algorithm to hashes, which are available only to the negotiating parties. A hashing algorithm is applied to almost all of the exchanged parameters.

Certificates might be provided also within exchange.

4.2 Authentication with Public Key Encryption

The exchange is authenticated by encrypting the identities and nonces other party's public key and then examining the hash sent by the other party. A right hash value proves that the other party can decrypt a data encrypted with its public key. The public keys must be provided somehow before hand.

The usage of public key encryption adds security to the key exchange, since an attacker would have to break the Diffie-Hellman exchange and RSA encryption. An identity is protected also with Aggressive Mode.

The authentication with public key encryption is computing wise relatively expensive, two public key encryption and decryption is needed by each party.

The each party can construct both sides of the exchange so there is no proof that the conversation ever took place.

Certificates might be provided also within exchange.

This exchange is derived from SKEME [5].

4.3 Authenticated With a Revised Mode of Public Key Encryption

The idea of revised mode of public key encryption is to take significant advantages of the previously described authentication and replace some of the costly public key encryptions with symmetric encryptions.

Certificates might be provided also within exchange.

4.4 Authentication with a Pre-Shared Key

A key shared by secure out-of-band mechanism may also be used to authenticate parties. This authentication limits identifying methods in the Main Mode to a IP address. The authentication with a pre-shared key is the only authentication method, which is mandatory according to [2].

5 Oakley Groups

With IKE, the group in which to do the Diffie-Hellman exchange is negotiated. These five groups originated with the Oakley protocol and are therefore called "Oakley Groups". Those five pre-defined groups were all generated by Richard Schroeppel at the University of Arizona. Three of the groups are classical modular exponentiation groups (MODP) and two are elliptic curve groups. Properties of these groups are described in [4].

New groups can be negotiated with the New Group Mode.

6 Security Considerations

6.1 Protection from the Attacks

ISAKMP sets requirements for its key exchange components and authentication. These requirements guards against protocol targeted attacks.

6.1.1 Man-In-The-Middle

Man-In-The-Middle attack is a situation where a bad guy sits between communicating parties (A and B) on the network and intercepts traffic. The man in the middle acts as B to A and as A to B and relays traffic between them. The man in the middle could also modify, delete or insert traffic.

The linking of ISAKMP exchanges is designed to prevent insertion of messages. The deletion of messages will cancel the creation of SA so partial SA won't be created. Strong authentication of the parties prevents the risk of establishing a SA with other than intended party.

6.1.2 Denial of Service

Denial of Service attack where an user can set the system unusable for legimate users by using the system's resources. Computers on a public network are vulnerable to denial of service attacks.

A cookie pair at the ISAKMP header is used to to protect computing resources without spending a lot of own resources to drop bogus messages before computing intensive public key operations. Also aggressive garbage state collection should be implement to discard protocol state information, which are created for started bogus exchanges. Absolute denial of service protection is impossible to create, but the design of the ISAKMP makes situation easier to handle.

6.1.3 Replay/Reflection

Replay or Reflection attack is a situation when a third party records network traffic and replays it.

ISAKMP sets requirement for cookies to include a time variable material which eases detection of replay.

6.1.4 Connection Hijacking

The connection hijacking is an attack where a third party jumps in in the middle of transaction and steals the connection.

IKE is protected from the connection hijacking by linking the authentication, key exchange, and security association exchanges. The linking of exchanges prevents a third party attacker to jump in after authentication and act as one of the authenticated party during key exchange or security association exchange.

6.2 Perfect Forward Secrecy

According to [2] Perfect Forward Secrecy (PFS) refers to the notion that compromise of a single key will permit access to only data protected by a single key. For PFS to exist the key used to protect transmission of data MUST NOT be used to derive any additional keys, and if the key used to protect transmission of data was derived from some other keying material, that material MUST NOT be used to derive any more keys.

To provide Perfect Forward Secrecy both parties must:

• Use the Main Mode to protect identities, when establishing ISAKMP SA
• Use the Quick Mode to negotiate SAs
• Delete ISAKMP SAs after each Quick Mode exchange pairs to force a creation of the new ISAKMP SA

When the ISAKMP SAs are deleted a new Diffie-Hellman key generation from the new keying material will be done and bindings to the old keys are totally lost and Perfect Forward Secrecy is preserved.

7 Implementations

Implementations of the IKE are usually Unix daemons or separated Windows processes. The IKE user mode process can use normal socket services to communicate with IKE peers, but it also needs to interact with kernel process, which implements security protocol (e.g. IPsec). Figure 5 illustrates integration of the IKE to the operating system and TCP/IP stack. IKE can be implemented over any transport protocol or over IP itself. Implementations must, however, support at least the User Datagram Protocol (UDP) at port 500.

Figure 5 The integration of the IKE to the operating system

There are commercial implementations of the IKE from many companies. SSH Communications Ltd is licensing their implementation as a source form for the other companies. SSH's IKE is amongst the first implementations. Some of commercial IKE products are based on that SSH's implementation (e.g. Data Fellows VPN+'s IKE and Sun Microsystems has also licensed it). Network Associates has at least IKE implementation' which is not based on SSH's one. There is also IKE implementation which is under GNU General Public License (GPL) FreeS/WAN.

8 Conclusions

The IPsec suite requires a protocol to securely manage, authenticate, and exchange Security Associations. IKE is instantiation of the ISAKMP key management framework and meets IPsec's requirements, even if other protocols are needed to e.g. obtain certificates or public keys.

Implementation of IKE might be painfully because it is combination of so many protocols and specifications and it must to inter-operate with other implementations. IKE is based on ISAKMP, which is a framework to manage Internet Security Association, but ISAKMP doesn't define a management protocol. Domain of Interpretation is defined for IPsec, and Oakley and SKEME is adapted to the ISAKMP framework to accomplish the requirements of key management.

ISAKMP's and that way IKE's two phase key exchange and authentication is well designed to be expandable to face security challenges of today's and future's Internet environment.

Abbreviations

References