Internet DRAFT - draft-harkins-ikev3
draft-harkins-ikev3
Internet Engineering Task Force D. Harkins, Ed.
Internet-Draft Aruba Networks
Intended status: Standards Track April 12, 2013
Expires: October 14, 2013
The (Real) Internet Key Exchange
draft-harkins-ikev3-01
Abstract
The current version (v2) of the Internet Key Exchange failed to
address many of the shortcomings of the original version (v1). This
memo defines a new version (v3) of the Internet Key Exchange that
attempts to do so.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 14, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Harkins Expires October 14, 2013 [Page 1]
Internet-Draft IKEv3 April 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Characteristics of Version 3 of IKE . . . . . . . . . . . . . 4
3. Differences from Previous Versions of IKE . . . . . . . . . . 4
3.1. Identity Confidentiality . . . . . . . . . . . . . . . . . 5
3.2. Single IKE SA, No Lifetime . . . . . . . . . . . . . . . . 5
3.3. Not A Request/Response Exchange . . . . . . . . . . . . . 5
3.4. State Machine Definition . . . . . . . . . . . . . . . . . 6
4. Cryptographic Tools . . . . . . . . . . . . . . . . . . . . . 6
4.1. Authenticated Encryption . . . . . . . . . . . . . . . . . 6
4.2. Hash Function . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Discrete Logarithm Cryptography . . . . . . . . . . . . . 7
4.4. Key Deriviation Function . . . . . . . . . . . . . . . . . 8
5. Authentication and Key Establishment . . . . . . . . . . . . . 9
5.1. Public Key Authentication . . . . . . . . . . . . . . . . 9
5.1.1. KE Payload with Public Key Authentication . . . . . . 9
5.1.2. AU Payload with Public Key Authentication . . . . . . 10
5.2. PSK Authentication . . . . . . . . . . . . . . . . . . . . 10
5.2.1. Hunting and Pecking with ECP Groups . . . . . . . . . 11
5.2.2. Hunting and Pecking with MODP Groups . . . . . . . . . 12
5.2.3. KE Payload with PSK Authentication . . . . . . . . . . 13
5.2.4. AU Payload with PSK Authentication . . . . . . . . . . 14
5.3. Deriving Shared Secrets . . . . . . . . . . . . . . . . . 15
6. The Internet Key Exchange Protocol . . . . . . . . . . . . . . 15
6.1. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 16
6.1.1. Init Messages . . . . . . . . . . . . . . . . . . . . 16
6.1.1.1. Construction of Init Messages . . . . . . . . . . 16
6.1.1.2. Processing of Init Messages . . . . . . . . . . . 17
6.1.2. Auth Messages . . . . . . . . . . . . . . . . . . . . 18
6.1.2.1. Construction of Auth Messages . . . . . . . . . . 18
6.1.2.2. Processing of Auth Messages . . . . . . . . . . . 19
6.2. IPsec Security Associations . . . . . . . . . . . . . . . 21
6.3. State Machine . . . . . . . . . . . . . . . . . . . . . . 21
6.3.1. Parent Process . . . . . . . . . . . . . . . . . . . . 22
6.3.2. Components of State Machine . . . . . . . . . . . . . 23
6.3.3. States . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3.3.1. Nothing State . . . . . . . . . . . . . . . . . . 24
6.3.3.2. Initiation State . . . . . . . . . . . . . . . . . 25
6.3.3.3. Reception State . . . . . . . . . . . . . . . . . 26
6.3.3.4. Done State . . . . . . . . . . . . . . . . . . . . 27
6.3.4. Cleaning Up Protocol Instances . . . . . . . . . . . . 28
6.4. IKEv3 Payload Formats . . . . . . . . . . . . . . . . . . 28
6.4.1. IKE header . . . . . . . . . . . . . . . . . . . . . . 28
6.4.2. Generic IKE payload header . . . . . . . . . . . . . . 30
6.4.3. IKE Attributes payload . . . . . . . . . . . . . . . . 31
6.4.4. Identity Payload . . . . . . . . . . . . . . . . . . . 33
Harkins Expires October 14, 2013 [Page 2]
Internet-Draft IKEv3 April 2013
6.4.5. Nonce Payload . . . . . . . . . . . . . . . . . . . . 34
6.4.6. Key Exchange Payload . . . . . . . . . . . . . . . . . 34
6.4.7. Certificate Payload . . . . . . . . . . . . . . . . . 35
6.4.8. Certificate Request Payload . . . . . . . . . . . . . 36
6.4.9. Authentication Payload . . . . . . . . . . . . . . . . 36
6.4.10. Address Indication Payload . . . . . . . . . . . . . . 37
6.4.11. Traffic Selecor Payload . . . . . . . . . . . . . . . 37
6.4.12. Security Association Payload . . . . . . . . . . . . . 39
6.4.13. Vendor Indication Payload . . . . . . . . . . . . . . 40
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
9. Security Considerations . . . . . . . . . . . . . . . . . . . 41
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
10.1. Normative References . . . . . . . . . . . . . . . . . . . 41
10.2. Informative References . . . . . . . . . . . . . . . . . . 42
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43
Harkins Expires October 14, 2013 [Page 3]
Internet-Draft IKEv3 April 2013
1. Introduction
The Internet Key Exchange was first defined in [RFC2409] to generate
security associations for the IPsec protocols. That specification
was poorly written and suffered from too many options, many of which
were unneeeded and went unused. In short, it was confusing and
complicated. An effort was made to come up with a simpler and less
confusing version, and that resulted in [RFC4306], so-called IKEv2
([RFC2409] was then dubbed IKEv1). While it was arguably simpler and
less confusing, IKEv2 failed to achieve its goal. It went through an
extensive clarification process that produced [RFC4718] and
development of a replacement specification for IKEv2, in [RFC5996].
While [RFC5996] is definitely a cleaner protocol than [RFC2409] it
still has too many options and is too complicated, and confusing.
This memo defines an IKEv3 in an effort to have a simpler, more easy
to implement protocol, that that has a high probability of achieving
interoperability while retaining security and utility.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Characteristics of Version 3 of IKE
Version 3 of the Internet Key Exchange is a simple peer-to-peer
protocol in which each side sends and receives two messages. It
performs mutual authentication, derives a shared, secret and
authenticated key, and negotiates parameters for IPsec security
associations (SAs) to protect transient data between the peers.
Either side can initiate the exchange to the other and both sides can
initiate simultaneously (hence the claim of a true "peer-to-peer"
exchange). This is advantageous for certain smart devices-- aka "the
Internet of things"-- or sensor network deployments where there is no
strict roles of client or server, initiator or responder.
In an effort to keep the definition of the Internet Key Exchange as
simple as possible, negotiation of the terms of its operation-- e.g.
encryption algorithm, hash algorithm-- is kept to a minimum.
3. Differences from Previous Versions of IKE
Harkins Expires October 14, 2013 [Page 4]
Internet-Draft IKEv3 April 2013
3.1. Identity Confidentiality
IKEv3 does not provide identity confidentiality. This is a tradeoff
made to increase simplicity in specification and, more importantly,
implementation at the cost of a feature whose benefit is somewhat
dubious.
While security on the Internet is a large issue (one that IKEv3
addresses) the problems associated with exposure of the identities of
two peers that are engaging in secure communication is not.
If identity hiding critical for a particular deployment, IKEv3
supports obfuscation of identity using an ID blob which has meaning
to the two peers of the exchange but has no meaning to any third
party that may observe it.
3.2. Single IKE SA, No Lifetime
IKEv3 can handle the situation where both sides initiate to each
other without resorting to carrying on two conversations and ending
up with two IKE Security Associations.
The IKEv3 SA is also short-lived. Its purpose is to create SAs for
IPsec and once it has done that the state that governed a particular
protocol run can go away. There is no notion of a long-lived IKE SA.
There is no SA lifetime necessary for IKEv3 to negotiate. This also
has the benefit of doing away with the Delete payloads and their
corresponding complexity as well as the complexity associated with
rekeying of SAs.
There is no need for "initial contact" notification or the need to
negotiate, or rekey, multiple IKE SAs.
3.3. Not A Request/Response Exchange
[RFC2409] and [RFC5996] are both Request/Response protocols. There
are defined roles-- one side is an "Initiator" and the other is a
"Responder"-- and one side makes Requests and the other Responds to
those requests.
In IKEv3 there are no roles involved-- no clients and servers, no
Initiators and Responders-- just two peers who perform identical
behavior. Since either side can initiate and both sides can initiate
simultaneously, there is no need to deal with "Exchange Collisions".
All the protocol specification complexity to address the problems
that occur due to role-based protocol definition goes away.
Harkins Expires October 14, 2013 [Page 5]
Internet-Draft IKEv3 April 2013
Many of the IKEv1 and IKEv2 use cases involved strict roles and IKEv3
can support them because the state machine (see Section 6.3) can
handle the case where one side initiates and the other responds just
as easily as it can handle the case where both sides initiate
simulteneously.
3.4. State Machine Definition
IKEv3 defines a very simple state machine that each side runs through
to implement the protocol. Accurate compliance with the state
machine ensures interoperability.
The state machine allows the protocol definition to be entirely from
the point of view of the implementation, making protocol
implementation much easier. The protocol is defined in terms of
actions causing events which result in a deterministic advancement of
state until the protocol is finished. The state machine definition
assures that each side either completes the protocol or neither side
completes the protocol.
Previous versions of IKE lacked a state machine definition and it
showed. IKEv1 achieved interoperability through implementor "bake-
offs" and not through a coherent specification. IKEv2 has gone
through forty (40) revisions, in total, in an effort to clarify and
straighten out ambiguous and confusing text and remains to this day a
complicated, ambiguous and confusing specification.
4. Cryptographic Tools
IKEv3 makes use of certain cryptographic primitives to achieve its
goals of key generation, mutual authentication, and security. Each
of the following subsections indicate negotiable components of the
IKE Security Association that are used during the protocol run.
Different protocol runs can negotiate different components and the
components to use in a particular run of the protocol are established
by exchanging payloads in the Init message that describe the
attributes of the IKE Security Association (see Section 6.4).
4.1. Authenticated Encryption
Authenticated encryption is employed by IKEv3 to protect the payloads
that set up IPsec Security Associations as well as any vendor-
specific payloads that are added to the final two messages of the
protocol. It is therefore a negotiable component. The privacy
algorithm negotiated MUST be a cipher mode, or construction of cipher
mode plus integrity check, that provides authenticated encrytion.
Harkins Expires October 14, 2013 [Page 6]
Internet-Draft IKEv3 April 2013
AES in SIV mode as defined in [RFC5297] is used in IKEv3 to
accomplish this goal. SIV supports authenticated encryption with
associated data (which is authenticated but not encrypted) and does
not require complex managment of a unique counter space to ensure
security. It is simple, secure and robust. A perfect fit for IKEv3.
4.2. Hash Function
A hash function takes a arbitrary-sized input and deterministically
produces a fixed sized output, called a digest. It is also a one-way
function: it is very easy to produce a digest but computationally
infeasible to reconstruct the arbitrary-sized input given a
particular digest.
IKEv3 uses a hash function, in [RFC2104] mode for key derivation and
key confirmation. IKEv3 also uses a hash function to construct a
random function, H():
H(x) = HMAC-Hash(0^n, x)
where Hash is the agreed-upon hash function and "0^n" signifies a key
of all zeros whose length equals the digest size of the hash
function.
IKEv3 defines SHA-256 and SHA-512 (as defined in [RFC4634]) for use
as hash functions.
4.3. Discrete Logarithm Cryptography
The Internet Key Exchange uses discrete logarithm cryptography. Each
party to the protocol derives ephemeral public and private key pairs
with respect to a particular domain parameter set, called a "group".
The group can be based on either finite field cryptography (modular
exponentiation, or MODP, groups) or elliptic curve cryptography (ECP
groups).
In this memo, elements in a group are denoted in upper case and
scalar values are in lower case-- element X and scalar x.
Groups are identified in messages using a convenient registry
maintained by IANA (see Section 8). Each group's domain parmameter
set contains the following:
o p - a prime number defining a finite field
o G - a generator, a base element forming a group
Harkins Expires October 14, 2013 [Page 7]
Internet-Draft IKEv3 April 2013
o q - a prime number indicating the order of the group defined by G
ECP groups additionally define "a" and "b" which are components of
the equation of the elliptic curve-- y^2 = x^3 + ax + b. Some MODP
groups are based on safe primes and do not have a specific order
defined. For these groups only, the order, q, SHALL be (p-1)/2.
For each group, the following operations are defined:
o "scalar operation" -- takes a scalar and an element in the group
to produce another element in the group-- Z = scalar-op(x, Y).
For ECP groups this is multiplication of the element by the
scalar; for MODP groups this is exponentiation of the element to
the scalar.
o "element operation" -- takes two elements in the group to produce
a third element in the group-- Z = element-op(X, Y). For ECP
groups this is point addition; for MODP groups this is modular
multiplication.
o "inverse operation" -- takes an element in the group and returns
another element in the group such that the element operation on
the two produces the identity element of the group-- Y =
inverse(X).
ECP: element-op(Y, inverse(Y)) = "point at infinity"
MODP: element-op(Y, inverse(Y)) = 1
In addition, ECP groups require a mapping function, r = F(R), to
convert a group element to an integer. The mapping function used in
this memo returns the x-coordinate of the point it is passed. MODP
groups do not need a mapping function as group elements in MODP
groups can be directly represented as integers. For the purpose of
protocol definition, the function F() when used with MODP groups will
be the identity function-- i.e. i = F(i).
4.4. Key Deriviation Function
IKEv3 uses a key derivation function, KDF(), to stretch a random key
to an indeterminate length and bind some arbitrary data to the
stretched key.
For ease of programming, IKEv3 uses the prf+() function from
[RFC5996] which, in turn, was derived from the prf() function in
[RFC2409], as its KDF().
THe pseudo-random function at the core of the prf+() construct is the
Harkins Expires October 14, 2013 [Page 8]
Internet-Draft IKEv3 April 2013
agreed-upon hash function in HMAC ([RFC2104]) mode. When KDF() is
called for in this memo, it is prf+() from [RFC5996] using HMAC-Hash
where hash is the agreed-upon hash algorithm.
5. Authentication and Key Establishment
The goal of any pairwise authenticated key exchange is key
establishment and mutual authentication. The IKEv3 protocol achieves
these goals. The particular method of key establishment is tied to
the authentication method which is tied to the type of credential
used for authentication-- a (certified) public key or a PSK.
5.1. Public Key Authentication
Public key authentication uses a Diffie-Hellman key exchange for key
establishment and digital signatures by a private key whose public
analog is trusted by the peer.
5.1.1. KE Payload with Public Key Authentication
The KE payload is used to present a Diffie-Hellman public value to
the peer. Each peer generates a random number between one (1) and
the order of the group, q, exclusive. This represents the peer's
private value, priv. The peer then performs the group's scalar
operation (see Section 4.3) with the group's generator to produce the
public value, Pub:
Pub = scalar-op(priv, G)
The public value is encoded in to the body of the KE Payload (see
Section 6.4) according to the integer to octet string conversion
technique from [RFC6090].
The Diffie-Hellman key exchange is completed when both sides have
finished sending and receiving an Init message. Each side generates
the same shared secret, secret, by applying the mapping function, F()
(see Section 4.3), to the result of the group's scalar operation with
the entities private value, priv, and the peer's public key, PubPeer:
secret = F(scalar-op(priv, PubPeer))
The secret is then used to generate three additional keys, the
authenticated encryption key, the confirmation key, and a key-
derivation key. (see Section 5.3).
Harkins Expires October 14, 2013 [Page 9]
Internet-Draft IKEv3 April 2013
5.1.2. AU Payload with Public Key Authentication
The AU payload contains a digital signature of the confirmation key
and both peers' Init messages concatenated together, transmitter's
Init message first. For example, assuming Alice sent the message
InitA and Bob send the message InitB, Alice's digital signature would
be "sig" where:
sig = Sign-Alice(cKEY | InitA | InitB)
where "|" signifies concatenation, and Sign-Alice() indicates a
digital signature of that data passed to it using the public key of
Alice. The portions of the Init messages that are covered by the
digital signature consist of the IKE header (inclusive) to the end of
the payload.
Bob would similarly send:
sig = Sign-Bob(cKEY | InitB | InitA)
since Bob was the transmitter of InitB.
To maintain a consistent level of security for IKEv3, the hash
algorithm used to generate the digital signature SHALL be the one
negotiated in the IKE Security Association that is used for other
hashing purposes in IKEv3. The body of the AU payload (see
Section 6.4) SHALL consist of the digital signature as a bitstring.
5.2. PSK Authentication
PSK authentication uses the "dragonfly" key exchange to both generate
a shared, and secret, key and to mutually authenticate the peers to
each other. Each side proves knowledge of the PSK in a manner that
is resistant to dictionary attack.
Each side proves possession of a single PSK (or password), there is
no notion of a "client's password" and a "server's password"; there
is just the one. This single PSK MUST be provisioned on the two
peers prior to beginning the IKEv3 exchange. Since there is only one
PSK it SHOULD have only one name, which is provisioned along with the
PSK. It is this name that is used in the ID payload when initiating
the dragonfly exchange to the peer. Note: it may make sense in
certain client/server deployments to have a proper client username
assigned to the password, in which case the server proving possession
of the client's password-- identified by username-- authenticates it
to the client.
When PSK authentication is chosen for a particular run of the
Harkins Expires October 14, 2013 [Page 10]
Internet-Draft IKEv3 April 2013
protocol, the KE payload contains each peer's "commit" contribution
to the dragonfly exchange and the AU payload contains a keyed message
authentication code binding the secret key to both peers' Init
messages concatenated together.
Prior to beginning the "dragonfly" exchange, both peers MUST agree
upon a secret element in the chosen group. A secret seed is
generated and that see is used in a group-specific hunting-and-
pecking process-- one process for MODP groups and another for ECP
groups. First, an 8-bit counter is set to one (1) and a secret base
is computed using the negotiated one-way function with the secret
PSK, and the counter:
base = H(PSK | counter)
The base is then stretched using the key derivation function from
Section 4.4 to the length of the prime from the group's domain
parameter set:
seed = KDF(base, "IKE PSK Hunting and Pecking")
The seed is then passed to the group-specific hunting and pecking
technique.
5.2.1. Hunting and Pecking with ECP Groups
The ECP specific hunting and pecking technique entails looping until
a valid point on the elliptic curve has been found. The seed is used
as the x-coordinate with the equation of the curve to solve for a
y-coordinate. If there is no solution, the counter is incremented, a
new base and new seed are generated and the hunting and pecking
continues. If there is a solution an ambiguity exists because two
values for the y-coordinate would be valid. The low-order bit of the
base is used to unambiguously determine the y-coordinate and the
resulting (x,y) pair becomes the secret generator for the dragonfly
exchange, SKE.
Algorithmically, the process looks like this:
Harkins Expires October 14, 2013 [Page 11]
Internet-Draft IKEv3 April 2013
found = 0
counter = 1
do {
base = H(psk | counter)
seed = KDF(seed, "IKE PSK Hunting And Pecking")
if (seed < p)
then
x = seed
if ( (x^3 + ax + b) is a quadratic residue mod p)
then
y = sqrt(x^3 + ax + b)
if (LSB(y) == LSB(base))
then
SKE = (x,y)
else
SKE = (x, p-y)
fi
found = 1
fi
fi
counter = counter + 1
} while (found == 0)
Figure 1: Fixing SKE for ECP Groups
5.2.2. Hunting and Pecking with MODP Groups
The MODP specific hunting and pecking technique entails finding a
random element which, when used as a generator, will create a group
with the same order as the group created by the generator from the
domain parameter set. The secret generator is found by
exponentiating the seed to the value ((p-1)/q), where p is the prime
and q is the order from the domain parameter set. If that value is
greater than one (1) it becomes SKE, otherwise the counter is
incremented, a new base and seed are generated, and the hunting and
pecking continues.
Algorithmically, the process looks like this:
Harkins Expires October 14, 2013 [Page 12]
Internet-Draft IKEv3 April 2013
found = 0
counter = 1
do {
base = H(psk | counter)
seed = KDF(base, "IKE SKE Hunting And Pecking")
if (seed < p)
then
SKE = seed ^ ((p-1)/r) mod p
if (SKE > 1)
then
found = 1
fi
fi
counter = counter + 1
} while (found == 0)
Figure 2: Fixing SKE for MODP Groups
5.2.3. KE Payload with PSK Authentication
Once SKE has been determined, the peer randomly chooses two numbers
between one and the order of the group, q, exclusively. These
represent a private value and a mask. The peer then generates a
scalar and an element using private, mask, and SKE:
scalar = (private + mask) mod q
Element = inverse(scalar-op(mask, SKE))
The scalar and element, respectively, are encoded into the KE payload
by using the integer to octet string conversion technique from
[RFC6090]. Octet strings are pre-pended with zero (0), if necessary,
to achieve the required resulting length. Since the length of each
component of the KE payload is implicitly known, the scalar and
element can be extracted from the KE payload for processing.
The scalar is the same length as the order of the group. It is
converted into an octet string and then the octet string is inserted
into the body of the KE Payload.
If the selected group is MODP, the element can be treated directly as
an integer and converted into an octet string. Its length is the
same as the length of the prime of the group. The converted octet
string is appended to the octet string representation of the scalar.
If the selected group is ECP, the element is an (x,y) pair and each
coordinate is separately converted into an octet string, each of
which is the same length as the prime of the group. The octet string
Harkins Expires October 14, 2013 [Page 13]
Internet-Draft IKEv3 April 2013
representation of the x-coordinate SHALL be appended to the scalar
and the y-coordinate SHALL be appended to the x-coordinate.
The dragonfly key handshake is completed when both sides have
finished sending and receiving an Init message. Each side generates
the same shared secret, secret, by performing the following
computation:
secret = F(scalar-op(private,
element-op(PeerElement,
scalar-op(peerscalar, SKE))))
where peerscalar and PeerElement are scalar and element from the
peer's KE payload taken out of a received Init message. The secret
is then used to generate three additional keys, the authenticated
encryption key, the confirmation key, and a key-derivation key. (see
Section 5.3).
5.2.4. AU Payload with PSK Authentication
The AU payload contains a keyed message authentication code which
proves knowledge of the derived secret, and therefore knowledge of
the PSK, and binds the two Init messages to the authenticated state.
Each side produces an authenticating message authentication code,
mac, by invoking the HMAC version of the negotiated hash function and
passing the confirmation key, cKEY, as the key and the concatentation
of both peers' Init messages concatenated together, transmitter's
Init message first. For example, assuming Alice sent the message
InitA and Bob sent the message InitB, Alice's message authentication
code would be "mac" where:
mac = HMAC-Hash(cKEY, InitA | InitB)
where "|" signifies concatentation and HMAC-Hash is the [RFC2104]
instantiation of the negotiated hash algorithm, Hash. The portions
of the Init messages passed HMAC-Hash consist of the IKE header
(inclusive) to the end of the payload.
Bob would similarly send:
mac = HMAC-Hash(cKEY, InitB | InitA)
since Bob was the transmitter of InitB.
Harkins Expires October 14, 2013 [Page 14]
Internet-Draft IKEv3 April 2013
5.3. Deriving Shared Secrets
Upon successful completion of key establishment, IKEv3 produces three
keys, an authenticated encryption key, aeKEY, to protect the Auth
Messages, a confirmation key, cKEY, and a derivation key, dKEY, used
to derive (a) shared secret(s) when constructing IPsec Security
Associations (see Section 6.2).
The length of aeKEY depends on the authenticated encryption mode used
and the length of cKEY and dKEY SHALL be the length of the digest of
negotiated hash function. The keys are derived by passing the two
nonces, appended to each other with the lexicographically larger
nonce being first, as the key and secret from the authenticated key
exchange concatenated with the label "IKEv3 Key Derivation" as the
data:
aeKEY | cKEY | dKEY = KDF(max(Na, Nb) | min(Na, Nb),
secret | "IKEv3 Key Derivation")
where Na and Nb are the two nonces from the exchange (the transmitter
is irrelevant in this peer-to-peer protocol), max() returns the
lexicographically larger of the two parameters passed, and min()
returns the lexicographically smaller of the two parameters passed.
The key aeKEY SHALL be used to protect the exchange of Auth Messages,
the same key is used in both directions.
6. The Internet Key Exchange Protocol
The Internet Key Exchange (IKE) authenticates two peers to each other
and derives security associations for use by IPsec. The credentials
supported by IKE are PSKs and certificates.
IKE supports varying degrees of security by supporting various domain
parameter groups, encryption algorithms, and hash algorithms.
IKEv3 supports detection of NATs between two peers through the
exchange of source and destination indicators. When (a) NAT(s) is
(are) present between the peers the source and/or destination
addresses and/or ports will be modified and differ from those in the
indicators. When (a) NATS(s) is (are) detected, UDP encapsulation of
ESP traffic as defined by [RFC3948] is required. Note that IKEv3 is
not required to use port 4500 in the presense of (a) NAT(s).
Harkins Expires October 14, 2013 [Page 15]
Internet-Draft IKEv3 April 2013
6.1. Message Flow
In the IKEv3 protocol each peer sends and receives an Init message
and an Auth message. The Init message negotiates the type of
authentication to be used between the peers, identifies the peers to
each other, exchanges random nonces, and exchanges the components of
a cryptographic key exchange. The Auth message authenticates the
peer to the other peer and establishes IPsec security associations.
Messages are comprised of an IKE header followed by one or more
payloads. The on-the-wire format of the IKE header and all payloads
defined for use in IKE are in Section 6.4.
As is typical in these sorts of memos, the participants in the
protocol are Alice and Bob. The exchange of Init and Auth messages
between Alice and Bob look like this:
Alice Bob
------ ----
Init: hdr, IAa, IDa, NOa, hdr, IAb, IDb, NOb,
KEa [, CRa] ----> <----- KEb [, CRb ]
Auth: hdr, { [CEa, ] AUa, AIs, hdr, { [CEb, ] Aub, AIs,
AId, SAa, TSs, TSd } ----> <----- AId, SAb, TSs, TSd }
Where { x } indicates the authenticated encryption of payload x using
the mode agreed upon in the exchange of IA payloads.
6.1.1. Init Messages
6.1.1.1. Construction of Init Messages
The IKEv3 header contains two message identifiers called SPIs, one
chosen by the transmitter of the message and one chosen by the
(intended) recipient of the message. The local SPI from the IKE
security association is copied into the transmitter SPI field. If a
peer SPI exists in the IKE security association, it is copied into
the receipient SPI field. If there is no peer SPI in the IKE
security association, the receipient SPI field remains all zero.
The first payload in an Init message MUST be an IA payload which
indicates the terms by which the IKE protocol will be run (see
Section 4). If this Init message is being constructed in response to
receipt of an accepted Init message then the attributes from the
received, and accepted, Init message MUST be copied into the Init
message being constructed. If the Init message is being constructed
due to an indication to the IKEv3 protocol to establish IPsec SAs
with a remote peer (see Section 6.3) then the attributes MUST reflect
the policy that accompanied that indication.
Harkins Expires October 14, 2013 [Page 16]
Internet-Draft IKEv3 April 2013
The next payload after the IA payload MUST be the ID payload which
indicates the identity of the peer sending the Init message (see
Section 3.1 for a discussion on identity confidentiality). The next
payload MUST be a NO payload which contributes additional randomness
to the exchange. The next payload MUST be a KE payload. The
particular construction of the body of the KE payload depends on the
authentication method being used for this run of the protocol (see
Section 5). Finally, a CR payload MAY be added if the authentication
method is public key authentication and the sender of the Init
message believes that it needs the peer's public key.
Vendor specific payloads MAY be appended to an Init message to convey
some additional semantics governing the Init message.
6.1.1.2. Processing of Init Messages
The first step of processing an Init Message is to record the peer's
SPI by taking it out of the transmitter SPI field of the IKEv3 header
and storing it in the IKE security association as the peer's SPI.
Next, the attributes that govern the IKEv3 protocol are checked. If
the recipient SPI field is not all zeros (0) then the attributes in
the received Init message MUST be identical to the attributes that
have already been sent to the peer. If they are not, processing
indicates a failure and stops. If the recipient SPI field is all
zeros (0) and a message has not been sent to the peer then the
attributes are checked for acceptability. If they are not acceptable
processing SHALL indicate a failure and stop. If they are
acceptable, then processing continues. Otherwise, if the recipient
SPI field is all zeros (0) and a message has already been sent to the
peer then there are three possible cases:
1. The attributes are identical to the attributes sent to the peer,
so processing continues.
2. The attributes are not acceptable in which case the message is
discarded and processing stops.
3. The attributes are acceptable but differ from those sent. In
this case, a test is made to see which side drops its offer.
Each side has sent its SPI to the other as the transmitter SPI in
its Init message. If the low-order bit of those SPIs are
identical then the transmitter of the larger SPI wins, if the
low-order bit of those SPIs differ then the transmitter of the
smaller SPI wins. The winner SHALL discard the message and the
loser SHALL indicate a failure. In both cases, processing stops.
Note: the loser will destroy all state associated with this
conversation and the winner will retransmit, allowing the two to
Harkins Expires October 14, 2013 [Page 17]
Internet-Draft IKEv3 April 2013
synch up on the new, mutually acceptable attributes.
Finally, the nonce and key exchange data are extracted from the
received Init message and processing finishes successfully. If the
peer requested a certificate, that fact is noted to ensure that a
certificate is included in the subsequent Auth message.
6.1.2. Auth Messages
6.1.2.1. Construction of Auth Messages
The Auth message MAY optionally contain a certificate payload (CE)
with the public key of the transmitter and MUST contain, in the
following order, an Auth payload (AU), a source Address Indication
payload (AIs), a destination Address Indication payload (AId), a
Security Association payload (SA), and two Traffic Selector payloads
(TS). Optional vendor specific payload(s) MAY be appended to the
message but MUST be the last payload(s) in the message.
The contents of AU payload are determined by the authentication
method agreed-upon during the exchange of Init messages (see
Section 5). The value of the Auth payload, from the point of view of
the transmitter, SHALL be determined and copied into the data portion
of the payload.
The AIs and AId payloads are constructed from the point of view of
the transmitting peer. The source Address Indication payload, AIs,
is the address and port being used as the source of the Auth message
and the destination Address Indication payload, AId, is the address
and port of the destination of the Auth message. The source Address
Indication payload MUST precede the destination Address Indication
payload.
The contents of the SA payload describe the transforms and options
that will be represented in the IPsec SA after successful
authentication. If this Auth message is being constructed in
response to the receipt of an Auth message from the peer, the
transforms in the Auth payload MUST be identical to those accepted
when processing the peer's Auth message. If a locally-unique SPI
with which to identify the security association for received IPsec
packets has not yet been chosen, the transmitter choses a SPI.
The TS payloads contains a description of the flows to protect using
IPsec. There are two (2) TS payloads in each Auth message. The
first describes the source of the flow and the second describes the
sink of the flow, both from the perspective of the transmitter of the
Auth message. If local Traffic Selector policy has been narrowed due
to the processing of the peer's Auth message, then the narrowed
Harkins Expires October 14, 2013 [Page 18]
Internet-Draft IKEv3 April 2013
policy SHALL be reflected in the TS payloads.
Auth messages are sent after each side has both sent and received an
Init message and completed the key establishment phase of the IKEv3
protocol. While the peers have not yet authenticated each other,
they share a secret which can be used to secure the Auth messages.
This is accomplished by using the authenticated encryption mode that
was agreed-upon during the exchange of Init messages.
All the payloads of the Auth message are encrypted-- that is,
everything after the IKEv3 header to the end of the message. The
IKEv3 header, and the encrypted payloads are all authenticated.
When [RFC5297] is used for authenticated encryption the IKEv3 header
from the transmitter's SPI (inclusive) to the Length (inclusive) is
passed as associated data, and the data immediately following the
IKEv3 header, from the generic IKEv3 header of the first payload
(inclusive) to the end of the message is the data to encrypt. The
ICV/SIV field of the IKEv3 header is not included in the associated
data passed to AES-SIV.
The output of the [RFC5297] mode is ciphertext and a Synthetic
Initialization Vector (SIV). The SIV SHALL be copied into the IKEv3
header and the ciphertext is appended to the IKEv3 header to form the
complete Auth message.
6.1.2.2. Processing of Auth Messages
Auth messages are encrypted and authenticated so the first step in
processing is to verify their integrity and to decrypt them. When
[RFC5297] is used, the Synthetic Initialization Vector (SIV) is
copied from the ICV/SIV field in the IKEv3 header. The IKEv3 header
from the transmitter's SPI (inclusive) to the length (inclusive) is
passed, along with the SIV to AES-SIV. If AES-SIV outputs FAIL the
message is discarded and processing stops. If AES-SIV outputs
plaintext, the plaintext will be the sequence of payloads that
comprise the Auth message.
The first payload will be the Auth payload (AU). The contents of the
AU payload are determined by the authentication method agreed-upon
during the exchange of Init messages (see Section 5). The value of
the the Auth message from the point of view of the transmitter (i.e.
the peer) is calculated and compared to the value in the data portion
of the AU payload. If they differ, the peer fails authentication,
processing stops and a failure MUST be returned. If they are
identical processing continues.
Next the Address Indication payloads are checked. If the source
Harkins Expires October 14, 2013 [Page 19]
Internet-Draft IKEv3 April 2013
address or port of the received message differ from the address or
port in the source Address Indication payload, or if the destination
address or port of the received message differ from the address or
port in the destination Address Indication payload then a NAT is
detected. Othewise, a NAT is not detected.
The SA payload is next. The transforms in the SA payload are checked
to determine whether they are acceptable according to local policy.
If they are not the message is discarded and processing stops. If
they are, then there are three possibilities:
o An Auth message has not yet been sent to the peer, in which case
processing continues; or,
o An Auth message has been sent to the peer and the transforms are
identical to those sent, in which case processing continues; or,
o An Auth message has been sent to the peer and the transforms
differ from those sent. In this case, a test is made to see
which side's offer prevails. Each side has sent its IPsec SPI to
the other in the SA payload. If the low-order bit of those SPIs
are identical then the transmitter of the larger SPI prevails.
If the low-order bit of those SPIs differ then the transmitter of
the smaller SPI prevails. The transforms offered by the
prevailing party SHALL be adopted by the party which does not
prevail. Processing continues.
The Traffic Selectors in the TS payloads are next checked to
determine whether they are accptable according to local policy. If
the they are not acceptable, and no narrowing of the scope of the
traffic flows is possible-- i.e. no intersection between the TS
payloads and local policy-- the Auth message SHALL be discarded,
processing stops.
If the Traffic Selectors are completely satisfactory and require no
narrowing, then the Traffic Selectors are retained for creation of
IPsec SAs and construction of an Auth message (if one has not already
been sent).
If the Traffic Selectors are partially acceptable, and require
narrowing, then the union of the local policy describing the flow and
the Traffic Selectors describing the flow SHALL be retained for
creation of IPsec SAs and construction of an Auth message (if one has
not yet already been sent).
If an Auth message has not yet been sent, a locally-unique SPI SHALL
be created to identify the IPsec SA for received IPsec-protected
packets. This SPI MUST be retained for use when constructing the
Harkins Expires October 14, 2013 [Page 20]
Internet-Draft IKEv3 April 2013
Auth message response.
Upon completion of processing an Auth message, Two IPsec SAs MUST be
instantiated (e.g. plumbed into the kernel) with the indicated
transforms for the flow described in the (possibly narrowed) Traffic
Selectors, one in each direction. The locally-unique SPI becomes the
identifier to look up the SA for inbound IPsec packets and the peer's
SPI (from its SA payload) becomes the identifier to look up the SA
for outbound IPsec packets.
If a NAT was detected, the IPsec SAs MUST use UDP encapsulation for
IPsec (see [RFC3948]). Since both sides know the original addresses
and ports and the NATted addresses and ports, it is possible to
obtain the required information to perform the necessary
decapsulation procedures on received UDP-encapsulated IPsec packets.
6.2. IPsec Security Associations
The goal of the Internet Key Exchange is the creation of Security
Associations (SAs) for [RFC4301]. SAs are established using Security
Association (Section 6.4.12) and Traffic Selector (Section 6.4.11)
payloads to negotiate the flow(s) to protect and the means to go
about protecting it (them).
IKEv3 derives keys for IPsec SAs using the KDF (Section 4.4). The
key derivation key, dKEY, established in Section 5.3 is used as the
key and the label "IPsec Key Derivation" is used as the data:
key = KDF(dKEY, "IPsec Key Derivation")
The length of the key derived by KDF depends on the parameters of the
IPsec SA and the key lengths used by the underlying primitives. If
multiple, distinct, keying material is used-- for example, an ESP SA
that performs encryption and integrity protection separately-- the
key used for encryption MUST be taken from first and the key used for
integrity protection MUST be taken from the remaining bits.
6.3. State Machine
The IKEv3 protocol is managed by a parent process that receives
protocol events and IKEv3 packets and passes them on to instances of
the IKEv3 state machine.
The state machine for IKE defines the behavior of a single run of the
protocol. Each peer maintains a "protocol instance" for each remote
peer that it is actively performing the protocol with that defines
the current state of the protocol for that peer. The state machine
guarantees that both sides will complete the protocol with each side
Harkins Expires October 14, 2013 [Page 21]
Internet-Draft IKEv3 April 2013
installing IPsec Security Associations or each side will fail to
complete the protocol.
The state machine addresses the potential of dropped messages with a
retransmission timer. This memo does not specify a period that state
machines use when setting its retransmission timer.
6.3.1. Parent Process
The parent process of the IKEv3 state machine handles events from the
IPsec SADB (e.g. an "acquire" message to create an IPsec security
association) as well as receives incoming IKEv3 messages that it
dispatches to state machine instances.
The parent process is also responsible for creation of state machine
processes. The state of a state machine is stored in an IKEv3
security association so creation of a state machine process entails
creation of a nascent IKEv3 security association, generating a unique
and unpredictable local SPI, setting the peer address, and putting
the state machine in NOTHING state.
When the parent process receives an event from the IPsec SADB to
create an IPsec security association it first checks whether there is
an existing IKEv3 state machine process with the indicated peer. If
so, the parent process drops the event and waits for the process to
complete. If there is no existing state machine process, the parent
process creates a new state machine (see above) and sends the newly
created state machine process a START event.
When the parent process receives an IKEv3 packet from a remote peer
it first checks the receipient SPI field in the received packet.
If the recipient SPI field is all zeros, it indicates a peer that is
initiating. If the IKEv3 message is an Auth frame, it SHALL be
dropped as being meaningless (it is not possible to initiate IKEv3
with an Auth message). If the IKEv3 message is an Init message, the
parent process checks whether there is an existing IKEv3 state
machine process for the remote peer (the transmitter of the packet)
that is in Initiation State. If so, the received message is passed
to the state machine process with an INIT event. Otherwise, if there
is no existing IKEv3 state machine process in Initiation State, the
parent process creates an IKEv3 state machine process (see above) and
passes the received message and an INIT event to it.
If the receipient SPI field is not all zeros, the parent process uses
the recipient SPI to look up an existing IKEv3 process. If none
exists, the packet SHALL be dropped. If the parent process succeeds
in looking up an existing IKEv3 state machine process using the
Harkins Expires October 14, 2013 [Page 22]
Internet-Draft IKEv3 April 2013
recipient SPI, the message is passed to that state machine process
with the appropriate event-- an INIT event for an Init message and an
AUTH event for an Auth message.
6.3.2. Components of State Machine
The following states are part of the state machine:
- Nothing: a quiescent state in which nothing has happened
- Initiation: an Initiator has sent an Initiate message to a peer
- Reception: a Responder has sent an Initiate message to a peer
- Done: an Authenticate message has been sent to a peer
The following variables are used in the state machine:
- retrans: the number of retransmissions made (unsigned)
- thresh: the maximum nuber of retransmissions allowed (unsigned)
- committed: a counter on transmitted Auth messages (signed)
- reauth: a counter on received Auth messages (signed)
The following events are delivered to the state machine:
- START: an instruction to initiate IKE to a peer
- INIT: receipt of an Initiate message from a peer
- AUTH: receipt of an Authenticate message from a peer
- TM: expiry of the retransmission timer
The following actions are taken by the state machine:
- init: send an Initiate message to a peer
- auth: send an Authenticate message to a peer
The following timers are used by the state machine:
- tm: the retransmission timer
- fin: a deletion timer
Harkins Expires October 14, 2013 [Page 23]
Internet-Draft IKEv3 April 2013
6.3.3. States
The state machine for an IKEv3 process is show in Figure 3.
-----------
| Nothing |
-----------
/ \
START/init / \ INIT/init
/ \
/ \
___ / \ ___
/ \ V V / \ INIT/init
TM/init | \ ------------ ------------ / | TM/init
\ ----->| Initiation | | Reception | <----/
------------ ------------
| |
| INIT/auth* |
| TM/auth |
INIT/auth | ___ | AUTH/auth
\ / \ /
\ / \ /
\ | | / ____
V \ V V / \
-------------- / | AUTH/auth*
| Done | <------/
--------------
Figure 3: Protocol State Machine
6.3.3.1. Nothing State
Nothing state is the state in which an instance of the IKE state
machine has just been created and has not received any events or
performed any actions yet. Two events cause the state machine to
exit Nothing state: a START event, and an INIT event.
When a state machine instance in Nothing state receives a START event
the IKE peer initiates a connection to another peer. The information
the IKE peer obtains as part of the START event is implementation
specific but MUST idicate at a minimum the following:
o IP address of peer
o SPD information regarding the type of IPsec security association
to form.
Harkins Expires October 14, 2013 [Page 24]
Internet-Draft IKEv3 April 2013
The method in which policy information regarding the type of
authentication to propose, what group to use, etc., is out of scope
of this memo. This information MUST be obtained but whether it is
part of the START event indication or obtained as part of separate
IKE configuration is irrelevant to the protocol.
The peer derives a session identifier, or SPI, to use as its
transmitting SPI.
The peer retains the SPD information and SPI and constructs an Init
message according Section 6.1.1.1 and transmits the message to the IP
address of the peer. The state machine assigns the value zero (0) to
the retrans counter, to the committed counter, and to the reauth
counter. It sets the restransmission timer, and transitions to state
Initiation.
When a state machine instance in Nothing state receives an INIT
event, it signifies the reception of an Init message from a remote
peer. The instance retains the IP address of the peer, extracts the
transmitter's SPI from the message, and assigns the value zero (0) to
the retrans counter, the committed counter and the reauth counter.
It then processes the Init message according to Section 6.1.1.2. If
processing of the Init message is successful, the instance generates
an Init message for the peer according to Section 6.1.1.1, transmits
the message to the peer, sets the retransmission timer and
transitions to state Reception. If processing of the Init message is
unsuccessful, the protocol instance remains in Nothing state and all
state created as a result of receipt of the Init message MUST be
deleted.
Note: a protocol instance that transition from Nothing state to
Reception state has both received and sent an Initiate message. It
MAY choose to finish the key exchange protocol and generate shared
secret state according to the negotiated authentication method, or it
may choose to delay such compuation until it receives an AUTH event
in Reception state.
6.3.3.2. Initiation State
In Initiation state a protocol instance has initiated the IKE
protocol to a peer. An INIT event causes the instance to leave
Initiation state, and a TM event causes it to remain in Initiation
state.
When a protocol instance in Initiation state receives an INIT event,
it signifies receipt of an Initiate message from the peer. The
protocol instance first cancels the retransmission timer and then
processes the Init message according to Section 6.1.1.2. If
Harkins Expires October 14, 2013 [Page 25]
Internet-Draft IKEv3 April 2013
processing indicates that the message was discarded, the protocol
instance sets the TM timer and remains in Initiation state. If
processing indicates a failure, the protocol instance deletes all
state it has created or retained and transitions back to Nothing
state. Otherwise, processing is successful and the protocol instance
shall finish the key exchange protocol and generate shared secret
state according to the negotiated authentication method. It then
increments the committed counter and generates an Auth message for
the peer according to Section 6.1.2.1, transmits the message to the
peer, sets the retransmission timer and transitions to state Done.
When a protocol instance in Initiation state receives a TM event it
indicates that the retransmission timer has expired. If the retrans
counter is higher than the retransmission threshold it indicates
failure of the protocol. In this case the protocol instance deletes
all state it has created or retained and transitions back to Nothing
state. If the retrans counter is not greater than the retransmission
threshhold, the Init message that was transmitted to the peer as part
of transitioning into Initiation state is sent again to the peer, the
retrans counter is incremented and the protocol instance remains in
Initiation state.
6.3.3.3. Reception State
In Reception state a protocol instance is acting as the traditional
"responder" in the IKE protocol. It has both sent and received an
Init message. An AUTH event causes the instance to leave Reception
state, and both an INIT and a TM event cause it to remain in
Reception state.
When a protocol instance in Reception state receives an INIT event it
signifies that the Init message it sent in order to transition into
Reception state was not received by the peer. When it receives a TM
event it indicates that its retransmission timer has expired. For an
INIT event, the protocol instance first cancels the retransmission
timer, after that the behavior a protocol instance takes is the same
for an INIT or TM event. The instance retransmits the Init message
it sent to the peer in order to transition in to Reception state, it
sets its retransmission timer, and it remains in Reception state.
When a protocol instance in Reception state receives an AUTH event it
signifies reception of an Auth message from its peer. First the
protocol instance cancels its retransmission timer. Next, if the
protocol instance has not finished the key exchange protocol (see the
note in Section 6.3.3.1) and generated a shared secret it does so
here. It then sets the reauth counter to the value of the
"committed" field in the processed Auth messages, sets its committed
counter to negative one (-1), generates an Auth message for the peer
Harkins Expires October 14, 2013 [Page 26]
Internet-Draft IKEv3 April 2013
according to Section 6.1.2.1, transmits the message to the peer,
installs the IPsec SAs (per Section 6.2) and transitions to Done
state. Note that the retransmission timer is not set.
6.3.3.4. Done State
Done state is the final state of the state machine. An initiator
arrives in Done state after it has sent both of its messages to the
peer and awaits a final Auth message. A responder arrives in Done
state after it has sent and received both messages. To address the
possibility of dropped packets and retransmission there are several
events that can happen in Done state. Regardless of the event,
though, after a state machine enters Done state it never leaves Done
state.
When a protocol in Done state receives an INIT event, it signfies the
receipt of a retransmitted Init message. Since the protocol has
entered Done state it has already received and processed an Init
message. If its committed counter is less than zero the protocol
instance drops the Init message and remains in Done state. If its
committed counter is not less than zero it cancels its retransmission
timer, increments the committed counter, generates an Auth message,
transmits the Auth message to the peer, sets its retransmission
timer, and remains in Done state.
When a protocol in Done state receives a TM event, it signiifies that
a previously sent Auth message has not been replied to in a timely
manner. In this case, the protocol instance, checks the
retransmission counter. If it is greater than the thresh counter the
protocol instance destroys all state associated with the current run
of the protocol (including any IPsec SAs that it might have
installed) and transitions back to Nothing state. If the
retransmission counter is not greater than the thresh counter, the
protocol instance increments the retransmission counter, increments
the committed counter, generates an Auth message, transmits the Auth
message to the peer, sets the retransmission counter, and remains in
Done state.
When a protocol instance in Done state receives an AUTH event it
signifies the receipt of an Auth message from the peer. This could
be in response to a message from the protocol instance or it could be
a retransmission or the replay of an old Auth message. To prevent a
storm of Auth messages going back and forth between protocol
instances in Done state, the response to an AUTH message is
conditional. If the committed counter is less than zero the protocol
instance drops the received Auth message and remains in Done state.
If the committed counter is not less than zero, the protocol instance
cancels its retransmission timer and processes the Auth message. If
Harkins Expires October 14, 2013 [Page 27]
Internet-Draft IKEv3 April 2013
processing of the Auth message fails the protocol instance sets the
retransmission timer and remains in Done state. If processing of the
Auth message succeeds, the value of the "committed" field in the
received Auth message is checked. If it is not numerically greater
than the reauth counter the message is dropped, the retransmission
timer is set, and the protocol instance remains in Done state. If
the "committed" field in the received Auth message is numerically
greater than the reauth counter, the reauth counter is set to the
value in the "committed" field, the committed counter is set to
negative one (-1), and an Auth message is generated. The protocol
instance then sends the Auth message to the peer, and installs the
IPsec SAs (per Section 6.2) and remains in Done state. Note that the
retransmission timer is not set.
6.3.4. Cleaning Up Protocol Instances
The state machine ensures that once each side has sent and received
an Auth message it installs IPsec SAs. To handle potential lost
messages and retransmissions of its final Auth message a protocol
instance remains in for a period of time after it has installed its
IPsec SAs. These stale protocol instances can have their state
deleted and transitioned back to Nothing state after a sufficient
period of time. This memo does not define what "sufficient" means
but suggests that after installing IPsec SAs, a protocol instance
waits at least the amount of time it would spend before
retranmissions would cause it to expire. That is:
wait = (thresh - retrans) * retrans-period
where "retrans-period" is the amount of time that the retransmission
timer is set for. This will ensure that either the protocol instance
expires because it retransmitted too many times or it will expire
because the protocol has naturally completed.
6.4. IKEv3 Payload Formats
All messages in the IKEv3 protocol consist of an IKE header followed
by additional payloads which define the semantics of the message.
All payloads contain the same generic header. The IKE header
indicates the first payload that follows and the generic header of
each payload indicates the payload, if any, that follows. In this
fashion payloads are chained together to form messages.
6.4.1. IKE header
The IKE header contains two message identifiers, called Security
Parameter Indicies (SPIs), one for the transmitter and one for the
receiver, an indicator of the first payload of the message,
Harkins Expires October 14, 2013 [Page 28]
Internet-Draft IKEv3 April 2013
versioning information, and the type of message, either an Init or an
Auth. The format of the IKE header is shown in Figure 4.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE SA Transmitter's SPI |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE SA Receivers's SPI |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Payload | MjVer | MnVer | Message Type | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ICV/SIV ~
~ (presence conditional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IKE Header Format
o Transmitter's SPI (8 octets) - A session identifier chosen by the
transmitter of the message.
o Receiver's SPI (8 octets) - A session identifier chosen by the
receiver of the message.
o First Payload (1 octet) - The type of payload that follows the
header. See Figure 6.
o Major Version (4 bits) - The major version of this version of
IKE. Implementations based on this memo MUST set the major
version to three (3). Reciept of an IKE message with a different
Major Version is governed by the memo which defines the version.
An implementation that is only compliant with this version of IKE
MUST drop any message with a Major version other than three (3).
o Minor Version (4 bits) - The minor version of this version of
IKE. Implementations based on this memo MUST set the minor
version to zero (0) on transmitted messages and ignore the Minor
Version on received messages.
o Message Type (1 octet) - The type of message being transmitted:
an Init message is type one (1) and an Auth message is type (2).
Harkins Expires October 14, 2013 [Page 29]
Internet-Draft IKEv3 April 2013
o Flags (1 octet) - A bitmask that indicates specific options for
the message. The bits in this bitmask are as follows:
+-+-+-+-+-+-+-+-+
|X|X|X|V|X|X|X|S|
+-+-+-+-+-+-+-+-+
Bits indicated as 'X' MUST be cleared on transmission and ignored
on reception. Setting a bit to one (1) indicates that the option
applies and clearing the bit to zero (0) indicates the option
does not apply.
* V (Version) - This bit indicates that the transmitter is
capable of speaking a higher major version number of the IKE
protocol than the one indicated in the major version field of
this header.
* S (Secured) - This bit indicates that the message following
this header is authenticated and encrypted. When this bit is
set the ICV/SIV field in the header is present.
o Length (4 octets) - an unsigned integer that indicates the length
of the total IKE message (IKE header + all payloads) in octets.
Note: if the 'E' bit in the Flags is set this length includes the
conditional field to hold the Synthetic Initialization Vector/
MAC.
o ICV/SIV (variable) - a conditional field that is present when the
message following the header is secured. This field is the
byproduct of authenticated encryption and is required for
verified decryption. The exact format of the ICV/SIV field
depends on the type of authenticated encryption used by the
peers.
6.4.2. Generic IKE payload header
The Generic IKE payload header is used to demark and chain all
payloads in a message. Each payload used in a message contains this
header. The Generic IKE payload header is defined in Figure 5.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IKE Header Format
Harkins Expires October 14, 2013 [Page 30]
Internet-Draft IKEv3 April 2013
o Next Payload (1 octet) - Indicates the payload, if any, that
follows the current payload. See Figure 6.
o RESERVED (1 octet) - Unused by this version of IKE. It MUST be
set to zero on all payloads in a transmitted message and ignored
on all payloads in a received message.
o Payload Length (2 octets) - An unsigned integer indicating the
entire length of the current payload, including this generic
header.
Subsequently defined payloads are all shown with the generic header
for completeness. Payload types listed here are current as of
publication of this memo. Readers are encouraged to see [IKEV3IANA]
for the latest values.
Payload Type Notation Value
------------------------------------------------------------
No Next Payload 0
IKE Attributes Payload IA 1
Identity Payload ID 2
Nonce Payload NO 3
Key Exchange Payload KE 4
Certificate Request Payload CR 5
Certificate Payload CE 6
Authentication Payload AU 7
Address Indication AI 8
Traffic Selector TS 9
Security Assocation Payload SA 10
Vendor Indication VE 11
Figure 6: IKEv3 Payload Assignment
The value "No Next Payload" SHALL only be used in the last payload of
a message.
6.4.3. IKE Attributes payload
The IKE attributes payload lists a number of attributes that define
the manner in which a run of the IKEv3 protocol occurs. Attributes
consist of type-value tuples to identify the type of attribute and
its particular value. These attributes are offered, not negotiated.
See Section 6.1.1.2 for a description of the processing and potential
rejection of an IA offer. The IA payload is defined in Figure 7.
Harkins Expires October 14, 2013 [Page 31]
Internet-Draft IKEv3 April 2013
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Number 1 Type | Attribute Number 1 Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . . ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Number N Type | Attribute Number N Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: IA Payload
The following attributes types are defined and are indicated by
assigning the indicated number to the Attributes Number <X> Type
field:
1. Authentication Method
2. Authenticated Encryption Mode
3. Hash Algorithm
4. Diffie-Hellman Group
All other values are reserved to IANA.
When the Attribute Type indicates "Authentication Method", the
following values are defined:
1. Digital Signatures
2. Pre-shared Key
All other values are reserved to IANA.
When the Attribute Type indicates "Authentication Encryption Mode",
the following values are defined:
1. AES in Synthetic Initialization Mode ([RFC5297]) with a 256-bit
key
2. AES in Synthetic Initialization Mode ([RFC5297]) with a 512-bit
key
All other values are reserved to IANA.
Harkins Expires October 14, 2013 [Page 32]
Internet-Draft IKEv3 April 2013
When the Attribute Type indicates "Hash Algorithm, the following
values are defined:
1. SHA-256 ([RFC4634])
2. SHA-512 ([RFC4634])
All other values are reserved to IANA.
When the Attribute Type indicates "Diffie-Hellman Group", the
attribute values are taken from the "Diffie-Hellman Group Transform
IDs" from [IKEV2IANA].
6.4.4. Identity Payload
The ID payload is used to convey the identity that is to be
authenticated by the remote peer.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Type | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Identification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: ID Payload
The following ID Types are defined:
ID Type Value Description
------- -------------- ----------------------------------------------
1 ID_IPV4_ADDR A single four (4) octet IPv4 address
2 ID_FQDN A fully-qualified domain name string. An
ID_FQDN string MUST NOT contain any
terminators (e.g. NULL, CR, etc.). All
characters in the ID_FQDN are ASCII.
3 ID_RFC822_ADDR A fully-qualified RFC 822 email address
string. An ID_RFC822_ADDR string MUST NOT
contain any terminators (e.g. NULL, CR,
etc.). This field SHOULD be treated as UTF-8
encoded text.
4 ID_IPV6_ADDR A single sixteen (16) octet IPv6 address
Harkins Expires October 14, 2013 [Page 33]
Internet-Draft IKEv3 April 2013
5 ID_DER_ASN1_DN The binary Distinguished Encoding Rules (DER)
encoding of an ASN.1 X.500 Distinguished Name.
See [RFC5280].
6 ID_DER_ASN1_GN The binary DER encoding of an ASN.1 X.500
GeneralName. See [RFC5280].
7 ID_BLOB_ID An opaque octet stream used for identity
obfuscation. The two parties to the exchange
MUST agree in an out-of-band fashion on how to
map a Blob ID to an unobfuscated identity.
Table 1
Identification Data is a variable-length field that contains the
identity of the specified type.
6.4.5. Nonce Payload
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Nonce of the transmitter ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: NO Payload
6.4.6. Key Exchange Payload
The KE payload is used to pass data used to perform the key exchange
portion of the IKEv3 protocol (see Section 5). The body of the KE
payload is authentication method specific. When doing The KE payload
is authentication method specific. authentication using digital
signatures, the body of the KE payload is a Diffie-Hellman public
value. When doing PSK authentication, the body of the KE payload is
a concatentation of the Commit and Confirm portions of the Dragonfly
key exchange.
Harkins Expires October 14, 2013 [Page 34]
Internet-Draft IKEv3 April 2013
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key exchange data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: KE Payload
The key exhange data is a variable-length field that contains data to
be transmitted to the remote peer to perform a cryptographic key
exchange.
6.4.7. Certificate Payload
The CE payload is used to convey a public key which will be used for
authentication to a remote peer. The public key can be certified or
raw.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Type | |
+-+-+-+-+-+-+-+-+ |
~ (Cerfified) Public Key Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: CE Payload
Encoding Description
-------- ------------------------------------------------------------
1 A DER-enocded X.509 certificate
2 Subject public key info for a raw key encoded according to
[RFC5480]
3 Subject public key info for a raw key encoded accoding to
[RFC3279]
Table 2
The Public key data is a variable-length field that contains the
public key of the specified encoding.
Harkins Expires October 14, 2013 [Page 35]
Internet-Draft IKEv3 April 2013
6.4.8. Certificate Request Payload
The CR payload is used to request a certificate from a remote peer.
The transmitter indicates a preference for the type of certificate
using by setting the Encoding type according to Table 2. The
transmitter SHOULD indicate a trusted Certification Authority for
certified pubilc keys.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Type | |
+-+-+-+-+-+-+-+-+ |
~ Certification Authority ~
~ (optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: CR Payload
The Certificate Authority field, when present, is a variable-length
field that contains the DER encoding of an ASN.1 X.509 IssuerName.
6.4.9. Authentication Payload
The AU payload contains data that authenticates a remote peer. The
content of the body of an AU payload is either a digital signature
(see Section 5.1.2) when authenticating with digital signatures, or a
keyed message authentication function using the negotiated hash
algorithm (see Section 5.2.4) when authenticating with a PSK.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Sig or MAC ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: AU Payload
Sig or MAC is a variable-length field that contains either a digital
signature of a message authentication code.
Harkins Expires October 14, 2013 [Page 36]
Internet-Draft IKEv3 April 2013
6.4.10. Address Indication Payload
The AI payload is used to convey the local view of addressing and
port selection to the remote peer for the purposes of NAT detection.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: AI Payload
Address Types have the following meaning:
Address Type Description
-------------- ------------------------------------------------------
1 The Address field is a single four (4) octet IPv4
address
2 The Address field is a single sixteeen (16) octet IPv6
address
Table 3
All other Address Types are reserved and MUST NOT be used.
6.4.11. Traffic Selecor Payload
The TS payload is used to convey a set of traffic selectors used to
identify traffic flows for processing by IPsec security services.
Harkins Expires October 14, 2013 [Page 37]
Internet-Draft IKEv3 April 2013
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of Tr Sels | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Sequence of one or more ~
~ Traffic Selectors ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: TS Payload
The traffic selectors conveyed to a peer are determined by the local
Security Policy Database (see [RFC4301]). They define the data that
MUST be protected by IPsec by individual flow. Each Traffic Selector
in the set is defined by the following structure:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Selector Type | IP Protocol ID| Traffic Selector Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Port | End Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Starting Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Ending Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Traffic Selector
o Select Type (one octet) - either a one (1) to indicate an
IPV4_ADDR_RANGE or two (2) to indicate an IPV6_ADDR_RANGE. All
other types are invalid and MUST be rejected.
o IP Protocol ID (one octet) - indicates the associated IP protocol
(such as UDP, TCP, and ICMP). A value of zero (0) means that the
traffic selector convers all protocols.
o Traffic Selector Length (two octets) - the total length of the
selector, including this sub header.
Harkins Expires October 14, 2013 [Page 38]
Internet-Draft IKEv3 April 2013
o Start Port (two octets) - the lowest port in a range of ports
that are covered by this traffic selector. A value of zero (0)
means that the traffic selector covers all ports. ICMP and
ICMPv6 Type and Code values, as well as Mobile IP version 6
(MIPv6) mobility header (MH) Type values, are represented
according to Section 4.4.1.1 of [RFC4301]. ICMP Type and Code
values are treated as a single 16-bit integer port number, with
Type in the most significant 8 bits and Code in the least
significant 8 bits. MIPv6 MH Type and Code values are treated as
a single 16-bit integer port number with Type in the most
significant 8 bits and the least signficant 8 bits set to zero.
o End Port (two octets) - the highest port in a range of ports that
are covered by this traffic selector. For protocols for which
port is undefined (including protocol 0), or if all ports are
allowed, this field MUST be 65535. ICMP and ICMPv6 Type and COde
values, as well as MIPv6 MH Type values, are represented in this
field as specified in Section 4.4.1.1 of [RFC4301]. ICMP Type
and COde values are treated as a single 16-bit port number with
Type in the most significant 8 bits and Code in the least
significant 8 bits. MIPv6 MH Type values are treated as a single
16-bit integer port number with Type in the most significant 8
bit and the least significant 8 bits set to zero.
o Starting Address (variable) - the lowest address in a range of
addresses that are covered by this traffic selector. This field
will be either sixteen (16) octets or four (4) octets depending
on whether the Selector Type was IPV6_ADDR_RANGE or
IPV4_ADDR_RANGE, respectively.
o Ending Address (variable) - the highest address in a range of
addresses that are covered by this traffic selector. This field
will be either sixteen (16) octets or four (4) octets depending
on whether the Selector Type was IPV6_ADDR_RANGE or
IPV4_ADDR_RANGE, respectively.
6.4.12. Security Association Payload
The SA payload indicates the type of protection that IPsec will apply
to the data that is covered by the Traffic Selector(s) in the TS
payload. Protection is described as a number of attributes with each
attribute consisting of a type-value tuple to identify the type of
attribute and its particular value.
Harkins Expires October 14, 2013 [Page 39]
Internet-Draft IKEv3 April 2013
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Number 1 Type | Attribute Number 1 Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . . ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Number N Type | Attribute Number N Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: SA Payload
SPI (4 octets) - the Security Parameter Index that the transmitter of
the SA payload will use to identify the resulting security
association for received IPsec-protected packets.
The following attribute types are defined:
1. Encryption Algorithm
2. Integrity Algorithm
3. Extended Sequence Numbers
If the Encryption Algorithm attribute is present in an SA payload the
SA SHALL be for ESP. If it is absent the SA SHALL be for AH. The
Integrity Algorithm attribute is OPTIONAL for ESP and MANDATORY for
AH. The Extended Sequence Number attribute is OPTIONAL.
The attribute values for the Encryption Algorithm attribute are
defined in [IKEV2IANA] in the "Encryption Algorithm Transform IDs"
table. The attribute values for the Integrity Algorithm attribute
are defined in [IKEV2IANA] in the "Integrity Algorithm Transform IDs"
table. The attribute values for the Extended Sequence Numbers
attribute are defined in [IKEV2IANA] in the "Extended Sequence
Numbers Transform IDs".
6.4.13. Vendor Indication Payload
The VI payload allows vendors of IKEv3 products to identify each
other during the protocol.
Harkins Expires October 14, 2013 [Page 40]
Internet-Draft IKEv3 April 2013
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Vendor Identifying Blob ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: VI Payload
The Vendor Identifying Blob is a variable length field that contains
information to identify the vendor of the transmitter of the payload.
No registry for vendor identification is used and it is advised that
vendors produce an opaque blob that will be different for each run of
the protocol to identify themselves. This can be accomplished, for
instance, by hashing the transmitter and receiver SPIs and/or the IP
addresses of the peers with a vendor-specific constant.
7. Acknowledgements
Portions of the payload descriptions (e.g. Traffic Selector payload)
were lifted from [RFC5996]. The author thanks the editors of that
document and the IPsecME Working Group that produced that document.
8. IANA Considerations
This section is incomplete.
9. Security Considerations
This section is incomplete.
10. References
10.1. Normative References
[IKEV2IANA]
"Internet Key Exchange Version 2 (IKEv2) Parameters",
<http://www.iana.org>.
[IKEV3IANA]
"Internet Key Exchange Version 3 (IKEv3) Parameters",
Harkins Expires October 14, 2013 [Page 41]
Internet-Draft IKEv3 April 2013
<http://www.iana.org>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, April 2002.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV)
Authenticated Encryption Using the Advanced Encryption
Standard (AES)", RFC 5297, October 2008.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, March 2009.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, February 2011.
10.2. Informative References
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
Harkins Expires October 14, 2013 [Page 42]
Internet-Draft IKEv3 April 2013
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
Author's Address
Dan Harkins (editor)
Aruba Networks
1322 Crossman avenue
Sunnyvale, Californaia 94089
United States of America
Phone: +1 408 227 4500
Email: dharkins@arubanetworks.com
Harkins Expires October 14, 2013 [Page 43]
