tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4306

 
 
 

Internet Key Exchange (IKEv2) Protocol

Part 3 of 5, p. 41 to 64
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 41 
3.  Header and Payload Formats

3.1.  The IKE Header

   IKE messages use UDP ports 500 and/or 4500, with one IKE message per
   UDP datagram.  Information from the beginning of the packet through
   the UDP header is largely ignored except that the IP addresses and
   UDP ports from the headers are reversed and used for return packets.
   When sent on UDP port 500, IKE messages begin immediately following
   the UDP header.  When sent on UDP port 4500, IKE messages have
   prepended four octets of zero.  These four octets of zero are not
   part of the IKE message and are not included in any of the length
   fields or checksums defined by IKE.  Each IKE message begins with the
   IKE header, denoted HDR in this memo.  Following the header are one
   or more IKE payloads each identified by a "Next Payload" field in the
   preceding payload.  Payloads are processed in the order in which they
   appear in an IKE message by invoking the appropriate processing
   routine according to the "Next Payload" field in the IKE header and
   subsequently according to the "Next Payload" field in the IKE payload
   itself until a "Next Payload" field of zero indicates that no
   payloads follow.  If a payload of type "Encrypted" is found, that
   payload is decrypted and its contents parsed as additional payloads.
   An Encrypted payload MUST be the last payload in a packet and an
   Encrypted payload MUST NOT contain another Encrypted payload.

   The Recipient SPI in the header identifies an instance of an IKE
   security association.  It is therefore possible for a single instance
   of IKE to multiplex distinct sessions with multiple peers.

   All multi-octet fields representing integers are laid out in big
   endian order (aka most significant byte first, or network byte
   order).

   The format of the IKE header is shown in Figure 4.

Top      Up      ToC       Page 42 
                           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 Initiator's SPI                  !
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                       IKE_SA Responder's SPI                  !
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !  Next Payload ! MjVer ! MnVer ! Exchange Type !     Flags     !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                          Message ID                           !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                            Length                             !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 4:  IKE Header Format

      o  Initiator's SPI (8 octets) - A value chosen by the
         initiator to identify a unique IKE security association.  This
         value MUST NOT be zero.

      o  Responder's SPI (8 octets) - A value chosen by the
         responder to identify a unique IKE security association.  This
         value MUST be zero in the first message of an IKE Initial
         Exchange (including repeats of that message including a
         cookie) and MUST NOT be zero in any other message.

      o  Next Payload (1 octet) - Indicates the type of payload that
         immediately follows the header.  The format and value of each
         payload are defined below.

      o  Major Version (4 bits) - Indicates the major version of the IKE
         protocol in use.  Implementations based on this version of IKE
         MUST set the Major Version to 2.  Implementations based on
         previous versions of IKE and ISAKMP MUST set the Major Version
         to 1.  Implementations based on this version of IKE MUST reject
         or ignore messages containing a version number greater than
         2.

      o  Minor Version (4 bits) - Indicates the minor version of the
         IKE protocol in use.  Implementations based on this version of
         IKE MUST set the Minor Version to 0.  They MUST ignore the
         minor version number of received messages.

      o  Exchange Type (1 octet) - Indicates the type of exchange being
         used.  This constrains the payloads sent in each message and
         orderings of messages in an exchange.

Top      Up      ToC       Page 43 
                       Exchange Type            Value

                       RESERVED                 0-33
                       IKE_SA_INIT              34
                       IKE_AUTH                 35
                       CREATE_CHILD_SA          36
                       INFORMATIONAL            37
                       RESERVED TO IANA         38-239
                       Reserved for private use 240-255

      o  Flags (1 octet) - Indicates specific options that are set
         for the message.  Presence of options are indicated by the
         appropriate bit in the flags field being set.  The bits are
         defined LSB first, so bit 0 would be the least significant
         bit of the Flags octet.  In the description below, a bit
         being 'set' means its value is '1', while 'cleared' means
         its value is '0'.

       --  X(reserved) (bits 0-2) - These bits MUST be cleared
           when sending and MUST be ignored on receipt.

       --  I(nitiator) (bit 3 of Flags) - This bit MUST be set in
           messages sent by the original initiator of the IKE_SA
           and MUST be cleared in messages sent by the original
           responder.  It is used by the recipient to determine
           which eight octets of the SPI were generated by the
           recipient.

       --  V(ersion) (bit 4 of Flags) - This bit indicates that
           the transmitter is capable of speaking a higher major
           version number of the protocol than the one indicated
           in the major version number field.  Implementations of
           IKEv2 must clear this bit when sending and MUST ignore
           it in incoming messages.

       --  R(esponse) (bit 5 of Flags) - This bit indicates that
           this message is a response to a message containing
           the same message ID.  This bit MUST be cleared in all
           request messages and MUST be set in all responses.
           An IKE endpoint MUST NOT generate a response to a
           message that is marked as being a response.

       --  X(reserved) (bits 6-7 of Flags) - These bits MUST be
           cleared when sending and MUST be ignored on receipt.

Top      Up      ToC       Page 44 
      o  Message ID (4 octets) - Message identifier used to control
      retransmission of lost packets and matching of requests and
      responses.  It is essential to the security of the protocol
      because it is used to prevent message replay attacks.
      See sections 2.1 and 2.2.

      o  Length (4 octets) - Length of total message (header + payloads)
      in octets.

3.2.  Generic Payload Header

   Each IKE payload defined in sections 3.3 through 3.16 begins with a
   generic payload header, shown in Figure 5.  Figures for each payload
   below will include the generic payload header, but for brevity the
   description of each field will be omitted.

                           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  !C!  RESERVED   !         Payload Length        !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 5:  Generic Payload Header

   The Generic Payload Header fields are defined as follows:

   o  Next Payload (1 octet) - Identifier for the payload type of the
      next payload in the message.  If the current payload is the last
      in the message, then this field will be 0.  This field provides a
      "chaining" capability whereby additional payloads can be added to
      a message by appending it to the end of the message and setting
      the "Next Payload" field of the preceding payload to indicate the
      new payload's type.  An Encrypted payload, which must always be
      the last payload of a message, is an exception.  It contains data
      structures in the format of additional payloads.  In the header of
      an Encrypted payload, the Next Payload field is set to the payload
      type of the first contained payload (instead of 0).

      Payload Type Values

          Next Payload Type               Notation  Value

          No Next Payload                              0

          RESERVED                                   1-32
          Security Association             SA         33
          Key Exchange                     KE         34
          Identification - Initiator       IDi        35

Top      Up      ToC       Page 45 
          Identification - Responder       IDr        36
          Certificate                      CERT       37
          Certificate Request              CERTREQ    38
          Authentication                   AUTH       39
          Nonce                            Ni, Nr     40
          Notify                           N          41
          Delete                           D          42
          Vendor ID                        V          43
          Traffic Selector - Initiator     TSi        44
          Traffic Selector - Responder     TSr        45
          Encrypted                        E          46
          Configuration                    CP         47
          Extensible Authentication        EAP        48
          RESERVED TO IANA                          49-127
          PRIVATE USE                              128-255

      Payload type values 1-32 should not be used so that there is no
      overlap with the code assignments for IKEv1.  Payload type values
      49-127 are reserved to IANA for future assignment in IKEv2 (see
      section 6).  Payload type values 128-255 are for private use among
      mutually consenting parties.

   o  Critical (1 bit) - MUST be set to zero if the sender wants the
      recipient to skip this payload if it does not understand the
      payload type code in the Next Payload field of the previous
      payload.  MUST be set to one if the sender wants the recipient to
      reject this entire message if it does not understand the payload
      type.  MUST be ignored by the recipient if the recipient
      understands the payload type code.  MUST be set to zero for
      payload types defined in this document.  Note that the critical
      bit applies to the current payload rather than the "next" payload
      whose type code appears in the first octet.  The reasoning behind
      not setting the critical bit for payloads defined in this document
      is that all implementations MUST understand all payload types
      defined in this document and therefore must ignore the Critical
      bit's value.  Skipped payloads are expected to have valid Next
      Payload and Payload Length fields.

   o  RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on
      receipt.

   o  Payload Length (2 octets) - Length in octets of the current
      payload, including the generic payload header.

Top      Up      ToC       Page 46 
3.3.  Security Association Payload

   The Security Association Payload, denoted SA in this memo, is used to
   negotiate attributes of a security association.  Assembly of Security
   Association Payloads requires great peace of mind.  An SA payload MAY
   contain multiple proposals.  If there is more than one, they MUST be
   ordered from most preferred to least preferred.  Each proposal may
   contain multiple IPsec protocols (where a protocol is IKE, ESP, or
   AH), each protocol MAY contain multiple transforms, and each
   transform MAY contain multiple attributes.  When parsing an SA, an
   implementation MUST check that the total Payload Length is consistent
   with the payload's internal lengths and counts.  Proposals,
   Transforms, and Attributes each have their own variable length
   encodings.  They are nested such that the Payload Length of an SA
   includes the combined contents of the SA, Proposal, Transform, and
   Attribute information.  The length of a Proposal includes the lengths
   of all Transforms and Attributes it contains.  The length of a
   Transform includes the lengths of all Attributes it contains.

   The syntax of Security Associations, Proposals, Transforms, and
   Attributes is based on ISAKMP; however, the semantics are somewhat
   different.  The reason for the complexity and the hierarchy is to
   allow for multiple possible combinations of algorithms to be encoded
   in a single SA.  Sometimes there is a choice of multiple algorithms,
   whereas other times there is a combination of algorithms.  For
   example, an initiator might want to propose using (AH w/MD5 and ESP
   w/3DES) OR (ESP w/MD5 and 3DES).

   One of the reasons the semantics of the SA payload has changed from
   ISAKMP and IKEv1 is to make the encodings more compact in common
   cases.

   The Proposal structure contains within it a Proposal # and an IPsec
   protocol ID.  Each structure MUST have the same Proposal # as the
   previous one or be one (1) greater.  The first Proposal MUST have a
   Proposal # of one (1).  If two successive structures have the same
   Proposal number, it means that the proposal consists of the first
   structure AND the second.  So a proposal of AH AND ESP would have two
   proposal structures, one for AH and one for ESP and both would have
   Proposal #1.  A proposal of AH OR ESP would have two proposal
   structures, one for AH with Proposal #1 and one for ESP with Proposal
   #2.

   Each Proposal/Protocol structure is followed by one or more transform
   structures.  The number of different transforms is generally
   determined by the Protocol.  AH generally has a single transform: an
   integrity check algorithm.  ESP generally has two: an encryption
   algorithm and an integrity check algorithm.  IKE generally has four

Top      Up      ToC       Page 47 
   transforms: a Diffie-Hellman group, an integrity check algorithm, a
   prf algorithm, and an encryption algorithm.  If an algorithm that
   combines encryption and integrity protection is proposed, it MUST be
   proposed as an encryption algorithm and an integrity protection
   algorithm MUST NOT be proposed.  For each Protocol, the set of
   permissible transforms is assigned transform ID numbers, which appear
   in the header of each transform.

   If there are multiple transforms with the same Transform Type, the
   proposal is an OR of those transforms.  If there are multiple
   Transforms with different Transform Types, the proposal is an AND of
   the different groups.  For example, to propose ESP with (3DES or
   IDEA) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two
   Transform Type 1 candidates (one for 3DES and one for IDEA) and two
   Transform Type 2 candidates (one for HMAC_MD5 and one for HMAC_SHA).
   This effectively proposes four combinations of algorithms.  If the
   initiator wanted to propose only a subset of those, for example (3DES
   and HMAC_MD5) or (IDEA and HMAC_SHA), there is no way to encode that
   as multiple transforms within a single Proposal.  Instead, the
   initiator would have to construct two different Proposals, each with
   two transforms.

   A given transform MAY have one or more Attributes.  Attributes are
   necessary when the transform can be used in more than one way, as
   when an encryption algorithm has a variable key size.  The transform
   would specify the algorithm and the attribute would specify the key
   size.  Most transforms do not have attributes.  A transform MUST NOT
   have multiple attributes of the same type.  To propose alternate
   values for an attribute (for example, multiple key sizes for the AES
   encryption algorithm), and implementation MUST include multiple
   Transforms with the same Transform Type each with a single Attribute.

   Note that the semantics of Transforms and Attributes are quite
   different from those in IKEv1.  In IKEv1, a single Transform carried
   multiple algorithms for a protocol with one carried in the Transform
   and the others carried in the Attributes.

                           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  !C!  RESERVED   !         Payload Length        !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                                                               !
      ~                          <Proposals>                          ~
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 6:  Security Association Payload

Top      Up      ToC       Page 48 
      o  Proposals (variable) - One or more proposal substructures.

      The payload type for the Security Association Payload is thirty
      three (33).

3.3.1.  Proposal Substructure

                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! 0 (last) or 2 !   RESERVED    !         Proposal Length       !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! Proposal #    !  Protocol ID  !    SPI Size   !# of Transforms!
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                        SPI (variable)                         ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                                                               !
      ~                        <Transforms>                           ~
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 7:  Proposal Substructure

      o  0 (last) or 2 (more) (1 octet) - Specifies whether this is the
         last Proposal Substructure in the SA.  This syntax is inherited
         from ISAKMP, but is unnecessary because the last Proposal could
         be identified from the length of the SA.  The value (2)
         corresponds to a Payload Type of Proposal in IKEv1, and the
         first 4 octets of the Proposal structure are designed to look
         somewhat like the header of a Payload.

      o  RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on
         receipt.

      o  Proposal Length (2 octets) - Length of this proposal, including
         all transforms and attributes that follow.

      o  Proposal # (1 octet) - When a proposal is made, the first
         proposal in an SA payload MUST be #1, and subsequent proposals
         MUST either be the same as the previous proposal (indicating an
         AND of the two proposals) or one more than the previous
         proposal (indicating an OR of the two proposals).  When a
         proposal is accepted, all of the proposal numbers in the SA
         payload MUST be the same and MUST match the number on the
         proposal sent that was accepted.

Top      Up      ToC       Page 49 
      o  Protocol ID (1 octet) - Specifies the IPsec protocol identifier
         for the current negotiation.  The defined values are:

          Protocol               Protocol ID
          RESERVED                0
          IKE                     1
          AH                      2
          ESP                     3
          RESERVED TO IANA        4-200
          PRIVATE USE             201-255

      o  SPI Size (1 octet) - For an initial IKE_SA negotiation, this
         field MUST be zero; the SPI is obtained from the outer header.
         During subsequent negotiations, it is equal to the size, in
         octets, of the SPI of the corresponding protocol (8 for IKE, 4
         for ESP and AH).

      o  # of Transforms (1 octet) - Specifies the number of transforms
         in this proposal.

      o  SPI (variable) - The sending entity's SPI. Even if the SPI Size
         is not a multiple of 4 octets, there is no padding applied to
         the payload.  When the SPI Size field is zero, this field is
         not present in the Security Association payload.

      o  Transforms (variable) - One or more transform substructures.

3.3.2.  Transform Substructure

                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! 0 (last) or 3 !   RESERVED    !        Transform Length       !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !Transform Type !   RESERVED    !          Transform ID         !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                                                               !
      ~                      Transform Attributes                     ~
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 8:  Transform Substructure

      o  0 (last) or 3 (more) (1 octet) - Specifies whether this is the
         last Transform Substructure in the Proposal.  This syntax is
         inherited from ISAKMP, but is unnecessary because the last
         Proposal could be identified from the length of the SA.  The

Top      Up      ToC       Page 50 
         value (3) corresponds to a Payload Type of Transform in IKEv1,
         and the first 4 octets of the Transform structure are designed
         to look somewhat like the header of a Payload.

      o  RESERVED - MUST be sent as zero; MUST be ignored on receipt.

      o  Transform Length - The length (in octets) of the Transform
         Substructure including Header and Attributes.

      o  Transform Type (1 octet) - The type of transform being
         specified in this transform.  Different protocols support
         different transform types.  For some protocols, some of the
         transforms may be optional.  If a transform is optional and the
         initiator wishes to propose that the transform be omitted, no
         transform of the given type is included in the proposal.  If
         the initiator wishes to make use of the transform optional to
         the responder, it includes a transform substructure with
         transform ID = 0 as one of the options.

      o  Transform ID (2 octets) - The specific instance of the
         transform type being proposed.

   Transform Type Values

                                     Transform    Used In
                                        Type
          RESERVED                        0
          Encryption Algorithm (ENCR)     1  (IKE and ESP)
          Pseudo-random Function (PRF)    2  (IKE)
          Integrity Algorithm (INTEG)     3  (IKE, AH, optional in ESP)
          Diffie-Hellman Group (D-H)      4  (IKE, optional in AH & ESP)
          Extended Sequence Numbers (ESN) 5  (AH and ESP)
          RESERVED TO IANA                6-240
          PRIVATE USE                     241-255

   For Transform Type 1 (Encryption Algorithm), defined Transform IDs
   are:

          Name                     Number           Defined In
          RESERVED                    0
          ENCR_DES_IV64               1              (RFC1827)
          ENCR_DES                    2              (RFC2405), [DES]
          ENCR_3DES                   3              (RFC2451)
          ENCR_RC5                    4              (RFC2451)
          ENCR_IDEA                   5              (RFC2451), [IDEA]
          ENCR_CAST                   6              (RFC2451)
          ENCR_BLOWFISH               7              (RFC2451)
          ENCR_3IDEA                  8              (RFC2451)

Top      Up      ToC       Page 51 
          ENCR_DES_IV32               9
          RESERVED                   10
          ENCR_NULL                  11              (RFC2410)
          ENCR_AES_CBC               12              (RFC3602)
          ENCR_AES_CTR               13              (RFC3664)

          values 14-1023 are reserved to IANA.  Values 1024-65535 are
          for private use among mutually consenting parties.

   For Transform Type 2 (Pseudo-random Function), defined Transform IDs
   are:

          Name                     Number               Defined In
          RESERVED                    0
          PRF_HMAC_MD5                1                 (RFC2104), [MD5]
          PRF_HMAC_SHA1               2                 (RFC2104), [SHA]
          PRF_HMAC_TIGER              3                 (RFC2104)
          PRF_AES128_XCBC             4                 (RFC3664)

          values 5-1023 are reserved to IANA.  Values 1024-65535 are for
          private use among mutually consenting parties.

   For Transform Type 3 (Integrity Algorithm), defined Transform IDs
   are:

          Name                     Number                 Defined In
          NONE                       0
          AUTH_HMAC_MD5_96           1                     (RFC2403)
          AUTH_HMAC_SHA1_96          2                     (RFC2404)
          AUTH_DES_MAC               3
          AUTH_KPDK_MD5              4                     (RFC1826)
          AUTH_AES_XCBC_96           5                     (RFC3566)

          values 6-1023 are reserved to IANA.  Values 1024-65535 are for
          private use among mutually consenting parties.

   For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs
   are:

          Name                                Number
          NONE                               0
          Defined in Appendix B              1 - 2
          RESERVED                           3 - 4
          Defined in [ADDGROUP]              5
          RESERVED TO IANA                   6 - 13
          Defined in [ADDGROUP]              14 - 18
          RESERVED TO IANA                   19 - 1023
          PRIVATE USE                        1024-65535

Top      Up      ToC       Page 52 
   For Transform Type 5 (Extended Sequence Numbers), defined Transform
   IDs are:

          Name                                Number
          No Extended Sequence Numbers       0
          Extended Sequence Numbers          1
          RESERVED                           2 - 65535

3.3.3.  Valid Transform Types by Protocol

   The number and type of transforms that accompany an SA payload are
   dependent on the protocol in the SA itself.  An SA payload proposing
   the establishment of an SA has the following mandatory and optional
   transform types.  A compliant implementation MUST understand all
   mandatory and optional types for each protocol it supports (though it
   need not accept proposals with unacceptable suites).  A proposal MAY
   omit the optional types if the only value for them it will accept is
   NONE.

          Protocol  Mandatory Types        Optional Types
            IKE     ENCR, PRF, INTEG, D-H
            ESP     ENCR, ESN              INTEG, D-H
            AH      INTEG, ESN             D-H

3.3.4.  Mandatory Transform IDs

   The specification of suites that MUST and SHOULD be supported for
   interoperability has been removed from this document because they are
   likely to change more rapidly than this document evolves.

   An important lesson learned from IKEv1 is that no system should only
   implement the mandatory algorithms and expect them to be the best
   choice for all customers.  For example, at the time that this
   document was written, many IKEv1 implementers were starting to
   migrate to AES in Cipher Block Chaining (CBC) mode for Virtual
   Private Network (VPN) applications.  Many IPsec systems based on
   IKEv2 will implement AES, additional Diffie-Hellman groups, and
   additional hash algorithms, and some IPsec customers already require
   these algorithms in addition to the ones listed above.

   It is likely that IANA will add additional transforms in the future,
   and some users may want to use private suites, especially for IKE
   where implementations should be capable of supporting different
   parameters, up to certain size limits.  In support of this goal, all
   implementations of IKEv2 SHOULD include a management facility that
   allows specification (by a user or system administrator) of Diffie-
   Hellman (DH) parameters (the generator, modulus, and exponent lengths
   and values) for new DH groups.  Implementations SHOULD provide a

Top      Up      ToC       Page 53 
   management interface via which these parameters and the associated
   transform IDs may be entered (by a user or system administrator), to
   enable negotiating such groups.

   All implementations of IKEv2 MUST include a management facility that
   enables a user or system administrator to specify the suites that are
   acceptable for use with IKE.  Upon receipt of a payload with a set of
   transform IDs, the implementation MUST compare the transmitted
   transform IDs against those locally configured via the management
   controls, to verify that the proposed suite is acceptable based on
   local policy.  The implementation MUST reject SA proposals that are
   not authorized by these IKE suite controls.  Note that cryptographic
   suites that MUST be implemented need not be configured as acceptable
   to local policy.

3.3.5.  Transform Attributes

   Each transform in a Security Association payload may include
   attributes that modify or complete the specification of the
   transform.  These attributes are type/value pairs and are defined
   below.  For example, if an encryption algorithm has a variable-length
   key, the key length to be used may be specified as an attribute.
   Attributes can have a value with a fixed two octet length or a
   variable-length value.  For the latter, the attribute is encoded as
   type/length/value.

                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !A!       Attribute Type        !    AF=0  Attribute Length     !
      !F!                             !    AF=1  Attribute Value      !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                   AF=0  Attribute Value                       !
      !                   AF=1  Not Transmitted                       !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 9:  Data Attributes

      o  Attribute Type (2 octets) - Unique identifier for each type of
         attribute (see below).

         The most significant bit of this field is the Attribute Format
         bit (AF).  It indicates whether the data attributes follow the
         Type/Length/Value (TLV) format or a shortened Type/Value (TV)
         format.  If the AF bit is zero (0), then the Data Attributes
         are of the Type/Length/Value (TLV) form.  If the AF bit is a
         one (1), then the Data Attributes are of the Type/Value form.

Top      Up      ToC       Page 54 
      o  Attribute Length (2 octets) - Length in octets of the Attribute
         Value.  When the AF bit is a one (1), the Attribute Value is
         only 2 octets and the Attribute Length field is not present.

      o  Attribute Value (variable length) - Value of the Attribute
         associated with the Attribute Type.  If the AF bit is a zero
         (0), this field has a variable length defined by the Attribute
         Length field.  If the AF bit is a one (1), the Attribute Value
         has a length of 2 octets.

   Note that only a single attribute type (Key Length) is defined, and
   it is fixed length.  The variable-length encoding specification is
   included only for future extensions.  The only algorithms defined in
   this document that accept attributes are the AES-based encryption,
   integrity, and pseudo-random functions, which require a single
   attribute specifying key width.

   Attributes described as basic MUST NOT be encoded using the
   variable-length encoding.  Variable-length attributes MUST NOT be
   encoded as basic even if their value can fit into two octets.  NOTE:
   This is a change from IKEv1, where increased flexibility may have
   simplified the composer of messages but certainly complicated the
   parser.

         Attribute Type                 Value        Attribute Format
      --------------------------------------------------------------
      RESERVED                           0-13 Key Length (in bits)
      14                 TV RESERVED                           15-17
      RESERVED TO IANA                   18-16383 PRIVATE USE
      16384-32767

   Values 0-13 and 15-17 were used in a similar context in IKEv1 and
   should not be assigned except to matching values.  Values 18-16383
   are reserved to IANA.  Values 16384-32767 are for private use among
   mutually consenting parties.

   - Key Length

      When using an Encryption Algorithm that has a variable-length key,
      this attribute specifies the key length in bits (MUST use network
      byte order).  This attribute MUST NOT be used when the specified
      Encryption Algorithm uses a fixed-length key.

Top      Up      ToC       Page 55 
3.3.6.  Attribute Negotiation

   During security association negotiation, initiators present offers to
   responders.  Responders MUST select a single complete set of
   parameters from the offers (or reject all offers if none are
   acceptable).  If there are multiple proposals, the responder MUST
   choose a single proposal number and return all of the Proposal
   substructures with that Proposal number.  If there are multiple
   Transforms with the same type, the responder MUST choose a single
   one.  Any attributes of a selected transform MUST be returned
   unmodified.  The initiator of an exchange MUST check that the
   accepted offer is consistent with one of its proposals, and if not
   that response MUST be rejected.

   Negotiating Diffie-Hellman groups presents some special challenges.
   SA offers include proposed attributes and a Diffie-Hellman public
   number (KE) in the same message.  If in the initial exchange the
   initiator offers to use one of several Diffie-Hellman groups, it
   SHOULD pick the one the responder is most likely to accept and
   include a KE corresponding to that group.  If the guess turns out to
   be wrong, the responder will indicate the correct group in the
   response and the initiator SHOULD pick an element of that group for
   its KE value when retrying the first message.  It SHOULD, however,
   continue to propose its full supported set of groups in order to
   prevent a man-in-the-middle downgrade attack.

   Implementation Note:

      Certain negotiable attributes can have ranges or could have
      multiple acceptable values.  These include the key length of a
      variable key length symmetric cipher.  To further interoperability
      and to support upgrading endpoints independently, implementers of
      this protocol SHOULD accept values that they deem to supply
      greater security.  For instance, if a peer is configured to accept
      a variable-length cipher with a key length of X bits and is
      offered that cipher with a larger key length, the implementation
      SHOULD accept the offer if it supports use of the longer key.

   Support of this capability allows an implementation to express a
   concept of "at least" a certain level of security -- "a key length of
   _at least_ X bits for cipher Y".

Top      Up      ToC       Page 56 
3.4.  Key Exchange Payload

   The Key Exchange Payload, denoted KE in this memo, is used to
   exchange Diffie-Hellman public numbers as part of a Diffie-Hellman
   key exchange.  The Key Exchange Payload consists of the IKE generic
   payload header followed by the Diffie-Hellman public value itself.

                           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  !C!  RESERVED   !         Payload Length        !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !          DH Group #           !           RESERVED            !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                                                               !
      ~                       Key Exchange Data                       ~
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 10:  Key Exchange Payload Format

   A key exchange payload is constructed by copying one's Diffie-Hellman
   public value into the "Key Exchange Data" portion of the payload.
   The length of the Diffie-Hellman public value MUST be equal to the
   length of the prime modulus over which the exponentiation was
   performed, prepending zero bits to the value if necessary.

   The DH Group # identifies the Diffie-Hellman group in which the Key
   Exchange Data was computed (see section 3.3.2).  If the selected
   proposal uses a different Diffie-Hellman group, the message MUST be
   rejected with a Notify payload of type INVALID_KE_PAYLOAD.

   The payload type for the Key Exchange payload is thirty four (34).

3.5.  Identification Payloads

   The Identification Payloads, denoted IDi and IDr in this memo, allow
   peers to assert an identity to one another.  This identity may be
   used for policy lookup, but does not necessarily have to match
   anything in the CERT payload; both fields may be used by an
   implementation to perform access control decisions.

   NOTE: In IKEv1, two ID payloads were used in each direction to hold
   Traffic Selector (TS) information for data passing over the SA.  In
   IKEv2, this information is carried in TS payloads (see section 3.13).

Top      Up      ToC       Page 57 
   The Identification Payload consists of the IKE generic payload header
   followed by identification fields as follows:

                           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  !C!  RESERVED   !         Payload Length        !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !   ID Type     !                 RESERVED                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                                                               !
      ~                   Identification Data                         ~
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 11:  Identification Payload Format

   o  ID Type (1 octet) - Specifies the type of Identification being
      used.

   o  RESERVED - MUST be sent as zero; MUST be ignored on receipt.

   o  Identification Data (variable length) - Value, as indicated by the
      Identification Type.  The length of the Identification Data is
      computed from the size in the ID payload header.

   The payload types for the Identification Payload are thirty five (35)
   for IDi and thirty six (36) for IDr.

   The following table lists the assigned values for the Identification
   Type field, followed by a description of the Identification Data
   which follows:

      ID Type                           Value
      -------                           -----
      RESERVED                            0

      ID_IPV4_ADDR                        1

            A single four (4) octet IPv4 address.

      ID_FQDN                             2

            A fully-qualified domain name string.  An example of a
            ID_FQDN is, "example.com".  The string MUST not contain any
            terminators (e.g., NULL, CR, etc.).

Top      Up      ToC       Page 58 
      ID_RFC822_ADDR                      3

            A fully-qualified RFC822 email address string, An example of
            a ID_RFC822_ADDR is, "jsmith@example.com".  The string MUST
            not contain any terminators.

      Reserved to IANA                    4

      ID_IPV6_ADDR                        5

            A single sixteen (16) octet IPv6 address.

      Reserved to IANA                    6 - 8

      ID_DER_ASN1_DN                      9

            The binary Distinguished Encoding Rules (DER) encoding of an
            ASN.1 X.500 Distinguished Name [X.501].

      ID_DER_ASN1_GN                      10

            The binary DER encoding of an ASN.1 X.500 GeneralName
            [X.509].

      ID_KEY_ID                           11

            An opaque octet stream which may be used to pass vendor-
            specific information necessary to do certain proprietary
            types of identification.

      Reserved to IANA                    12-200

      Reserved for private use            201-255

   Two implementations will interoperate only if each can generate a
   type of ID acceptable to the other.  To assure maximum
   interoperability, implementations MUST be configurable to send at
   least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and
   MUST be configurable to accept all of these types.  Implementations
   SHOULD be capable of generating and accepting all of these types.
   IPv6-capable implementations MUST additionally be configurable to
   accept ID_IPV6_ADDR.  IPv6-only implementations MAY be configurable
   to send only ID_IPV6_ADDR.

Top      Up      ToC       Page 59 
3.6.  Certificate Payload

   The Certificate Payload, denoted CERT in this memo, provides a means
   to transport certificates or other authentication-related information
   via IKE.  Certificate payloads SHOULD be included in an exchange if
   certificates are available to the sender unless the peer has
   indicated an ability to retrieve this information from elsewhere
   using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload.  Note that the
   term "Certificate Payload" is somewhat misleading, because not all
   authentication mechanisms use certificates and data other than
   certificates may be passed in this payload.

   The Certificate Payload is defined as follows:

                           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  !C!  RESERVED   !         Payload Length        !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! Cert Encoding !                                               !
      +-+-+-+-+-+-+-+-+                                               !
      ~                       Certificate Data                        ~
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 12:  Certificate Payload Format

      o  Certificate Encoding (1 octet) - This field indicates the type
         of certificate or certificate-related information contained in
         the Certificate Data field.

           Certificate Encoding               Value
           --------------------               -----
           RESERVED                             0
           PKCS #7 wrapped X.509 certificate    1
           PGP Certificate                      2
           DNS Signed Key                       3
           X.509 Certificate - Signature        4
           Kerberos Token                       6
           Certificate Revocation List (CRL)    7
           Authority Revocation List (ARL)      8
           SPKI Certificate                     9
           X.509 Certificate - Attribute       10
           Raw RSA Key                         11
           Hash and URL of X.509 certificate   12
           Hash and URL of X.509 bundle        13
           RESERVED to IANA                  14 - 200
           PRIVATE USE                      201 - 255

Top      Up      ToC       Page 60 
      o  Certificate Data (variable length) - Actual encoding of
         certificate data.  The type of certificate is indicated by the
         Certificate Encoding field.

   The payload type for the Certificate Payload is thirty seven (37).

   Specific syntax is for some of the certificate type codes above is
   not defined in this document.  The types whose syntax is defined in
   this document are:

      X.509 Certificate - Signature (4) contains a DER encoded X.509
      certificate whose public key is used to validate the sender's AUTH
      payload.

      Certificate Revocation List (7) contains a DER encoded X.509
      certificate revocation list.

      Raw RSA Key (11) contains a PKCS #1 encoded RSA key (see [RSA] and
      [PKCS1]).

      Hash and URL encodings (12-13) allow IKE messages to remain short
      by replacing long data structures with a 20 octet SHA-1 hash (see
      [SHA]) of the replaced value followed by a variable-length URL
      that resolves to the DER encoded data structure itself.  This
      improves efficiency when the endpoints have certificate data
      cached and makes IKE less subject to denial of service attacks
      that become easier to mount when IKE messages are large enough to
      require IP fragmentation [KPS03].

      Use the following ASN.1 definition for an X.509 bundle:

            CertBundle
              { iso(1) identified-organization(3) dod(6) internet(1)
                security(5) mechanisms(5) pkix(7) id-mod(0)
                id-mod-cert-bundle(34) }

            DEFINITIONS EXPLICIT TAGS ::=
            BEGIN

            IMPORTS
              Certificate, CertificateList
              FROM PKIX1Explicit88
                 { iso(1) identified-organization(3) dod(6)
                   internet(1) security(5) mechanisms(5) pkix(7)
                   id-mod(0) id-pkix1-explicit(18) } ;

Top      Up      ToC       Page 61 
           CertificateOrCRL ::= CHOICE {
             cert [0] Certificate,
             crl  [1] CertificateList }

           CertificateBundle ::= SEQUENCE OF CertificateOrCRL

           END

   Implementations MUST be capable of being configured to send and
   accept up to four X.509 certificates in support of authentication,
   and also MUST be capable of being configured to send and accept the
   first two Hash and URL formats (with HTTP URLs).  Implementations
   SHOULD be capable of being configured to send and accept Raw RSA
   keys.  If multiple certificates are sent, the first certificate MUST
   contain the public key used to sign the AUTH payload.  The other
   certificates may be sent in any order.

3.7.  Certificate Request Payload

   The Certificate Request Payload, denoted CERTREQ in this memo,
   provides a means to request preferred certificates via IKE and can
   appear in the IKE_INIT_SA response and/or the IKE_AUTH request.
   Certificate Request payloads MAY be included in an exchange when the
   sender needs to get the certificate of the receiver.  If multiple CAs
   are trusted and the cert encoding does not allow a list, then
   multiple Certificate Request payloads SHOULD be transmitted.

   The Certificate Request Payload is defined as follows:

                           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  !C!  RESERVED   !         Payload Length        !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! Cert Encoding !                                               !
      +-+-+-+-+-+-+-+-+                                               !
      ~                    Certification Authority                    ~
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 13:  Certificate Request Payload Format

   o  Certificate Encoding (1 octet) - Contains an encoding of the type
      or format of certificate requested.  Values are listed in section
      3.6.

Top      Up      ToC       Page 62 
   o  Certification Authority (variable length) - Contains an encoding
      of an acceptable certification authority for the type of
      certificate requested.

   The payload type for the Certificate Request Payload is thirty eight
   (38).

   The Certificate Encoding field has the same values as those defined
   in section 3.6. The Certification Authority field contains an
   indicator of trusted authorities for this certificate type.  The
   Certification Authority value is a concatenated list of SHA-1 hashes
   of the public keys of trusted Certification Authorities (CAs).  Each
   is encoded as the SHA-1 hash of the Subject Public Key Info element
   (see section 4.1.2.7 of [RFC3280]) from each Trust Anchor
   certificate.  The twenty-octet hashes are concatenated and included
   with no other formatting.

   Note that the term "Certificate Request" is somewhat misleading, in
   that values other than certificates are defined in a "Certificate"
   payload and requests for those values can be present in a Certificate
   Request Payload.  The syntax of the Certificate Request payload in
   such cases is not defined in this document.

   The Certificate Request Payload is processed by inspecting the "Cert
   Encoding" field to determine whether the processor has any
   certificates of this type.  If so, the "Certification Authority"
   field is inspected to determine if the processor has any certificates
   that can be validated up to one of the specified certification
   authorities.  This can be a chain of certificates.

   If an end-entity certificate exists that satisfies the criteria
   specified in the CERTREQ, a certificate or certificate chain SHOULD
   be sent back to the certificate requestor if the recipient of the
   CERTREQ:

   - is configured to use certificate authentication,

   - is allowed to send a CERT payload,

   - has matching CA trust policy governing the current negotiation, and

   - has at least one time-wise and usage appropriate end-entity
     certificate chaining to a CA provided in the CERTREQ.

   Certificate revocation checking must be considered during the
   chaining process used to select a certificate.  Note that even if two
   peers are configured to use two different CAs, cross-certification
   relationships should be supported by appropriate selection logic.

Top      Up      ToC       Page 63 
   The intent is not to prevent communication through the strict
   adherence of selection of a certificate based on CERTREQ, when an
   alternate certificate could be selected by the sender that would
   still enable the recipient to successfully validate and trust it
   through trust conveyed by cross-certification, CRLs, or other out-
   of-band configured means.  Thus, the processing of a CERTREQ should
   be seen as a suggestion for a certificate to select, not a mandated
   one.  If no certificates exist, then the CERTREQ is ignored.  This is
   not an error condition of the protocol.  There may be cases where
   there is a preferred CA sent in the CERTREQ, but an alternate might
   be acceptable (perhaps after prompting a human operator).

3.8.  Authentication Payload

   The Authentication Payload, denoted AUTH in this memo, contains data
   used for authentication purposes.  The syntax of the Authentication
   data varies according to the Auth Method as specified below.

   The Authentication Payload is defined as follows:

                           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  !C!  RESERVED   !         Payload Length        !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! Auth Method   !                RESERVED                       !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                                                               !
      ~                      Authentication Data                      ~
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 14:  Authentication Payload Format

   o  Auth Method (1 octet) - Specifies the method of authentication
      used.  Values defined are:

        RSA Digital Signature (1) - Computed as specified in section
        2.15 using an RSA private key over a PKCS#1 padded hash (see
        [RSA] and [PKCS1]).

        Shared Key Message Integrity Code (2) - Computed as specified in
        section 2.15 using the shared key associated with the identity
        in the ID payload and the negotiated prf function

        DSS Digital Signature (3) - Computed as specified in section
        2.15 using a DSS private key (see [DSS]) over a SHA-1 hash.

Top      Up      ToC       Page 64 
        The values 0 and 4-200 are reserved to IANA.  The values 201-255
        are available for private use.

   o  Authentication Data (variable length) - see section 2.15.

   The payload type for the Authentication Payload is thirty nine (39).

3.9.  Nonce Payload

   The Nonce Payload, denoted Ni and Nr in this memo for the initiator's
   and responder's nonce respectively, contains random data used to
   guarantee liveness during an exchange and protect against replay
   attacks.

   The Nonce Payload is defined as follows:

                           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  !C!  RESERVED   !         Payload Length        !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                                                               !
      ~                            Nonce Data                         ~
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 15:  Nonce Payload Format

   o  Nonce Data (variable length) - Contains the random data generated
      by the transmitting entity.

   The payload type for the Nonce Payload is forty (40).

   The size of a Nonce MUST be between 16 and 256 octets inclusive.
   Nonce values MUST NOT be reused.



(page 64 continued on part 4)

Next RFC Part