Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4535

GSAKMP: Group Secure Association Key Management Protocol

Pages: 106
Proposed Standard
Part 4 of 4 – Pages 75 to 106
First   Prev   None

Top   ToC   RFC4535 - Page 75   prevText

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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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   ToC   RFC4535 - 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).