PlutoPlus:
An IKE Reference Implementation for Linux


Contents:



IKE Generic Description


PlutoPlus is a reference implementation of the Internet Key Exchange Protocol (IKE), the Internet Security Association and Key Management Protocol (ISAKMP), and the Internet IP Security Domain of Interpretation for ISAKMP (DOI). The goal of any IKE implementation is to negotiate an IPsec Security Association (SA) with a peer. This is accomplished through a 2-phase negotiation: Phase 1 establishes an ISAKMP (Internet Security Association and Key Management Protocol) SA, which is a secure channel through which the IPsec SA negotiation can take place; Phase 2 establishes the actual IPsec SA.

Phase 1 Negotiation

A Phase 1 exchange has 3 goals:

Main Mode

There are 2 possible types of Phase 1 exchanges: Main Mode and Aggressive Mode. A Phase 1 Main Mode Exchange consists of 6 messages (3 messages sent from the Initiator to the Responder, 3 sent from the Responder to the Initiator).

The first 2 Main Mode Messages (Message #1 from the Initiator to the Responder; Message #2 from the Responder to the Initiator) consist of the following components:

After the first 2 messages have been exchanged, each peer is assured that the other peer exists and is ready to negotiate (as opposed to a denial of service attack, in which the Initiator would most likely be unreachable by the Responder). In addition, both peers have agreed to the Security Parameters that will govern the remaining message exchanges.

The nature and order of the payloads that comprise the next 2 Main Mode Messages (Message #3 from the Initiator to the Responder; Message #4 from the Responder to the Initiator) varies, depending on the Authentication Method (pre-shared key, digital signatures, public key original mode, or public key revised mode).

Thus, the next 2 Main Mode Messages (Message #3 from the Initiator to the Responder; Message #4 from the Responder to the Initiator) consist of some or all of the following components:

The secret Phase 1 keys can now be calculated by each peer. The value SKEYID is first calculated from the shared secret. The exact calculation depends upon the authentication method, as follows:

Signatures:   SKEYID = prf(Nonce_I | Nonce_R, g^xy)
Public key 
  encryption: SKEYID = prf(hash(Nonce_I | Nonce_R), Cookie_I | Cookie_R)
Pre-shared 
  keys:       SKEYID = prf(pre-shared-key, Nonce_I | Nonce_R)

where:
  prf is the negotiated keyed pseudo-random function 
	(or the HMAC version of the negotiated keyed hash)
  hash is the native form of the negotiated keyed hash
  Nonce_I is the Initiator's Nonce
  Nonce_R is the Responder's Nonce
  Cookie_I is the Initiator's Cookie 
  Cookie_R is the Responder's Cookie
  g^xy is the shared secret
The Phase 1 encryption key (SKEYID_e) is calculated as follows:
      SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | Cookie_I | Cookie_R | 2)
The Phase 1 authentication key (SKEYID_a) is calculated as follows:
      SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | Cookie_I | Cookie_R | 1)
The Phase 1 keying material (SKEYID_d) is calculated as follows:
      SKEYID_d = prf(SKEYID, g^xy | Cookie_I | Cookie_R | 0)
(If Perfect Forward Secrecy of Keys is not required, SKEYID_d will be used in Phase 2 to calculate the keying material for the IPsec SA.)

After the first 4 messages have been exchanged, and the secret Phase 1 keys calculated, further traffic can be encrypted and authenticated. If the Authentication Method is either public key original mode or public key revised mode, an exchange of the identities for whom the Phase 2 SA is to be negotiated has already taken place; through the use of the public keys used for mutual authentication, it was possible to encrypt the identities and accomplish the exchange without publicly revealing either identity. If the Authentication Method is either through signatures or through pre-shared secret key, this exchange of identities has not yet taken place; it will occur in this exchange, under the protection of the negotiated key. In either case, since the identities are encrypted, a Phase 1 Main Mode provides identity protection for the participants. Besides that, all that remains to be accomplished in Phase 1 is to authenticate the exchange via the exchange and verification of hashes.

The last 2 Main Mode Messages (Message #5 from the Initiator to the Responder; Message #6 from the Responder to the Initiator) consist of the following components:

Since the Identification Payload is encrypted, a Main Mode Exchange provides identity protection for the participants.

Aggressive Mode

The first Aggressive Mode Message from the Initiator contains the same fields that are normally contained in the Initiator's first two Main Mode Messages, plus the Identification Payload. (In Main Mode, the Identification Payload is part of Message #1 for both public key Authentication Methods, but is part of Message #2 for the digital signature and pre-shared secret key Authentication Methods.) The first (and only) Aggressive Exchange message from the Responder contains all of the fields that are spread across that peer's 3 Main Mode Messages. Thus, a Phase 1 Aggressive Exchange consists of 3 messages (2 messages sent from the Initiator to the Responder, 1 sent from the Responder to the Initiator).

Since the Identification Payload is sent before any sort of mutual key has been established, it is not encrypted; thus, an Aggressive Mode Exchange does not provide identity protection for the participants. However, if identify protection is not required, an Aggressive Mode Exchange requires half the number of messages needed for a Main Mode Exchange.

Once the ISAKMP SA is established, it can be used to protect multiple Phase 2 Quick Mode Exchanges; New Group Exchanges; and Informational Exchanges, until its lifetime expires or some other untoward event occurs (such as a rebooting of the machine that causes the SAs to be lost).

Phase 2 Negotiation

Once the Phase 1 Negotiation is complete, an ISAKMP SA, which is a protected channel, has been established between the peers. This SA consists of agreed-upon policy and parameters for further negotiations, along with symmetric secret keys that can be used to authenticate and encrypt those negotiations. The index, or SPI, that is used to reference the ISAKMP SA is the quantity formed by concatenating the Initiator Cookie and the Responder Cookie.

Either peer can initiate subsequent negotiations, in which the ISAKMP SA will be used to protect negotiations for a non-ISAKMP SA. The most common example of a non-ISAKMP SA is an IPsec SA, that can then be used to protect IP communications in general between the peers.

Quick Mode

A Phase 2 Quick Mode Exchange has 3 goals:

In addition, two additional goals may be satisfied:

A Phase 2 Quick Mode Exchange consists of 3 messages (2 messages sent from the Initiator to the Responder, 1 sent from the Responder to the Initiator).

The first 2 Quick Mode Messages (Message #1 from the Initiator to the Responder; Message #2 from the Responder to the Initiator) consist of the following components:

Thus, the first exchange negotiates the IPsec SA's policy and parameters and generates the keying material, in an authenticated manner that protects against a replay of a previous negotiation.

The last message, from the Initiator to the Responder, concludes the exchange and reassures the Responder that the Responder's proposal was received. It consists of the following components:

Once an ISAKMP SA has been established, it can be used to protect all traffic between the endpoints, until its lifetime expires or some other untoward event occurs (such as a rebooting of the machine that causes the SAs to be lost).

Additional Exchanges

New Group Mode

New Group Mode is an exchange that uses an established Phase 1 ISAKMP SA to protect the negotiation of a new Diffie-Hellman group that can then be used in subsequent exchanges. This allows the peers to negotiate a private group whose parameters are not known, except to the participants. In subsequent Phase 1 exchanges, only the Group Description Number will be required; thus, the specific group parameters will not be sent in an unencrypted message.

A New Group Exchange consists of 2 messages (1 message sent from the Initiator to the Responder, 1 sent from the Responder to the Initiator). Each message consists of the following components:

Informational Exchanges

An Informational Exchange is a one-way single message used to send the peer status or diagnostic information. If an ISAKMP SA has been established between the peers, or a Phase 1 Exchange has progressed far enough that keying material has been generated, the ISAKMP SA or keying material is used to protect the exchange, and the exchange is authenticated with a HASH. Either the Initiator or the Responder of the Phase 1 or Phase 2 Exchange can act as the Initiator of an Informational Exchange. The message consists of the following components:

PlutoPlus Description


PlutoPlus is a reference implementation of the Internet Key Exchange Protocol (IKE), the Internet Security Association and Key Management Protocol (ISAKMP), and the Internet IP Security Domain of Interpretation for ISAKMP (DOI).

PlutoPlus Modes of Operation

Under normal operations, PlutoPlus is a daemon that waits for one of 2 types of requests: a kernel request to initiate negotiations for the establishment of an IPsec SA (in which case PlutoPlus's role is that of Initiator) or a peer request (generally via port 500) to establish an IPsec SA (in which case PlutoPlus's role is that of Responder). In this mode, any error messages are logged to syslog and, in some cases, cause a Notification Message to be sent to the negotiating peer.

For debugging and testing purposes, PlutoPlus has a DEBUG mode that causes increased diagnostic and informational output; in this mode, all messages are printed to the standard output or standard error.

In addition, PlutoPlus has a WIT DEBUG mode that is used for the version of PlutoPlus running on IPsec WIT, ITL's IPsec Interoperability Tester. In this mode, PlutoPlus conducts a single negotiation, either as Initiator or Responder, and then exits. If an error is encountered, or if too much time elapses without a message from the negotiating peer, PlutoPlus also exits.

In the WIT DEBUG mode, command-line options are used to dictate whether PlutoPlus will act as Initiator or Responder, and also to communicate the parameters of the proposal to be sent (as Initiator) or accepted (as Responder). In the WIT DEBUG mode PlutoPlus, as Initiator, sends a single proposal, dictated by the command-line options. As Responder, PlutoPlus can accept multiple proposals, but checks to ensure that one of the proposals is consistent with the command-line options.

IKE / ISAKMP / DOI Features Found in PlutoPlus

Please NOTE: PlutoPlus currently sends only a few Notify Messages, and does not set or check the Commit Bit. This should be fixed REAL SOON NOW.

IKE / ISAKMP / DOI Features Not Found in PlutoPlus


References:

PlutoPlus is a reference implementation of the Internet Key Exchange Protocol (IKE), the Internet Security Association and Key Management Protocol (ISAKMP), and the Internet IP Security Domain of Interpretation for ISAKMP (DOI). These protocols are defined in the Internet Drafts The Internet Key Exchange (IKE), Internet Security Association and Key Management Protocol (ISAKMP), The Internet IP Security Domain of Interpretation for ISAKMP (DOI), and other Internet Drafts developed by the IPsec working group of the IETF. The most current versions of all of the IPsec drafts are available from the IETF.

Request for Feedback:

We welcome feedback on the PlutoPlus documentation, implementation, and WIT Test System. Suggestions for change or improvement, criticism of content or form, notification of innacuracies would all be appreciated. Please use the WIT feedback form or email

For further information:

Sheila Frankel
National Institute of Standards and Technology
NIST North, Room 680
Gaithersburg, MD 20899

301/975-3297

301/948-0279

sheila.frankel@nist.gov

Last Modified: