Internet Key Exchange

INTERNET KEY EXCHANGE

The key management portion of IPsec involves the determination and distribution of secret keys. A typical requirement is four keys for communication between two applications: transmit and receive pairs for both integrity and confidentiality. The IPsec Architecture document mandates support for two types of key management:

•                           Manual: A system administrator manually configures each system with its  own keys and with the keys of other communicating systems. This is practical for small, relatively static environments.

•                           Automated: An automated system enables the on-demand creation of keys for SAs and facilitates the use of keys in a large distributed system with an evolving configuration.

The default automated key management protocol for IPsec is referred to as ISAKMP/Oakley and consists of the following elements:

•                 Oakley Key Determination Protocol: Oakley is a key exchange protocol based on the Diffie-Hellman algorithm but providing added security. Oakley is generic in that it does not dictate specific formats.

•                 Internet Security Association and Key Management Protocol (ISAKMP): ISAKMP provides a framework for Internet key management and provides the specific protocol support, including formats, for negotiation of security attributes.

ISAKMP by itself does not dictate a specific key exchange algorithm; rather, ISAKMP consists of a set of message types that enable the use of a variety of key exchange algorithms. Oakley is the specific key exchange algorithm mandated for use with the initial version of ISAKMP.

In IKEv2, the terms Oakley and ISAKMP are no longer used, and there are significant differences from the use of Oakley and ISAKMP in IKEv1. Nevertheless, the basic functionality is the same. In this section, we describe the IKEv2 specification.

Key  Determination Protocol

IKE key determination is a refinement of the Diffie-Hellman key exchange algo- rithm. Recall that Diffie-Hellman involves the following interaction between users A and B. There is prior agreement on two global parameters: q, a large prime num- ber; and a, a primitive root of q. A selects a random integer XA as its private key and transmits to B its public key VA  =  aXA mod q. Similarly, B selects a random integer XB as its private key and transmits to A its public key VB  =  aXB mod q. Each side can now compute the secret session key:

K  =  (VB)XA mod q  =  (VA)XB mod q  =  aXAXB mod q

The Diffie-Hellman algorithm has two attractive features:

•                 Secret keys are created only when needed. There is no need to store secret keys for a long period of time, exposing them to increased vulnerability.

•                 The exchange requires no pre-existing infrastructure other than an agreement on the global parameters.

However, there are a number of weaknesses to Diffie-Hellman, as pointed out in [HUIT98].

•                 It does not provide any information about the identities of the parties.

•                 It is subject to a man-in-the-middle attack, in which a third party C imperson- ates B while communicating with A and impersonates A while communicating with B. Both A and B end up negotiating a key with C, which can then listen to and pass on traffic. The man-in-the-middle attack proceeds as

1.                                B sends his public key YB in a message addressed to A (see Figure 10.2).

The enemy (E) intercepts this message. E saves B’s public key and sends a message to A that has B’s User ID but E’s public key YE. This message is sent in such a way that it appears as though it was sent from B’s host system. A receives E’s message and stores E’s public key with B’s User ID. Similarly, E sends a message to B with E’s public key, purporting to come from A.

2.                                               B computes a secret key K1 based on B’s private key and YE. A computes a secret key K2 based on A’s private key and YE. E computes K1 using E’s secret key XE and YB and computers K2 using XE and  YA.

3.                                               From now on, E is able to relay messages from A to B and from B to A, appropriately changing their encipherment en route in such a way that neither A nor B will know that they share their communication with E.

•                           It is computationally intensive. As a result, it is vulnerable to a clogging attack, in which an opponent requests a high number of keys. The victim spends considerable computing resources doing useless modular exponentiation rather than real work.

IKE key determination is designed to retain the advantages of Diffie- Hellman, while countering its weaknesses.

FEATURES OF IKE KEY DETERMINATION The IKE key determination algorithm is characterized by five important   features:

1.                                       It employs a mechanism known as cookies to thwart clogging attacks.

2.                                       It enables the two parties to negotiate a group; this, in essence, specifies the global parameters of the Diffie-Hellman key exchange.

3.                                       It uses nonces to ensure against replay attacks.

4.                                       It enables the exchange of Diffie-Hellman public key values.

5.                                       It authenticates the Diffie-Hellman exchange to thwart man-in-the-middle attacks.

We have already discussed Diffie-Hellman. Let us look at the remainder of these elements in turn. First, consider the problem of clogging attacks. In this attack, an opponent forges the source address of a legitimate user and sends a public Diffie- Hellman key to the victim. The victim then performs a modular exponentiation to compute the secret key. Repeated messages of this type can clog the victim’s system with useless work. The cookie exchange requires that each side send a pseudoran- dom number, the cookie, in the initial message, which the other side acknowledges. This acknowledgment must be repeated in the first message of the Diffie-Hellman key exchange. If the source address was forged, the opponent gets no answer. Thus, an opponent can only force a user to generate acknowledgments and not to perform the Diffie-Hellman calculation.

IKE mandates that cookie generation satisfy three basic requirements:

1.                                       The cookie must depend on the specific parties. This prevents an attacker from obtaining a cookie using a real IP address and UDP port and then using it to swamp the victim with requests from randomly chosen IP addresses or ports.

It must not be possible for anyone other than the issuing entity to generate cook- ies that will be accepted by that entity. This implies that the issuing entity will use local secret information in the generation and subsequent verification of a cookie. It must not be possible to deduce this secret information from any partic- ular cookie. The point of this requirement is that the issuing entity need not save copies of its cookies, which are then more vulnerable to discovery, but can verify an incoming cookie acknowledgment when it needs to.

2.                        The cookie generation and verification methods must be fast to thwart attacks intended to sabotage processor resources.

The recommended method for creating the cookie is to perform a fast hash (e.g., MD5) over the IP Source and Destination addresses, the UDP Source and Destination ports, and a locally generated secret value.

IKE key determination supports the use of different groups for the Diffie- Hellman key exchange. Each group includes the definition of the two global parame- ters and the identity of the algorithm. The current specification includes the following groups.

•                 Modular exponentiation with a 768-bit modulus

q = 2768 - 2704 - 1 + 264 * (:2638 * p; + 149686)

a  = 2

•                 Modular exponentiation with a 1024-bit modulus

q = 21024 - 2960 - 1 + 264 * (:2894 * p; + 129093)

a  = 2

•                 Modular exponentiation with a 1536-bit modulus

•                      Parameters to be determined

•                 Elliptic curve group over 2155

•                      Generator (hexadecimal): X = 7B, Y = 1C8

•                      Elliptic curve parameters (hexadecimal): A = 0, Y = 7338F

•                 Elliptic curve group over 2185

•                      Generator (hexadecimal): X = 18, Y =  D

•                      Elliptic curve parameters (hexadecimal): A = 0, Y = 1EE9

The first three groups are the classic Diffie-Hellman algorithm using modular exponentiation. The last two groups use the elliptic curve analog to Diffie-Hellman, which was described in Chapter 10.

IKE key determination employs nonces to ensure against replay attacks. Each nonce is a locally generated pseudorandom number. Nonces appear in responses and are encrypted during certain portions of the exchange to secure their use.

Three different authentication methods can be used with IKE key determination:

•                 Digital signatures: The exchange is authenticated by signing a mutually obtainable hash; each party encrypts the hash with its private key. The hash is generated over important parameters, such as user IDs and nonces.

•                 Public-key encryption: The exchange is authenticated by encrypting parame- ters such as IDs and nonces with the sender’s private key.

•                          Symmetric-key encryption: A key derived by some out-of-band mechanism can be used to authenticate the exchange by symmetric encryption of exchange parameters.

IKEV2 EXCHANGES The IKEv2 protocol involves the exchange of messages in pairs. The first two pairs of exchanges are referred to as the initial exchanges (Figure 19.11a). In the first exchange, the two peers exchange information concerning cryptographic algorithms and other security parameters they are willing to use along with nonces and Diffie-Hellman (DH) values. The result of this exchange is to set up a special SA called the IKE SA (see Figure 19.2). This SA defines parameters for a secure channel between the peers over which subsequent message exchanges take place. Thus, all subsequent IKE message exchanges are protected by encryption and message authentication. In the second exchange, the two parties authenticate one another and set up a first IPsec SA to be placed in  the SADB and used for protecting ordinary (i.e. non-IKE) communications between the peers. Thus, four messages are needed to establish the first SA for general use.

The CREATE_CHILD_SA exchange can be used to establish further SAs for protecting traffic. The informational exchange is used to exchange management information, IKEv2 error messages, and other   notifications.

Header and Payload Formats

IKE defines procedures and packet formats to establish, negotiate, modify, and delete security associations. As part of SA establishment, IKE defines payloads for exchanging key generation and authentication data. These payload formats provide a consistent framework independent of the specific key exchange protocol, encryp- tion algorithm, and authentication mechanism.

IKE HEADER FORMAT An IKE message consists of an IKE header followed by one or more payloads. All of this is carried in a transport protocol. The specification dictates that implementations must support the use of UDP for the transport protocol.

Figure 19.12a shows the header format for an IKE message. It consists of the following fields.

•                 Initiator SPI (64 bits): A value chosen by the initiator to identify a unique IKE security association (SA).

•                 Responder SPI (64 bits): A value chosen by the responder to identify a unique IKE SA.

•                 Next Payload (8 bits): Indicates the type of the first payload in the message; payloads are discussed in the next subsection.

•                 Major Version (4 bits): Indicates major version of IKE in use.

•                 Minor Version (4 bits):  Indicates minor version in use.

•                          Exchange Type (8 bits): Indicates the type of exchange; these are discussed later in this section.

•                          Flags (8 bits): Indicates specific options set for this IKE exchange. Three bits are defined so far. The initiator bit indicates whether this packet is sent by the SA ini- tiator. The version bit indicates whether the transmitter is capable of using a higher major version number than the one currently indicated. The response bit indicates whether this is a response to a message containing the same message ID.

•                          Message ID (32 bits): Used to control retransmission of lost packets and matching of requests and responses.

•                          Length (32 bits): Length of total message (header plus all payloads) in octets.

IKE PAYLOAD TYPES All IKE payloads begin with the same generic payload header shown in Figure 19.12b. The Next Payload field has a value of 0 if this is the last payload in the message; otherwise its value is the type of the next payload. The Payload Length field indicates the length in octets of this payload, including the generic payload header.

The critical bit is 0 if the sender wants the recipient to skip this payload if it does not understand the payload type code in the Next Payload field of the previous payload. It is set to 1 if the sender wants the recipient to reject this entire message if it does not understand the payload type.

Table 19.3 summarizes the payload types defined for IKE and lists the fields, or parameters, that are part of each payload. The SA payload is used to begin

Table 19.3  IKE Payload Types

the establishment of an SA. The payload has a complex, hierarchical structure. The payload may contain multiple proposals. Each proposal may contain multiple proto- cols. Each protocol may contain multiple transforms. And each transform may contain multiple attributes. These elements are formatted as substructures within the payload as follows.

•                 Proposal: This substructure includes a proposal number, a protocol ID (AH, ESP, or IKE), an indicator of the number of transforms, and then a transform substructure. If more than one protocol is to be included in a proposal, then there is a subsequent proposal substructure with the same pro- posal number.

•                 Transform: Different protocols support different transform types. The trans- forms are used primarily to define cryptographic algorithms to be used with a particular protocol.

•                 Attribute: Each transform may include attributes that modify or complete the specification of the transform. An example is key  length.

The Key Exchange payload can be used for a variety of key exchange tech- niques, including Oakley, Diffie-Hellman, and the RSA-based key exchange used by PGP. The Key Exchange data field contains the data required to generate a session key and is dependent on the key exchange algorithm used.

The Identification payload is used to determine the identity of communicating peers and may be used for determining authenticity of information. Typically the ID Data field will contain an IPv4 or IPv6 address.

The Certificate payload transfers a public-key certificate. The Certificate Encoding field indicates the type of certificate or certificate-related information, which may include the following:

•                 PKCS #7 wrapped X.509 certificate

•                 PGP certificate

•                 DNS signed key

•                 X.509 certificate—signature

•                 X.509 certificate—key exchange

•                 Kerberos tokens

•                 Certificate Revocation List (CRL)

•                 Authority Revocation List (ARL)

•                 SPKI certificate

At any point in an IKE exchange, the sender may include a Certificate Request payload to request the certificate of the other communicating entity. The payload may list more than one certificate type that is acceptable and more than one certificate authority that is acceptable.

The Authentication payload contains data used for message authentication purposes. The authentication method types so far defined are RSA digital signature, shared-key message integrity code, and DSS digital signature.

The Nonce payload contains random data used to guarantee liveness during an exchange and to protect against replay attacks.

The Notify payload contains either error or status information associated with this SA or this SA negotiation. The following table lists the IKE notify messages.

The Delete payload indicates one or more SAs that the sender has deleted from its database and that therefore are no longer valid.

The Vendor ID payload contains a vendor-defined constant. The constant is used by vendors to identify and recognize remote instances of their implementa- tions. This mechanism allows a vendor to experiment with new features while maintaining  backward compatibility.

The Traffic Selector payload allows peers to identify packet flows for process- ing by IPsec services.

The Encrypted payload contains other payloads in encrypted form. The encrypted payload format is similar to that of ESP. It may include an IV if the encryption algorithm requires it and an ICV if authentication is selected.

The Configuration payload is used to exchange configuration information between IKE peers.

The Extensible Authentication Protocol (EAP) payload allows IKE SAs to be authenticated using EAP, which was discussed in Chapter 17.