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:
- 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
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:
- 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
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:
- 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:
- Encryption Algorithm:
- Hash Algorithm:
- Authentication Method: Pre-shared key
- Group Description: Default 768-bit MODP Group
- Life Type and Duration:
- 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:
- IPsec Phase 2 AH Transform Identifiers:
- IPsec Phase 2 ESP Transform Identifiers:
- DES_IV64
- DES
- 3DES
- RC5
- IDEA
- BLOWFISH
- ESP_NULL
- IPsec Phase 2 Attributes:
- SA Life Type and Duration:
- Group Description: Default 768-bit MODP Group
- Encapsulation Mode
- Authentication Algorithm
- 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:
- IPsec Phase 2 Protocol Identifiers: IP Compression (IPCOMP)
- IPsec Phase 2 AH Transform Identifiers: DES
- IPsec Phase 2 ESP Transform Identifiers:
- 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
- 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:
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: