An exploration of the Intenet Key Exchange (IKE) version 1, IKE version 2, and the different modes in which it operates, aggressive, main and quick.
Is Internet Key Exchange (IKE) really necessary? Well, actually IPSEC can get along fine without it if everyting is setup manually. This includes the mode of operation, all of the encryption algorithms, authentication algorithims, encryption keys and all of the other fun stuff it will work just fine, and instantaneously for that matter with no delays. Just as long the peers agree on everything! Otherwise, one side encrypts -- the other side decrypts with different parameters and winds up with packets full of indecipherable garbage.
However, this manual setup process can be a real pain in the ass -- especially the encryption keys. Additionally, if one is really worried about keeping their traffic looking like a randomly generated number stream to an eavesdropper, it's probably a good idea to change the encryption keys every now and then. Changing the traffic encryption keys manually usually means at best a short interruption while each end updates their configurations and starts using the new keys. IKE is a big, BIG, help in the key updating arena, allowing key updates to be smooth and automated! It can also be quite good helper in setting up all and getting peers to agree on all of the other parameters.
Using IKE can also (if done properly) authenticate the identity of the party on the other side. This makes it much (hopfully much^1e6) harder for an eavesdropper to perform a man-in-the-middle attack, or just masqeurade as the other party.
Comparing IPSEC with manual encryption keys to IKE is semi-analogous to static routes versus a dynamic routing protocol, like OSPF or IS-IS. Static works fine until it's time to change, then it gets difficult to maintain continuity. However, just like static routes are easy, and dynamic routing can be loaded with even more complexities -- IKE in itself can be as cryptic as the traffic it's trying to protect (especially if you're using DES).
As with most protocols, IKE started out with version 1 -- but has since moved onto a new improved version, version 2. Alghouth version 2 is definately better in most respects, IKE version 1 is still out there in abundance. It is definately worthwile at the time of writing to learn both versions as it doesn't look like the old stuff is going away anytime soon.
IKE version 1, or IKEv1, has two phases that occurr sequentially during an IKE session setup. These are appropriately named IKE Phase 1 and IKE Phase 2. The purpose of IKE Phase 1 is to setup a secure channel between two parties to keep any eavesroppers in the cryptographic dark about what goes on in Phase 2. Phase 1 is basically about aggreeing on what encryption and authentication algorithms to use, who will be involved in the negotiations and how to authenticate them, how long the secure channel will be used, as well as a lot of other fun goodies like Dead Peer Detection, NAT traversal, and vendor specific add-ons. Phase 2 is all about what will be done about actually encrypting and/or authenticating actual network traffic. Again this invoves authentication and encryption parameters, key lifetimes, modes, and a few other bells and whistles.
Of course, in order to keep things complicated enought to keep network nerds employed for a while longer, Phase 1 is broken further down by offering two different modes that it can run in with IKEv1: main mode and aggressive mode. Main mode is the "normal" method of exchanges between two peers to setup the secure channel between the two of them. Main mode keeps the identties of the peers protected, and allows them to authenticate each other while keeping their identities safe from prying eyes. Main mode requires a total of six messages (in the form of a IKE packet) to be passed between the two parties, three in each direction. The first pair of messages passed back and forth allow the peers to aggree on the encryption parameters and include a unique 5 byte number, a cookie, to identify the IKE session being negotiated. The second pair of messages are a Diffie-Hellmen-Merkle key exchange that allow both peers to agree upon a shared secret over the previously insecure communications channel. Once this shared secret has been established, the two peers can validate each other's identities.
The other mode, aggressive, combines the initial message exchanges from main mode so only a total of three packets are needed to setup the security association. Policy and Diffie-Hellman-Merkle exchanges are combined. However, this comes at a price as the identities of the two IKE peers are exposed. If using pre-shared keys for athentication, aggressive mode exposes enough information to allow an eavesdropper who captures the first packet of an exchange to mount an attack to recover the pre-shared-key secret. Additionally, an eavesdropper could capture enough identity information in order to mount an attack on a peer using a pre-shared-key, getting the peer to act as a responder in aggressive mode and cough up an encrypted hash of the key which can be subjected to offline cracking.
Quick mode occurs after Phase 1 has been completed, and makes up the entirety of Phase 2. Quick mode is bound to a Phase 1 exchange, and cannot be dissaociated; it uses the secure channel setup in Phase 1. The purpose of Quick mode is to agree on policies and derive keying material for the encryption and/or authentication of actual traffic protected by IPSEC. Quick mode takes a total of three packets, where the peers agree on the encryption and authentication algorithms that will be used and what traffic should be protected by the security association (SAs) that are being setup. Optionally, another Diffie-Hellman-Merkle exchange, known as Perfect Forward Secrecy, can be performed in order to derive fresh keying material that has not been derived from any previous keys. This makes it even tougher for an eavesdropper to guess what keys are being used.
IKEv2 doesn't really keep the nomenclature of phases, but addresses the process as several distinct types of exchanges: the IKE_SA_INIT exchange, IKE_AUTH exchange and the CREATE_CHILD_SA exchange. IKEv2 also completely drops the idea of modes. There is no such thing as main mode or aggressive mode in IKEv2.
The IKE_SA_INIT exchange and IKE_AUTH exchange basically cover what Phase I did in IKEv1. The first pair of messages make up the IKE_SA_INIT exchange, and negotiate the encryption and authentication algorityms, exchange nonces, and perform a Diffie-Hellman-Merkle exchange. The next pair of messages, the IKE_AUTH exchange, are encrypted by the keys derived from the Diffie-Hellman-Merkle key exchange and are used to authenticate and identify the peers and to establish the first CHILD_SA.
A Child SA can be though of as analogous to Phase 2 in IKEv1. Each Child SA is setup with a CREATE_CHILD_SA exchange which is protected by the secure channel setup by the first two packets in the IKE_SA_INIT exchange. A CREATE_CHILD_SA contains a proposal of what traffic should be encrypted and/or authenticated, desired encryption and authentication algorithms, encryption keys and a nonce. Another Diffie-Hellman-Merkle key exchange can also performed to come up with fresh new encryption keying material.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version 0 | C | Plenty | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID - www.blackhole-networks.com | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID - IKE Modes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum OK | Construction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | PAGE STILL | +- UNDER -+ | CONSTRUCTION | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+