[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
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]