PlutoPlus:
An IKE Reference Implementation for Linux

Contents:

• IKE Generic Description
  • Phase 1 Negotiation
    • Main Mode
    • Aggressive Mode
  • Phase 2 Negotiation
    • Quick Mode
  • Additional Exchanges
    • New Group Mode
    • Informational Exchanges
  • IKE Headers
    • ISAKMP Header
    • Generic Payload Header
  • IKE Payloads
    • SA Payload
    • Proposal Payload
    • Transform Payload (Phase 1)
    • Transform Payload (Phase 2)
    • Key Exchange Payload
    • Nonce Payload
    • Identification Payload
    • Hash Payload
    • Certificate Payload
    • Signature Payload
    • Notify Payload
    • Delete Payload
• PlutoPlus Description
  • PlutoPlus Modes of Operation
  • PlutoPlus Command Line Options
  • IKE / ISAKMP / DOI Features Found in PlutoPlus
  • IKE / ISAKMP / DOI Features Not Found in PlutoPlus
• IPsec-WIT, WWW-based Interoperability Testing Tool
• References
• Request for Feedback
• For Further Information

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:

• Negotiate Security Parameters: The Initiator and Responder must agree on the values and settings of a number of parameters that will govern the format of the last 2 (encrypted) messages of Phase 1 and all of the Phase 2 messages. They must also negotiate which method the peers will use to authenticate each other; the maximum lifetime of the Phase 1 SA, and how that lifetime will be measured; the method to be used to establish the shared secret that will be used to calculate the Phase 1 keying material, and the parameters used to generate the shared secret.
  
  
• Establish a shared secret: Once the peers have agreed upon the method and parameters to be used to generate the Phase 1 shared secret, an exchange of messages is used to eatablish that shared secret, which will be used in the generation of secret keys.
  
  
• Authenticate identities: The peers authenticate each other's identities based on some additional out-of-band information.

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:

• ISAKMP Header: The ISAKMP Header, which precedes every IKE message, consists of the following fields:
  • Initiator Cookie: a random value generated by the Initiator, which serves as an anti-clogging device and as part of the SPI (Security Parameters Index), the unique key used to identify the Phase 1 SA. By allowing an exchange between the peers prior to executing a resource-intensive public key calculation, the cookie exchange thwarts some types of denial-of-service attacks.
  • Responder Cookie: the Responder's counterpart to the Initiator cookie (zero in Phase 1 Message #1, since the Initiator has not yet received this value).
  • Next Payload: Each message contains one or more payloads; this header field identifies the type of the first payload.
  • Major Version Number/Minor Version Number: These numbers allow the peer's IKE daemon to determine whether it is compatible with the current IKE version; if not, it can reject this negotiation.
  • Exchange Type:
    • Phase 1: Main Mode or Aggressive Mode
    • Phase 2: Quick Mode
    • Other: New Group Mode or Informational (used to send status/diagnostic messages related to an IKE exchange).
  • Flags: The encryption flag indicates that the message following this header is encrypted; the commit flag is set by one of the negotiators to notify the peer that an SA that is in the process of being established should not be used until the sender sends an informational message that the SA has been completely established; the authentication only flag indicates that the message following this header is an informational message that is authenticated but not encrypted
  • Message ID: a random value generated by the Initiator, which serves as the unique key used to identify the Phase 2 SA during negotiation (zero in Phase 1)
  • Length: length of the entire message (header and payloads)
  
  
• Generic Payload Header: Every Payload contained in an IKE message is prefaced by a Generic Payload Header, which contains the following fields:
  • Next Payload: the type of the payload that follows this payload (0 if none)
  • Reserved: unused (set to 0)
  • Payload Length: the length of this payload, including the Generic Payload Header
  
  
• SA Payload: The SA Payload is a multi-layered payload, which contains 1 or more Proposal Payloads, each of which contains 1 or more Transform Payloads. The totality of the SA Payload sent by the Initiator is a series of alternative combinations of the attributes to be negotiated. Each series of attributes collectively characterizes the operation and longevity of a particular proposed SA.

  A Phase 1 SA Payload contains a single Proposal Payload, which can have multiple, alternative Transform Payloads. The Responder's SA Payload contains the single proposal that the Responder selected from all of the proposals offered by the Initiator.

  A Phase 2 message can contain multiple SA Payloads, which will result in the negotiation of multiple IPsec SAs. Each SA Payload can contain multiple Proposal Payloads, each of which characterizes a different Protocol to be provided by the SA; each Proposal Payload can have multiple, alternative Transform Payloads. The Responder's SA Payload contains a single proposal (for each Protocol for each proposed SA) that the Responder selected from all of the proposals offered by the Initiator (for that SA).

  The SA Payload itself contains the following fields:

  • DOI (Domain of Interpretation): A Phase 1 SA whose DOI is Generic ISAKMP can be used to negotiate Phase 2 SAs for any other DOI; a Phase 1 SA whose DOI is IPSEC can only be used to negotiate Phase 2 IPsec SAs. A Phase 2 IPsec SA will have a DOI of IPsec.
  • Situation: For the IPsec DOI, this indicates whether standard IPsec Identification Payloads will be sufficient to identify the peers to each other, or whether some type of compartmented secrecy or integrity labels will also be required.
    
    
• Proposal Payload: Each Proposal Payload has 2 fields which define the general nature and access index of the proposed SA, as follows:
  • Protocol ID: In Phase 1, this will be ISAKMP, since an ISAKMP SA is being negotiated; in Phase 2, this can be IPsec AH (for an Authentication Header SA), IPsec ESP (for an Encapsulating Security Protocol SA), or IPCOMP (for a compression header).
  • SPI (Security Parameters Index): the unique key used to access or identify the SA.

    The Phase 1 ISAKMP SA's SPI consists of the Initiator's Cookie followed by the Responder's Cookie, and is used by all messages subsequent to Phase 1 (e.g. Phase 2 Messages, New Group Messages or Informational Messages) that will use the Phase 1 ISAKMP SA for protection.

    The Phase 2 IPsec SA's SPI will be generated by each peer and, together with the Protocol ID and the destination address, will uniquely identify the IPsec SA. This identification tuple (SPI, Protocol, Destination) will appear in all traffic covered by the IPsec SA. (The Initiator's SPI will be used in conjunction with the Initiator's Outbound SA, for traffic from Initiator to Responder; the Responder's SPI will be used in conjunction with the Responder's Outbound SA, for traffic from Responder to Initiator.)
    
    

• Transform Payload: The Transform Payload defines the specific algorithms, negotiation mechanisms, and policy (collectively known as attributes) that will characterize the established SA.

  The Phase 1 attributes that are open to negotiation are:

  • Encryption Algorithm (and Key Length): the algorithm to be used to encrypt all IKE messages once the secret key is established. The mandatory-to-implement algorithm is DES_CBC. If an encryption algorithm with a variable length key (for example, BLOWFISH) is selected, then the key length must also be negotiated.
  • Hash Algorithm: the keyed hash algorithm to be used in some of the IKE calculations; if no prf (pseudo-random function) is negotiated, the HMAC form of this hash algorithm is also used to generate the key material and to authenticate all IKE messages once the secret key is established. The mandatory-to-implement hash algorithms are MD5 and SHA.
  • Authentication Method: the method through which the peers will mutually authenticate each others' identities (pre-shared key, digital signatures, public key original mode, or public key revised mode). The mandatory-to-implement authentication method is pre-shared key.
  • Group Description /Type /Prime / Generator(s) /Curve(s) / Order / Field Size: These values define the specifics of the Diffie-Hellman exchange that will establish the shared secret used in the generation of the key material. The mandatory-to-implement group is a MODP (modular exponentiation) group with a generator of 2 and the following prime:

          2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 }
    

    It is recommended that IKE daemons support three other pre-defined groups: another MODP group with a different prime and two elliptic curve groups. The Group Description attribute is used to specify which of these 4 groups will be used.

    It is also possible to negotiate groups with different defining characteristics. In that case, the Group Type attribute is used to specify whether the group is a MODP or elliptic curve group. The Group Prime and Group Generator attributes are used to define a new MODP group; the Group Prime, Group Generator, Group Curve, Group Order, and Field Size attributes are used to define a new elliptic curve group.

  • Life Type, Life Duration: The Life Type attribute specifies whether the duration of the Phase 1 SA will be measured in seconds or kilobytes. The Life Duration attribute gives the numeric value of the SA's duration in the specified measure (seconds or kilobytes). There are no default values for these attributes. Both types of Life Type can be specified for a single SA, in which case the SA expires when either one of the lifetimes is reached.
  • Pseudo-Random Function(PRF): keyed pseudo-random function used to generate the key material and to authenticate all IKE messages once the secret key is established. There is no mandatory-to-implement prf, and no pre-defined values for this attribute; unless the peers agree to a privately defined prf, the default prf is the HMAC version of the negotiated hash function.

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).

• If authentication is via pre-shared key or digital signatures, the messages will contain the following components: ISAKMP Header, Key Exchange Payload, Nonce Payload.
  
  
• If authentication is via public key original mode, the messages will contain the following components: ISAKMP Header, Key Exchange Payload, Hash Payload (optional - Initiator only), Identification Payload, Nonce Payload.

  The data portions (but not the Generic Payload Header) of the Identification and Nonce Payloads are encrypted with the peer's public key.
  
  

• If authentication is via public key revised mode, the messages will contain the following components: ISAKMP Header, Hash Payload (optional - Initiator only), Nonce Payload, Key Exchange Payload, Identification Payload, Certificate Payload (optional - Initiator only).

  The data portion (but not the Generic Payload Header) of the Nonce Payload is encrypted with the peer's public key. The data portions (but not the Generic Payload Header) of the Key Exchange, Identification, and Certificate Payloads are encrypted with a symmetric private key derived from the Nonce.

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:

• ISAKMP Header: (same as above)
  
  
• Key Exchange Payload: This payload contains the public portion of each peer's Diffie Hellman value. The Initiator sends the value g^x to the Responder; the Responder sends the value g^y to the Initiator. This enables each peer to compute the shared secret, g^xy.

  If the Authentication Method is through public key original mode, this payload is encrypted with the peer's public key. If the Authentication Method is through public key revised mode, this payload is encrypted with a symmetric private key derived from the Nonce.
  
  

• Nonce Payload: The Nonce is a random value generated by each peer and used both in the Phase 1 key material calculations and the Phase 2 calculations. Since each peer generates a Nonce during a Phase 1 negotiation, this protects against replay attacks, in which 1 peer might be replaying a previous negotiation rather than trying to conduct a totally new one.

  If the Authentication Method is through public key original mode or public key revised mode, this payload is encrypted with the peer's public key.
  
  

• Identification Payload: Each peer can negotiate an SA on its own behalf or on the behalf of one or more hosts. The Identification payload defines the nature of the entity for which the SA is being negotiated, which can be one of the following:
  • a single IP address (IPv4 or IPv6);
  • a fully-qualified domain name string (for example, "foo.bar.com");
  • a fully-qualified username string (for example, "piper@foo.bar.com");
  • a subnet, defined by an IP address and an IP network mask (both IPv4 or IPv6);
  • a range of IP addresses, represented by two IP addresses (both IPv4 or IPv6);
  • an ASN.1 X.500 Distinguished Name [X.501] or GeneralName [X.509]; an opaque byte stream used to pass vendor-specific information that identifies which pre-shared key should be used to authenticate Aggressive mode negotiations.
  The Identification Payload also contains the actual identity, in the proper format for the selected type. (A Phase 2 Identification Payload also contains port and protocol data; in Phase 1 the port must be either 0 or 500 and the protocol must be 0 or UDP.)

  If the Authentication Method is through public key revised mode, this payload is encrypted with a symmetric private key derived from the Nonce.
  
  

• Hash Payload (optional, Initiator only, if Authentication Mode is public key original mode or public key revised mode): If the Responder has multiple public key certificates, this payload contains a hash (using the negotiated hash function) of the Responder's public key certificate that contains the Responder's public key used by the Initiator to encrypt other payloads in this exchange.
  
  
• Certificate Payload (optional, Initiator only, if Authentication Mode is public key revised mode): If the Initiator has multiple public key certificates, this payload contains the Initiator's public key certificate that contains the Initiator's public key that should be used by the Responder to encrypt payloads in the response to this message.

  If the Authentication Method is through public key revised mode, this payload is encrypted with a symmetric private key derived from the Nonce.

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

      SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | Cookie_I | Cookie_R | 2)

      SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | Cookie_I | Cookie_R | 1)

      SKEYID_d = prf(SKEYID, g^xy | Cookie_I | Cookie_R | 0)

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:

• ISAKMP Header: (same as above)
  
  
• Identification Payload (only if Authentication Mode is digital signature or pre-shared secret key): (same as above)
  
  
• Hash Payload: The Hash is a value calculated by each party to the exchange and verified by the peer. If the Hash is calculated over portions of the exchanged message, it serves to authenticate the message. If the Hash contains a Nonce, which itself is a proof of current participation in the exchange and an insurance against replay attacks, then the Hash authenticates the liveness of the exchange.

  The Hash in this message is calculated as follows:

  HASH_I = prf(SKEYID, g^x | g^y | Cookie_I | Cookie_R | SA_I | ID_I )
  HASH_R = prf(SKEYID, g^y | g^x | Cookie_R | Cookie_I | SA_I | ID_R )
  
  where:
    HASH_I is the Initiator's Hash
    HASH_R is the Responder's Hash
    prf is the negotiated keyed pseudo-random function 
  	(or the HMAC version of the negotiated keyed hash)
    g^x is Initiator's public Diffie Hellman value
    g^y is the Responder's public Diffie Hellman value
    Cookie_I is the Initiator's Cookie 
    Cookie_R is the Responder's Cookie
    SA_I is the Initiator's SA Payload (minus the ISAKMP generic header) 
    ID_I is the Initiator's ID Payload (minus the ISAKMP generic header) 
    ID_R is the Responder's ID Payload (minus the ISAKMP generic header)
  

• Certificate Payload (optional, if Authentication Mode is digital signature): This payload contains the public key certificate for the digital signature used to authenticate the exchange.
• Signature Payload (if Authentication Mode is digital signature): This payload contains the data generated by the digital signature. The signature is calculated over HASH_I and HASH_R using the negotiated prf (or the HMAC version of the negotiated hash function) or, if mandated by the specific digital signature being used, the HMAC version of the hash algorithm associated with the digital signature.

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:

• Negotiate Security Parameters: The Initiator and Responder must agree on the values and settings of a number of parameters that will govern the operation of the negotiated IPsec SA. They must also negotiate the maximum lifetime of the SA, and how that lifetime will be measured. If Perfect Forward Secrecy is desired, they must also negotiate the method to be used to establish the shared secret that will be used to calculate the Phase 2 keying material and the parameters used to generate the shared secret.
  
  
• Replay Prevention: Hashes, which include freshly generated nonces, are exchanged and verified to ensure that this negotiation is not merely a replay of a previous Phase 2 Negotiation.
  
  
• Generate Keying Material: Using the shared secret from Phase 1 (or a newly generated shared secret if Perfect Forward Secrecy is required), the keying material for the IPsec SA is produced. The Phase 2 nonces are also used in this process, to ensure the freshness of the keying material.

In addition, two additional goals may be satisfied:

• Provide Perfect Forward Secrecy (PFS) of Keys and/or Identities: PFS is a guarantee that only one key has been generated from a single Diffie-Hellman exchange, and that key has no relationship to any other keys used between the peers. This ensures that discovery of the key by a third party will jeopardize only traffic that was protected with the single discovered key, but not traffic that was protected by another key negotiated by the peers.

  PFS of keys is provided by performing a second Diffie-Hellman exchange during Phase 2, and generating the IPsec SA's key from the new shared secret, rather than using the same shared secret that was used to generate the Phase 1 authentication key (SKEYID_a) and encryption key (SKEYID_e).

  PFS of identities is provided by deleting the Phase 1 ISAKMP SA after it has been used for a single Phase 2 Quick Mode Exchange.
  
  

• Exchange Identities: If the address of the negotiating peer is not sufficient to characterize the IPsec SA, the endpoint Identities must be exchanged. This is necessary in the following cases:
  • The peer is negotiating an SA on behalf of another entity (for example, a gateway negotiating a tunnel-mode SA for one or more clients).
  • Multiple SAs exist between the peers, each of which is characterized by different port and/or protocol numbers.

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:

• ISAKMP Header: (same as above)
  
  
• Hash Payload: (same as above)

  The Hash in this message is calculated as follows:

  HASH_I = prf(SKEYID_a, M-ID | SA_I | N_I [ | KE_I ] [ | ID_I | ID_R ] )
  HASH_R = prf(SKEYID_a, M-ID | N_Ib | SA_R | N_R 
  			[ | KE_R ] [ | ID_I | ID_R ] )
  HASH_I = prf(SKEYID_a, 0 | M-ID | N_I | N_I)
  
  where:
    HASH_I is the Initiator's Hash
    HASH_R is the Responder's Hash
    prf is the negotiated keyed pseudo-random function 
  	(or the HMAC version of the negotiated keyed hash)
    SKEYID_a is the Phase 1 authentication key
    M-ID is the Message ID from the ISAKMP Header
    SA_I is the Initiator's SA Payload (with the ISAKMP generic header) 
    SA_R is the Responder's SA Payload (with the ISAKMP generic header) 
    N_I is the Initiator's Nonce Payload (with the ISAKMP generic header) 
    N_Ib is the Initiator's Nonce Payload (minus the ISAKMP generic header) 
    N_R is the Responder's Nonce Payload (with the ISAKMP generic header) 
    KE_I is the Initiator's (Optional) Key Exchange Payload 
  	(with the ISAKMP generic header) 
    KE_R is the Responder's (Optional) Key Exchange Payload 
  	(with the ISAKMP generic header) 
    ID_I is the Initiator's (optional) Client ID Payload 
  	(with the ISAKMP generic header) 
    ID_R is the Responder's (optional) Client ID Payload 
  	(with the ISAKMP generic header)
  

• SA Payload: (same as above)
  
  
• Proposal Payload: (same as above)
  
  
• Transform Payload: The Transform Payload defines the specific algorithms, negotiation mechanisms, and policy (collectively known as attributes) that will characterize the established SA. The Phase 2 attributes that are open to negotiation are:
  • Life Type, Life Duration: The Life Type attribute specifies whether the duration of the Phase 2 SA will be measured in seconds or kilobytes. The Life Duration attribute gives the numeric value of the SA's duration in the specified measure (seconds or kilobytes). There are no default values for these attributes. Both types of Life Type can be specified for a single SA, in which case the SA expires when either one of the lifetimes is reached.
  • Group Description: This value defines the specifics of the optional Phase 2 Diffie-Hellman exchange that will establish the shared secret(s) used in the generation of the key material if Perfect Forward Secrecy (PFS) of keys is desired. The mandatory-to-implement group is a MODP (modular exponentiation) group with a generator of 2 and the following prime:

          2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 }
    

    It is recommended that IKE daemons support three other pre-defined groups: another MODP group with a different prime and two elliptic curve groups. The Group Description attribute is used to specify which of these 4 groups will be used.

    It is also possible to negotiate groups with different defining characteristics. If a New Group Mode Exchange has previously occurred between the peers, that newly defined group may be used.

  • Encapsulation Mode: describes whether the SA will be a transport-mode SA or a tunnel-mode SA.
  • Authentication Algorithm: the keyed hash algorithm to be used if the SA is to provide authentication. This is mandatory for an AH (Authentication Header) SA or an ESP (Encapsulating Security Payload) SA whose Encryption Algorithm is ESP_NULL, but optional for an ESP SA whose Encryption Algorithm is not ESP_NULL. The mandatory-to-implement authentication algorithms are HMAC-MD5 and HMAC-SHA.
  • Key Length: For an ESP SA whose encryption algorithm takes a variable length key (for example, BLOWFISH), the key length must be negotiated.
  • Key Rounds: For an ESP SA whose encryption algorithm key can be calculated with a variable number of rounds, the number of key rounds must be negotiated.
  • Compress Dictionary Size: If the SA is to provide traffic compression, the maximum dictionary size must be negotiated.
  • Compress Private Algorithm: If the SA is to provide traffic compression, the compression algorithm must be negotiated.
• Key Exchange Payload: (if Perfect Forward Secrecy of Keys is required) (same as above)
• Identification Payload: (if endpoint identity is not equivalent to the peer address) (same as above)

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:

• ISAKMP Header: (same as above)
  
  
• Hash Payload: (same as above)

  The Hash in this message is calculated as follows:

  HASH_I = prf(SKEYID_a, 0 | M-ID | N_I | N_R)
  
  where:
    HASH_I is the Initiator's Hash
    prf is the negotiated keyed pseudo-random function 
  	(or the HMAC version of the negotiated keyed hash)
    M-ID is the Message ID from the ISAKMP Header
    N_I is the Initiator's Nonce Payload (minus the ISAKMP generic header) 
    N_R is the Responder's Nonce Payload (minus the ISAKMP generic header) 
  

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

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:

• ISAKMP Header: (same as above)
  
  
• Hash Payload: (same as above)

  The Hash in this message is calculated as follows:

  HASH_I = prf(SKEYID_a, M-ID | SA_I)
  HASH_R = prf(SKEYID_a, M-ID | SA_R)
  
  where:
    HASH_I is the Initiator's Hash
    HASH_R is the Responder's Hash
    prf is the negotiated keyed pseudo-random function 
  	(or the HMAC version of the negotiated keyed hash)
    SKEYID_a is the Phase 1 authentication key
    M-ID is the Message ID from the ISAKMP Header
    SA_I is the Initiator's Nonce Payload (with the ISAKMP generic header) 
    SA_R is the Initiator's Nonce Payload (with the ISAKMP generic header) 
  

• SA Payload: (same as above)
  
  
• Proposal Payload: (same as above)
  
  
• Transform Payload: The Transform Payload defines the specific algorithms, negotiation mechanisms, and policy (collectively known as attributes) that will characterize the New Group. The New Group attributes that are open to negotiation are:
  • Group Description /Type /Prime / Generator(s) /Curve(s) / Order / Field Size: These values define the specifics of the Diffie-Hellman exchange that will establish the shared secret used in the generation of the key material. The Group Description serves as the group's identification number. The Group Type attribute is used to specify whether the group is a MODP or elliptic curve group. The Group Prime and Group Generator attributes are used to define a new MODP group; the Group Prime, Group Generator, Group Curve, Group Order, and Field Size attributes are used to define a new elliptic curve group.

Informational Exchanges

• ISAKMP Header: (same as above)

  Each Information Exchange has a unique Message ID that is distinct from the Phase 2 Message ID (if any).
  
  

• Notify Payload or Delete Payload: A Notify Payload contains the identifying number of a pre-defined status (e.g. initial contact received) or diagnostic (e.g. invalid payload type) message. A Delete Payload is used to notify the peer that an SA has been deleted, and contains data identifying the deleted SA.
  
  
• Hash Payload: (only if ISAKMP SA exists or keying material has been computed) (same as above)

  The Hash in this message is calculated as follows:

  HASH = prf(SKEYID_a, M-ID | N/D)
  
  where:
    prf is the negotiated keyed pseudo-random function 
  	(or the HMAC version of the negotiated keyed hash)
    SKEYID_a is the Phase 1 authentication key
    M-ID is the unique Message ID for this message
    N/D is the Notify or Delete Payload (with the ISAKMP generic header)
  

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

• Phase 1 Negotiation Mode: Main Mode
• IKE Phase 1 Attributes:
  • Encryption Algorithm:
    • DES_CBC
    • 3DES_CBC
  • Hash Algorithm:
    • MD5
    • SHA
  • Authentication Method: Pre-shared key
  • Group Description: Default 768-bit MODP Group
  • Life Type and Duration:
    • Seconds
    • Kilobytes
  • PRF (Pseudo-Random Function): None (Use HMAC form of Authentication Algorithm)
• Phase 2 Negotiation Mode: Quick Mode
• Perfect Forward Secrecy: PFS of keys (optional Phase 2 Key Exchange Payload)
• ISAKMP Payloads:
  • Security Association Payload
  • Proposal Payload
  • Transform Payload
  • Key Exchange Payload
  • Identification Payload
  • Hash Payload
  • Nonce Payload
  • Notification Payload (some)
• Identification Types (in Identification Payload):
  • single IP address (IPv4 only);
• DOI: IPSEC
• Situation: Identity Only
• IPsec Phase 1 Protocol Identifier: ISAKMP
• IPsec Phase 1 ISAKMP Transform Identifier: IKE
• IPsec Phase 2 Protocol Identifiers:
  • AH
  • ESP
• IPsec Phase 2 AH Transform Identifiers:
  • MD5
  • SHA
• IPsec Phase 2 ESP Transform Identifiers:
  • DES_IV64
  • DES
  • 3DES
  • RC5
  • IDEA
  • BLOWFISH
  • ESP_NULL
• IPsec Phase 2 Attributes:
  • SA Life Type and Duration:
    • Seconds
    • Kilobytes
  • Group Description: Default 768-bit MODP Group
  • Encapsulation Mode
    • Transport
    • Tunnel
  • Authentication Algorithm
    • HMAC-MD5
    • HMAC-SHA
  • Key Length
    • RC5: 5, 16, or 20 bytes
    • BLOWFISH: 5 - 56 bytes

IKE / ISAKMP / DOI Features Not Found in PlutoPlus

• Phase 1 Negotiation Mode: Aggressive Mode
• IKE Phase 1 Attributes:
  • Encryption Algorithm:
    • IDEA_CBC
    • BLOWFISH_CBC
    • RC5_R16_B64_CBC
    • CAST_CBC
  • Hash Algorithm: Tiger
  • Authentication Method:
    • Digital signatures (DSS and RSA)
    • Public key original mode (with RSA)
    • Public key revised mode (with RSA)
  • Group Description:
    • Alternate 1024-bit MODP Group
    • EC2N Group on GP[2^155]
    • EC2N Group on GP[2^185]
  • Group Type
  • Group Prime/Irreducible Polynomial
  • Group Generator One and Two
  • Group Curve A and B
  • PRF (Pseudo-Random Function)
  • Key Length
  • Field Size
  • Group Order
• Phase 2 Negotiation Mode: New Groups Mode
• ISAKMP Payloads:
  • Certificate Payload
  • Certificate Request Payload
  • Signature Payload
  • Notification Payload (some)
  • Delete Payload
  • Vendor ID Payload
• Identification Types (in Identification Payload):
  • single IP address (IPv6 only);
  • fully-qualified domain name string
  • fully-qualified username string
  • subnet(IPv4 or IPv6);
  • range of IP addresses (IPv4 or IPv6);
  • ASN.1 X.500 Distinguished Name [X.501] or GeneralName [X.509];
• Phase 2 Client IDs
• DOI: Generic ISAKMP
• Situation:
  • Secrecy
  • Integrity
• IPsec Phase 2 Protocol Identifiers: IP Compression (IPCOMP)
• IPsec Phase 2 AH Transform Identifiers: DES
• IPsec Phase 2 ESP Transform Identifiers:
  • CAST
  • 3IDEA
  • DES_IV32
  • RC4
• IPsec Phase 2 Attributes:
  • Group Description:
    • Alternate 1024-bit MODP Group
    • EC2N Group on GP[2^155]
    • EC2N Group on GP[2^185]
  • Authentication Algorithm
    • DES-MAC
    • KPDK
  • Key Rounds
  • Compress Dictionary Size
  • Compress Private Algorithm

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:

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