The IKE Protocol

  IPsec provides a solution to the problem of securing communications. However, for large-scale deployment and use, an automated method for managing SAs and key setup is required. There are several issues in this problem domain: negotiation of SA attributes, authentication, secure key distribution, and key aging to name some. Manual management is complicated, tedious, error-prone, and does not scale. Standardized protocols addressing these issues are needed; IETF's recommended protocol is named IKE, the Internet Key Exchange. IKE is based on a framework protocol called ISAKMP and implements semantics from the Oakley key exchange, therefore IKE is also known as ISAKMP/Oakley.

The IKE protocol is unfortunately a rather complex one, with many modes and options. Furthermore, new extensions proposed result in a further increase in complexity. Interoperation has been a problem because of this, but we are beginning to see good interoperability in the mandatory parts of the protocol.

The IKE protocol has two phases: the first phase establishes a secure channel between the two key management daemons, while in the second phase IPsec SAs can be directly negotiated. The first phase negotiates at least an authentication method, an encryption algorithm, a hash algorithm, and a Diffie-Hellman [9] group. This set of parameters is called a ``Phase 1 SA.'' Using this information, the peers authenticate each other and compute key material to use for protecting Phase 2. Depending on the protection suite specified during Phase 1, different modes can be used to establish a Phase 1 SA, the two most important ones being ``main mode'' and ``aggressive mode.'' Main mode provides identity protection, by transmitting the identities of the peers encrypted. Aggressive mode provides somewhat weaker guarantees, but requires fewer messages and allows for ``road warrior'' types of configuration using passphrase-based authentication.

The second phase is commonly called ``quick mode'' and results in a IPsec SA tuple (one incoming and one outgoing). As quick mode is protected by a Phase 1 SA, it does not need to provide its own authentication protection, allowing for a fast negotiation (hence the name). Optionally, a new Diffie-Hellman computation can be done, providing ``Perfect Forward Secrecy''. PFS is an attribute of encrypted communications allowing for a transient session key to get compromised without affecting the security of future keys negotiated under the same Phase 1 SA (in other words, all session keys are cryptographically independent).