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

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 4535

SPARTA, Inc.                                               H Harney (SPARTA)
INTERNET-DRAFT                                               A Schuett (NSA)
                                                             U Meth (SPARTA)
                                                        A Colegrove (SPARTA)
                                      SPARTA, Inc., National Security Agency
draft-ietf-msec-gsakmp-sec-01.txt                              February 2003


                                   GSAKMP




                            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:  August 31, 2003


                                  Abstract


     This document specifies the Group Secure Association Key
    Management Protocol (GSAKMP). The GSAKMP provides a security
    framework for creating and managing cryptographic groups on a
    network.  The GSAKMP provides mechanisms to disseminate group
    security policy, authenticate users, rules to perform access
    control, generate group keys, and recover from compromise.


INTERNET-DRAFT                      GSAKMP                     February 2003

                              Copyright Notice

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


















































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

INTERNET-DRAFT                      GSAKMP                     February 2003

Contents

1 Overview                                                                 7
  1.1 GSAKMP Overview . . . . . . . . . . . . . . . . . . . . . . . . . .  7
  1.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
  1.3 Document Organization . . . . . . . . . . . . . . . . . . . . . . .  9
  1.4 Specification Modifications since Last Version  . . . . . . . . . .  9

2 Terminology                                                              9
3 Basis of security                                                       11

4 Group Life Cycle                                                        12
  4.1 Group Definition  . . . . . . . . . . . . . . . . . . . . . . . . . 12
  4.2 Group Establishment . . . . . . . . . . . . . . . . . . . . . . . . 13
    4.2.1Request to Join  . . . . . . . . . . . . . . . . . . . . . . . . 14
    4.2.2Key Download . . . . . . . . . . . . . . . . . . . . . . . . . . 15
    4.2.3Notification . . . . . . . . . . . . . . . . . . . . . . . . . . 15
  4.3 Group Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 16
    4.3.1Member Joins/Leaves  . . . . . . . . . . . . . . . . . . . . . . 16
    4.3.2Rekey Events . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5 Security Suite                                                          17
  5.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
  5.2 Definition Suite 1  . . . . . . . . . . . . . . . . . . . . . . . . 18

6 GSAKMP Payload Structure                                                19
  6.1 GSAKMP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
  6.2 Generic Payload Header  . . . . . . . . . . . . . . . . . . . . . . 21
  6.3 Policy Token Payload  . . . . . . . . . . . . . . . . . . . . . . . 21
  6.4 Key Download Payload  . . . . . . . . . . . . . . . . . . . . . . . 23
  6.5 Rekey Event Payload . . . . . . . . . . . . . . . . . . . . . . . . 24
  6.6 Identification Payload  . . . . . . . . . . . . . . . . . . . . . . 25
  6.7 Certificate Payload . . . . . . . . . . . . . . . . . . . . . . . . 26
  6.8 Signature Payload . . . . . . . . . . . . . . . . . . . . . . . . . 27
  6.9 Notification Payload  . . . . . . . . . . . . . . . . . . . . . . . 29
    6.9.1Notification Data - Acknowledgement (ACK) Message Type . . . . . 32
  6.10Key Creation Payload  . . . . . . . . . . . . . . . . . . . . . . . 33
  6.11Nonce Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

A APPENDIX A -- Variable Length Payload Field Definitions                 35
  A.1 GSAKMP Header Fields  . . . . . . . . . . . . . . . . . . . . . . . 35
  A.2 Key Download Payload Fields . . . . . . . . . . . . . . . . . . . . 35
    A.2.1GTEK Key Packet Fields . . . . . . . . . . . . . . . . . . . . . 35
    A.2.2Rekey Key Packet Fields  . . . . . . . . . . . . . . . . . . . . 36
  A.3 Rekey Event Payload Fields  . . . . . . . . . . . . . . . . . . . . 36
  A.4 Identification Payload Fields . . . . . . . . . . . . . . . . . . . 36
B APPENDIX B -- LKH Variable Length Payload Field Definitions             36
  B.1 LKH Rekey Key Packet Fields . . . . . . . . . . . . . . . . . . . . 36
  B.2 LKH Rekey Packet Data Format Fields . . . . . . . . . . . . . . . . 37
    B.2.1Rekey Event Header . . . . . . . . . . . . . . . . . . . . . . . 37
    B.2.2Rekey Event Packet Data(s) . . . . . . . . . . . . . . . . . . . 38
    B.2.3Key Pack Data  . . . . . . . . . . . . . . . . . . . . . . . . . 39


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

INTERNET-DRAFT                      GSAKMP                     February 2003

    B.2.4Pack Data Formats  . . . . . . . . . . . . . . . . . . . . . . . 40
        B.2.4.1GTEK Pack Data . . . . . . . . . . . . . . . . . . . . . . 40
        B.2.4.2LKH Pack Data  . . . . . . . . . . . . . . . . . . . . . . 40
    B.2.5Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

C References and authors addesses                                         42
  C.1 References  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
  C.2 Authors Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 43













































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

INTERNET-DRAFT                      GSAKMP                     February 2003

List of Figures

  1   GSAKMP Ladder Diagram . . . . . . . . . . . . . . . . . . . . . . . 13
  2   GSAKMP Header Format  . . . . . . . . . . . . . . . . . . . . . . . 19
  3   Generic Payload Header  . . . . . . . . . . . . . . . . . . . . . . 21
  4   Policy Token Payload Format . . . . . . . . . . . . . . . . . . . . 22
  5   Key Download Payload Format . . . . . . . . . . . . . . . . . . . . 23
  6   Rekey Event Payload Format  . . . . . . . . . . . . . . . . . . . . 24
  7   Identification Payload Format . . . . . . . . . . . . . . . . . . . 26
  8   Certificate Payload Format  . . . . . . . . . . . . . . . . . . . . 27
  9   Signature Payload Format  . . . . . . . . . . . . . . . . . . . . . 28
  10  Notification Payload Format . . . . . . . . . . . . . . . . . . . . 30
  11  Notification Data - Acknowledge Message Type Format . . . . . . . . 32
  12  Key Creation Payload Format . . . . . . . . . . . . . . . . . . . . 33
  13  Nonce Payload Format  . . . . . . . . . . . . . . . . . . . . . . . 34
  14   B. 1:  Rekey Event Header Format . . . . . . . . . . . . . . . . . 38
  15   B. 2:  Rekey Event Packet Data Format  . . . . . . . . . . . . . . 39
  16   B. 3:  Key Pack Data Format  . . . . . . . . . . . . . . . . . . . 39



































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

INTERNET-DRAFT                      GSAKMP                     February 2003

List of Tables

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
































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

INTERNET-DRAFT                      GSAKMP                     February 2003

1 Overview


The Group Secure Association Key Management Protocol (GSAKMP) provides key
to groups of users on a network.  It provides mechanisms to disseminate
group policy, authenticate users, rules to perform access control decisions
during group establishment and recovery, generate group keys, recover from
the compromise of group members, delegate group security functions, and
destroy the group.

To reduce the number of messages required for group establishment, GSAKMP
requires that group members have been notified of the security mechanisms
used for joining a group during the group announcement or invitation.
This announcement allows for the complete join exchange to occur without
first establishing a unicast security association between the negotiating
entities.  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.



1.1 GSAKMP Overview


The primary purpose of GSAKMP is to generate and disseminate a group key in
a secure fashion.  To protect the group information requires the definition
of a security policy and the enforcement of that policy by all participating
parties.  Controlling dissemination of cryptographic key is the primary
mechanism to enforce the access control policy.

The GSAKMP separates group security management functions and
responsibilities into three major roles:  Group Owner, Group Controller Key
Server, and Group Member.  The Group Owner is responsible for creating the
security policy rules for a group (eg., the Token).  The Group Controller
Key Server is responsible for creating the keys and enforcing the group
policy by granting access to potential Group Members in accordance with
the rules put forth by the group owner.  The potential group members
need to have ``knowledge'' of the access control policy for the group,
an unambiguous identification of any party downloading keys to them, and
verifiable chain of authority for key download.  The group members also need
to verify that the key disseminator is authorized to act in that capacity.

In order to establish a Group Secure Association (GSA) to support these
activities, the identity of each party in the security/access control
process must be unambiguously stated/asserted and authenticated to ensure
that they are authorized to be a member of the group as defined by the
group's security policy.

The security characteristics of the establishment protocol for the SA ought
to include


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

INTERNET-DRAFT                      GSAKMP                     February 2003

1.  Group policy

2.  Group policy dissemination

3.  Member to Controller SA to protect data

4.  Access control checking



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 can easily
be transmitted to the prospective group members.

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.

Even though GSAKMP announces some of the 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 (each potential source of data), the ability to determine
if the group provides adequate protection for member data.


1.2 Assumptions


GSAKMP assumes the operating system can provide the process and data
separation services at the appropriate assurance level to support software
encryption.




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

INTERNET-DRAFT                      GSAKMP                     February 2003

1.3 Document Organization


The remainder of this document is organized as follows:  Section 2 presents
the terminology and concepts used to present the requirements of this
protocol.  Section 3 defines the basis of security.  Section 4 describes
the group management life-cycle.  Section 5 describes the Security Suite
Definition and Section 6 presents the message types and formats used during
each phase of the life-cycle.



1.4 Specification Modifications since Last Version


This specification was based on two earlier versions of GSAKMP drafts,
referred to to GSAKMP and GSAKMP-Light.  These two specifications were
merged to incorporate all information necessary to allow the original
GSAKMP-Light specification to stand on its own.  The original GSAKMP
protocol no longer exists as a standard, it has been subsumed by
GSAKMP-Light.  GSAKMP-Light is now called GSAKMP.

Major modifications to the specification are


Removed Payloads:   Authorization, Certificate Request, Vendor ID, and
    Hash.

Removed Messages:   Group Removal/Destruction.

Signature Processing:   The signature processing has been modified.


2 Terminology


The following terminology is used throughout the GSAKMP paper.



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

Cryptographic Group:   A Cryptographic Group is a set of entities sharing
    or desiring to share a GSA.

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



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

INTERNET-DRAFT                      GSAKMP                     February 2003

    1.  Creating and distributing keys

    2.  Maintaining the rekey infrastructure

    3.  Building and maintaining the rekey structures



    As the group evolves, it may become desirable to have multiple
    controllers perform these functions.

Group Member (GM):  A Group Member 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 GCKS

    3.  Request group keys from the GCKS

    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

    7.  Manage their local key


Group Owner (GO):  A Group Owner is the entity authorized for generating
    and modifying an authenticatable policy token for the group, and
    notifying the GCKS to start the group.

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.

Group Secure Association (GSA):  A GSA 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.

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.

Policy Token/Certificate:   The policy token is a data structure used

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

INTERNET-DRAFT                      GSAKMP                     February 2003

    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, (eg., encrypt application data with a
    specific algorithm).  The group policy token will contain a variety of
    information including:



    1.  GSAKMP protocol version

    2.  Key creation method

    3.  Key dissemination policy

    4.  Access control policy

    5.  Group authorization policy

    6.  Compromise recovery policy

    7.  Data protection mechanisms


    The policy token specification will be fully presented in a separate
    document.

Rekey:   The act of changing keys within a group.

Subordinate Group Controller Key Server (SGCKS):  Any group member having
    the appropriate processing and trust characteristics as defined in the
    group policy that has the potential to act as a SGCKS. This will allow
    the group processing and communication requirements to be distributed
    equitably throughout the network (eg., distribute group key).  The
    optional use of GSAKMP with Subordinate Group Controller Key Servers
    will be documented in a separate paper.


3 Basis of security


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

These protocols are combined as follows:  Using the extended ISAKMP


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

INTERNET-DRAFT                      GSAKMP                     February 2003

payloads, GSAKMP 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 includes a nonce and is signed; the second message contains a
nonce, combined nonce (hash of the two nonces), and is signed, and the
third contains the combined nonce and is signed.  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 nonce value
to be used from the third message and onward.



4 Group Life Cycle


The management of a cryptographic group follows a life-cycle:  group
definition, group establishment, group maintenance, and group removal.
Group definition involves defining the parameters necessary to support
a secure group, including its policy token.  Group establishment is the
process of granting access to new members.  Group maintenance messages
include rekey, policy changes and member deletion.  Group removal provides
the process for destructing the group as a whole.  Each of these life-cycle
phases is discussed in the following sections.


4.1 Group Definition


A cryptographic group is established based on some need for secure
communications among a group of individuals.  The activities involved in
creating a cryptographic group include


1.  Determine Access Policy:  Group Join

2.  Determine Authorization Policy:  Key Dissemination, Computer Trust, and
    Architecture Authorization

3.  Determine Mechanisms:  Algorithms and Infrastructure

4.  Determine Architecture:  Key Dissemination and Compromise Recovery

5.  Create Group Policy Token


For the purposes of this document, it is assumed that the group definition
activity has occurred and the group information has been broadcast on a key
management channel or through a directory service.




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

INTERNET-DRAFT                      GSAKMP                     February 2003

4.2 Group Establishment


After a group definition has been created, a potential GCKS verifies the
token and it's rules.  This entity then establishes that eligibility rules
for GCKS creation have been met.  The GCKS may then create any needed group
keys and begin to establish the group.

The Group Establishment Flow diagram, Figure 1, is presented to illustrate
the process of establishing a cryptographic group.  The left side of the
diagram represents the actions of the GCKS. The right side of the diagram
represents the actions of the GMs.  The components of each message shown in
the diagram are presented in the Message Definitions sections following the
diagram.

          CONTROLLER                  MESSAGE                  MEMBER

                    !<------------Request to Join-------------!
      <Process RTJ> !                                         !
                    !-------------Key Download--------------->!
                    !                                         ! <Process KD>
                    !<------Notification - Ack/Failure--------!
   <Process Notif>  !                                         !
                    !<=======SHARED KEYED GROUP SESSION======>!




                      Figure 1:  GSAKMP Ladder Diagram

To facilitate a well ordered group creation, the GCKS MUST send security
policy information to the GM using a group policy token.  The group policy
token must include the group's address, group permissions, group join
policy, group controller key server identity, group management information,
and digital signature of the policy creation authority.  This will allow the
GM to determine wether group policy is compatible with local policy.

Standard design principles for secure protocols mandate the use of explicit
identification of senders and recipients of messages.  The signature payload
of each message identifies the signer of the message and therefore satisfies
the sender requirement.  Within the GSAKMP header is a group ID. Because
the member may be served by any Key Server within a group, this ID provides
sufficient granularity for the recipient ID for the Request to Join message.
Other messages sent by the potential member will contain the recipient ID
for the GCKS serving that member.

The only action not discussed is what to do if the Notification message
received by the GCKS is either malformed or does not verify.  In this
scenario, the GCKS MUST remove this GM from the group and handle according
to policy (e.g.  compromise recovery, potential GM failure notification).



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

INTERNET-DRAFT                      GSAKMP                     February 2003

As shown in the ladder diagram of Figure 1, the Request to Join, Key
Download, and Notification (Ack/Failure) messages MUST be present.

For the following message structure sections, details about payload formats
can be found in Section  6.


4.2.1 Request to Join


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


                Table 1:  Request to Join Message Definition

    Message Name  : RTJ
    Dissection    : {HDR-GrpID, Key Creation, Nonce_I, [VendorID]}
                    SigM, [Cert]
    Payload Types : GSAKMP Header, Key Creation, Nonce, Signature,
                    [Certificate], [VendorID]

       SigM       : Signature of Group Member
       Cert       : Necessary Certificates, zero or more
       {}SigX      :Indicates minimum fields used in Signature
       []         : Indicate an optional data item

As shown by Figure 1, potential GMs may join a group by initiating a request
for permission to join.  In response, the GCKS must accept or deny the
request.  <Process RTJ> indicates provisions for permitting the join and
for refusing the request due to some specified reason (e.g., no group, group
full, repetitive attempts to join).  Please note, that repeated attempts
to join by the same potential GM MUST be ignored while that potential GM
is being serviced to prevent Denial of Service attacks.  If the results of
<Process RTJ> indicate that the GCKS should reject the request, the session
MUST be terminated.  If the request is permitted, the session continues.

The GCKS receives this message and processes it according to the provisions
of processing the Request to Join.  In this procedure, the GCKS will verify
the signature on the message to ensure its authenticity.  If the message
signature does not verify, the session MUST be terminated.  If the message
signature verifies, then the identification of the sender is extracted from
the Signature Payload.  This identification information will later be used
by the GCKS in the Identification Payload of the Key Download message to
identify the recipient of this message.  If necessary, the GCKS will use the
supplied Certificates to verify the message.

The GCKS then confirms that all required payloads are present and
properly formatted based upon the mechanisms announced with the group
characteristics.  If not, the session MUST be terminated.

If the message signature is verified, and the GM passes the GCKS's access
control checks, the GCKS will create and send the Key Download message as

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

INTERNET-DRAFT                      GSAKMP                     February 2003

described in section  4.2.2.


4.2.2 Key Download


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


                 Table 2:  Key Download Message Definition

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

       SigC       : Signature of Group Controller Key Server
       Cert       : Necessary Certificates, zero or more
       {}SigX      :Indicates minimum fields used in Signature
       []         : Indicate an optional data item
       (data)*    : Indicates encrypted information

The GM receives this message and verifies the following information:
signature on the message to ensure its authenticity, the contents of the
nonce payloads, the contents of the key creation payload, and the identity
information contained in the Identification payload is the GM identity
information.  If the message signature, nonce, or identification information
does not verify, the session MUST be terminated.  GSAKMP sends a properly
authenticated message with a Notification Payload of type NACK to indicate
termination.

The Policy Token and Key Download payloads are sent encrypted in the KEK
generated by the Key Creation payload information using the mechanisms
defined in the group announcment.  This guarantees that the sensitive policy
and key data for the group and potential rekey data for this individual
cannot be read by anyone but the intended recipient.


4.2.3 Notification


The components of a Notification Message are shown in Table 3:

The GCKS receives the signed notification and will verify the signature on
the message to ensure its authenticity and the nonce value.  If the message
signature or nonce does not verify, the session MUST be terminated.  GSAKMP
sends a properly authenticated message with a Notification Payload of type
NACK to indicate termination.


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

INTERNET-DRAFT                      GSAKMP                     February 2003


                 Table 3:  Notification Message Definition

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

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

If the message signature and nonce are verified, then the GCKS and GM have
established a Shared Keyed Group Session.

This Notification Message is a general purpose message, and SHOULD be used
whenever a failure occurs.  The only diffenece is that instead of containing
a Notification payload of type ACK, it will be of the appropriate type.


4.3 Group Maintenance


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


4.3.1 Member Joins/Leaves


The addition of group members to a previously established group will closely
follow the processing presented in Sections 4.2.  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 4.2.1 through 4.2.3.

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


4.3.2 Rekey Events


A Rekey Event is any action, including compromise report or key expiration,
that requires the creation and dissemination of a new group key and/or Rekey
information.

Once an event has been identified (as defined in the group security policy
token), the GCKS must create and send a signed message containing the GTEK
and Rekey information to the group.


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

INTERNET-DRAFT                      GSAKMP                     February 2003

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 message MUST be discarded.  Upon verification the GM will find the
appropriate Rekey download packet and decrypt the information with a stored
Rekey key(s).  If a new Policy Token is distributed with the message, it
MUST be encrypted in the old GTEK.

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


                  Table 4:  Rekey Event Message Definition

    Message Name  : Rekey Event
    Dissection    : {HDR-GrpID, ([Policy Token])*, [VendorID], Rekey
                    Array}SigC, [Cert]
    Payload Types : GSAKMP Header, [Policy Token], Rekey Event,
                    Signature, [Certificate], [Vendor ID]

       SigC       : Signature of Group Controller Key Server
       Cert       : Necessary Certificates, zero or more
       {}SigX      :Indicates minimum fields used in Signature
       (data)*    : Indicates encrypted information
       []         : Indicate an optional data item


5 Security Suite


GSAKMP is designed to support architectures with a capability to announce
or otherwise prepublish the group establishment parameters.  Group
establishment parameters must contain enough information for a group member
to configure GSAKMP. The Security Definition Suite 1 defines the mandatory
supported definition of group establishment messages for GSAKMP. Other
security suite definitions MAY be defined in other internet specifications.


5.1 Assumptions


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

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







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

INTERNET-DRAFT                      GSAKMP                     February 2003

5.2 Definition Suite 1


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

The GSAKMP Suite 1 definition defines all the algorithm and cryptographic
definitions required to process group establishment messages.  It is
important to note that GSAKMP does not negotiate these cryptographic
mechanisms.  This definition is set by the Group Owner via the Policy Token
(passed during the GSAKMP exchange for member verification purposes).

The GSAKMP Suite definition is



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


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

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

Nonce Hash algorithm is:
  SHA-1

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

NOTE: The p and g values comes from IKE [RFC 2409], section 6.2 Second
      Oakley Group, and p is 1024 bits long.


The digital signature algorithm is:

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

INTERNET-DRAFT                      GSAKMP                     February 2003

DSS-ASN1-DER
Hash algorithm is:
SHA-1



6 GSAKMP Payload Structure


A GSAKMP Message is composed of a GSAKMP Header (Section  6.1) followed
by at least one GSAKMP Payload.  All GSAKMP Payloads are composed of the
Generic Payload Header (Section  6.2) followed by the specific payload data.
The message is chained by a preceeding payload defining its succeeding
payload.  The final payload in a message will point to no succeeding
payload.


6.1 GSAKMP Header


The GSAKMP Header fields are defined in Figure 2:

     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


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

Group Identification Value (variable length)  - Indicates the name/title
    of the group.  The specific format for this field is defined in
    Section A.1.

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 6 presents the payload types.


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

INTERNET-DRAFT                      GSAKMP                     February 2003


                    Table 5:  Group Identification Types


                            Grp ID Type   Value
                           _____________________

                            IPv4            0
                            Other         1-255


                          Table 6:  Payload Types


                     Next_Payload_Type        Value
                    ___________________________________

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


Version (1 octet)  - Indicates the version of the GSAKMP protocol in use.
    The current value is one (1).

Exchange Type (1 octet)  - Indicates the type of exchange (also known as
    the message type).  Table 7 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).  When a GCKS/SGCKS is initiated,
    it must generate/select an initial value, not zero (0).  For each
    distinct group management message that this GCKS/SGCKS transmits, this
    value MUST be incremented.  Receivers of this group management message
    MUST confirm that the value received is greater that the value of the
    sequence ID received with the last group management message from this
    GCKS/SGCKS. GCKS/SGCKS MUST also garantee that this value does not
    suffer from rollover problems.

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

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

INTERNET-DRAFT                      GSAKMP                     February 2003


                          Table 7:  Exchange Types


                         Exchange_Type      Value
                        __________________________

                         Reserved           0 - 3
                         Notification         4
                         Rekey Event          5
                         Reserved             6
                         No Message           7
                         Request to Join      8
                         Key Download         9
                         Other             10-255


6.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.  Table 6 identifies the payload types.

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

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



6.3 Policy Token Payload


The Policy Token Payload contains group specific information that describes
the group security relevant behaviors, access control parameters, and

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

INTERNET-DRAFT                      GSAKMP                     February 2003

security mechanisms.  This information may contain a digital signature(s) to
prove authority and integrity of the information.  Figure 4 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 4:  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.

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 8 identifies the types of policy tokens.


                        Table 8:  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 Policy Token format is specified in a
    separate document.


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

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


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

INTERNET-DRAFT                      GSAKMP                     February 2003

     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 5:  Key Download Payload Format


6.4 Key Download Payload


The Key Download Payload contains group keys (eg., group keys, initial
rekey keys, etc.).  These key download payloads can have several security
attributes applied to them based upon the security policy of the group.
Figure 5 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:


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 9 for the possible
            values of this field.



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

INTERNET-DRAFT                      GSAKMP                     February 2003


                     Table 9:  Key Download Data Types

                      Key Download Data Type   Value
                     ________________________________

                      GTEK                       0
                      Rekey - LKH                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.


If this payload is encrypted, only the Key Download Data field is encrypted.

For a Key Download Data value of GTEK, the Key Packet Data field format is
defined in Section A.2.1.

For a Key Download Data value of Rekey, the Key Packet Data field format is
defined in Section A.2.2.

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


6.5 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 6 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 6:  Rekey Event Payload Format

The Rekey Event Payload fields are defined as follows:


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

INTERNET-DRAFT                      GSAKMP                     February 2003

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 10 presents the types of Rekey events.


                        Table 10:  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.
    The values for this field are group specific and the format is
    specified by the ID Type field.  The format for this field is defined in
    Section A.3


The Rekey Event payload type is three (3).



6.6 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 7 shows the format of the
Identification Payload.

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.

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

INTERNET-DRAFT                      GSAKMP                     February 2003

     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 7:  Identification Payload Format


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 11 identifies the types of identities.


                      Table 11:  Identification Types

                    ID_Type                       Value
                   _____________________________________

                    Sender Distinguished Name       0
                    Receiver Distinguished Name     1
                    Unassigned                    2-255

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


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


6.7 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 8 shows the format of the Certificate
Payload.

The Certificate Payload fields are defined as follows:



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

INTERNET-DRAFT                      GSAKMP                     February 2003

     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 8:  Certificate 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.

Certificate Type (2 octets)  - This field indicates the type of certificate
    or certificate-related information contained in the Certificate Data
    field.  Table 12 presents the types of certificate payloads.


                    Table 12:  Certificate Payload Types

         Certificate_Type                                  Value
        __________________________________________________________

         None                                                0
         Reserved                                          1 - 3
         X.509 Certificate -- Signature - DER Encoding       4
         Reserved                                        5 -- 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).


6.8 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 but not including the Signature Data Length.
Figure 9 shows the format of the Signature Payload.


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

INTERNET-DRAFT                      GSAKMP                     February 2003

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



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

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 (2 octets)  -- Indicates the type of signature.  This is
    really treated as 2 one byte fields.  The first byte is the Signature
    Type as represented by Table 13.  The second byte is the format for the
    Signer ID data and is defined by the values in Table 11.


                         Table 13:  Signature Types

                    Signature Type - byte 1       Value
                   _____________________________________

                    DSS with ASN.1/DER encoding     0
                    Other                         1-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

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

INTERNET-DRAFT                      GSAKMP                     February 2003

    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.

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


                       Table 14:  Authorization Types

              Auth_Type                                 Value
             _________________________________________________

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

Signature Timestamp (4 octets)  -- Date and time that the digital signature
    was applied.  This field contains the time in seconds from the epoch
    00:00 GMT 1 January 1970.

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

Signer ID Data (variable length)  -- Data identifying the Signer's ID
    (e.g., DN). The format for this field is based on the second byte in the
    Signature Type field and is shown where that type is defined.

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 eight (8).



6.9 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 10 shows the format of the Notification
Payload.

The Notification Payload fields are defined as follows:

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

INTERNET-DRAFT                      GSAKMP                     February 2003

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

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

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 16 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
    field are Domain of Interpretation (DOI)-specific.


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













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

INTERNET-DRAFT                      GSAKMP                     February 2003




                      Table 15:  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-Sequence-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
               Reserved                           21 - 22
               Acknowledgement                      23
               Reserved                           24 - 25
               Nack                                 26
               Reserved (future use)             27 - 8191
               Private Use                     8192 -- 16383






                 Table 16:  Notify Messages -- Status Types

                       Status                  Value

                      _______________________________
                       Not connected             0
                       Establishing group        1
                       Reserved (future use)   2-255




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

INTERNET-DRAFT                      GSAKMP                     February 2003

6.9.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 11
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 11:  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 17 presents the Notify Acknowledgement Message Types.


                      Table 17:  Acknowledgement Types

                            ACK_Type     Value
                           ____________________

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


    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.

    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.





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

INTERNET-DRAFT                      GSAKMP                     February 2003

6.10 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 12 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 12:  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.

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 18 identifies the types of key download information.


                Table 18:  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 eleven (11).


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

INTERNET-DRAFT                      GSAKMP                     February 2003

6.11 Nonce Payload


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

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 19
    identifies the types of nonces.


                           Table 19:  Nonce Types

Nonce_Type   Value     Definition
________________________________________________________________________________

None           0
Initiator      1
Responder      2
Combined       3       Hash ( Append (Initiator_Value, Responder_Value) )
                       The hash type comes from the Security Suite Definition.
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.


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

INTERNET-DRAFT                      GSAKMP                     February 2003

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



A APPENDIX A -- Variable Length Payload Field Definitions


This appendix defines the format of all variable length fields that contain
multiple items of information.


A.1 GSAKMP Header Fields


Group Identification Value Format  - For IPv4, this field is 8 octets long,
    4 octets for IPv4 internet address in network byte order, and 4 octets
    for serial number in network byte order.


A.2 Key Download Payload Fields


A.2.1 GTEK Key Packet Fields


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
    data was originally generated.  This field contains the time in seconds
    from the epoch 00:00 GMT 1 January 1970.

Key Expiration Date (4 octets)  -- This is the time value of when this key
    is no longer valid for use.  This field contains the time in seconds
    from the epoch 00:00 GMT 1 January 1970.

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/Meth/Colegrove  draft-ietf-msec-gsakmp-sec-02.txt   [Page 35]

INTERNET-DRAFT                      GSAKMP                     February 2003

A.2.2 Rekey Key Packet Fields


This field is defined within the specific type of rekey scheme used by the
group.

For LKH, the format of the this field is defined in Section B.1.



A.3 Rekey Event Payload Fields


This field is defined within the specific type of rekey event scheme used by
the group.

For LKH, the format of the this field is defined in Section B.2.


A.4 Identification Payload Fields


Identification Data  - For type Distinguished Name (DN) the format is:


    Serial Number (4 octets)  -- The certificate serial number in network
        byte order.

    Length (4 octets)  -- Length in octets of the DN Data field.

    DN Data (variable length)  -- The actual DN value.



B APPENDIX B -- LKH Variable Length Payload Field Definitions


This appendix defines the format of all LKH specific variable length fields
that contain multiple items of information.


B.1 LKH Rekey Key Packet Fields


When using the Logical Key Hierarchy (LKH) protocol for Rekey operations,
the 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 in which
    the data is formatted.  The current value for this field is one (1).


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

INTERNET-DRAFT                      GSAKMP                     February 2003

Leaf ID (2 octets)  -- This is the Leaf Node ID of the LKH sequence
    contained in this Key Packet Data block.  The leftmost leaf node ID
    value is one (1).

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. The base node of the binary tree has a
        value of one (1).

    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.  This field contains the time in
        seconds from the epoch 00:00 GMT 1 January 1970.

    Key Expiration Date (4 octets)  -- This is the time value of when this
        key is no longer valid for use.  This field contains the time in
        seconds from the epoch 00:00 GMT 1 January 1970.

    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.


B.2 LKH Rekey Packet Data Format Fields


This section defines the format of the Rekey Event Data in the Rekey Event
Payload, when using Logical Key Hierarchy (LKH) as the rekeying mechanism.

The Rekey Event Data consists of Rekey Event Header and Rekey Event Packet
Data(s).  A Packet Data is a complete set of information that an end-user
requires to be Rekeyed.  Packet Datas are comprised of new Key Packs of
types GTEK and Rekey.


B.2.1 Rekey Event Header


The Rekey Event Data Header contains information about the rekey data being
transmitted to the group.  Figure 14 shows the format for the header.


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

INTERNET-DRAFT                      GSAKMP                     February 2003

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    !                    Group ID Value                             ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ~                    Group ID Value                             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ! Time/Date Stamp                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ! Rekey Type    ! Algorithm Ver ! # of Rekey Packets            !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ! Rekey Event Packet Data(s)                                    ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!


               Figure 14:   B. 1:  Rekey Event Header Format


Group Identification Value (variable length)  - Indicates the name/title
    of the group to be rekeyed.  This is the same format as the Group
    Identification Value in Section  6.1 GSAKMP Message Header.

Time/Date Stamp (4 octets)  - This is the time stamp when the Rekey Event
    Data was generated.  This field contains the time in seconds from the
    epoch 00:00 GMT 1 January 1970.

Rekey Type (1 octet)  - This is the Rekey algorithm being used for this
    group.  This value is token specific.  For this appendix, this value is
    LKH, which has a value of one (1).

Algorithm Version (1 octet)  - Indicates the version of the Rekey Type
    being used.  The value at this time is one (1).

# of Rekey Packets (2 octets)  - The number of Rekey Packets contained in
    the Rekey Data.

Rekey Event Packet Data(s) (variable length)  - Contains the packets of
    rekey event information being transmitted.


B.2.2 Rekey Event Packet Data(s)


As defined in the Rekey Event Header, # of Rekey Packets field, multiple
pieces of information are sent in a Rekey Event Data.  Each end user, will
be interested in only one packet of the information sent.  Each Packet, will
contain all the Key Packs that a user requires.  For each Packet, the data
following the Security Header fields is encrypted with the key identified in
the Security Header.  Figure 15 shows the format of each Rekey Event Packet
with respect to LKH.



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

INTERNET-DRAFT                      GSAKMP                     February 2003

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ! Packet Length                 ! Security Header: LKH ID       !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ! Security Header: Key Handle                                   !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ! # of Key Packs                ! Key Pack Data(s)              !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!


             Figure 15:   B. 2:  Rekey Event Packet Data Format


Packet Length (2 octets)  - Length in octets of the Rekey Packet, which
    consists of the # of Key Packs and the Key Pack Data(s).

Security Header:  LKH ID (2 octets)  - This is the LKH ID of the Rekey Pack
    that is being used for encryption/decryption.  Refer to Section B.1 for
    the values of this field.

Security Header:  Key Handle (4 octets)  - This is a randomly generated
    value to uniquely identify the key defined by the LKH ID.

# of Key Packs (2 octets)  - The number of key packs contained in this
    Packet Data.

Key Pack Data(s) (variable length)  - Contains all the key pack data for
    this packet.


B.2.3 Key Pack Data


Each Key Pack contains all the information about the key.  Figure 16 shows
the format for each type of key pack.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ! Pack Type     ! Pack Length                   ! Pack Data     ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!


                  Figure 16:   B. 3:  Key Pack Data Format


Pack Type (1 octet)  - The type of key in this key pack.  Legal values are
    GTEK (0) and LKH (1).

Pack Length (2 octets)  - The length of the Pack Data.


Harney/Schuett/Meth/Colegrove  draft-ietf-msec-gsakmp-sec-02.txt   [Page 39]

INTERNET-DRAFT                      GSAKMP                     February 2003

Pack Data (variable length)  - The actual data of the key, defined by the
    key type.



B.2.4 Pack Data Formats


There are 2 legal values for the Pack Type, GTEK and LKH. The formats for
each Pack type are defined in this section.


B.2.4.1 GTEK Pack Data


This is data for the new GTEK being sent to the Rekeyed group.


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.  This field contains the time in seconds
    from the epoch 00:00 GMT 1 January 1970.

Key Expiration Date (4 octets)  - This is the time value of when this key
    is no longer valid for use.  This field contains the time in seconds
    from the epoch 00:00 GMT 1 January 1970.

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.


B.2.4.2 LKH Pack Data


This is the data to fix an Group Member Rekey sequence to recover from a
compromise.


LKH ID (2 octets)  -- This is the position of this key in the binary tree
    structure used by LKH. Refer to Section B.1 for the values of this
    field.

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.  This field contains the time in seconds

Harney/Schuett/Meth/Colegrove  draft-ietf-msec-gsakmp-sec-02.txt   [Page 40]

INTERNET-DRAFT                      GSAKMP                     February 2003

    from the epoch 00:00 GMT 1 January 1970.

Key Expiration Date (4 octets)  - This is the time value of when this key
    is no longer valid for use.  This field contains the time in seconds
    from the epoch 00:00 GMT 1 January 1970.

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.



B.2.5 Example


This section will give an example of the data.  The data to be transmitted
is:

| GroupID | Date/Time | Rekey Type | Algorithm Ver | # of Packets|
{ (GTEK)A, (GTEK, B, E)6, (GTEK, B)F }

This data shows that three packets are being transmitted.  Read each
packet as:
a) GTEK wrapped in LKH key A
b) GTEK, LKH keys B & E, all wrapped in LKH key 6
c) GTEK and LKH key B, all wrapped in LKH key F

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

Definition of values:
0xLLLL     - length value
0xHHHHHHH# - handle value
0xTTTTTTTC - creation time
0xTTTTTTTE - expiration time



GroupID        - 0xAABBCCDD
                 0x12345678
Date/Time      - 0x34574509
Rekey Type     - 0x01 (LKH)
Algorithm Vers - 0x01
# of Packets   - 0x0003
For Packet (b):
Packet Length      - 0xLLLL
Sec HDR:LKH ID     - 0x0006
Sec HDR:Key Handle - 0xHHHHHHH1
# of Key Packs     - 0x0003
  Key Pack 1:
    Pack Type   - 0x00 (GTEK)

Harney/Schuett/Meth/Colegrove  draft-ietf-msec-gsakmp-sec-02.txt   [Page 41]

INTERNET-DRAFT                      GSAKMP                     February 2003

    Pack Length - 0xLLLL
      Key Type            - 0x02 (DES3)
      Key Creation Date   - 0xTTTTTTTC
      Key Expiration Date - 0xTTTTTTTE
      Key Handle          - 0xHHHHHHH2
      Key Data            - variable, based on key definition
  Key Pack 2:
    Pack Type   - 0x01 (LKH)
    Pack Length - 0xLLLL
      LKH ID              - 0x000B
      Key Type            - 0x02 (DES3)
      Key Creation Date   - 0xTTTTTTTC
      Key Expiration Date - 0xTTTTTTTE
      Key Handle          - 0xHHHHHHH3
      Key Data            - variable, based on key definition
  Key Pack 3:
    Pack Type   - 0x01 (LKH)
    Pack Length - 0xLLLL
      LKH ID              - 0x000E
      Key Type            - 0x02 (DES3)
      Key Creation Date   - 0xTTTTTTTC
      Key Expiration Date - 0xTTTTTTTE
      Key Handle          - 0xHHHHHHH4
      Key Data            - variable, based on key definition



C References and authors addesses


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


C.1 References


[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.

[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


Harney/Schuett/Meth/Colegrove  draft-ietf-msec-gsakmp-sec-02.txt   [Page 42]

INTERNET-DRAFT                      GSAKMP                     February 2003

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.

``Logical Key Hierarchy (LKH) Protocol'', SPARTA, October, 1998.



C.2 Authors Addresses


Hugh Harney (point-of-contact)
7075 Samuel Morse Drive
Columbia, MD 21046
(410) 872-1515 ext 203

Harney/Schuett/Meth/Colegrove  draft-ietf-msec-gsakmp-sec-02.txt   [Page 43]

INTERNET-DRAFT                      GSAKMP                     February 2003

FAX (410) 872-8079
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

Uri Meth
7075 Samuel Morse Drive
Columbia, MD 21046
(410) 872-1515 ext 233
FAX (410) 872-8079
umeth@sparta.com

Andrea Colegrove
7075 Samuel Morse Drive
Columbia, MD 21046
(410) 872-1515 ext 232
FAX (410) 872-8079
acc@columbia.sparta.com

Document expiration:  August 31, 2003


























Harney/Schuett/Meth/Colegrove  draft-ietf-msec-gsakmp-sec-02.txt   [Page 44]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/