[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

SPARTA, Inc.                                                H Harney (SPARTA)
INTERNET-DRAFT                                                A Schuett (NSA)
                                                         A Colegrove (SPARTA)
                                       SPARTA, Inc., National Security Agency
draft-ietf-msec-gsakmp-light-sec-01.txt                             July 2002


                                GSAKMP Light




                            Status of this memo



This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.  Internet-Drafts are working documents
of the Internet Engineering Task Force (IETF), its areas, and its working
groups.  Note that other groups may also distribute working documents as
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and
may be updated, replaced, or obsoleted by other documents at any time.  It
is inappropriate to use Internet-Drafts as reference material or to cite
them other than as ``work in progress''.

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Document expiration:  December 31, 2002


                                  Abstract


     A protocol specification must balance two often conflicting goals:
    to produce as general a protocol as possible, and to produce a
    simple protocol.  The Group Secure Association Key Management
    Protocol (GSAKMP) is a general protocol for creating and managing
    cryptographic groups on a network.  This document describes
    the GSAKMP-Light (GL) profile, a way to shorten the number of
    messages exchanged during secure group establishment.  The GSAKMP
    protocol assumed that group members joining a secure group had
    no information about the specific security mechanisms used by the
    group (for example, the key length, encryption protocol, etc).
    GSAKMP-Light provides a profile for the case where group members


INTERNET-DRAFT                     GSAKMP Light                    July 2002

    have been previously notified of these security mechanisms, used
    for joining a group, during the group announcement or invitation.
    This simplification removes 2 messages from the group establishment
    portion of the GSAKMP protocol, eliminates the need for initiating
    a unicast security association, and removes the need for many
    of the optional fields of individual messages.  The profile
    does not sacrifice any of the security properties of the full
    protocol.  To facilitate the transmission of security mechanism
    settings during session invitation or announcement, this document
    also describes a useful default set of security algorithms and
    configurations, Security Suite 1.  Full specification of this suite
    allows an entire set of algorithms and settings to be described
    to prospective group members in a concise manner.  Future security
    suites can be defined as needed.

































                              Copyright Notice

      Copyright (c) The Internet Society (2002).  All Rights Reserved.



Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt   [Page 2]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

Contents

1 Introduction                                                             6

2 GSAKMP Light (GL)                                                        7
  2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Basis of security                                                        9

4 Sequence of events                                                      10
5 Security Policy                                                         11

6 Security Suite 1 (SS1)                                                  11
  6.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
  6.2 Definition Suite 1  . . . . . . . . . . . . . . . . . . . . . . . . 11

7 Message Structure                                                       12
  7.1 Flow Diagram  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
  7.2 Light Request to Join . . . . . . . . . . . . . . . . . . . . . . . 13
  7.3 Light Key Download  . . . . . . . . . . . . . . . . . . . . . . . . 13
  7.4 Light Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13
  7.5 Group Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 13
    7.5.1Member Joins/Leaves  . . . . . . . . . . . . . . . . . . . . . . 14
    7.5.2Rekey Events . . . . . . . . . . . . . . . . . . . . . . . . . . 14
    7.5.3Group Removal/Destruction  . . . . . . . . . . . . . . . . . . . 15
8 GSAKMP Payload Structure                                                15
  8.1 GSAKMP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
  8.2 Generic Payload Header  . . . . . . . . . . . . . . . . . . . . . . 18
  8.3 Data Attributes Payload . . . . . . . . . . . . . . . . . . . . . . 18
  8.4 Policy Token Payload  . . . . . . . . . . . . . . . . . . . . . . . 19
  8.5 Key Download Payload  . . . . . . . . . . . . . . . . . . . . . . . 20
    8.5.1GTEK Key Packet  . . . . . . . . . . . . . . . . . . . . . . . . 21
    8.5.2Rekey Key Packet . . . . . . . . . . . . . . . . . . . . . . . . 22
  8.6 Rekey Event Payload . . . . . . . . . . . . . . . . . . . . . . . . 23
  8.7 Identification Payload  . . . . . . . . . . . . . . . . . . . . . . 24
  8.8 Authorization Payload . . . . . . . . . . . . . . . . . . . . . . . 25
  8.9 Certificate Payload . . . . . . . . . . . . . . . . . . . . . . . . 26
  8.10Certificate Request Payload . . . . . . . . . . . . . . . . . . . . 27
  8.11Signature Payload . . . . . . . . . . . . . . . . . . . . . . . . . 28
  8.12Notification Payload  . . . . . . . . . . . . . . . . . . . . . . . 30
    8.12.1Notification Data - Acknowledgement (ACK) Message Type . . . . . 32
  8.13Vendor ID Payload . . . . . . . . . . . . . . . . . . . . . . . . . 33
  8.14Key Creation Payload  . . . . . . . . . . . . . . . . . . . . . . . 34
  8.15Nonce Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

9 References and authors addesses                                         36
  9.1 References  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
  9.2 Authors Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 38






Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt   [Page 3]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

List of Figures

  1   GSAKMP Light Ladder Diagram . . . . . . . . . . . . . . . . . . . . 12
  2   GSAKMP Header Format  . . . . . . . . . . . . . . . . . . . . . . . 16
  3   Generic Payload Header  . . . . . . . . . . . . . . . . . . . . . . 18
  4   Data Attributes Payload . . . . . . . . . . . . . . . . . . . . . . 19
  5   Policy Token Payload Format . . . . . . . . . . . . . . . . . . . . 19
  6   Key Download Payload Format . . . . . . . . . . . . . . . . . . . . 20
  7   Rekey Event Payload Format  . . . . . . . . . . . . . . . . . . . . 23
  8   Identification Payload Format . . . . . . . . . . . . . . . . . . . 24
  9   Authorization Payload Format  . . . . . . . . . . . . . . . . . . . 25
  10  Certificate Payload Format  . . . . . . . . . . . . . . . . . . . . 26
  11  Certificate Request Payload Format  . . . . . . . . . . . . . . . . 28
  12  Signature Payload Format  . . . . . . . . . . . . . . . . . . . . . 29
  13  Notification Payload Format . . . . . . . . . . . . . . . . . . . . 30
  14  Notification Data - Acknowledge Message Type Format . . . . . . . . 32
  15  Vendor ID Payload Format  . . . . . . . . . . . . . . . . . . . . . 34
  16  Key Creation Payload Format . . . . . . . . . . . . . . . . . . . . 34
  17  Nonce Payload Format  . . . . . . . . . . . . . . . . . . . . . . . 35


































Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt   [Page 4]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

List of Tables

  1   Light Request to Join Message Definition  . . . . . . . . . . . . . 13
  2   Light Key Download Message Definition . . . . . . . . . . . . . . . 13
  3   Light Acknowledgment Message Definition . . . . . . . . . . . . . . 14
  4   Rekey Event Message Definition  . . . . . . . . . . . . . . . . . . 15
  5   Group Removal/Destruction Message Definition  . . . . . . . . . . . 15
  6   Group Identification Types  . . . . . . . . . . . . . . . . . . . . 16
  7   Payload Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
  8   Exchange Types  . . . . . . . . . . . . . . . . . . . . . . . . . . 17
  9   Policy Token Types  . . . . . . . . . . . . . . . . . . . . . . . . 20
  10  Key Download Data Types . . . . . . . . . . . . . . . . . . . . . . 21
  11  Rekey Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 23
  12  Identification Types  . . . . . . . . . . . . . . . . . . . . . . . 25
  13  Authorization Types . . . . . . . . . . . . . . . . . . . . . . . . 26
  14  Certificate Payload Types . . . . . . . . . . . . . . . . . . . . . 27
  15  Signature Types . . . . . . . . . . . . . . . . . . . . . . . . . . 29
  16  Notify Messages Types . . . . . . . . . . . . . . . . . . . . . . . 31
  17  Notify Messages -- Status Types . . . . . . . . . . . . . . . . . . 32
  18  Acknowledgement Types . . . . . . . . . . . . . . . . . . . . . . . 33
  19  Types Of Key Creation Information . . . . . . . . . . . . . . . . . 35
  20  Nonce Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36































Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt   [Page 5]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

1 Introduction


The Group Secure Association Key Management Protocol (GSAKMP)[HCHMF01]
is a general protocol for creating and managing cryptographic groups on
a network.  A cryptographic group is a logical association of users or
hosts that support a common security policy using shared cryptographic
keying material.  The GSAKMP-Light (GL) profile of GSAKMP is a three
message version of GSAKMP that does not require an underlying secure unicast
security association.  GL achieves this simplification by assuming that the
group creation process includes the transmission to prospective members of
an acceptable security suite for group establishment.

While GSAKMP provides mechanisms for cryptographic group creation,
other protocols may be used in conjunction with GSAKMP to allow various
applications to create groups according to their application-specific
requirements.  For example, in a small-scale video conference the organizer
might use a session invitation protocol like SIP [RFC2543] to transmit
information about the time of the conference, the address of the session,
and the formats to be used.  For a large-scale video transmission, the
organizer might use a multicast announcement protocol like SAP [RFC2974].
In both of these cases, non-sensitive information about the security
mechanisms to be used in the cryptographic group establishment could
easily be transmitted to the prospective group members.  As we will show,
including this information allows 2 messages to be removed from the group
establishment portion of GSAKMP, producing the GSAKMP-Light (GL) profile.
GSAKMP-Light provides a profile for the group establishment case where group
members have been previously notified of a set of security mechanisms during
the group announcement or invitation.

The GSAKMP protocol includes mechanisms for group policy dissemination,
group key dissemination, and group rekey operation.  The GL profile shortens
the policy and key dissemination steps, but does not limit or decrease
the security of either of these operations.  This profile of GSAKMP still
contains the necessary mechanisms to facilitate policy enforcement and
key management.  Key management must be paired with policy enforcement
to produce a viable secure association.  As in GSAKMP, GL uses the policy
definition stated in Internet Draft [HHMCD01] as the policy input to the
enforcement process.

While the GL profile does move some security profile information outside
of the protocol, the entire policy token is still transmitted within the
protocol.  The transmission of a fully specified policy token to all joining
group members is what allows GSAKMP to support distributed architectures
and multiple data sources within a single cryptographic group.  Distributed
architectures are supported because the policy token allows rule-based
allocation of Group Security Association actions to network resources.
Multiple data sources are supported because the inclusion of a policy token
and policy payloads allow group members to review the group access control
and authorization parameters.  This member review process gives each member
and each potential source of data the ability to determine if the group


Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt   [Page 6]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

provides adequate protection for member data.

The GL profile uses the same rekey operation as GSAKMP. This document
repeats the specification for the rekey operation and GSAKMP payloads.  This
is to avoid having two draft documents getting out of synchronization.
Like GSAKMP, the GL profile is provably secure, supports distributed
architectures, allows multiple data sources within a single cryptographic
group, and provides group management mechanisms.

To facilitate the transmission of security mechanism settings during session
invitation/announcement, this document also describes a useful default
set of security algorithms and configurations, Security Suite 1.  Full
specification of this suite allows an entire set of algorithms and settings
to be described to prospective group members in a concise manner.  Future
security suites can be defined as needed.



2 GSAKMP Light (GL)


2.1 Definitions


Group Member:  A group member (GM) is any entity with access to the group
keys.  Regardless of how a member becomes a part of the group or how the
group is structured, GMs will perform the following actions:


1.  Validate the authorizations for security relevant actions;

2.  Accept group keys from the GC;

3.  Request group keys from the GC;

4.  Maintain local Certificate Revocation Lists (CRLs);

5.  Enforce the cooperative group policies as stated in the group policy
    token;

6.  Perform peer review of key management actions; and

7.  Manage their local key.


Group Secure Association (GSA): A cryptographic group is a logical
association of users or hosts that share cryptographic key(s).  This
group may be established to support associations between applications or
communication protocols.




Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt   [Page 7]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

Group Policy:  The group policy completely describes the protection
mechanisms and security relevant behaviors of the group.  This policy
must be commonly understood and enforced by the group for coherent secure
operations.

Policy Token/Certificate:  The policy token is a data structure used to
disseminate group policy and the mechanisms to enforce it.  The policy token
is issued and signed by an authorized source.  Each member of the group must
verify the token, meet the group join policy, and enforce the policy of the
group.  The group policy data element will contain a variety of information
including:



1.  GSAKMP protocol format,

2.  Key creation method,

3.  Key dissemination policy,

4.  Access control policy,

5.  Group authorization policy, and

6.  Compromise recovery policy.


The policy token layout will be fully presented in the Group Policy Token
Specification document.

Group Controller:  The Group Controller (GC) is a group member with
authority to perform any critical protocol actions including:


1.  Creating and distributing keys;

2.  Maintain the Rekey infrastructure; and

3.  Building and maintaining the Rekey arrays.


As the group evolves, it may become desirable to have multiple controllers
perform these functions (e.g., Rekey Controller and Group Key Controller).

Subordinate Group Controller (SGC): Any group member, as defined in
the group policy, and having the appropriate processing and trust
characteristics, has the potential to act as a Subordinate Group Controller
(SGC) thus allowing the group processing and communication requirements to
be distributed equitably throughout the network.  If the group is structured
in such a way, the delegated group members would be identified via the
policy token.  The SGCs may perform actions delegated to them by the GC
including:

Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt   [Page 8]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

1.  Dissemination of the group key and

2.  Management of the status of the local group.



The ease of managing a very large group may also be improved by delegating
the creation of subordinate LKH arrays Ref [WHA98] to the SGCs.  The SGCs
would have the authority and mechanisms necessary to create and disseminate
the LKH arrays for the members under their control.  A more detailed
discussion of LKH arrays may be found in the Logical Key Hierarchy (LKH)
Protocol document.

Peer-to-Peer SA: Peer-to-Peer SA keys can be created by using any number
of key generation protocols including the Internet Secure Association Key
Management Protocol (ISAKMP)/IPSec [RFC 2401] and HS/SSL. These protocols
rely on cooperative key generation algorithms and on peer review of
permissions.  Modern SA protocols are specifically developed to support this
task.  Once the peer-to-peer SA is established, the group protocol can use
that SA mechanism for secure confidential peer communications throughout the
life of the group.

GSA Keys:  GSA keys can be created using strong randomization key generation
protocols.  These protocols rely on a cooperatively conferred policy.
Once the group keys are created and disseminated to the group members,
the group protocol can use that SA mechanism for secure confidential group
communications throughout the life of the group.

Group Traffic Encryption Key (GTEK): The key or keys created for encrypting
the group data.

Logical Key Hierarchy (LKH) array:  The group of keys created to facilitate
the LKH compromise recovery methodology.

Compromise Recovery:  The act of recovering a secure operating state after
detecting that a group member cannot be trusted.


3 Basis of security


GSAKMP Light is based upon several existing protocols:  ISAKMP [MSST98],
GSAKMP, FIPS Pub 196 [FIPS 196], and Diffie-Hellman key exchange [DH77].
ISAKMP provided a flexible structure of chained payloads in support of
authenticated key exchange and security association management for diverse
pairwise communications.  GSAKMP expanded upon these features to provide
policy enforcement features in support of diverse group communications,
and tunneling over existing security protocols.  FIPS Pub 196 provides a
mutual authentication protocol.  Finally, Diffie-Hellman provides dynamic
key exchange.



Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt   [Page 9]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

Using the GSAKMP payloads, GSAKMP Light provides an authenticated security
management protocol.  Its message structure greatly parallels that of the
FIPS Pub 196 mutual authentication exchange.  Two points of departure:
the first message of GSAKMP Light is signed and in the second and third
messages, a nonce and combined nonce (hash of the two) is provided.  The
signature on the first message allows authenticated Diffie-Hellman, thereby
preventing man-in-the-middle attacks.  The digested combined nonce is a
construct, which if a longer exchange were present would allow for only one
value to be used after the third message.



4 Sequence of events


The sequence of events for GL is straightforward.  The sequence is:


1.  Security suite definition is transmitted outside the protocol.

2.  Light Request to Join (L-RTJ)

3.  Light Key Download (L-KD)

4.  Light Acknowledgement (L-ACK)

5.  Group SA up and running

6.  Group management


The announcement will contain at a minimum the security suite for GL.
Security Suite 1 is defined below.

The member will initiate the following series of 3 messages for group
establishment.


-  Light Request to Join initiates the GL group establishment portion
   of the protocol. L-RTJ contains a key creation field for use in group
   establishment.
-  Light Key Download contains a key creation field and encrypted Policy
   Token and Key Download payloads.
-  The Light Acknowledgement message completes the authentication of the
   GCKS for the member.



Once a member has joined the group the GSA is considered up.

Group management messages are multicast in nature and include rekey, policy
changes, and group deletion.

Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 10]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

5 Security Policy


GL recognizes that the distribution of a key is only relevant to the
security of a system in so far as it represents a valid enforcement of
security policy.



6 Security Suite 1 (SS1)


GL is designed to support architectures with a capability to announce or
otherwise prepublish the group establishment parameters.  These group
establishment parameters must contain enough information for a group member
to configure GL. The SS1 defines the mandatory supported definition of
Category one exchanges for GL.


6.1 Assumptions


Assumption:  There is a mechanism to either announce the Category 1 SA
mechanisms to potential group members, post the Cat 1 policy, or inform
group members of Cat 1 policy.

In the case of an announced Category 1 policy it is desirable to have
concise definitions of entire suites of algorithms and settings.  To this
end the authors define the GSAKMP Light Suite 1.


6.2 Definition Suite 1


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

The GSAKMP Light suite 1 definition defines all the algorithm and
cryptographic definitions required to process the default mode of GSAKMP
Light.  It is important to note that GSAKMP Light does not negotiate
these cryptographic modes.  This definition is set by the Group Owner
via the Policy Token (passed during the GSAKMP Light exchange for member
verification purposes).

The GSAKMP Light Suite definition is:


Key download encryption algorithm definition:
Algorithm:  3DES
Mode:       CBC64


Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 11]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

Key Length: 192 bits


Policy Token encryption algorithm definition:
Algorithm:  3DES
Mode:       CBC64
Key Length: 192 bits


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

NOTE: The p {\&} g values comes from rfc 2409, IKE, section 6.2 Second
      Oakley Group, and p is 1024 bits long.


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



7 Message Structure


7.1 Flow Diagram


The Light Group Establishment Flow Diagram is shown in Figure 1:

          CONTROLLER                  MESSAGE                  MEMBER

                    !<------------Request to Join-------------!
                    !                                         !
                    !-------------Key Download--------------->!
                    !                                         !
                    !<------------Acknowledgment--------------!



                   Figure 1:  GSAKMP Light Ladder Diagram



Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 12]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

7.2 Light Request to Join


The components of a Light Request to Join Message are shown in Table 1:


             Table 1:  Light Request to Join Message Definition

    Message Name  : L-RTJ
    Dissection    : {HDR, GrpID, Key Creation, Nonce_I} SigM, [CertM]
    Payload Types : GSAKMP Header, Key Creation, Nonce, Signature,
                    [Certificate]
       SigM       : Signature of Group Member
       CertM      : Certificate of Group Member
       {}SigX      :Indicates minimum fields used in Signature
       []         : Indicate an optional data item



7.3 Light Key Download


The components of a Light Key Download Message are shown in Table 2:

              Table 2:  Light Key Download Message Definition

    Message Name  : L-KD
    Dissection    : {HDR, GrpID, Member ID, Nonce_R, Nonce_C, Key
                    Creation, (Policy Token)*, (Key Download)*} SigC,
                    [CertC]
    Payload Types : GSAKMP Header, Identification, Nonce, Key
                    Creation, Policy Token, Key Download, Signature,
                    [Certificate]

       SigC       : Signature of Group Controller
       CertC      : Certificate of Group Controller
       {}SigX      :Indicates minimum fields used in Signature
       []         : Indicate an optional data item
       (data)*    : Indicates encrypted information


7.4 Light Acknowledgement


The components of a Light Acknowledgement Message are shown in Table 3:


7.5 Group Maintenance


The Group Maintenance phase includes member joins and leaves, group rekey
activities, and the management of Rekey events.  These activities are

Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 13]


INTERNET-DRAFT                     GSAKMP Light                    July 2002


             Table 3:  Light Acknowledgment Message Definition

    Message Name  : Acknowledgment
    Dissection    : {HDR, GrpID, Nonce_C, ACK}SigM
    Payload Types : GSAKMP Header, Nonce, Notification, Signature

       SigM       : Signature of Group Member
       CertM      : Certificate of Group Member
       {}SigX      :Indicates minimum fields used in Signature

presented in the following sections.


7.5.1 Member Joins/Leaves


The addition of group members to a previously established group will closely
follow the processing presented in Sections 7.1 through 7.4.  With the
exception of the pure group establishment tasks (e.g., creation of policy
token, GTEK, and Rekey array), an entity becomes a GM using the same message
exchanges described in Sections 7.1 through 7.4.

A member who elects to voluntarily leave the group will be responsible for
destroying his key.  Any further action for a voluntary leave should be
specifically addressed in the group's security policy.


7.5.2 Rekey Events


A Rekey event is any action, including compromises, that involves the
creation and dissemination of a new group key and/or Rekey information.

Once it has been identified, using the group's security policy, that a Rekey
event has occurred, the GC must create and send a signed message containing
the GTEK and Rekey array to the group.

Each GM who receives this message must verify the signature on the message
to ensure its authenticity.  If the message signature does not verify, the
processing is terminated.  GSAKMP sends a properly authenticated message
with a Notification Payload of type NACK to indicate termination.  Upon
verification the GM will find the appropriate Rekey download packet and
decrypt the information with a stored Rekey key.

The components of a Rekey Event message are shown in Table  4:







Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 14]


INTERNET-DRAFT                     GSAKMP Light                    July 2002


                  Table 4:  Rekey Event Message Definition

    Message Name  : Rekey Event
    Dissection    : {HDR, GrpID, [Policy Token], Rekey Array}SigC,
                    [CertC]
    Payload Types : GSAKMP Header, [Policy Token], Rekey Event,
                    Signature, [Certificate], [Vendor ID]

       SigC       : Signature of Group Controller
       CertC      : Certificate of Group Controller
       {}SigX      :Indicates minimum fields used in Signature
       []         : Indicate an optional data item

7.5.3 Group Removal/Destruction


At this point in the group's life-cycle, there has been a decision to
destroy the group and the notification is broadcast on a key management
channel or through a directory service.

The components of a Group Removal/Destruction message are shown in  5:


           Table 5:  Group Removal/Destruction Message Definition

    Message Name  : Group Removal/Destruction
    Dissection    : {HDR, GrpID, [Policy Token], Destruct}SigC,
                    [CertC]
    Payload Types : GSAKMP Header, [Policy Token], Notification,
                    Signature, [Certificate], [Vendor ID]

       SigC       : Signature of Group Controller
       CertC      : Certificate of Group Controller
       {}SigX      :Indicates minimum fields used in Signature
       []         : Indicate an optional data item


8 GSAKMP Payload Structure


8.1 GSAKMP Header


The GSAKMP Header fields are defined in Figure 2:


Group Identification Type (1 octet)  - Table 6 presents the group
    identification types.

Group Identification Value (8 octets)  - Indicates the name/title of the


Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 15]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    !Group ID Type  !      Group ID Value                           ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ~               ! Next Payload  !   Version     ! Exchange Type !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ! Sequence ID                                                   !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ! Length                                                        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!



                      Figure 2:  GSAKMP Header Format


                    Table 6:  Group Identification Types


                            Grp ID Type   Value
                           _____________________

                            IPSec IPv4      0
                            IPSec IPv6      1
                            TLS             2
                            SMIME           3
                            Other         4-255


    group.

Next Payload (1 octet)  - Indicates the type of the first payload in the
    message.  The format for each payload is defined in the following
    sections.  Table 7 presents the payload types.

Version (1 octet)  - Indicates the version of the GSAKMP protocol in use.

Exchange Type (1 octet)  - Indicates the type of exchange (also known as
    the message type).  Table 8 presents the exchange type values.

Sequence ID (4 octets)  - Group Management replay protection field.
    Sequence ID for group management messages.  If not a group management
    message, this value is set to zero (0).

Length (4 octets)  - Length of total message (header + payloads) in octets.
    Encryption can expand the size of a GSAKMP message.




Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 16]


INTERNET-DRAFT                     GSAKMP Light                    July 2002





                          Table 7:  Payload Types


                     Next_Payload_Type        Value
                    ___________________________________

                     None                       0
                     Policy Token               1
                     Key Download Packet        2
                     Rekey event                3
                     Identification             4
                     Authorization              5
                     Certificate                6
                     Certificate Request        7
                     Signature                  9
                     Notification              10
                     Vendor ID                 11
                     Key Creation              12
                     Nonce                     13
                     Reserved               14 - 127
                     Private Use           128 -- 255







                          Table 8:  Exchange Types


                    Exchange_Type                Value
                   ____________________________________

                    Request to Join                0
                    Invitation                     1
                    Invitation Response            2
                    Key Download                   3
                    Acknowledgement                4
                    Rekey Event                    5
                    Group Removal/Destruction      6
                    No Message                     7
                    Light Request to Join          8
                    Light Key Download             9
                    Other                       10-255




Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 17]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

8.2 Generic Payload Header


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

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ! Next Payload  !   RESERVED    !         Payload Length        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!



                     Figure 3:  Generic Payload Header


Next Payload (1 octet)  - Identifier for the payload type of the next
    payload in the message.  If the current payload is the last in
    the message, then this field will be 0.  This field provides the
    ``chaining`` capability.

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

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



8.3 Data Attributes Payload


There are instances within GSAKMP where it is necessary to represent
Data Attributes.  These Data Attributes are not a GSAKMP payload, but
are contained within GSAKMP payloads.  The format of the Data Attributes
provides the flexibility for representation of many different types of
information.  There can be multiple Data Attributes within a payload.
The length of the Data Attributes will either be 4 octets or defined by
the Attribute Length field.  This is done using the Attribute Format bit
described in Figure 4.

The Data Attributes fields are defined as follows:


Attribute Type (2 octets)  - Unique identifier for each type of attribute.
    The most significant bit, or Attribute Format (AF), indicates whether
    the data attributes follow the Type/Length/Value (TLV) format or a
    shortened Type/Value (TV) format.  If the AF bit is a zero (0), then the
    Data Attributes are of the Type/Length/Value (TLV) form.  If the AF bit
    is a one (1), then the Data Attributes are of the Type/Value form.

Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 18]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

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



                     Figure 4:  Data Attributes Payload


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

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


8.4 Policy Token Payload


The Policy Token Payload contains group specific information that describes
the group security relevant behaviors, access control parameters, and
security mechanisms.  This information may contain a digital signature(s) to
prove authority and integrity of the information.  Figure 5 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        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    !   ID Type     !              Policy Token Data                ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!



                   Figure 5:  Policy Token Payload Format

The Policy Token Payload fields are defined as follows:


Next Payload (1 octet)  - Identifier for the payload type of the next
    payload in the message.  If the current payload is the last in the
    message, then this field will be 0.

Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 19]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

     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 Download Data                          ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!



                   Figure 6:  Key Download Payload Format


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

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

ID Type (1 octet)  - Specifies the type of Policy Token being used.
    Table 9 identifies the types of policy tokens.

                        Table 9:  Policy Token Types

                           ID_Type       Value

                          ______________________
                           Group           0
                           Auxiliary       1
                           Reserved       2-63
                           Unassigned   64-255

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

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



8.5 Key Download Payload


The Key Download Payload contains group keys.  These key download payloads
can have several security attributes applied to them based upon the security
policy of the group.  Figure 6 shows the format of the payload.

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

The Key Download Payload fields are defined as follows:

Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 20]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

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.

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

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

Key Download Data (variable length)  - Contains Key Download information.



    Number of Key Packets (2 octets)  -- Contains the total number of both
        GTEK and Rekey arrays being passed in this data block.

        For each Key Packet, the data format is as follows:


        Key Download Data (KDD) Type (1 octet)  -- Identifier for the Key
            Data field of this Key Packet.  See Table 10 for the possible
            values of this field.

                     Table 10:  Key Download Data Types

                      Key Download Data Type   Value
                     ________________________________

                      GTEK                       0
                      Rekey                      1
                      Unassigned               2-255

        Key Download Length (2 octets)  -- Length in octets of the Key
            Packet data following this field.

        Key Packet Data (variable length)  -- Contains Key information.
            The format of this field is specific depending on the value of
            the Key Download Data field.



8.5.1 GTEK Key Packet


For a Key Download Data value of GTEK, the Key Packet Data field is
formatted as follows:


Key Type (1 octet)  -- This is the encryption algorithm for which this key
    data is to be used.  This value is specified in the Policy Token.

Key Creation Date (4 octets)  -- This is the time value of when this key

Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 21]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

    data was originally generated.

Key Expiration Date (4 octets)  -- This is the time value of when this key
    is no longer valid for use.

Key Handle (4 octets)  -- This is the randomly generated value to uniquely
    identify a key.

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



8.5.2 Rekey Key Packet


GSAKMP currently uses the Logical Key Hierarchy (LKH) protocol for Rekey
operations.  This Key Packet Data is assumed to contain LKH Array data of
the following format:


LKH Version (1 octet)  -- Contains the version of the LKH protocol which
    the data is formatted in.

Leaf ID (2 octets)  -- This is the Leaf Node ID of the LKH sequence
    contained in this Key Packet Data block.

Number of LKH Keys (2 octets)  -- This value is the number of distinct LKH
    keys in this sequence.

    For each LKH key in the sequence, the data format is as follows:


    LKH ID (2 octets)  -- This is the position of this key in the binary
        tree structure used by LKH.

    Key Type (1 octet)  -- This is the encryption algorithm for which this
        key data is to be used.  This value is specified in the Policy
        Token.

    Key Creation Date (4 octets)  -- This is the time value of when this
        key data was originally generated.

    Key Expiration Date (4 octets)  -- This is the time value of when this
        key is no longer valid for use.

    Key Handle (4 octets)  -- This is the randomly generated value to
        uniquely identify a key.

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


Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 22]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

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



8.6 Rekey Event Payload


The Rekey Event Payload contains multiple keys encrypted in Rekey keys.
These Rekey Event payloads can have several security attributes applied to
them based upon the security policy of the group.  Figure 7 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        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    !   ID Type     !           Rekey Event Data                    ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!



                   Figure 7:  Rekey Event Payload Format

The Rekey Event Payload fields are defined as follows:


Next Payload (1 octet)  - Identifier for the payload type of the next
    payload in the message.  If the current payload is the last in the
    message, then this field will be 0.

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

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

ID Type (1 octet)  - Specifies the type of Rekey Event being used.
    Table 11 presents the types of Rekey events.


                        Table 11:  Rekey Event Types

                       ID_Type                Value
                      ______________________________

                       None                     0
                       Group Recovery           1
                       Individual Recovery      2
                       Maintenance              3
                       Delete Group Key         4
                       Unassigned            5-255

Rekey Event Data (variable length)  - Contains Rekey Event information.

Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 23]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

    The values for this field are group specific and the format is specified
    by the ID Type field.  The format for the LKH type of Rekey Event Data
    is located in the appendix section.



The Rekey Event payload type is three (3).


8.7 Identification Payload


The Identification Payload contains entity-specific data used to
exchange identification information.  This information is used for
determining the identities of negotiating members and may be used for
determining authenticity of information.  Figure 8 shows the format of the
Identification 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        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    !   ID Type     !            Identification Data                ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!



                  Figure 8:  Identification Payload Format

The Identification Payload fields are defined as follows:


Next Payload (1 octet) - Identifier for the payload type of the next
    payload in the message.  If the current payload is the last in the
    message, then this field will be 0.

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

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

ID Type (1 octet)  - Specifies the type of Identification being used.
    Table 12 identifies the types of identities.

Identification Data (variable length)  - Contains identity information.
    The values for this field are group-specific and the format is specified
    by the ID Type field.


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


Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 24]


INTERNET-DRAFT                     GSAKMP Light                    July 2002


                      Table 12:  Identification Types

                ID_Type                               Value
               _____________________________________________

                Sender Distinguished Name               0
                Receiver Distinguished Name             1
                Hash of Sender Distinguished Name       2
                Hash of Receiver Distinguished Name     3
                Unassigned                            4-255


8.8 Authorization Payload


The Authorization Payload contains group-specific data used to exchange role
authorization information.  This information is used for determining the
authorization of entities within a group.  Figure 9 shows the format of the
Authorization 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        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ! Auth Type     !            Authorization Data                 ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!



                  Figure 9:  Authorization Payload Format

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

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

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

Authorization Type (1 octet)  - Specifies the type of role authorization
    being used.  Table 13 identifies the types of roles.

Authorization Data (variable length)  - Contains authorization information.
    The values for this field are group-specific and the format is specified
    by the Authorization Type field.


Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 25]


INTERNET-DRAFT                     GSAKMP Light                    July 2002


                       Table 13:  Authorization Types

              Auth_Type                                Value
             ________________________________________________

              Group Controller                           0
              Group and Rekey Controller                 1
              Rekey Controller                           2
              Subordinate Group Controller               3
              Subordinate Group and Rekey Controller     4
              Subordinate Rekey Controller               5
              Member ID                                  6
              Unassigned                               7-255


The payload type for the Authorization Payload is five (5).


8.9 Certificate Payload


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.  Secure DNS [DNSSEC]) is not available
to distribute certificates.  The Certificate payload MUST be accepted at
any point during an exchange.  Figure 10 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 Encoding !             Certificate Data                  ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!



                   Figure 10:  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.

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

Payload Length (2 octets)  - Length in octets of the current payload,

Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 26]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

    including the generic payload header.

Certificate Encoding (1 octet)  - This field indicates the type of
    certificate or certificate-related information contained in the
    Certificate Data field.  Table 14 presents the types of certificate
    payloads.


                    Table 14:  Certificate Payload Types

               Certificate_Type                      Value
              _______________________________________________

               None                                    0
               PKCS #7 wrapped X.509 certificate       1
               PGP Certificate                         2
               DNS Signed Key                          3
               X.509 Certificate -- Signature          4
               X.509 Certificate - Key Exchange        5
               Kerberos Tokens                         6
               Certificate Revocation List (CRL)       7
               Authority Revocation List (ARL)         8
               SPKI Certificate                        9
               X.509 Certificate -- Attribute         10
               Reserved                            11 -- 255

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


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



8.10 Certificate Request Payload


The Certificate Request Payload provides a means to request certificates
via GSAKMP and can appear in any message.  Certificate Request payloads
SHOULD be included in an exchange whenever an appropriate directory service
(e.g., Secure DNS [DNSSEC]) is not available to distribute certificates.
The Certificate Request payload MUST be accepted at any point during the
exchange.  The responder to the Certificate Request payload MUST send its
certificate, if certificates are supported, based on the values contained
in the payload.  If multiple certificates are required, then multiple
Certificate Request payloads SHOULD be transmitted.  Figure 11 shows the
format of the Certificate Request Payload.

The Certificate Payload fields are defined as follows:


Next Payload (1 octet)  - Identifier for the payload type of the next

Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 27]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

     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 Authority              ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!



               Figure 11:  Certificate Request Payload Format


    payload in the message.  If the current payload is the last in the
    message, then this field will be 0.

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

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

Certificate Type (1 octet)  - Contains an encoding of the type of
    certificate requested.

Certificate Authority (variable length)  - Contains an encoding of an
    acceptable certificate authority for the type of certificate requested.
    As an example, for an X.509 certificate this field would contain the
    Distinguished Name encoding of the Issuer Name of an X.509 certificate
    authority acceptable to the sender of this payload.  This would be
    included to assist the responder in determining how much of the
    certificate chain would need to be sent in response to this request.  If
    there is no specific certificate authority requested, this field SHOULD
    NOT be included.


The payload type for the Certificate Request Payload is seven (7).


8.11 Signature Payload


The Signature Payload contains data generated by the digital signature
function.  The digital signature covers the Signature Payload Span and the
Signature Payload up to the Signature Data.  The exception to this is if
the signature algorithm used is DSS with ASN.1/DER encoding.  Due to the
variable length of a DER encoding, the signature span across the signature
payload itself only extends up to the signature data length field, not the
signature data.  Figure 12 shows the format of the Signature Payload.

The Signature Payload fields are defined as follows:



Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 28]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

     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        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    !  Sig Type     !        Signature Payload Span                 ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ~               ! Sig ID Role   !     Signature Timestamp       ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ~                               !  Signer ID Length             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ~                    Signer ID Data                             ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    !     Signature Length          !     Signature Data            ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!



                    Figure 12:  Signature Payload Format


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.

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

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

Signature Type (1 octet)  -- Indicates the type of signature.  Table 15
    presents the Signature Types.


                         Table 15:  Signature Types

                    Signature Type                Value
                   _____________________________________

                    DSS with ASN.1/DER encoding     0
                    DSS without encoding            1
                    Other                         2-255

Signature Payload Span (4 octets)  - Identifies the information included in
    the signature.  The first two octets define the first signature payload.
    The third and fourth octet define the last payload.  The payloads in the
    message are an ordered sequence beginning at the header, with a value
    of 0.  If the signature payload itself is not in the signature span, you
    must still sign over the signature payload up to the signature data.


Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 29]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

Signature ID Role (1 octet)  -- Specifies the type of Authorization (Role)
    being used.  Refer to Table 13 for the types of authorization (role).

Signature Timestamp (4 octets)  -- Date and time that the digital signature
    was applied.

Signer ID Length (2 octets)  - Length in octets of the Signer' ID.

Signer ID (variable length)  -- Data identifying the Signer's ID (e.g.,
    DN).

Signature Length (2 octets)  -- Length in octets of the Signature Data.

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 nine (9).


8.12 Notification Payload


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 Notification payloads in
a single GSAKMP message.  Figure 13 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         !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    !     Notify Message Type       !  STATUS TYPE  !               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ~                       Notification Data                       ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!



                  Figure 13:  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.

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

Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 30]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

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

Notify Message Type (2 octets)  - Specifies the type of notification
    message.  Table 16 presents the Notify Message Types.


                      Table 16:  Notify Messages Types

               Information                         Value
              _______________________________________________

               None                                  0
               Invalid-Payload-Type                  1
               Situation-Not-Supported               2
               Invalid-Major-Version                 3
               Invalid-Version                       4
               Invalid-Group-ID                      5
               Invalid-Message-ID                    6
               Payload-Malformed                     7
               Invalid-Key-Information               8
               Invalid-ID-Information                9
               Invalid-Cert-Encoding                10
               Invalid-Certificate                  11
               Cert-Type-Unsupported                12
               Invalid-Cert-Authority               13
               Authentication-Failed                14
               Invalid-Signature                    15
               Notify-GSA-Lifetime                  16
               Certificate-Unavailable              17
               Unequal-Payload-Lengths              18
               Unauthorized Request                 19
               Unable To Take Requested Role        20
               Group Deleted                        21
               Request To Join                      22
               Acknowledgement                      23
               Invitation                           24
               Invitation-Response                  25
               Nack                                 26
               Reserved (future use)             27 - 8191
               Private Use                     8192 -- 16383

Status Type (1 octet)  - Specifies the status of group with respect to
    originator of notification.  Notification information specifies status
    data and can be used by a process managing a SA database to communicate
    with a peer process.  For example, a secure front end or security
    gateway may use the Notify message to synchronize SA communication.
    Table 17 presents the Notification Message Status Types.

Notification Data (variable length)  - Informational or error data
    transmitted in addition to the Notify Message Type.  Values for this


Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 31]


INTERNET-DRAFT                     GSAKMP Light                    July 2002


                 Table 17:  Notify Messages -- Status Types

                    Status                       Value
                   ____________________________________

                    Not connected                  0
                    Establishing group             1
                    Connected to group             2
                    Previously member of group     3
                    Reserved (future use)        4-255


    field are Domain of Interpretation (DOI)-specific.


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


8.12.1 Notification Data - Acknowledgement (ACK) Message Type


The data portion of the ACK payload serves either for confirmation of
correct receipt of the Key Download message, or, when needed, can provide
non-repudiation of receipt when included in a signed message.  Figure 14
shows the format of the Notification Data - Acknowledge Message 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 14:  Notification Data - Acknowledge Message Type Format

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


Ack Type (1 octet)  - Specifies the type of acknowledgement message.
    Table 18 presents the Notify Acknowledgement Message Types.


    Simple - Data portion null.

    MD5 MAC - Data portion contains output of MD5 HMAC function [RFC
        2104].  Input to HMAC function is the Nonce_C value appended to the
        decrypted portion, sans encryption padding, of the Key Download
        payload of the received Key Download Packet.


Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 32]


INTERNET-DRAFT                     GSAKMP Light                    July 2002


                      Table 18:  Acknowledgement Types

                            ACK_Type     Value
                           ____________________

                            Simple         0
                            MD5 MAC        1
                            SHA-1 HMAC     2
                            Unassigned   3-255


    SHA-1 HMAC - Data portion contains output of SHA-1 HMAC function [RFC
        2104].  Input to HMAC function is the Nonce_C value appended to the
        decrypted portion, sans encryption padding, of the Key Download
        payload of the received Key Download Packet.


8.13 Vendor ID Payload


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.  This is not a general
extension facility of GSAKMP. Figure 15 shows the format of the Vendor ID
Payload.

The Vendor ID payload is not an announcement from the sender that it
will send private payload types.  A vendor sending the Vendor ID MUST
NOT make any assumptions about private payloads that it may send unless
a Vendor ID is received as well.  Multiple Vendor ID payloads MAY be
sent.  An implementation is NOT REQUIRED to understand any Vendor ID
payloads.  An implementation is NOT REQUIRED to send any Vendor ID payload
at all.  If a private payload was sent without prior agreement to send it, a
compliant implementation may reject a proposal with a notify message of type
INVALID-PAYLOAD-TYPE.

The vendor defined constant MUST be unique.  The choice of hash and text to
hash is left to the vendor to decide.  As an example, vendors could generate
their vendor id by taking a plain (non-keyed) hash of a string containing
the product name, and the version of the product.

The Vendor ID 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.

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


Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 33]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

     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 15:  Vendor ID Payload Format


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

Vendor ID (variable length)  - Hash of the vendor string plus version (as
    described above).


The payload type for the Vendor ID Payload is eleven (11).


8.14 Key Creation Payload


The Key Creation Payload contains information used to create key encryption
keys.  These key creation payloads can have security attributes applied
to them based upon the security policy of the group.  Figure 16 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        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    !   ID Type     !           Key Creation Data                   ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!



                  Figure 16:  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.

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


Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 34]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

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

ID Type (1 octet)  - Specifies the type of Key Creation being used.
    Table 19 identifies the types of key download information.


                Table 19:  Types Of Key Creation Information

                          ID_Type          Value
                         ________________________

                          Reserved           0
                          Diffie-Hellman     1
                          other            2-255

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


The payload type for the Key Creation Packet is twelve (12).



8.15 Nonce Payload


The Nonce Payload contains random data used to guarantee freshness during an
exchange and protect against replay attacks.  Figure 17 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 17:  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.

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

Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 35]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

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

Nonce Type (1 octet)  - Specifies the type of Nonce being used.  Table 20
    identifies the types of nonces.


                           Table 20:  Nonce Types

 Nonce_Type   Value     Definition
__________________________________________________________________________

 None           0
 Initiator      1
 Responder      2
 Combined       3       Hash ( Append (Initiator_Value, Responder_Value) )
 Unassigned   4-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 thirteen (13).



9 References and authors addesses


The following references were used in the preparation of this document.


9.1 References


[HCHMF01] H. Harney, A. Colegrove, E. Harder, U. Meth, R. Fleischer, Group
Secure Association Key Management Protocol, draft-ietf-msec-gsakmp-sec-00,
March 2001

[HHMCD01] , Thomas Hardjono, Hugh Harney, Pat McDaniel, Andrea Colgrove,
Pete Dinsmore, Group Security Policy Token:  Definition and Payloads',
draft-ietf-msec-gspt-00.txt, Work in progress.

[MSST98] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
``Internet Security Association and Key Management Protocol (ISAKMP)'', RFC
2408, November 1998.

[FIPS 196], ``Entity Authentication Using Public Key Cryptography,'' Federal
Information Processing Standards Publication 196, NIST, February 1997.


Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 36]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

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

[WHA98], Wallner, D., Harder E., and Agee R., ``Key Management for
Multicast:  Issues and Architectures'', Internet Draft, Informational,
September 1998.

[BMS], Balenson D., McGrew D., Sherman A., ``Key Management for Large
Dynamic Groups:  One-Way Function Trees and Amortized Initialization'',
Internet Draft, February 1999.

[RFC 2093] Harney H., Muckenhirn C., and Rivers T., ``Group Key, Management
Protocol Specification'', RFC 2093, Experimental, July 1997.

[RFC 2094] Harney H., Muckenhirn C., and Rivers T., ``Group Key Management
Protocol Architecture'', RFC 2094, Experimental, July 1997.

[RFC 2104] Krawczyk H., Bellare M., and Canetti R., ``HMAC: Keyed-Hashing
for Message Authentication'', RFC 2104, Informational, February

[RFC 2401] Kent S. and Atkinson, R., ``Security Architecture for the
Internet Protocol'', RFC 2401, November 1998, Proposed Standard.

[RFC 2402] Kent S. and Atkinson, R., ``IP Authentication Header'', RFC 2402,
November 1998, Proposed Standard.1997.

[RFC 2406] Kent S. and Atkinson, R., ``IP Encapsulating Security Payload
(ESP)'', RFC 2406, November 1998, Proposed Standard.

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

[RFC 2409] Harkins D. and Carrel D., ``The Internet Key Exchange (IKE)'',
RFC 2409, Proposed Standard, November 1998.

[RFC 2412] Orman H. K., ``The OAKLEY Key Determination Protocol'', RFC 2412,
Informational, November 1998.

[RFC2543], M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, SIP:
Session Initiation Protocol, March 99

[RFC2974], M. Handley, C. Perkins, E. Whelan, Session Announcement Protocol,
Oct 2000.









Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 37]


INTERNET-DRAFT                     GSAKMP Light                    July 2002

9.2 Authors Addresses


Hugh Harney (point-of-contact)
9861 Broken Land Parkway
Suite 300
Columbia, MD 21046
(410) 381-9400 ext 203
FAX (410) 381-5559
hh@columbia.sparta.com

Angela Schuett
R231 NSA
9800 Savage Rd
Suite 6534
Fort Meade, MD 20755
(301) 688-0850
FAX (301) 688-0255
amschue@tycho.ncsc.mil

Andrea Colegrove
9861 Broken Land Parkway
Suite 300
Columbia, MD 21046
(410) 381-9400 ext 232
FAX (410) 381-5559
acc@columbia.sparta.com

Document expiration:  December 31, 2002
























Harney/Schuett/Colegrove  draft-ietf-msec-gsakmp-light-sec-01.txt  [Page 38]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/