The Internet Key Exchange (IKEv1 and IKEv2) is based on ISAKMP (Internet Security Association and Key Management Protocol), which is a framework for key exchange. It uses parts of the Oakley and SKEME (Secure Key Exchange MEchanism for Internet) protocols within this framework. Oakley describes a series of key exchanges, known as modes, and specifies things such as perfect forward secrecy for keys, identity protection and authentication. It is discussed in RFC 2412, “The Oakley Key Determination Protocol”. SKEME (Secure Key Exchange MEchanism for Internet) is a key exchange technique which provides anonymity and quick key refreshment. There is no RFC that covers SKEME, but there are some papers available online. There is coverage of the parts of Oakley and SKEME used in IKE in RFCs 2408 and 2409.

IKE uses the Diffie-Hellman Key Agreement protocol to securely exchange a shared secret, from which symmetric session keys for AH and ESP are derived. IKE is also used to mutually authenticate nodes to each other. Authentication can be accomplished with a pre-shared secret (manually distributed to each node), or by use of IPsec digital certificates (ones that bind IPv4 and/or IPv6 addresses to the public key). Each pair of nodes that use IPsec use IKE to do key exchange and mutual authentication, which results in setting up a Security Association (SA) at each end for the other node in the pair.

IKE is usually implemented as a daemon process (a software application that starts running when the computer boots, and stays running until shutdown) on each IPsec enabled node, in user space. IKE communicates via UDP over port 500. There is no client or server role, the communication is between peers. Either node of a pair can initiate an IKE connection, and the other node will accept it. The AH and ESP packet processing is embedded in the TCP/IP stack (specifically in the IP layer), which usually runs in kernel space.

There are two phases in an IKE connection, called (imaginatively enough) Phase 1 and Phase 2.

IKE Phase 1 establishes an encrypted, authenticated communication channel between the two parties. It first uses the Diffie-Hellman Key Agreement protocol, which produces a shared secret. A symmetric session key is derived from the shared secret by both parties, which is used to encrypt further IKE exchanges. The goal of Phase 1 is to create a bidirectional ISAKMP Security Association (SA). Mutual Authentication can be accomplished using either a pre-shared secret, or via cryptographic challenge/response using IPsec public key digital certificates. Either a pre-shared secret, or an IPsec certificate must be installed on each IPsec enabled node when the system is deployed. Phase 1 can operate in either Main Mode or Aggressive Mode. Main Mode protects the identities of the nodes, but takes longer. Aggressive mode is faster, but does not protect the identities of the nodes.

IKE Phase 2 uses the secure channel established in Phase 1 to negotiate additional Security Associations (SAs) for services such as IPsec. The output of Phase 2 is a pair of unidirectional SAs (one for traffic from Alice to Bob and one for traffic from Bob to Alice). On each node, one of these SAs is used for inbound traffic and the other one for outbound traffic. Phase two operates in Quick Mode.

Cryptographic challenge/response is used by each end to authenticate itself to the other. Each direction works as follows (flipping roles A and B when the second direction is done):

Step 1 – Node A sends its public key digital certificate to Node B.
Step 2 – Node B verifies Node A’s digital certificate by checking its digital signature, its expiration date, and its revocation status. It also climbs the chain of trust to a trusted root key. If the identity in the certificate is an IP address, it must match the source IP address of the IKE connection.
Step 3 – Node B generates a random string and encrypts it using Node A’s public key (from its digital certificate) and sends it as a challenge to Node A.
Step 4 – Node A decrypts the challenge using its own private key and returns the result to Node B as its response.
Step 5 – Node B compares the response to the original string. If they match, that is proof that Node A possesses the private key associated with the public key in Node A’s digital certificate (without Node A revealing its private key to anyone). This authenticates Node A to Node B.

An IPsec digital certificate is like a Server (SSL) digital certificate or a Client digital certificate. The primary difference is what identity information the public key is bound to. In a Server cert, the identity information is an FQDN (e.g. www.example.com) and an organization name (in the distinguished name). In a Client cert, the identity information is a person’s name and e-mail address (in the distinguished name). It is also possible for an IPsec certificate to specifically include IKE as a valid key usage (id_kp_ipsecIKE attribute). In an IPsec cert, there are several possibilities for the identity:

• Individual IPv4 and/or IPv6 address (ID_IPV4_ADDR and ID_IPV6_ADDR). These do not work well if the connection traverses NAT. There is no problem with using IPv6 addresses.
• IPv4 or IPv6 subnet (ID_IPv4_ADDR_SUBNET and ID_IPv6_ADDR_SUBNET). The same issues are involved if the connection traverses NAT. For example, you could identify your node as being in the subnet 2001:418:5403:3000::/64.
• IPv4 or IPv6 address range (ID_IPv4_ADDR_RANGE and ID_IPV6_ADDR_RANGE). This is used for specifying a block of addresses that doesn’t happen to fall on (power of 2) subnet boundaries (e.g. all addresses from 2001:418:5403:3000::100 to 2001:418:5403:3000::200).
• FQDN (ID_FQDN). This depends on trusting the mapping from FQDN to IP address; hence DNS should only be used if DNSSEC is deployed. Otherwise the resolution from FQDN to IP address must be handled by some other means, which is trusted. Again, NAT can cause problems with this.

If IP addresses are specified, during the authentication process the source IP address of the IKE connection must match the IP address (byte for byte) in the IPsec digital certificate. This is similar to SSL/TLS, where the node name you are connecting to must match the FQDN in the server certificate. In SSL, if you connect to an alias name or a numeric IP address, you will get an error.

SOURCE: The Second Internet, book authored by InfoWeapons Chairman and CTO Lawrence E. Hughes.