tech-invite   World Map     

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

RFC 4535

 
 
 

GSAKMP: Group Secure Association Key Management Protocol

Part 3 of 4, p. 45 to 75
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 45 
6.  Security Suite

   The Security Definition Suite 1 MUST be supported.  Other security
   suite definitions MAY be defined in other Internet specifications.

6.1.  Assumptions

   All potential GMs will have enough information available to them to
   use the correct Security Suite to join the group.  This can be
   accomplished by a well-known default suite, 'Security Suite 1', or by
   announcing/posting another suite.

6.2.  Definition Suite 1

   GSAKMP implementations MUST support the following suite of algorithms
   and configurations.  The following definition of Suite 1 borrows
   heavily from IKE's Oakley group 2 definition and Oakley itself.

   The GSAKMP Suite 1 definition gives all the algorithm and
   cryptographic definitions required to process group establishment
   messages.  It is important to note that GSAKMP does not negotiate

Top      Up      ToC       Page 46 
   these cryptographic mechanisms.  This definition is set by the Group
   Owner via the Policy Token (passed during the GSAKMP exchange for
   member verification purposes).

   The GSAKMP Suite 1 definition is:

     Key download and Policy Token encryption algorithm definition:
     Algorithm:  AES
     Mode:       CBC
     Key Length: 128 bits

     Policy Token digital signature algorithm is:
       DSS-ASN1-DER
       Hash algorithm is:
       SHA-1

     Nonce Hash algorithm is:
       SHA-1

     The Key Creation definition is:
     Algorithm type is Diffie Hellman
     MODP group definition
     g:   2
     p:   "FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1"
          "29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD"
          "EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245"
          "E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED"
          "EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381"
          "FFFFFFFF FFFFFFFF"

     NOTE: The p and g values come from IKE [RFC2409], Section 6.2,
           "Second Oakley Group", and p is 1024 bits long.


     The GSAKMP message digital signature algorithm is:
     DSS-SHA1-ASN1-DER

     The digital signature ID type is:
     ID-DN-STRING

Top      Up      ToC       Page 47 
7.  GSAKMP Payload Structure

   A GSAKMP Message is composed of a GSAKMP Header (Section 7.1)
   followed by at least one GSAKMP Payload.  All GSAKMP Payloads are
   composed of the Generic Payload Header (Section 7.2) followed by the
   specific payload data.  The message is chained by a preceding payload
   defining its succeeding payload.  Payloads are not required to be in
   the exact order shown in the message dissection in Section 5,
   provided that all required payloads are present.  Unless it is
   explicitly stated in a dissection that multiple payloads of a single
   type may be present, no more than one payload of each type allowed by
   the message may appear.  The final payload in a message will point to
   no succeeding payload.

   All fields of type integer in the Header and Payload structure that
   are larger than one octet MUST be converted into Network Byte Order
   prior to data transmission.

   Padding of fields MUST NOT be done as this leads to processing
   errors.

   When a message contains a Vendor ID payload, the processing of the
   payloads of that message is modified as defined in Section 7.10.

7.1.  GSAKMP Header

7.1.1.  GSAKMP Header Structure

   The GSAKMP Header fields are shown in Figure 3 and defined as:

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! GroupID Type  ! GroupID Length!      Group ID Value           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~               ! Next Payload  !   Version     ! Exchange Type !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Sequence ID                                                   !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Length                                                        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 3: GSAKMP Header Format

Top      Up      ToC       Page 48 
   Group Identification Type (1 octet) - Table 11 presents the group
       identification types.  This field is treated as an unsigned
       value.

                     Table 11:  Group Identification Types

   Grp ID Type          Value       Description
   _____________________________________________________________________

   Reserved               0
   UTF-8                  1         Format defined in Section 7.1.1.1.1.
   Octet String           2         This type MUST be implemented.
                                    Format defined in Section 7.1.1.1.2.
   IPv4                   3         Format defined in Section 7.1.1.1.3.
   IPv6                   4         Format defined in Section 7.1.1.1.4.
   Reserved to IANA    5 - 192
   Private Use        193 - 255

   Group Identification Length (1 octet)  - Length of the Group
       Identification Value field in octets.  This value MUST NOT be
       zero (0).  This field is treated as an unsigned value.

   Group Identification Value (variable length)  - Indicates the
       name/title of the group.  All GroupID types should provide unique
       naming across groups.  GroupID types SHOULD provide this
       capability by including a random element generated by the creator
       (owner) of the group of at least eight (8) octets, providing
       extremely low probability of collision in group names.  The
       GroupID value is static throughout the life of the group.

   Next Payload (1 octet)  - Indicates the type of the next payload in
       the message.  The format for each payload is defined in the
       following sections.  Table 12 presents the payload types.  This
       field is treated as an unsigned value.

Top      Up      ToC       Page 49 
                           Table 12: Payload Types

                      Next_Payload_Type        Value
                     ___________________________________

                      None                       0
                      Policy Token               1
                      Key Download Packet        2
                      Rekey Event                3
                      Identification             4
                      Reserved                   5
                      Certificate                6
                      Reserved                   7
                      Signature                  8
                      Notification               9
                      Vendor ID                  10
                      Key Creation               11
                      Nonce                      12
                      Reserved to IANA        13 - 192
                      Private Use            193 - 255

   Version (1 octet) - Indicates the version of the GSAKMP protocol in
       use.  The current value is one (1).  This field is treated as an
       unsigned value.

   Exchange Type (1 octet) - Indicates the type of exchange (also known
       as the message type).  Table 13 presents the exchange type
       values.  This field is treated as an unsigned value.

                           Table 13: Exchange Types

                    Exchange_Type                 Value
                   ________________________________________

                    Reserved                      0 - 3
                    Key Download Ack/Failure        4
                    Rekey Event                     5
                    Reserved                      6 - 7
                    Request to Join                 8
                    Key Download                    9
                    Cookie Download                10
                    Request to Join Error          11
                    Lack of Ack                    12
                    Request to Depart              13
                    Departure Response             14
                    Departure Ack                  15
                    Reserved to IANA            16 - 192
                    Private Use                193 - 255

Top      Up      ToC       Page 50 
   Sequence ID (4 octets) - The Sequence ID is used for replay
       protection of group management messages.  If the message is not a
       group management message, this value MUST be set to zero (0).
       The first value used by a (S-)GC/KS MUST be one (1).  For each
       distinct group management message that this (S-)GC/KS transmits,
       this value MUST be incremented by one (1).  Receivers of this
       group management message MUST confirm that the value received is
       greater than the value of the sequence ID received with the last
       group management message from this (S-)GC/KS.  Group Components
       (e.g., GMs, S-GC/KSes) MUST terminate processing upon receipt of
       an authenticated group management message containing a Sequence
       ID of 0xFFFFFFFF.  This field is treated as an unsigned integer
       in network byte order.

   Length (4 octets) - Length of total message (header + payloads) in
       octets.  This field is treated as an unsigned integer in network
       byte order.

Top      Up      ToC       Page 51 
7.1.1.1.  GroupID Structure

   This section defines the formats for the defined GroupID types.

7.1.1.1.1.  UTF-8

   The format for type UTF-8 [RFC3629] is shown in Figure 4.

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Random Value                                                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! UTF-8 String                                                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 4: GroupID UTF-8 Format

   Random Value (16 octets) - For the UTF-8 GroupID type, the Random
       Value is represented as a string of exactly 16 hexadecimal digits
       converted from its octet values in network-byte order.  The
       leading zero hexadecimal digits and the trailing zero hexadecimal
       digits are always included in the string, rather than being
       truncated.

   UTF-8 String (variable length) - This field contains the human
       readable portion of the GroupID in UTF-8 format.  Its length is
       calculated as the (GroupID Length - 16) for the Random Value
       field.  The minimum length for this field is one (1) octet.

Top      Up      ToC       Page 52 
7.1.1.1.2.  Octet String

   The format for type Octet String is shown in Figure 5.

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Random Value                                                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Octet String                                                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 5:  GroupID Octet String Format

   Random Value (8 octets) - The 8-octet unsigned random value in
       network byte order format.

   Octet String (variable length) - This field contains the Octet String
       portion of the GroupID.  Its length is calculated as the (GroupID
       Length - 8) for the Random Value field.  The minimum length for
       this field is one (1) octet.

7.1.1.1.3.  IPv4 Group Identifier

   The format for type IPv4 Group Identifier is shown in Figure 6.

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Random Value                                                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! IPv4 Value                                                    !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 6: GroupID IPv4 Format

   Random Value (8 octets) - The 8-octet unsigned random value in
       network byte order format.

   IPv4 Value (4 octets) - The IPv4 value in network byte order format.
       This value MAY contain the multicast address of the group.

Top      Up      ToC       Page 53 
7.1.1.1.4.  IPv6 Group Identifier

   The format for type IPv6 Group Identifier is shown in Figure 7.

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Random Value                                                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! IPv6 Value                                                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 7: GroupID IPv6 Format

   Random Value (8 octets) - The 8-octet unsigned random value in
       network byte order format.

   IPv6 Value (16 octets) - The IPv6 value in network byte order format.
       This value MAY contain the multicast address of the group.

7.1.2.  GSAKMP Header Processing

   When processing the GSAKMP Header, the following fields MUST be
   checked for correct values:

   1.  Group ID Type - The Group ID Type value MUST be checked to be a
       valid group identification payload type as defined by Table 11.
       If the value is not valid, then an error is logged.  If in
       Verbose Mode, an appropriate message containing notification
       value Payload-Malformed will be sent.

   2.  GroupID - The GroupID of the received message MUST be checked
       against the valid GroupIDs of the Group Component.  If no match
       is found, then an error is logged; in addition, if in Verbose
       Mode, an appropriate message containing notification value
       Invalid-Group-ID will be sent.

Top      Up      ToC       Page 54 
   3.  Next Payload - The Next Payload value MUST be checked to be a
       valid payload type as defined by Table 12.  If the value is not
       valid, then an error is logged.  If in Verbose Mode, an
       appropriate message containing notification value Invalid-
       Payload-Type will be sent.

   4.  Version - The GSAKMP version number MUST be checked that its
       value is one (1).  For other values, see below for processing.
       The GSAKMP version number MUST be checked that it is consistent
       with the group's policy as specified in its Policy Token.  If the
       version is not supported or authorized, then an error is logged.
       If in Verbose Mode, an appropriate message containing
       notification value Invalid-Version will be sent.

   5.  Exchange Type - The Exchange Type MUST be checked to be a valid
       exchange type as defined by Table 13 and MUST be of the type
       expected to be received by the GSAKMP state machine.  If the
       exchange type is not valid, then an error is logged.  If in
       Verbose Mode, an appropriate message containing notification
       value Invalid-Exchange-Type will be sent.

   6.  Sequence ID - The Sequence ID value MUST be checked for
       correctness.  For negotiation messages, this value MUST be zero
       (0).  For group management messages, this value MUST be greater
       than the last sequence ID received from this (S-)GC/KS.  Receipt
       of incorrect Sequence ID on group management messages MUST NOT
       cause a reply message to be generated.  Upon receipt of incorrect
       Sequence ID on non-group management messages, an error is logged.
       If in Verbose Mode, an appropriate message containing
       notification value Invalid-Sequence-ID will be sent.

   The length fields in the GSAKMP Header (Group ID Length and Length)
   are used to help process the message.  If any field is found to be
   incorrect, then an error is logged.  If in Verbose Mode, an
   appropriate message containing notification value Payload-Malformed
   will be sent.

   In order to allow a GSAKMP version one (v1) implementation to
   interoperate with future versions of the protocol, some ideas will be
   discussed here to this effect.

   A (S-)GC/KS that is operating in a multi-versioned group as defined
   by the Policy Token can take many approaches on how to interact with
   the GMs in this group for a rekey message.

Top      Up      ToC       Page 55 
   One possible solution is for the (S-)GC/KS to send out multiple rekey
   messages, one per version level that it supports.  Then each GM would
   only process the message that has the version at which it is
   operating.

   An alternative approach that all GM v1 implementations MUST support
   is the embedding of a v1 message inside a version two (v2) message.
   If a GM running at v1 receives a GSAKMP message that has a version
   value greater than one (1), the GM will attempt to process the
   information immediately after the Group Header as a Group Header for
   v1 of the protocol.  If this is in fact a v1 Group Header, then the
   remainder of this v1 message will be processed in place.  After
   processing this v1 embedded message, the data following the v1
   message should be the payload as identified by the Next Payload field
   in the original header of the message and will be ignored by the v1
   member.  However, if the payload following the initial header is not
   a v1 Group Header, then the GM will gracefully handle the
   unrecognized message.

7.2.  Generic Payload Header

7.2.1.  Generic Payload Header Structure

   Each GSAKMP payload defined in the following sections begins with a
   generic header, shown in Figure 8, that provides a payload "chaining"
   capability and clearly defines the boundaries of a payload.  The
   Generic Payload Header fields are defined as follows:

    0                   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 8: Generic Payload Header

   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 the
       "chaining" capability.  Table 12 identifies the payload types.
       This field is treated as an unsigned value.

   RESERVED (1 octet) - Unused, set to 0.

   Payload Length (2 octets) - Length in octets of the current payload,
       including the generic payload header.  This field is treated as
       an unsigned integer in network byte order format.

Top      Up      ToC       Page 56 
7.2.2.  Generic Payload Header Processing

   When processing the Generic Payload Header, the following fields MUST
   be checked for correct values:

   1.  Next Payload - The Next Payload value MUST be checked to be a
       valid payload type as defined by Table 12.  If the payload type
       is not valid, then an error is logged.  If in Verbose Mode, an
       appropriate message containing notification value Invalid-
       Payload-Type will be sent.

   2.  RESERVED - This field MUST contain the value zero (0).  If the
       value of this field is not zero (0), then an error is logged.  If
       in Verbose Mode, an appropriate message containing notification
       value Payload-Malformed will be sent.

   The length field in the Generic Payload Header is used to process the
   remainder of the payload.  If this field is found to be incorrect,
   then an error is logged.  If in Verbose Mode, an appropriate message
   containing notification value Payload-Malformed will be sent.

7.3.  Policy Token Payload

7.3.1.  Policy Token Payload Structure

   The Policy Token Payload contains authenticatable group-specific
   information that describes the group security-relevant behaviors,
   access control parameters, and security mechanisms.  Figure 9 shows
   the format of the payload.

    0                   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        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Policy Token Type             ! Policy Token Data             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 9: Policy Token Payload Format

   The Policy Token Payload fields are defined as follows:

   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 the
       "chaining" capability.  Table 12 identifies the payload types.
       This field is treated as an unsigned value.

Top      Up      ToC       Page 57 
   RESERVED (1 octet) - Unused, set to 0.

   Payload Length (2 octets) - Length in octets of the current payload,
       including the generic payload header.  This field is treated as
       an unsigned integer in network byte order format.

   Policy Token Type (2 octets) - Specifies the type of Policy Token
       being used.  Table 14 identifies the types of policy tokens.
       This field is treated as an unsigned integer in network byte
       order format.

                       Table 14: Policy Token Types

    Policy_Token_Type      Value         Definition/Defined In
   ____________________________________________________________________

   Reserved                  0
   GSAKMP_ASN.1_PT_V1        1          All implementations of GSAKMP
                                        MUST support this PT format.
                                        Format specified in [RFC4534].
   Reserved to IANA      2 - 49152
   Private Use         49153 - 65535

   Policy Token Data (variable length) - Contains Policy Token
       information.  The values for this field are token specific, and
       the format is specified by the PT Type field.

   If this payload is encrypted, only the Policy Token Data field is
   encrypted.

   The payload type for the Policy Token Payload is one (1).

7.3.2.  Policy Token Payload Processing

   When processing the Policy Token Payload, the following fields MUST
   be checked for correct values:

   1.  Next Payload, RESERVED, Payload Length - These fields are
       processed as defined in Section 7.2.2, "Generic Payload Header
       Processing".

   2.  Policy Token Type - The Policy Token Type value MUST be checked
       to be a valid policy token type as defined by Table 14.  If the
       value is not valid, then an error is logged.  If in Verbose Mode,
       an appropriate message containing notification value Payload-
       Malformed will be sent.

Top      Up      ToC       Page 58 
   3.  Policy Token Data - This Policy Token Data MUST be processed
       according to the Policy Token Type specified.  The type will
       define the format of the data.

7.4.  Key Download Payload

   Refer to the terminology section for the different terms relating to
   keys used within this section.

7.4.1.  Key Download Payload Structure

   The Key Download Payload contains group keys (e.g., group keys,
   initial rekey keys, etc.).  These key download payloads can have
   several security attributes applied to them based upon the security
   policy of the group.  Figure 10 shows the format of the payload.

   The security policy of the group dictates that the key download
   payload MUST be encrypted with a key encryption key (KEK).  The
   encryption mechanism used is specified in the Policy Token.  The
   group members MUST create the KEK using the key creation method
   identified in the Key Creation Payload.

    0                   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        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Number of Items               ! Key Download Data Items       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 10: Key Download Payload Format

   The Key Download Payload fields are defined as follows:

   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 the
       "chaining" capability.  Table 12 identifies the payload types.
       This field is treated as an unsigned value.

   RESERVED (1 octet) - Unused, set to 0.

   Payload Length (2 octets) - Length in octets of the current payload,
       including the generic payload header.  This field is treated as
       an unsigned integer in network byte order format.

Top      Up      ToC       Page 59 
   Number of Items (2 octets) - Contains the total number of group
       traffic protection keys and Rekey Arrays being passed in this
       data block.  This field is treated as an unsigned integer in
       network byte order format.

   Key Download Data Items (variable length) - Contains Key Download
       information.  The Key Download Data is a sequence of
       Type/Length/Data of the Number of Items.  The format for each
       item is defined in Figure 11.

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! KDD Item Type !  Key Download Data Item Length!               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ Data for Key Download Data Item (Key Datum/Rekey Array)       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 11: Key Download Data Item Format

   For each Key Download Data Item, the data format is as follows:

       Key Download Data (KDD) Item Type (1 octet) - Identifier for the
           type of data contained in this Key Download Data Item.  See
           Table 15 for the possible values of this field.  This field
           is treated as an unsigned value.

       Key Download Data Item Length (2 octets) - Length in octets of
           the Data for the Key Download Data Item following this field.
           This field is treated as an unsigned integer in network byte
           order format.

       Data for Key Download Data Item (variable length) - Contains Keys
           and related information.  The format of this field is
           specific depending on the value of the Key Download Data Item
           Type field.  For KDD Item Type of GTPK, this field will
           contain a Key Datum as defined in Section 7.4.1.1.  For KDD
           Item Type Rekey - LKH, this field will contain a Rekey Array
           as defined in Section 7.4.1.2.

Top      Up      ToC       Page 60 
                 Table 15: Key Download Data Item Types

   Key Download Data     Value      Definition
   Item Type
   _________________________________________________________________

   GTPK                    0        This type MUST be implemented.
                                    This type identifies that the
                                    data contains group traffic
                                    protection key information.
   Rekey - LKH             1        Optional
   Reserved to IANA     2 - 192
   Private Use         193 - 255

   The encryption of this payload only covers the data subsequent to the
   Generic Payload header (Number of Items and Key Download Data Items
   fields).

   The payload type for the Key Download Packet is two (2).

Top      Up      ToC       Page 61 
7.4.1.1.  Key Datum Structure

   A Key Datum contains all the information for a key.  Figure 12 shows
   the format for this structure.

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Key Type                      ! Key ID                        ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                               ! Key Handle                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                               ! Key Creation Date             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !               ! Key Expiration Date                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                               !               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ Key Data                                                      ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 12: Key Datum Format

   Key Type (2 octets) - This is the cryptographic algorithm for which
       this key data is to be used.  This value is specified in the
       Policy Token.  See Table 16 for the possible values of this
       field.  This field is treated as an unsigned value.

Top      Up      ToC       Page 62 
                    Table 16: Cryptographic Key Types

    Cryptographic_Key_Types     Value         Description/Defined In
   ____________________________________________________________________

   Reserved                     0 - 2
   3DES_CBC64_192                 3           See [RFC2451].
   Reserved                     4 - 11
   AES_CBC_128                    12          This type MUST be
                                              supported.  See [IKEv2].
   AES_CTR                        13          See [IKEv2].
   Reserved to IANA           14 - 49152
   Private Use              49153 - 65535

   Key ID (4 octets) - This is the permanent ID of all versions of the
       key.  This value MAY be defined by the Policy Token.  This field
       is treated as an octet string.

   Key Handle (4 octets) - This is the value to uniquely identify a
       version (particular instance) of a key.  This field is treated as
       an octet string.

   Key Creation Date (15 octets) - This is the time value of when this
       key data was originally generated.  This field contains the
       timestamp in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year
       (0000 - 9999), MM is the numerical value of the month (01 - 12),
       DD is the day of the month (01 - 31), HH is the hour of the day
       (00 - 23), MM is the minute within the hour (00 - 59), SS is the
       seconds within the minute (00 - 59), and the letter Z indicates
       that this is Zulu time.  This format is loosely based on
       [RFC3161].

   Key Expiration Date (15 octets) - This is the time value of when this
       key is no longer valid for use.  This field contains the
       timestamp in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year
       (0000 - 9999), MM is the numerical value of the month (01 - 12),
       DD is the day of the month (01 - 31), HH is the hour of the day
       (00 - 23), MM is the minute within the hour (00 - 59), SS is the
       seconds within the minute (00 - 59), and the letter Z indicates
       that this is Zulu time.  This format is loosely based on
       [RFC3161].

   Key Data (variable length) - This is the actual key data, which is
       dependent on the Key Type algorithm for its format.

   NOTE: The combination of the Key ID and the Key Handle MUST be unique
   within the group.  This combination will be used to uniquely identify
   a key.

Top      Up      ToC       Page 63 
7.4.1.2.  Rekey Array Structure

   A Rekey Array contains the information for the set of KEKs that is
   associated with a Group Member.  Figure 13 shows the format for this
   structure.

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Rekey Version#! Member ID                                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~               ! Number of KEK Keys            !               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ Key Datum(s)                                                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 13: Rekey Array Structure Format

   Rekey Version (1 octet) - Contains the version of the Rekey protocol
       in which the data is formatted.  For Key Download Data Item Type
       of Rekey - LKH, refer to Section A.2 for a description of this
       value.  This field is treated as an unsigned value.

   Member ID (4 octets) - This is the Member ID of the Rekey sequence
       contained in this Rekey Array.  This field is treated as an octet
       string.  For Key Download Data Item Type of Rekey - LKH, refer to
       Section A.2 for a description of this value.

   Number of KEK Keys (2 octets) - This value is the number of distinct
       KEK keys in this sequence.  This value is treated as an unsigned
       integer in network byte order format.

   Key Datum(s) (variable length) - The sequence of KEKs in Key Datum
       format.  The format for each Key Datum in this sequence is
       defined in section 7.4.1.1.

   Key ID (for Key ID within the Rekey) - LKH space, refer to Section
       A.2 for a description of this value.

7.4.2.  Key Download Payload Processing

   Prior to processing its data, the payload contents MUST be decrypted.

   When processing the Key Download Payload, the following fields MUST
   be checked for correct values:

Top      Up      ToC       Page 64 
   1.  Next Payload, RESERVED, Payload Length - These fields are
       processed as defined in Section 7.2.2, "Generic Payload Header
       Processing".

   2.  KDD Item Type - All KDD Item Type fields MUST be checked to be a
       valid Key Download Data Item type as defined by Table 15.  If the
       value is not valid, then an error is logged.  If in Verbose Mode,
       an appropriate message containing notification value Payload-
       Malformed will be sent.

   3.  Key Type - All Key Type fields MUST be checked to be a valid
       encryption type as defined by Table 16.  If the value is not
       valid, then an error is logged.  If in Verbose Mode, an
       appropriate message containing notification value Invalid-Key-
       Information will be sent.

   4.  Key Expiration Date - All Key Expiration Date fields MUST be
       checked confirm that their values represent a future and not a
       past time value.  If the value is not valid, then an error is
       logged.  If in Verbose Mode, an appropriate message containing
       notification value Invalid-Key-Information will be sent.

   The length and counter fields in the payload are used to help process
   the payload.  If any field is found to be incorrect, then an error is
   logged.  If in Verbose Mode, an appropriate message containing
   notification value Payload-Malformed will be sent.

7.5.  Rekey Event Payload

   Refer to the terminology section for the different terms relating to
   keys used within this section.

7.5.1.  Rekey Event Payload Structure

   The Rekey Event Payload MAY contain multiple keys encrypted in
   Wrapping KEKs.  Figure 14 shows the format of the payload.  If the
   data to be contained within a Rekey Event Payload is too large for
   the payload, the sequence can be split across multiple Rekey Event
   Payloads at a Rekey Event Data boundary.

Top      Up      ToC       Page 65 
    0                   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        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! RekeyEvnt Type!  Rekey Event Header                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ Rekey Event Data(s)                                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 14: Rekey Event Payload Format

   The Rekey Event Payload fields are defined as follows:

   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 the
       "chaining" capability.  Table 12 identifies the payload types.
       This field is treated as an unsigned value.

   RESERVED (1 octet) - Unused, set to 0.

   Payload Length (2 octets) - Length in octets of the current payload,
       including the generic payload header.  This field is treated as
       an unsigned integer in network byte order format.

   Rekey Event Type (1 octet) - Specifies the type of Rekey Event being
       used.  Table 17 presents the types of Rekey events.  This field
       is treated as an unsigned value.

   Rekey Event Header (variable length) - This is the header information
       for the Rekey Event.  The format for this is defined in Section
       7.5.1.1, "Rekey Event Header Structure".

   Rekey Event Data(s) (variable length) - This is the rekey information
       for the Rekey Event.  The format for this is defined in Section
       7.5.1.2, "Rekey Event Data Structure".

   The Rekey Event payload type is three (3).

Top      Up      ToC       Page 66 
                       Table 17: Rekey Event Types

   Rekey_Event_Type     Value       Definition/Defined In
   _____________________________________________________________________

   None                   0         This type MUST be implemented.
                                    In this case, the size of the Rekey
                                    Event Data field will be zero bytes
                                    long.  The purpose of a Rekey Event
                                    Payload with type None is when it is
                                    necessary to send out a new token
                                    with no rekey information.  GSAKMP
                                    rekey msg requires a Rekey Event
                                    Payload, and in this instance it
                                    would have rekey data of type None.
   GSAKMP_LKH             1         The rekey data will be of
                                    type LKH formatted according to
                                    GSAKMP.  The format for this field
                                    is defined in Section 7.5.1.2.
   Reserved to IANA    2 - 192
   Private Use        193 - 255

7.5.1.1.  Rekey Event Header Structure

   The format for the Rekey Event Header is shown in Figure 15.

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                    Group ID Value                             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                    Group ID Value                             !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Time/Date Stamp                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                               ! RekeyEnt Type ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Algorithm Ver ! # of Rekey Event Data(s)      !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 15: Rekey Event Header Format

Top      Up      ToC       Page 67 
   Group Identification Value (variable length) - Indicates the
       name/title of the group to be rekeyed.  This is the same format,
       length, and value as the Group Identification Value in Section
       7.1, "GSAKMP Header".

   Time/Date Stamp (15 octets) - This is the time value when the Rekey
       Event Data was generated.  This field contains the timestamp in
       UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 -
       9999), MM is the numerical value of the month (01 - 12), DD is
       the day of the month (01 - 31), HH is the hour of the day (00 -
       23), MM is the minute within the hour (00 - 59), SS is the
       seconds within the minute (00 - 59), and the letter Z indicates
       that this is Zulu time.  This format is loosely based on
       [RFC3161].

   Rekey Event Type (1 octet) - This is the Rekey algorithm being used
       for this group.  The values for this field can be found in Table
       17.  This field is treated as an unsigned value.

   Algorithm Version (1 octet) - Indicates the version of the Rekey Type
       being used.  For Rekey Event Type of GSAKMP_LKH, refer to Section
       A.2 for a description of this value.  This field is treated as an
       unsigned value.

   # of Rekey Event Data(s) (2 octets) - The number of Rekey Event
       Data(s) contained in the Rekey Data.  This value is treated as an
       unsigned integer in network byte order.

7.5.1.2.  Rekey Event Data Structure

   As defined in the Rekey Event Header, # of Rekey Data(s) field,
   multiple pieces of information are sent in a Rekey Event Data.  Each
   end user, will be interested in only one Rekey Event Data among all
   of the information sent.  Each Rekey Event Data will contain all the
   Key Packages that a user requires.  For each Rekey Event Data, the
   data following the Wrapping fields is encrypted with the key
   identified in the Wrapping Header.  Figure 16 shows the format of
   each Rekey Event Data.

Top      Up      ToC       Page 68 
    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Packet Length                 ! Wrapping KeyID                ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                               ! Wrapping Key Handle           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                               ! # of Key Packages             !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Key Packages(s)                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 16: Rekey Event Data Format

   Packet Length (2 octets) - Length in octets of the Rekey Event Data,
       which consists of the # of Key Packages and the Key Packages(s).
       This value is treated as an unsigned integer in network byte
       order.

   Wrapping KeyID (4 octets) - This is the Key ID of the KEK that is
       being used for encryption/decryption of the new (rekeyed) keys.
       For Rekey Event Type of Rekey - LKH, refer to Section A.2 for a
       description of this value.

   Wrapping Key Handle (4 octets) - This is a Key Handle of the KEK that
       is being used for encryption/decryption of the new (rekeyed)
       keys.  Refer to Section 7.4.1.1 for the values of this field.

   # of Key Packages (2 octets) - The number of key packages contained
       in this Rekey Event Data.  This value is treated as an unsigned
       integer in network byte order.

   Key Package(s) (variable length) - The type/length/value format of a
       Key Datum.  The format for this is defined in Section 7.5.1.2.1.

7.5.1.2.1.  Key Package Structure

   Each Key Package contains all the information about the key.  Figure
   17 shows the format for a Key Package.

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! KeyPkg Type   ! Key Package Length            ! Key Datum     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 17: Key Package Format

Top      Up      ToC       Page 69 
   Key Package Type (1 octet) - The type of key in this key package.
       Legal values for this field are defined in Table 15, Key Download
       Data Types.  This field is treated as an unsigned value.

   Key Package Length (2 octets) - The length of the Key Datum.  This
       field is treated as an unsigned integer in network byte order
       format.

   Key Datum (variable length) - The actual data of the key.  The format
       for this field is defined in Section 7.4.1.1, "Key Datum
       Structure".

7.5.2.  Rekey Event Payload Processing

   When processing the Rekey Event Payload, the following fields MUST be
   checked for correct values:

   1.  Next Payload, RESERVED, Payload Length - These fields are
       processed as defined in Section 7.2.2, "Generic Payload Header
       Processing".

   2.  Rekey Event Type field within "Rekey Event" payload header - The
       Rekey Event Type MUST be checked to be a valid rekey event type
       as defined by Table 17.  If the Rekey Event Type is not valid,
       then regardless of mode (e.g., Terse or Verbose) an error is
       logged.  No response error message is generated for receipt of a
       Group Management Message.

   3.  Group ID Value - The Group ID value of the Rekey Event Header
       received message MUST be checked against the GroupID of the Group
       Component.  If no match is found, the payload is discarded, then
       regardless of mode (e.g., Terse or Verbose) an error is logged.
       No response error message is generated for receipt of a Group
       Management Message.

   4.  Date/Time Stamp - The Date/Time Stamp value of the Rekey Event
       Header MAY be checked to determine if the Rekey Event generation
       time is recent relative to network delay and processing times.
       If the TimeStamp is judged not to be recent, an error is logged.
       No response error message is generated for receipt of a Group
       Management Message.

   5.  Rekey Event Type field within the "Rekey Event Header" - The
       Rekey Event Type of the Rekey Event Header received message MUST
       be checked to be a valid rekey event type, as defined by Table
       17, and the same value of the Rekey Event Type earlier in this
       payload.  If the Rekey Event Type is not valid or not equal to
       the previous value of the Rekey Event Type, then regardless of

Top      Up      ToC       Page 70 
       mode (e.g., Terse or Verbose) an error is logged.  No response
       error message is generated for receipt of a Group Management
       Message.

   6.  Algorithm Version - The Rekey Algorithm Version number MUST be
       checked to ensure that the version indicated is supported.  If it
       is not supported, then regardless of mode (e.g., Terse or
       Verbose) an error is logged.  No response error message is
       generated for receipt of a Group Management Message.

   The length and counter fields are used to help process the message.
   If any field is found to be incorrect, then termination processing
   MUST be initiated.

   A GM MUST process all the Rekey Event Datas as based on the rekey
   method used there is a potential that multiple Rekey Event Datas are
   for this GM.  The Rekey Event Datas are processed in order until all
   Rekey Event Datas are consumed.

   1.  Wrapping KeyID - The Wrapping KeyID MUST be checked against the
       list of stored KEKs that this GM holds.  If a match is found,
       then continue processing this Rekey Event Data.  Otherwise, skip
       to the next Rekey Event Data.

   2.  Wrapping Handle - If a matching Wrapping KeyID was found, then
       the Wrapping Handle MUST be checked against the handle of the KEK
       for which the KeyID was a match.  If the handles match, then the
       GM will process the Key Packages associated with this Rekey Event
       Data.  Otherwise, skip to the next Rekey Event Data.

   If a GM has found a matching Wrapping KeyID and Wrapping Handle, the
   GM decrypts the remaining data in this Rekey Event Data according to
   policy using the KEK defined by the Wrapping KeyID and Handle.  After
   decrypting the data, the GM extracts the # of Key Packages field to
   help process the subsequent Key Packages.  The Key Packages are
   processed as follows:

   1.  Key Package Type - The Key Package Type MUST be checked to be a
       valid key package type as defined by Table 15.  If the Key
       Package Type is not valid, then regardless of mode (e.g., Terse
       or Verbose) an error is logged.  No response error message is
       generated for receipt of a Group Management Message.

   2.  Key Package Length - The Key Package Length is used to process
       the subsequent Key Datum information.

Top      Up      ToC       Page 71 
   3.  Key Type - The Key Type MUST be checked to be a valid key type as
       defined by Table 16.  If the Key Package Type is not valid, then
       regardless of mode (e.g., Terse or Verbose) an error is logged.
       No response error message is generated for receipt of a Group
       Management Message.

   4.  Key ID - The Key ID MUST be checked against the set of Key IDs
       that this user maintains for this Key Type.  If no match is
       found, then regardless of mode (e.g., Terse or Verbose) an error
       is logged.  No response error message is generated for receipt of
       a Group Management Message.

   5.  Key Handle - The Key Handle is extracted as is and is used to be
       the new Key Handle for the Key currently associated with the Key
       Package's Key ID.

   6.  Key Creation Date - The Key Creation Date MUST be checked that it
       is subsequent to the Key Creation Date for the currently held
       key.  If this date is prior to the currently held key, then
       regardless of mode (e.g., Terse or Verbose) an error is logged.
       No response error message is generated for receipt of a Group
       Management Message.

   7.  Key Expiration Date - The Key Expiration Date MUST be checked
       that it is subsequent to the Key Creation Date just received and
       that the time rules conform with policy.  If the expiration date
       is not subsequent to the creation date or does not conform with
       policy, then regardless of mode (e.g., Terse or Verbose) an error
       is logged.  No response error message is generated for receipt of
       a Group Management Message.

   8.  Key Data - The Key Data is extracted based on the length
       information in the key package.

   If there were no errors when processing the Key Package, the key
   represented by the KeyID will have all of its data updated based upon
   the received information.

7.6.  Identification Payload

7.6.1.  Identification Payload Structure

   The Identification Payload contains entity-specific data used to
   exchange identification information.  This information is used to
   verify the identities of members.  Figure 18 shows the format of the
   Identification Payload.

Top      Up      ToC       Page 72 
    0                   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 Classif    !  ID Type      !      Identification Data      ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 18: Identification Payload Format

   The Identification Payload fields are defined as follows:

   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 the
       "chaining" capability.  Table 12 identifies the payload types.
       This field is treated as an unsigned value.

   RESERVED (1 octet) - Unused, set to 0.

   Payload Length (2 octets) - Length in octets of the current payload,
       including the generic payload header.  This field is treated as
       an unsigned integer in network byte order format.

   Identification (ID) Classification (1 octet) - Classifies the
       ownership of the Identification Data.  Table 18 identifies
       possible values for this field.  This field is treated as an
       unsigned value.

                   Table 18: Identification Classification

                        ID_Classification     Value
                       _______________________________

                        Sender                  0
                        Receiver                1
                        Third Party             2
                        Reserved to IANA     3 - 192
                        Private Use         193 - 255

   Identification (ID) Type (1 octet) - Specifies the type of
       Identification being used.  Table 19 identifies possible values
       for this type.  This field is treated as an unsigned value.  All
       defined types are OPTIONAL unless otherwise stated.

Top      Up      ToC       Page 73 
   Identification Data (variable length) - Contains identity
       information.  The values for this field are group specific, and
       the format is specified by the ID Type field.  The format for
       this field is stated in conjunction with the type in Table 19.

   The payload type for the Identification Payload is four (4).

                      Table 19: Identification Types

   ID_Type              Value       PKIX Cert           Description
                                    Field               Defined In
   _____________________________________________________________________

   Reserved               0
   ID_IPV4_ADDR           1         SubjAltName         See [IKEv2]
                                    iPAddress           Section 3.5.
   ID_FQDN                2         SubjAltName         See [IKEv2]
                                    dNSName             Section 3.5.
   ID_RFC822_ADDR         3         SubjAltName         See [IKEv2]
                                    rfc822Name          Section 3.5.
   Reserved               4
   ID_IPV6_ADDR           5         SubjAltName         See [IKEv2]
                                    iPAddress           Section 3.5.
   Reserved             6 - 8
   ID_DER_ASN1_DN         9         Entire Subject,     See [IKEv2]
                                    bitwise Compare     Section 3.5.
   Reserved               10
   ID_KEY_ID              11        N/A                 See [IKEv2]
   Reserved            12 - 29                          Section 3.5.
   Unencoded Name         30        Subject             The format for
    (ID_U_NAME)                                         this type is
                                                        defined in
                                                        Section 7.6.1.1.
   ID_DN_STRING           31        Subject             See [RFC4514].
                                                        This type MUST
                                                        be implemented.
   Reserved to IANA    32 - 192
   Private Use        193 - 255

Top      Up      ToC       Page 74 
7.6.1.1.  ID_U_NAME Structure

   The format for type Unencoded Name (ID_U_NAME) is shown in Figure 19.

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Serial Number                                                 ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Length                                                        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! DN Data                                                       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 19: Unencoded Name (ID-U-NAME) Format

   Serial Number (20 octets) - The certificate serial number.  This
       field is treated as an unsigned integer in network byte order
       format.

   Length (4 octets) - Length in octets of the DN Data field.  This
       field is treated as an unsigned integer in network byte order
       format.

   DN Data (variable length) - The actual UTF-8 DN value (Subject field)
       using the slash (/) character for field delimiters (e.g.,
       "/C=US/ST=MD/L=Somewhere/O=ACME, Inc./OU=DIV1/CN=user1/
       Email=user1@acme.com" without the surrounding quotes).

7.6.2.  Identification Payload Processing

   When processing the Identification Payload, the following fields MUST
   be checked for correct values:

   1.  Next Payload, RESERVED, Payload Length - These fields are
       processed as defined in Section 7.2.2, "Generic Payload Header
       Processing".

Top      Up      ToC       Page 75 
   2.  Identification Classification - The Identification Classification
       value MUST be checked to be a valid identification classification
       type as defined by Table 18.  If the value is not valid, then an
       error is logged.  If in Verbose Mode, an appropriate message
       containing notification value Payload-Malformed will be sent.

   3.  Identification Type - The Identification Type value MUST be
       checked to be a valid identification type as defined by Table 19.
       If the value is not valid, then an error is logged.  If in
       Verbose Mode, an appropriate message containing notification
       value Payload-Malformed will be sent.

   4.  Identification Data - This Identification Data MUST be processed
       according to the identification type specified.  The type will
       define the format of the data.  If the identification data is
       being used to find a match and no match is found, then an error
       is logged.  If in Verbose Mode, an appropriate message containing
       notification value Invalid-ID-Information will be sent.

7.6.2.1.  ID_U_NAME Processing

   When processing the Identification Data of type ID_U_NAME, the
   following fields MUST be checked for correct values:

   1.  Serial Number - The serial number MUST be a greater than or equal
       to one (1) to be a valid serial number from a conforming CA
       [RFC3280].  If the value is not valid, then an error is logged.
       If in Verbose Mode, an appropriate message containing
       notification value Payload-Malformed will be sent.

   2.  DN Data - The DN data is processed as a UTF-8 string.

   3.  The CA MUST be a valid trusted policy creation authority as
       defined by the Policy Token.

   These 2 pieces of information, Serial Number and DN Data, in
   conjunction, will then be used for party identification.  These
   values are also used to help identify the certificate when necessary.



(page 75 continued on part 4)

Next RFC Part