---------------------------------------------------------------------------

PlutoPlus:
An IKE Reference Implementation for Linux

---------------------------------------------------------------------------

Contents:

   * IKE Generic Description
        o Phase 1 Negotiation
             + Main Mode
             + Aggressive Mode
        o Phase 2 Negotiation
             + Quick Mode
        o Additional Exchanges
             + New Group Mode
             + Informational Exchanges
        o IKE Headers
             + ISAKMP Header
             + Generic Payload Header
        o 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
        o PlutoPlus Modes of Operation
        o PlutoPlus Command Line Options
        o IKE / ISAKMP / DOI Features Found in PlutoPlus
        o 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:
        o 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.
        o 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).
        o Next Payload: Each message contains one or more payloads; this
          header field identifies the type of the first payload.
        o 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.
        o 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).
        o 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
        o 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)
        o 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:
        o Next Payload: the type of the payload that follows this payload
          (0 if none)
        o Reserved: unused (set to 0)
        o 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:
        o 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.
        o 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:
        o 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).
        o 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:
        o 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.
        o 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.
        o 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.
        o 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.
        o 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.
        o 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:
        o a single IP address (IPv4 or IPv6);
        o a fully-qualified domain name string (for example,
          "foo.bar.com");
        o a fully-qualified username string (for example,
          "piper@foo.bar.com");
        o a subnet, defined by an IP address and an IP network mask (both
          IPv4 or IPv6);
        o a range of IP addresses, represented by two IP addresses (both
          IPv4 or IPv6);
        o 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

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:

   * 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:
        o 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).
        o 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:
        o 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.
        o 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.
        o Encapsulation Mode: describes whether the SA will be a
          transport-mode SA or a tunnel-mode SA.
        o 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.
        o Key Length: For an ESP SA whose encryption algorithm takes a
          variable length key (for example, BLOWFISH), the key length must
          be negotiated.
        o 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.
        o Compress Dictionary Size: If the SA is to provide traffic
          compression, the maximum dictionary size must be negotiated.
        o 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

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:

   * 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:
        o 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

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:

   * 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

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.

   * Phase 1 Negotiation Mode: Main Mode
   * IKE Phase 1 Attributes:
        o Encryption Algorithm:
             + DES_CBC
             + 3DES_CBC
        o Hash Algorithm:
             + MD5
             + SHA
        o Authentication Method: Pre-shared key
        o Group Description: Default 768-bit MODP Group
        o Life Type and Duration:
             + Seconds
             + Kilobytes
        o 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:
        o Security Association Payload
        o Proposal Payload
        o Transform Payload
        o Key Exchange Payload
        o Identification Payload
        o Hash Payload
        o Nonce Payload
        o Notification Payload (some)
   * Identification Types (in Identification Payload):
        o 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:
        o AH
        o ESP
   * IPsec Phase 2 AH Transform Identifiers:
        o MD5
        o SHA
   * IPsec Phase 2 ESP Transform Identifiers:
        o DES_IV64
        o DES
        o 3DES
        o RC5
        o IDEA
        o BLOWFISH
        o ESP_NULL
   * IPsec Phase 2 Attributes:
        o SA Life Type and Duration:
             + Seconds
             + Kilobytes
        o Group Description: Default 768-bit MODP Group
        o Encapsulation Mode
             + Transport
             + Tunnel
        o Authentication Algorithm
             + HMAC-MD5
             + HMAC-SHA
        o 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:
        o Encryption Algorithm:
             + IDEA_CBC
             + BLOWFISH_CBC
             + RC5_R16_B64_CBC
             + CAST_CBC
        o Hash Algorithm: Tiger
        o Authentication Method:
             + Digital signatures (DSS and RSA)
             + Public key original mode (with RSA)
             + Public key revised mode (with RSA)
        o Group Description:
             + Alternate 1024-bit MODP Group
             + EC2N Group on GP[2^155]
             + EC2N Group on GP[2^185]
        o Group Type
        o Group Prime/Irreducible Polynomial
        o Group Generator One and Two
        o Group Curve A and B
        o PRF (Pseudo-Random Function)
        o Key Length
        o Field Size
        o Group Order
   * Phase 2 Negotiation Mode: New Groups Mode
   * ISAKMP Payloads:
        o Certificate Payload
        o Certificate Request Payload
        o Signature Payload
        o Notification Payload (some)
        o Delete Payload
	o Vendor ID Payload
   * Identification Types (in Identification Payload):
        o single IP address (IPv6 only);
        o fully-qualified domain name string
        o fully-qualified username string
        o subnet(IPv4 or IPv6);
        o range of IP addresses (IPv4 or IPv6);
        o ASN.1 X.500 Distinguished Name [X.501] or GeneralName [X.509];
   * Phase 2 Client IDs
   * DOI: Generic ISAKMP
   * Situation:
        o Secrecy
        o Integrity
   * IPsec Phase 2 Protocol Identifiers: IP Compression (IPCOMP)
   * IPsec Phase 2 AH Transform Identifiers: DES
   * IPsec Phase 2 ESP Transform Identifiers:
        o CAST
        o 3IDEA
        o DES_IV32
        o RC4
   * IPsec Phase 2 Attributes:
        o Group Description:
             + Alternate 1024-bit MODP Group
             + EC2N Group on GP[2^155]
             + EC2N Group on GP[2^185]
        o Authentication Algorithm
             + DES-MAC
             + KPDK
        o Key Rounds
        o Compress Dictionary Size
        o 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:

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

[Image] 301/975-3297

[Image] 301/948-0279

[Image] sheila.frankel@nist.gov
---------------------------------------------------------------------------
Last Modified: Wednesday, 16-Sep-98 12:09:16 EDT
