tech-invite   World Map     

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

RFC 4535

 
 
 

GSAKMP: Group Secure Association Key Management Protocol

Part 4 of 4, p. 75 to 106
Prev RFC Part

 


prevText      Top      Up      ToC       Page 75 
7.7.  Certificate Payload

7.7.1.  Certificate Payload Structure

   The Certificate Payload provides a means to transport certificates or
   other certificate-related information via GSAKMP and can appear in
   any GSAKMP message.  Certificate payloads SHOULD be included in an
   exchange whenever an appropriate directory service (e.g., LDAP
   [RFC4523]) is not available to distribute certificates.  Multiple

Top      Up      ToC       Page 76 
   certificate payloads MAY be sent to enable verification of
   certificate chains.  Conversely, zero (0) certificate payloads may be
   sent, and the receiving GSAKMP MUST rely on some other mechanism to
   retrieve certificates for verification purposes.  Figure 20 shows the
   format of the Certificate 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        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Cert Type                     !    Certificate Data           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 20: Certificate Payload Format

   The Certificate 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.

   Certificate Type (2 octets) - This field indicates the type of
       certificate or certificate-related information contained in the
       Certificate Data field.  Table 20 presents the types of
       certificate payloads.  This field is treated as an unsigned
       integer in network byte order format.

   Certificate Data (variable length) - Actual encoding of certificate
       data.  The type of certificate is indicated by the Certificate
       Type/Encoding field.

   The payload type for the Certificate Payload is six (6).

Top      Up      ToC       Page 77 
                   Table 20: Certificate Payload Types

   Certificate_Type                   Value        Description/
                                                   Defined In
   _____________________________________________________________________

   None                                 0
   Reserved                           1 - 3
   X.509v3 Certificate                  4          This type MUST be
     -- Signature                                  implemented.
     -- DER Encoding                               Contains a DER
                                                   encoded X.509
                                                   certificate.
   Reserved                           5 - 6
   Certificate Revocation List          7          Contains a BER
     (CRL)                                         encoded X.509 CRL.
   Reserved                           8 - 9
   X.509 Certificate                   10          See [IKEv2], Sec 3.6.
     -- Attribute
   Raw RSA Key                         11          See [IKEv2], Sec 3.6.
   Hash and URL of X.509               12          See [IKEv2], Sec 3.6.
    Certificate
   Hash and URL of X.509               13          See [IKEv2], Sec 3.6.
    bundle
   Reserved to IANA                14 -- 49152
   Private Use                   49153 -- 65535

7.7.2.  Certificate Payload Processing

   When processing the Certificate 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.  Certificate Type - The Certificate Type value MUST be checked to
       be a valid certificate type as defined by Table 20.  If the value
       is not valid, then an error is logged.  If in Verbose Mode, an
       appropriate message containing notification value Cert-Type-
       Unsupported will be sent.

   3.  Certificate Data - This Certificate Data MUST be processed
       according to the certificate type specified.  The type will
       define the format of the data.  Receipt of a certificate of the
       trusted policy creation authority in a Certificate payload causes

Top      Up      ToC       Page 78 
       the payload to be discarded.  This received certificate MUST NOT
       be used to verify the message.  The certificate of the trusted
       policy creation authority MUST be retrieved by other means.

7.8.  Signature Payload

7.8.1.  Signature Payload Structure

       The Signature Payload contains data generated by the digital
       signature function.  The digital signature, as defined by the
       dissection of each message, covers the message from the GSAKMP
       Message Header through the Signature Payload, up to but not
       including the Signature Data Length.  Figure 21 shows the format
       of the Signature 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        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Signature Type                ! Sig ID Type   !               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ Signature Timestamp                                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                               ! Signer ID Length              !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                    Signer ID Data                             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !     Signature Length          !     Signature Data            ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 21: Signature Payload Format

   The Signature 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.

Top      Up      ToC       Page 79 
   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.

   Signature Type (2 octets) - Indicates the type of signature.  Table
       21 presents the allowable signature types.  This field is treated
       as an unsigned integer in network byte order format.

                        Table 21: Signature Types

   Signature Type                         Value         Description/
                                                        Defined In
   _____________________________________________________________________

   DSS/SHA1 with ASN.1/DER encoding         0           This type MUST
   (DSS-SHA1-ASN1-DER)                                  be supported.
   RSA1024-MD5                              1           See [RFC3447].
   ECDSA-P384-SHA3                          2           See [FIPS186-2].
   Reserved to IANA                       3 - 41952
   Private Use                        41953 - 65536

   Signature ID Type (1 octet) - Indicates the format for the Signature
       ID Data.  These values are the same as those defined for the
       Identification Payload Identification types, which can be found
       in Table 19.  This field is treated as an unsigned value.

   Signature Timestamp (15 octets) - This is the time value when the
       digital signature was applied.  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].

   Signer ID Length (2 octets) - Length in octets of the Signer's ID.
       This field is treated as an unsigned integer in network byte
       order format.

   Signer ID Data (variable length) - Data identifying the Signer's ID
       (e.g., DN).  The format for this field is based on the Signature
       ID Type field and is shown where that type is defined.  The
       contents of this field MUST be checked against the Policy Token
       to determine the authority and access of the Signer within the
       context of the group.

Top      Up      ToC       Page 80 
   Signature Length (2 octets) - Length in octets of the Signature Data.
       This field is treated as an unsigned integer in network byte
       order format.

   Signature Data (variable length) - Data that results from applying
       the digital signature function to the GSAKMP message and/or
       payload.

   The payload type for the Signature Payload is eight (8).

7.8.2.  Signature Payload Processing

   When processing the Signature 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.  Signature Type - The Signature Type value MUST be checked to be a
       valid signature type as defined by Table 21.  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.  Signature ID Type - The Signature ID Type value MUST be checked
       to be a valid signature ID 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.  Signature Timestamp - This field MAY be checked to determine if
       the transaction signing time is fresh relative to expected
       network delays.  Such a check is appropriate for systems in which
       archived sequences of events are desired.

       NOTE: The maximum acceptable age of a signature timestamp
       relative to the local system clock is a locally configured
       parameter that can be tuned by its GSAKMP management interface.

   5.  Signature ID Data - This field will be used to identify the
       sending party.  This information MUST then be used to confirm
       that the correct party sent this information.  This field is also
       used to retrieve the appropriate public key of the certificate to
       verify the message.

Top      Up      ToC       Page 81 
   6.  Signature Data - This value MUST be compared to the recomputed
       signature to verify the message.  Information on how to verify
       certificates used to ascertain the validity of the signature can
       be found in [RFC3280].  Only after the certificate identified by
       the Signature ID Data is verified can the signature be computed
       to compare to the signature data for signature verification.  A
       potential error that can occur during signature verification is
       Authentication-Failed.  Potential errors that can occur while
       processing certificates for signature verification are: Invalid-
       Certificate, Invalid-Cert-Authority, Cert-Type-Unsupported, and
       Certificate-Unavailable.

   The length fields in the Signature Payload are used to process the
   remainder of the payload.  If any field is found to be incorrect,
   then termination processing MUST be initiated.

7.9.  Notification Payload

7.9.1.  Notification Payload Structure

   The Notification Payload can contain both GSAKMP and group-specific
   data and is used to transmit informational data, such as error
   conditions, to a GSAKMP peer.  It is possible to send multiple
   independent Notification payloads in a single GSAKMP message.  Figure
   22 shows the format of the Notification 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         !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Notification Type             !  Notification Data            ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 22: Notification Payload Format

   The Notification 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.

Top      Up      ToC       Page 82 
   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.

   Notification Type (2 octets) - Specifies the type of notification
       message.  Table 22 presents the Notify Payload Types.  This field
       is treated as an unsigned integer in network byte order format.

   Notification Data (variable length) - Informational or error data
       transmitted in addition to the Notify Payload Type.  Values for
       this field are Domain of Interpretation (DOI) specific.

   The payload type for the Notification Payload is nine (9).

                    Table 22: Notification Types

      Notification Type                             Value
     __________________________________________________________

      None                                            0
      Invalid-Payload-Type                            1
      Reserved                                      2 - 3
      Invalid-Version                                 4
      Invalid-Group-ID                                5
      Invalid-Sequence-ID                             6
      Payload-Malformed                               7
      Invalid-Key-Information                         8
      Invalid-ID-Information                          9
      Reserved                                     10 - 11
      Cert-Type-Unsupported                           12
      Invalid-Cert-Authority                          13
      Authentication-Failed                           14
      Reserved                                     15 - 16
      Certificate-Unavailable                         17
      Reserved                                        18
      Unauthorized-Request                            19
      Reserved                                     20 - 22
      Acknowledgement                                 23
      Reserved                                     24 - 25
      Nack                                            26
      Cookie-Required                                 27
      Cookie                                          28
      Mechanism Choices                               29
      Leave Group                                     30
      Departure Accepted                              31
      Request to Depart Error                         32
      Invalid Exchange Type                           33
      IPv4 Value                                      34

Top      Up      ToC       Page 83 
      IPv6 Value                                      35
      Prohibited by Group Policy                      36
      Prohibited by Locally Configured Policy         37
      Reserved to IANA                            38 - 49152
      Private Use                               49153 -- 65535

7.9.1.1.  Notification Data - Acknowledgement (ACK) Payload Type

   The data portion of the Notification payload of type ACK either
   serves as confirmation of correct receipt of the Key Download message
   or, when needed, provides other receipt information when included in
   a signed message.  Figure 23 shows the format of the Notification
   Data - Acknowledge Payload Type.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Ack Type      !       Acknowledgement Data                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 23: Notification Data - Acknowledge Payload Type Format

   The Notification Data - Acknowledgement Payload Type data fields are
   defined as follows:

   Ack Type (1 octet) - Specifies the type of acknowledgement.  Table 23
       presents the Notify Acknowledgement Payload Types.  This field is
       treated as an unsigned value.

                        Table 23: Acknowledgement Types

             ACK_Type             Value       Definition
            _____________________________________________________

             Simple                 0         Data portion null.
             Reserved to IANA     1 - 192
             Private Use        193 - 255

7.9.1.2.  Notification Data - Cookie_Required and Cookie Payload Type

   The data portion of the Notification payload of types Cookie_Required
   and Cookie contain the Cookie value.  The value for this field will
   have been computed by the responder GC/KS and sent to the GM.  The GM
   will take the value received and copy it into the Notification
   payload Notification Data field of type Cookie that is transmitted in
   the "Request to Join with Cookie Info" back to the GC/KS.  The cookie
   value MUST NOT be modified.

Top      Up      ToC       Page 84 
   The format for this is already described in the discussion on cookies
   in Section 5.2.2.

7.9.1.3.  Notification Data - Mechanism Choices Payload Type

   The data portion of the Notification payload of type Mechanism
   Choices contains the mechanisms the GM is requesting to use for the
   negotiation with the GC/KS.  This information will be supplied by the
   GM in a RTJ message.  Figure 24 shows the format of the Notification
   Data - Mechanism Choices Payload Type.  Multiple type|length|data
   choices are strung together in one notification payload to allow a
   user to transmit all relevant information within one Notification
   Payload.  The length of the payload will control the parsing of the
   Notification Data Mechanism Choices field.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Mech Type     ! Mechanism Choice Data         !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..

   Figure 24: Notification Data - Mechanism Choices Payload Type Format

   The Notification Data - Mechanism Choices Payload Type data fields
   are defined as follows:

   Mechanism Type (1 octet) - Specifies the type of mechanism.  Table 24
       presents the Notify Mechanism Choices Mechanism Types.  This
       field is treated as an unsigned value.

                          Table 24: Mechanism Types

      Mechanism_Type             Value       Mechanism Choice
                                             Data Value Table Reference
     ___________________________________________________________________

      Key Creation Algorithm       0         Table 26
      Encryption Algorithm         1         Table 16
      Nonce Hash Algorithm         2         Table 25
      Reserved to IANA          3 - 192
      Private Use              193 - 255

   Mechanism Choice Data (2 octets) - The data value for the mechanism
       type being selected.  The values are specific to each Mechanism
       Type defined.  All tables necessary to define the values that are
       not defined elsewhere (in this specification or others) are
       defined here.  This field is treated as an unsigned integer in
       network byte order format.

Top      Up      ToC       Page 85 
                       Table 25: Nonce Hash Types

   Nonce_Hash_Type        Value         Description
   __________________________________________________________________

   Reserved                 0
   SHA-1                    1           This type MUST be supported.
   Reserved to IANA     2 - 49152
   Private Use        49153 - 65535

7.9.1.4.  Notification Data - IPv4 and IPv6 Value Payload Types

   The data portion of the Notification payload of type IPv4 and IPv6
   value contains the appropriate IP value in network byte order.  This
   value will be set by the creator of the message for consumption by
   the receiver of the message.

7.9.2.  Notification Payload Processing

   When processing the Notification 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.  Notification Type - The Notification type value MUST be checked
       to be a notification type as defined by Table 22.  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.  Notification Data - This Notification Data MUST be processed
       according to the notification type specified.  The type will
       define the format of the data.  When processing this data, any
       type field MUST be checked against the appropriate table for
       correct values.  If the contents of the Notification Data are 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 86 
7.10.  Vendor ID Payload

7.10.1.  Vendor ID Payload Structure

       The Vendor ID Payload contains a vendor-defined constant.  The
       constant is used by vendors to identify and recognize remote
       instances of their implementations.  This mechanism allows a
       vendor to experiment with new features while maintaining
       backwards compatibility.  Figure 25 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        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                         Vendor ID (VID)                       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 25: Vendor ID Payload Format

   A Vendor ID payload MAY announce that the sender is capable of
   accepting certain extensions to the protocol, or it MAY simply
   identify the implementation as an aid in debugging.  A Vendor ID
   payload MUST NOT change the interpretation of any information defined
   in this specification.  Multiple Vendor ID payloads MAY be sent.  An
   implementation is NOT REQUIRED to send any Vendor ID payload at all.

   A Vendor ID payload may be sent as part of any message.  Receipt of a
   familiar Vendor ID payload allows an implementation to make use of
   Private Use numbers described throughout this specification --
   private payloads, private exchanges, private notifications, etc.
   This implies that all the processing rules defined for all the
   payloads are now modified to recognize all values defined by this
   Vendor ID for all fields of all payloads.  Unfamiliar Vendor IDs MUST
   be ignored.

   Writers of Internet-Drafts who wish to extend this protocol MUST
   define a Vendor ID payload to announce the ability to implement the
   extension in the Internet-Draft.  It is expected that Internet-Drafts
   that gain acceptance and are standardized will be given assigned
   values out of the Reserved to IANA range, and the requirement to use
   a Vendor ID payload will go away.

   The Vendor ID payload fields are defined as follows:

Top      Up      ToC       Page 87 
   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.

   Vendor ID (variable length) - The Vendor ID value.  The minimum
       length for this field is four (4) octets.  It is the
       responsibility of the person choosing the Vendor ID to assure its
       uniqueness in spite of the absence of any central registry for
       IDs.  Good practice is to include a company name, a person name,
       or similar type data.  A message digest of a long unique string
       is preferable to the long unique string itself.

   The payload type for the Vendor ID Payload is ten (10).

7.10.2.  Vendor ID Payload Processing

   When processing the Vendor ID 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.  Vendor ID - The Vendor ID Data MUST be processed to determine if
       the Vendor ID value is recognized by the implementation.  If the
       Vendor ID value is not recognized, then regardless of mode (e.g.,
       Terse or Verbose) this information is logged.  Processing of the
       message MUST continue regardless of recognition of this value.

   It is recommended that implementations that want to use Vendor-ID-
   specific information attempt to process the Vendor ID payloads of an
   incoming message prior to the remainder of the message processing.
   This will allow the implementation to recognize that when processing
   other payloads it can use the larger set of values for payload fields
   (Private Use values, etc.) as defined by the recognized Vendor IDs.

Top      Up      ToC       Page 88 
7.11.  Key Creation Payload

7.11.1.  Key Creation Payload Structure

   The Key Creation Payload contains information used to create key
   encryption keys.  The security attributes for this payload are
   provided in the Policy Token.  Figure 26 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        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Key Creation Type             ! Key Creation Data             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 26: Key Creation Payload Format

   The Key Creation 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.

   Key Creation Type (2 octets) - Specifies the type of Key Creation
       being used.  Table 26 identifies the types of key creation
       information.  This field is treated as an unsigned integer in
       network byte order format.

   Key Creation Data (variable length) - Contains Key Creation
       information.  The values for this field are group specific, and
       the format is specified by the key creation type field.

   The payload type for the Key Creation Packet is eleven (11).

Top      Up      ToC       Page 89 
               Table 26: Types of Key Creation Information

   Key Creation Type           Value        Definition/Defined In
   _____________________________________________________________________

   Reserved                    0 - 1
   Diffie-Hellman                2          This type MUST be supported.
     1024-bit MODP Group                    Defined in [IKEv2] B.2.
     Truncated                              If the output of the process
                                            is longer than needed for
                                            the defined mechanism, use
                                            the first X low order bits
                                            and truncate the remainder.
   Reserved                   3 - 13
   Diffie-Hellman               14          Defined in [RFC3526].
     2048-bit MODP Group                    If the output of the process
     Truncated                              is longer than needed for
                                            the defined mechanism, use
                                            the first X low order bits
                                            and truncate the remainder.
   Reserved to IANA         15 - 49152
   Private Use             49153 - 65535

7.11.2.  Key Creation Payload Processing

   The specifics of the Key Creation Payload are defined in Section
   7.11.

   When processing the Key Creation 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.  Key Creation Type - The Key Creation Type value MUST be checked
       to be a valid key creation type as defined by Table 26.  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 Creation Data - This Key Creation Data MUST be processed
       according to the key creation type specified to generate the KEK
       to protect the information to be sent in the appropriate message.
       The type will define the format of the data.

Top      Up      ToC       Page 90 
   Implementations that want to derive other keys from the initial Key
   Creation keying material (for example, DH Secret keying material)
   MUST define a Key Creation Type other than one of those shown in
   Table 26.  The new Key Creation Type must specify that derivation's
   algorithm, for which the KEK MAY be one of the keys derived.

7.12.  Nonce Payload

7.12.1.  Nonce Payload Structure

   The Nonce Payload contains random data used to guarantee freshness
   during an exchange and protect against replay attacks.  Figure 27
   shows the format of the Nonce 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        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Nonce Type    !            Nonce Data                         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 27: Nonce Payload Format

   The Nonce 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.

   Nonce Type (1 octet) - Specifies the type of nonce being used.  Table
       27 identifies the types of nonces.  This field is treated as an
       unsigned value.

Top      Up      ToC       Page 91 
                          Table 27: Nonce Types

   Nonce_Type              Value      Definition
   _____________________________________________________________________

   None                      0
   Initiator (Nonce_I)       1
   Responder (Nonce_R)       2
   Combined (Nonce_C)        3        Hash (Append
                                      (Initiator_Value,Responder_Value))
                                      The hash type comes from the
                                      Policy (e.g., Security Suite
                                      Definition of Policy Token).
   Reserved to IANA       4 - 192
   Private Use           192 - 255

   Nonce Data (variable length) - Contains the nonce information.  The
       values for this field are group specific, and the format is
       specified by the Nonce Type field.  If no group-specific
       information is provided, the minimum length for this field is 4
       bytes.

   The payload type for the Nonce Payload is twelve (12).

7.12.2.  Nonce Payload Processing

   When processing the Nonce 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.  Nonce Type - The Nonce Type value MUST be checked to be a valid
       nonce type as defined by Table 27.  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.  Nonce Data - This is the nonce data and it must be checked
       according to its content.  The size of this field is defined in
       Section 7.12, "Nonce Payload".  Refer to Section 5.2, "Group
       Establishment", for interpretation of this field.

Top      Up      ToC       Page 92 
8.  GSAKMP State Diagram

   Figure 28 presents the states encountered in the use of this
   protocol.  Table 28 defines the states.  Table 29 defines the
   transitions.

         !-----------------> (                  )
         !   !-------------> (       Idle       ) <------------------!
         !   !               (                  )                    !
         !   !                !                !                     !
         !   !                !                !                     !
         !   !               (1a)             (1)                    !
         !   !                !                !                     !
         !   !                !                !                     !
         !   !                V                V                     !
         !   !---(5a)--- (Wait for  )       (Wait for  ) ----(5)-----!
         !               (Group     )       (GC/KS Event) <---
         !               (Membership)        ^  !   \        \
         !                    !              !  !    \        \
         !                    !              !  !     \--(2)---\
         !                   (2a)           (4)(3)
         !                    !              !  !
         !                    !              !  !
         !                    V              !  V
         !-------(4a)--- (Wait for  )       (Wait for  )
                         (Group     )       (Response  )
                         (Membership)       (from Key  )
                    /--> (Event     )       (Download  )
                   /         /
                  /         /
                 /--(3a)---/


                    Figure 28: GSAKMP State Diagram

Top      Up      ToC       Page 93 
                        Table 28: GSAKMP States
  ______________________________________________________________________

  Idle                 : GSAKMP Application waiting for input
  ______________________________________________________________________

  Wait for GC/KS Event : GC/KS up and running, waiting for events
  ______________________________________________________________________

  Wait for Response    : GC/KS has sent Key Download,
   from Key Download   :  waiting for response from GM
  ______________________________________________________________________

  Wait for Group       : GM in process of joining group
   Membership          :
  ______________________________________________________________________

  Wait for Group       : GM has group key, waiting for
   Membership Event    :  group management messages.
  ______________________________________________________________________

Top      Up      ToC       Page 94 
                   Table 29: State Transition Events
  ____________________________________________________________________

  Transition 1  : Create group command
  ______________:_____________________________________________________
                :
  Transition 2  : Receive bad RTJ
                : Receive valid command to change group membership
                : Send Compromise message x times
                : Member Deregistration
  ______________:_____________________________________________________
                :
  Transition 3  : Receive valid RTJ
  ______________:_____________________________________________________
                :
  Transition 4  : Timeout
                : Receive Ack
                : Receive Nack
  ______________:_____________________________________________________
                :
  Transition 5  : Delete group command
  ______________:_____________________________________________________
                :
  Transition 1a : Join group command
  ______________:_____________________________________________________
                :
  Transition 2a : Send Ack
  ______________:_____________________________________________________
                :
  Transition 3a : Receipt of group management messages
  ______________:_____________________________________________________
                :
  Transition 4a : Delete group command
                : Deregistration command
  ______________:_____________________________________________________
                :
  Transition 5a : Time out
                : Msg failure
                : errors
                :
  ____________________________________________________________________

Top      Up      ToC       Page 95 
9.  IANA Considerations

9.1.  IANA Port Number Assignment

   IANA has provided GSAKMP port number 3761 in both the UDP and TCP
   spaces.  All implementations MUST use this port assignment in the
   appropriate manner.

9.2.  Initial IANA Registry Contents

   The following registry entries have been created:

   GSAKMP Group Identification Types (Section 7.1.1)
   GSAKMP Payload Types (Section 7.1.1)
   GSAKMP Exchange Types (Section 7.1.1)
   GSAKMP Policy Token Types (Section 7.3.1)
   GSAKMP Key Download Data Item Types (Section 7.4.1)
   GSAKMP Cryptographic Key Types (Section 7.4.1.1)
   GSAKMP Rekey Event Types (Section 7.5.1)
   GSAKMP Identification Classification (Section 7.6.1)
   GSAKMP Identification Types (Section 7.6.1)
   GSAKMP Certificate Types (Section 7.7.1)
   GSAKMP Signature Types (Section 7.8.1)
   GSAKMP Notification Types (Section 7.9.1)
   GSAKMP Acknowledgement Types (Section 7.9.1.1)
   GSAKMP Mechanism Types (Section 7.9.1.3)
   GSAKMP Nonce Hash Types (Section 7.9.1.3)
   GSAKMP Key Creation Types (Section 7.11.1)
   GSAKMP Nonce Types (Section 7.12.1)

   Changes and additions to the following registries are by IETF
   Standards Action:

   GSAKMP Group Identification Types
   GSAKMP Payload Types
   GSAKMP Exchange Types
   GSAKMP Policy Token Types
   GSAKMP Key Download Data Item Types
   GSAKMP Rekey Event Types
   GSAKMP Identification Classification
   GSAKMP Notification Types
   GSAKMP Acknowledgement Types
   GSAKMP Mechanism Types
   GSAKMP Nonce Types

Top      Up      ToC       Page 96 
   Changes and additions to the following registries are by Expert
   Review:

   GSAKMP Cryptographic Key Types
   GSAKMP Identification Types
   GSAKMP Certificate Types
   GSAKMP Signature Types
   GSAKMP Nonce Hash Types
   GSAKMP Key Creation Types

10.  Acknowledgements

   This document is the collaborative effort of many individuals.  If
   there were no limit to the number of authors that could appear on an
   RFC, the following, in alphabetical order, would have been listed:
   Haitham S. Cruickshank of University of Surrey, Sunil Iyengar of
   University Of Surrey Gavin Kenny of LogicaCMG, Patrick McDaniel of
   AT&T Labs Research, and Angela Schuett of NSA.

   The following individuals deserve recognition and thanks for their
   contributions, which have greatly improved this protocol: Eric Harder
   is an author to the Tunneled-GSAKMP, whose concepts are found in
   GSAKMP as well.  Rod Fleischer, also a Tunneled-GSAKMP author, and
   Peter Lough were both instrumental in coding a prototype of the
   GSAKMP software and helped define many areas of the protocol that
   were vague at best.  Andrew McFarland and Gregory Bergren provided
   critical analysis of early versions of the specification.  Ran
   Canetti analyzed the security of the protocol and provided denial of
   service suggestions leading to optional "cookie protection".

Top      Up      ToC       Page 97 
11.  References

11.1.  Normative References

   [DH77]      Diffie, W., and M. Hellman, "New Directions in
               Cryptography", IEEE Transactions on Information Theory,
               June 1977.

   [FIPS186-2] NIST, "Digital Signature Standard", FIPS PUB 186-2,
               National Institute of Standards and Technology, U.S.
               Department of Commerce, January 2000.

   [FIPS196]   "Entity Authentication Using Public Key Cryptography,"
               Federal Information Processing Standards Publication 196,
               NIST, February 1997.

   [IKEv2]     Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
               RFC 4306, December 2005.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2409]   Harkins, D. and D. Carrel, "The Internet Key Exchange
               (IKE)", RFC 2409, November 1998.

   [RFC2412]   Orman, H., "The OAKLEY Key Determination Protocol", RFC
               2412, November 1998.

   [RFC2627]   Wallner, D., Harder, E., and R. Agee, "Key Management for
               Multicast: Issues and Architectures", RFC 2627, June
               1999.

   [RFC3280]   Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
               X.509 Public Key Infrastructure Certificate and
               Certificate Revocation List (CRL) Profile", RFC 3280,
               April 2002.

   [RFC3629]   Yergeau, F., "UTF-8, a transformation format of ISO
               10646", STD 63, RFC 3629, November 2003.

   [RFC4514]   Zeilenga, K., Ed., "Lightweight Directory Access Protocol
               (LDAP): String Representation of Distinguished Names",
               RFC 4514, June 2006.

   [RFC4534]   Colegrove, A. and H. Harney, "Group Security Policy Token
               v1", RFC 4534, June 2006.

Top      Up      ToC       Page 98 
11.2.  Informative References

   [BMS]       Balenson, D., McGrew, D., and A. Sherman, "Key Management
               for Large Dynamic Groups:  One-Way Function Trees and
               Amortized Initialization", Work in Progress, February
               1999.

   [HCM]       H. Harney, A. Colegrove, P. McDaniel, "Principles of
               Policy in Secure Groups", Proceedings of Network and
               Distributed Systems Security 2001 Internet Society, San
               Diego, CA, February 2001.

   [HHMCD01]   Hardjono, T., Harney, H., McDaniel, P., Colegrove, A.,
               and P. Dinsmore, "Group Security Policy Token:
               Definition and Payloads", Work in Progress, August 2003.

   [RFC2093]   Harney, H. and C. Muckenhirn, "Group Key Management
               Protocol (GKMP) Specification", RFC 2093, July 1997.

   [RFC2094]   Harney, H. and C. Muckenhirn, "Group Key Management
               Protocol (GKMP) Architecture", RFC 2094, July 1997.

   [RFC2408]   Maughan D., Schertler M., Schneider M., and Turner J.,
               "Internet Security Association and Key Management
               Protocol (ISAKMP)", RFC 2408, Proposed Standard, November
               1998

   [RFC2451]   Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
               Algorithms", RFC 2451, November 1998.

   [RFC2522]   Karn, P. and W. Simpson, "Photuris: Session-Key
               Management Protocol", RFC 2522, March 1999.

   [RFC4523]   Zeilenga, K., "Lightweight Directory Access Protocol
               (LDAP) Schema Definitions for X.509 Certificates", RFC
               4523, June 2006.

   [RFC2974]   Handley, M., Perkins, C., and E. Whelan, "Session
               Announcement Protocol", RFC 2974, October 2000.

   [RFC3161]   Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
               "Internet X.509 Public Key Infrastructure Time-Stamp
               Protocol (TSP)", RFC 3161, August 2001.

   [RFC3261]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
               A., Peterson, J., Sparks, R., Handley, M., and E.
               Schooler, "SIP: Session Initiation Protocol", RFC 3261,
               June 2002.

Top      Up      ToC       Page 99 
   [RFC3447]   Jonsson, J. and B. Kaliski, "Public-Key Cryptography
               Standards (PKCS) #1: RSA Cryptography Specifications
               Version 2.1", RFC 3447, February 2003.

   [RFC3526]   Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
               Diffie-Hellman groups for Internet Key Exchange (IKE)",
               RFC 3526, May 2003.

   [RFC3740]   Hardjono, T. and B. Weis, "The Multicast Group Security
               Architecture", RFC 3740, March 2004.

   [RFC4086]   Eastlake, D., 3rd, Schiller, J., and S. Crocker,
               "Randomness Requirements for Security", BCP 106, RFC
               4086, June 2005.

Top      Up      ToC       Page 100 
Appendix A.  LKH Information

   This appendix will give an overview of LKH, define the values for
   fields within GSAKMP messages that are specific to LKH, and give an
   example of a Rekey Event Message using the LKH scheme.

A.1.  LKH Overview

   LKH provides a topology for handling key distribution for a group
   rekey.  It rekeys a group based upon a tree structure and subgroup
   keys.  In the LKH tree shown in Figure 29, members are represented by
   the leaf nodes on the tree, while intermediate tree nodes represent
   abstract key groups.  A member will possess multiple keys: the group
   traffic protection key (GTPK), subgroup keys for every node on its
   path to the root of the tree, and a personal key.  For example, the
   member labeled as #3 will have the GTPK, Key A, Key D, and Key 3.

                              root
                    /                      \
                   /                        \
                A                               B
            /      \                        /      \
           /        \                      /        \
        C               D               E               F
      /   \           /   \           /   \           /   \
     /     \         /     \         /     \         /     \
   1         2     3         4     5         6     7         8


                      Figure 29: LKH Tree

   This keying topology provides for a rapid rekey to all but a
   compromised member of the group.  If Member 3 were compromised, the
   new GTPK (GTPK') would need to be distributed to the group under a
   key not possessed by Member 3.  Additionally, new Keys A and D (Key
   A' and Key D') would also need to be securely distributed to the
   other members of those subtrees.  Encrypting the GTPK' with Key B
   would securely distribute that key to Members 5, 6, 7, and 8.  Key C
   can be used to encrypt both the GTPK' and Key A' for Members 1 and 2.
   Member 3's nearest neighbor, Member 4, can obtain GTPK', Key D', and
   Key A' encrypted under its personal key, Key 4.  At the end of this
   process, the group is securely rekeyed with Member 3 fully excluded.

Top      Up      ToC       Page 101 
A.2.  LKH and GSAKMP

   When using LKH with GSAKMP, the following issues require attention:

   1.  Rekey Version # - The Rekey Version # in the Rekey Array of the
       Key Download Payload MUST contain the value one (1).

   2.  Algorithm Version - The Algorithm Version in the Rekey Event
       Payload MUST contain the value one (1).

   3.  Degree of Tree - The LKH tree used can be of any degree; it need
       not be binary.

   4.  Node Identification - Each node in the tree is treated as a KEK.
       A KEK is just a special key.  As the rule stated for all keys in
       GSAKMP, the set of the KeyID and the KeyHandle MUST be unique.  A
       suggestion on how to do this will be given in this section.

   5.  Wrapping KeyID and Handle - This is the KeyID and Handle of the
       LKH node used to wrap/encrypt the data in a Rekey Event Data.

   For the following discussion, refer to Figure 30.

   Key:
   o: a node in the LKH tree
   N: this line contains the KeyID node number
   L: this line contains the MemberID number for all leaves ONLY

       LEVEL
       ----
       root                          o
   N:                         /      1     \
                             /              \
       1              o                             o
   N:              /  2  \                       /  3  \
                  /       \                     /       \
       2      o               o             o               o
   N:        /4\             /5\           /6\             /7\
            /   \           /   \         /   \           /   \
       3  o       o       o       o     o       o       o       o
   N:     8       9      10      11    12      13      14      15
   L:     1       2       3       4     5       6       7       8

                        Figure 30: GSAKMP LKH Tree

Top      Up      ToC       Page 102 
   To guarantee uniqueness of KeyID, the Rekey Controller SHOULD build a
   virtual tree and label the KeyID of each node, doing a breadth-first
   search of a fully populated tree regardless of whether or not the
   tree is actually full.  For simplicity of this example, the root of
   the tree was given KeyID value of one (1).  These KeyID values will
   be static throughout the life of this tree.  Additionally, the rekey
   arrays distributed to GMs requires a MemberID value associated with
   them to be distributed with the KeyDownload Payload.  These MemberID
   values MUST be unique.  Therefore, the set associated with each leaf
   node (the nodes from that leaf back to the root) are given a
   MemberID.  In this example, the leftmost leaf node is given MemberID
   value of one (1).  These 2 sets of values, the KeyIDs (represented on
   lines N) and the MemberIDs (represented on line L), will give
   sufficient information in the KeyDownload and RekeyEvent Payloads to
   disseminate information.  The KeyHandle associated with these keys is
   regenerated each time the key is replaced in the tree due to
   compromise.

A.3.  LKH Examples

   Definition of values:
   0xLLLL          - length value
   0xHHHHHHH#      - handle value
   YYYYMMDDHHMMSSZ - time value

A.3.1.  LKH Key Download Example

   This section will give an example of the data for the Key Download
   payload.  The GM will be given MemberID 1 and its associated keys.
   The data shown will be subsequent to the Generic Payload Header.

   | GTPK | MemberID 1 | KeyID 2 | KeyID 4 | KeyID 8

   Number of Items                   - 0x0002
     Item #1:
       Key Download Data Item Type   - 0x00 (GTPK)
       Key Download Data Item Length - 0xLLLL
         Key Type                    - 0x03 (3DES`CBC64`192)
         Key ID                      - KEY1
         Key Handle                  - 0xHHHHHHH0
         Key Creation Date           - YYYYMMDDHHMMSSZ
         Key Expiration Date         - YYYYMMDDHHMMSSZ
         Key Data                    - variable, based on key definition
     Item #2:
       Key Download Data Item Type   - 0x01 (Rekey - LKH)
       Key Download Data Item Length - 0xLLLL
       Rekey Version Number          - 0x01
       Member ID                     - 0x00000001

Top      Up      ToC       Page 103 
       Number of KEK Keys            - 0x0003
         KEK #1:
           Key Type                  - 0x03 (3DES`CBC64`192)
           Key ID                    - 0x00000002
           Key Handle                - 0xHHHHHHH2
           Key Creation Date         - YYYYMMDDHHMMSSZ
           Key Expiration Date       - YYYYMMDDHHMMSSZ
           Key Data                  - variable, based on key definition
         KEK #2:
           Key Type                  - 0x03 (3DES`CBC64`192)
           Key ID                    - 0x00000004
           Key Handle                - 0xHHHHHHH4
           Key Creation Date         - YYYYMMDDHHMMSSZ
           Key Expiration Date       - YYYYMMDDHHMMSSZ
           Key Data                  - variable, based on key definition
         KEK #3:
           Key Type                  - 0x03 (3DES`CBC64`192)
           Key ID                    - 0x00000008
           Key Handle                - 0xHHHHHHH8
           Key Creation Date         - YYYYMMDDHHMMSSZ
           Key Expiration Date       - YYYYMMDDHHMMSSZ
           Key Data                  - variable, based on key definition

A.3.2.  LKH Rekey Event Example

   This section will give an example of the data for the Rekey Event
   payload.  The GM with MemberID 6 will be keyed out of the group.  The
   data shown will be subsequent to the Generic Payload Header.

   | Rekey Event Type | GroupID | Date/Time | Rekey Type |
   Algorithm Ver | # of Packets |
   { (GTPK)2, (GTPK, 3', 6')12, (GTPK, 3')7 }

   This data shows that three packets are being transmitted.  Read each
   packet as:

   a) GTPK wrapped in LKH KeyID 2
   b) GTPK, LKH KeyIDs 3' & 6', all wrapped in LKH KeyID 12
   c) GTPK and LKH KeyID 3', all wrapped in LKH KeyID 7

   NOTE: Although in this example multiple keys are encrypted under one
   key, alternative pairings are legal (e.g., (GTPK)2, (GTPK)3', (3')6',
   (3')7', (6')12).

   We will show the format for all header data and packet (b).

Top      Up      ToC       Page 104 
   Rekey Event Type  - 0x01 (GSAKMP`LKH)
   GroupID           - 0xAABBCCDD
                       0x12345678
   Time/Date Stamp   - YYYYMMDDHHMMSSZ
   Rekey Event Type  - 0x01 (GSAKMP`LKH)
   Algorithm Vers    - 0x01
   # of RkyEvt Pkts  - 0x0003
   For Packet (b):
   Packet Length       - 0xLLLL
   Wrapping KeyID      - 0x000C
   Wrapping Key Handle - 0xHHHHHHHD
   # of Key Packages   - 0x0003
     Key Package 1:
       Key Pkg Type  - 0x00 (GTPK)
       Pack Length   - 0xLLLL
         Key Type            - 0x03 (3DES`CBC64`192)
         Key ID              - KEY1
         Key Handle          - 0xHHHHHHH0
         Key Creation Date   - YYYYMMDDHHMMSSZ
         Key Expiration Date - YYYYMMDDHHMMSSZ
         Key Data            - variable, based on key definition
     Key Package 2:
       Key Pkg Type  - 0x01 (Rekey  - LKH)
       Pack Length   - 0xLLLL
         Key Type            - 0x03 (3DES`CBC64`192)
         Key ID              - 0x00000003
         Key Handle          - 0xHHHHHHH3
         Key Creation Date   - YYYYMMDDHHMMSSZ
         Key Expiration Date - YYYYMMDDHHMMSSZ
         Key Data            - variable, based on key definition
     Key Package 3:
       Key Pkg Type  - 0x01 (Rekey  - LKH)
       Pack Length   - 0xLLLL
         Key Type            - 0x03 (3DES`CBC64`192)
         Key ID              - 0x00000006
         Key Handle          - 0xHHHHHHH6
         Key Creation Date   - YYYYMMDDHHMMSSZ
         Key Expiration Date - YYYYMMDDHHMMSSZ
         Key Data            - variable, based on key definition

Top      Up      ToC       Page 105 
Authors' Addresses

   Hugh Harney (point-of-contact)
   SPARTA, Inc.
   7110 Samuel Morse Drive
   Columbia, MD 21046

   Phone: (443) 430-8032
   Fax:   (443) 430-8181
   EMail: hh@sparta.com


   Uri Meth
   SPARTA, Inc.
   7110 Samuel Morse Drive
   Columbia, MD 21046

   Phone: (443) 430-8058
   Fax:   (443) 430-8207
   EMail: umeth@sparta.com


   Andrea Colegrove
   SPARTA, Inc.
   7110 Samuel Morse Drive
   Columbia, MD 21046

   Phone: (443) 430-8014
   Fax:   (443) 430-8163
   EMail: acc@sparta.com


   George Gross
   IdentAware Security
   82 Old Mountain Road
   Lebanon, NJ 08833

   Phone: (908) 268-1629
   EMail: gmgross@identaware.com

Top      Up      ToC       Page 106 
Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).