WDIFF

draft-ietf-msec-gsakmp-sec-00.txt --> draft-ietf-msec-gsakmp-sec-02.txt

SPARTA, Inc.

Internet Engineering Task Force
INTERNET-DRAFT H Harney (SPARTA) Harney, U Meth, A Colegrove (SPARTA)
E Harder
A Schuett (NSA)
U Meth (SPARTA)
R Fleischer (SPARTA)
INTERNET-DRAFT
P McDaniel (AT&T)
G Kenny (Logica)
H Cruickshank, S Iyengar (UoS)
draft-ietf-msec-gsakmp-sec-02.txt SPARTA, Inc., National Security Agency
March 2001

Group Secure Association Key Management Protocol

<draft-ietf-msec-gsakmp-sec-00.txt>
AT&T Labs, LogicaCMG, University of Surrey
Expires: December 30, 2003 June 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, 2001

Abstract

The

This document specifies the Group Secure Association Key
Management Protocol (GSAKMP) (GSAKMP). The GSAKMP provides a security
framework for creating and managing cryptographic groups on a
network. It provides mechanisms to disseminate group security
policy, policy and
authenticate users, rules to perform access control based upon PKI certificates,
generate decisions
during group keys, establishment and recovery, capabilities to recover
from compromise. This framework
addresses the compromise of group scalability issues by facilitating members, delegation of
process-intensive actions in a secure group security
functions, and controlled manner. capabilities to destroy the group. It also
generates group keys.

INTERNET-DRAFT GSAKM Protocol March 2001 GSAKMP June 2003

Harney/Colegrove/Harder/Meth/Fleischer

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 2]

INTERNET-DRAFT GSAKM Protocol March 2001 GSAKMP June 2003

Contents

1 Overview 7
1.1 GSAKMP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Assumptions . . . . . . Protocol Considerations . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Document Organization . . . . . . . . . . . . . . . . . . . . . . . 8

2 Terminology 9
2.1 GSAKMP Terminology 8
3 Security Considerations 10
3.1 Security Assumptions . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 GSAKMP Use of Other Protocols . 9
3 GROUP LIFE-CYCLE 12
3.1 Group Establishment . . . . . . . . . . . . . . . . . . 11
3.2.1ISAKMP . . . . . . 12
3.1.1Group Establishment without the Use of an Underlying SA . . . . 14
3.1.2Create Group Key . . . . . . . . . . . . . . . . . . . 11
3.2.2FIPS Pub 196 . . . . 14
3.1.3Distribute Group Key . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Group Maintenance 11
3.2.3LKH . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1Member Joins/Leaves . . . . . 11
3.2.4Diffie-Hellman . . . . . . . . . . . . . . . . . 19
3.2.2Rekey Events . . . . . . . . 12
3.3 Denial of Service (DoS) Attack . . . . . . . . . . . . . . . . . . 19
3.3 Group Removal/Destruction 12
3.4 Proof of Trust Hierarchy . . . . . . . . . . . . . . . . . . . . . 19 12

4 Message formats 21 Group Life Cycle 13
4.1 GSAKMP Header . . Group Definition . . . . . . . . . . . . . . . . . . . . . . . . . 21 13
4.2 Generic Payload Header . Group Establishment . . . . . . . . . . . . . . . . . . . . . 23
4.3 Data Attributes Payload . . . 13
4.2.1Standard Group Establishment . . . . . . . . . . . . . . . . . . 13
4.2.1.1Request to Join . 23
4.4 Policy Token Payload . . . . . . . . . . . . . . . . . . . . 14
4.2.1.2Key Download . . . 24
4.5 Key Download Payload . . . . . . . . . . . . . . . . . . . 15
4.2.1.3Notification . . . . 25
4.5.1GTEK Key Packet . . . . . . . . . . . . . . . . . . 16
4.2.2Cookies - Group Establishment with Denial of Service Protection 17
4.3 Group Maintenance . . . . . . 26
4.5.2Rekey Key Packet . . . . . . . . . . . . . . . . . . . 19
4.3.1Member Joins/Leaves . . . . . 27
4.6 Rekey Event Payload . . . . . . . . . . . . . . . . . 19
4.3.2Rekey Events . . . . . . . 28
4.7 Identification Payload . . . . . . . . . . . . . . . . . . . 19
5 Security Suite 19
5.1 Assumptions . . . 29
4.8 Authorization Payload . . . . . . . . . . . . . . . . . . . . . . . 30
4.9 Certificate Payload . . 20
5.2 Definition Suite 1 . . . . . . . . . . . . . . . . . . . . . . 31
4.10Certificate Request Payload . . 20

6 GSAKMP Payload Structure 21
6.1 GSAKMP Header . . . . . . . . . . . . . . . . . . 32
4.11Hash Payload . . . . . . . . . 21
6.2 Generic Payload Header . . . . . . . . . . . . . . . . . . 33
4.12Signature Payload . . . . 24
6.3 Policy Token Payload . . . . . . . . . . . . . . . . . . . . . 34
4.13Notification Payload . . 24
6.4 Key Download Payload . . . . . . . . . . . . . . . . . . . . . 36
4.13.1Notification Data - Acknowledgement (ACK) Message Type . . 25
6.5 Rekey Event Payload . . . 38
4.14Vendor ID Payload . . . . . . . . . . . . . . . . . . . . . 27
6.6 Identification Payload . . . . 39
4.15Key Creation Payload . . . . . . . . . . . . . . . . . . 28
6.7 Certificate Payload . . . . . 40
4.16Nonce Payload . . . . . . . . . . . . . . . . . . . 29
6.8 Signature Payload . . . . . . . . 41
5 GSAKMP State Diagram 43

6 APPENDIX A -- Rekey Packet data format 45
6.1 Rekey Event Header . . . . . . . . . . . . . . . . . 30
6.9 Notification Payload . . . . . . . 45
6.2 Rekey Event Packet Data(s) . . . . . . . . . . . . . . . . 32
6.9.1Notification Data - Acknowledgement (ACK) Payload Type . . . . 46
6.3 Key Pack . 34
6.9.2Notification Data - Cookie Request and Cookie Payload Type . . . 35
6.10Key Creation Payload . . . . . . . . . . . . . . . . . . . . . . . 35
6.11Nonce Payload . 47
6.4 Pack Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.4.1GTEK Pack Data . 36

7 GSAKMP State Diagram 38
A APPENDIX A -- Variable Length Payload Field Definitions 41
A.1 GSAKMP Header Fields . . . . . . . . . . . . . . . . . . . . . . . 41

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 3]

INTERNET-DRAFT GSAKMP June 2003

A.2 Key Download Payload Fields . 47
6.4.2LKH Pack Data . . . . . . . . . . . . . . . . . . . 41
A.2.1GTEK Key Packet Fields . . . . . . 48
6.5 Example . . . . . . . . . . . . . . . 41
A.2.2Rekey Key Packet Fields . . . . . . . . . . . . . . . 48

7 References and Authors Addresses 50
7.1 References . . . . . 41
A.3 Rekey Event Payload Fields . . . . . . . . . . . . . . . . . . . . 42
A.4 Identification Payload Fields . . . 50

Harney/Colegrove/Harder/Meth/Fleischer [Page 3]

INTERNET-DRAFT GSAKM Protocol March 2001

7.2 Authors Addresses . . . . . . . . . . . . . . . . 42

B APPENDIX B -- LKH Variable Length Payload Field Definitions 42
B.1 LKH Rekey Key Packet Fields . . . . . . . . . 51

Harney/Colegrove/Harder/Meth/Fleischer [Page 4]

INTERNET-DRAFT GSAKM Protocol March 2001

List of Figures

1 Group Establishment Ladder Diagram . . . . . . . . . . . 42
B.2 LKH Rekey Packet Data Format Fields . . . . . 13
2 GSAKMP Header Format . . . . . . . . . . . 43
B.2.1Rekey Event Header . . . . . . . . . . . . 21
3 Generic Payload Header . . . . . . . . . . . 43
B.2.2Rekey Event Packet Data(s) . . . . . . . . . . . 23
4 Data Attributes Payload . . . . . . . . 44
B.2.3Key Pack Data . . . . . . . . . . . . . . 24
5 Policy Token Payload Format . . . . . . . . . . . 45
B.2.4Pack Data Formats . . . . . . . . . 24
6 Key Download Payload Format . . . . . . . . . . . . . . 46
B.2.4.1GTEK Pack Data . . . . . . 25
7 Rekey Event Payload Format . . . . . . . . . . . . . . . . 46
B.2.4.2LKH Pack Data . . . . 28
8 Identification Payload Format . . . . . . . . . . . . . . . . . . 46
B.2.5Example . 29
9 Authorization Payload Format . . . . . . . . . . . . . . . . . . . 30
10 Certificate Payload Format . . . . . . . . 47
C APPENDIX C -- Change History 48
C.1 Changes from GSAKMP-01 to GSAKMP-02 February 2003 . . . . . . . . . 48
C.2 Changes from GSAKMP-02 to GSAKMP-03 June 2003 . . . 31
11 Certificate Request Payload Format . . . . . . . . 49

D References, Authors Addesses, and Acknowledgements 49
D.1 References . . . . . . . . 33
12 Hash Payload Format . . . . . . . . . . . . . . . . . . . . 49
D.2 Authors Addresses . . . . 34
13 Signature Payload Format . . . . . . . . . . . . . . . . . . . . . 35
14 Notification Payload Format 50
D.3 Acknowledgements . . . . . . . . . . . . . . . . . . . . 36
15 Notification Data - Acknowledge Message Type Format . . . . . 52

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 4]

INTERNET-DRAFT GSAKMP June 2003

List of Figures

1 GSAKMP Ladder Diagram . . . 38
16 Vendor ID Payload Format . . . . . . . . . . . . . . . . . . . . 14
2 GSAKMP Ladder Diagram with Cookies . 39
17 Key Creation Payload Format . . . . . . . . . . . . . . . 18
3 GSAKMP Header Format . . . . . 40
18 Nonce Payload Format . . . . . . . . . . . . . . . . . . 22
4 Generic Payload Header . . . . . 41
19 GSAKMP State Diagram . . . . . . . . . . . . . . . . . 24
5 Policy Token Payload Format . . . . . . 43
20 A.1: Rekey Event Header Format . . . . . . . . . . . . . . 25
6 Key Download Payload Format . . . . 45
21 A.2: Rekey Event Packet Data Format . . . . . . . . . . . . . . . 46
22 A.3: Key Pack Data . 26
7 Rekey Event Payload Format . . . . . . . . . . . . . . . . . . . . 47

Harney/Colegrove/Harder/Meth/Fleischer [Page 5]

INTERNET-DRAFT GSAKM Protocol March 2001

List of Tables

1 Request to Join Message Definition 27
8 Identification Payload Format . . . . . . . . . . . . . . . . 15
2 Invitation to Join Message Definition . . . 28
9 Certificate Payload Format . . . . . . . . . . . . 15
3 Invitation Response Message Definition . . . . . . . . 29
10 Signature Payload Format . . . . . . 17
4 Key Download Message Definition . . . . . . . . . . . . . . . 31
11 Notification Payload Format . . . 17
5 Key Download Message with Insufficient SA Definition . . . . . . . 18
6 Acknowledgment Message Definition . . . . . . . . . . 32
12 Notification Data - Acknowledge Payload Type Format . . . . . . . 18
7 Rekey Event Message Definition . 34
13 Key Creation Payload Format . . . . . . . . . . . . . . . . . 20
8 Group Removal/Destruction Message Definition . . . 35
14 Nonce Payload Format . . . . . . . . 20
9 Group Identification Types . . . . . . . . . . . . . . . 36
15 GSAKMP State Diagram . . . . . 21
10 Payload Types . . . . . . . . . . . . . . . . . . 38
16 B. 1: Rekey Event Header Format . . . . . . . . . . . . . . . . 22
11 Exchange Types . 44
17 B. 2: Rekey Event Packet Data Format . . . . . . . . . . . . . . 45
18 B. 3: Key Pack Data Format . . . . . . . . . . . 22
12 Policy Token Types . . . . . . . . 45

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 5]

INTERNET-DRAFT GSAKMP June 2003

List of Tables

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

Harney/Colegrove/Harder/Meth/Fleischer [Page 6]

INTERNET-DRAFT GSAKM Protocol March 2001

1 Overview

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

The goals of the Creation Information . . . . . . . . . . . . . . . . . 36
20 Nonce Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
21 GSAKMP are to create a protocol that:

1. Distributes group policy,

2. Provides mechanisms for distributing the group key, and

3. Provides mechanisms for a Rekey of the group. States . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
22 State Transition Events . . . . . . . . . . . . . . . . . . . . . . 40

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 6]

INTERNET-DRAFT GSAKMP June 2003

1 Overview

1.1 GSAKMP Overview

Protecting group information requires the definition of a security
policy and the enforcement of that policy by capable all participating parties. Control and access to the
Controlling dissemination of cryptographic key is the primary mechanism to
enforce the access control policy. The It is the primary purpose of GSAKMP provides these mechanisms to control access to the
generate and disseminate a group
key.

This document identifies the key in a secure fashion.

GSAKMP Message Passing Requirements. The group
key(s) are created by the separates group controller. security management functions and responsibilities
into three major roles: 1) Group Owner, 2) Group Controller Key Server,
and 3) Group Member. The group controller must start Group Owner is responsible for creating the group access control,
security policy enforcement process. The group controller
needs to have the access rules defined for joining the a group and should be
able to identify expressing these in the Policy Token.
The Group Controller Key Server (GCKS) is responsible for creating and verify
maintaining the permissions of keys and enforcing the members group policy by granting access
to which they
will distribute keys.

The potential group members Group Members (GM) in accordance with the Policy Token. To
enforce a group's policy the potential Group Members need to have ``knowledge'' knowledge
of the access control policy for the group, an unambiguous identification
of any party downloading keys to them, and verifiable chain chains of authority
for key download. The group
members also In other words, the Group Members need to know who
potentially will be in the group and to verify that the key creator disseminator is
authorized to act in that capacity.

In order to establish a group Group Secure Association (SA) (GSA) to support these
activities, the identity of each party in the security/access control process must MUST be unambiguously stated/asserted
asserted and authenticated to ensure
that they are authorized to authenticated. It MUST also be a member of the group verified that each party is
authorized, as defined by the
group's security policy. Policy Token, to function in his role in the
protocol (e.g., GM or GCKS).

The security characteristics features of the establishment protocol for the SA should include:

1. Coherent permission topology,

Harney/Colegrove/Harder/Meth/Fleischer [Page 7]

INTERNET-DRAFT GSAKM Protocol March 2001

2. include

- Group policy,

3. policy identification

- Group policy dissemination,

4. Peer dissemination

- GM to GCKS SA establishment to protect data, and

5. data

- Access control checking.

1.2 Assumptions checking

GSAKMP makes the following assumptions of the underlying host:

1. The operating system can provide the process provides mechanisms for cryptographic group creation and data separation
services
management. Other protocols may be used in conjunction with GSAKMP to support software encryption.

2. A separate SA mechanism is present that is sufficient
allow various applications to protect create functional groups according to their
application-specific requirements. For example, in a small-scale video
conference the
distribution of organizer might use a session invitation protocol like SIP
[RFC2543] to transmit information about the group key.

3. The host and all time of the applications on that host share conference, the same
certificate identities (at least initially).

1.3 Document Organization

Section 1 presents an overview
address of secure group communications. Section 2
presents the terminology session, and concepts used the formats to present be used. For a large-scale video

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 7]

INTERNET-DRAFT GSAKMP June 2003

transmission, the requirements of
this protocol. organizer might use a multicast announcement protocol like
SAP [RFC2974].

This document describes a useful default set of security algorithms and
configurations, Security Suite 1. This suite allows an entire set of
algorithms and settings to be described to prospective group members in a
concise manner. Other security suites MAY be defined as needed and MAY be
disseminated during the out-of-band announcement of a group.

Distributed architectures support large scale cryptographic groups. Secure
distributed architectures require authorized delegation of GSA actions to
network resources. The fully specified Policy Token is the mechanism to
facilitate this authorization. Trasmission of this Policy Token to all
joining GMs allows GSAKMP to securely support distributed architectures and
multiple data sources.

Many-to-many group communications require multiple data sources. 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 Protocol Considerations

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

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 outlines the security considerations with respect to
GSAKMP. Section 4 describes the group management life-cycle and life-cycle. Section 4 5
describes the Security Suite Definition. Section 6 presents the message
types and formats used during each phase of the life-cycle. Section 5 presents a discussion of 7
defines the states encountered
in state diagram for the protocol.

Harney/Colegrove/Harder/Meth/Fleischer [Page 8]

INTERNET-DRAFT GSAKM Protocol March 2001

2 Terminology

The following terminology is used throughout the GSAKMP paper.

2.1 GSAKMP Terminology

Group Member:

Certificate: A group member (GM) is any entity with access data structure used to verifiably bind an identity to the group
keys. Regardless of how a member becomes a part

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 8]

INTERNET-DRAFT GSAKMP June 2003

cryptographic key (e.g., X.509v3).

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

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

Group Controller Key Server (GCKS): A group member with authority to
perform critical protocol actions including creating and distributing
keys and 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

- Authenticate and validate the GC's authorization to perform actions;

2. identities and the authorizations of
entities performing security relevant actions

- Accept group keys from the GC;

3. GCKS

- Request group keys from the GC;

4. Maintain local Certificate Revocation Lists (CRLs);

5. GCKS

- Enforce the cooperative group policies as stated in the group
policy token;

6. token

- Perform peer review of key management actions; and

7. actions

- Manage their local key. 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 cryptographic group 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 Policy: Traffic Encryption Key (GTEK): The group policy completely describes key or keys created for
encrypting the protection
mechanisms and security relevant behaviors group data.

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 9]

INTERNET-DRAFT GSAKMP June 2003

Logical Key Hierarchy (LKH) Array: The group of keys created to
facilitate the group. This policy
must be commonly understood and enforced by the group for coherent
secure operations. LKH compromise recovery methodology.

Policy Token/Certificate: Token: The policy token is a mechanism data structure used to disseminate the
group policy. policy and the mechanisms to enforce it. The policy token
is issued and signed by an authorized source. Each member of the
group must MUST verify the token, meet the group join policy , policy, and enforce
the policy of the group.
The group policy data element group, (e.g., encrypt application data with a
specific algorithm). The group policy token will contain a variety of
information including:

- GSAKMP protocol format,

Harney/Colegrove/Harder/Meth/Fleischer [Page 9]

INTERNET-DRAFT GSAKM Protocol March 2001

2. version

- Key creation method,

3. method

- Key dissemination policy,

4. policy

- Access control policy,

5. policy

- Group architecture policy, and

6. authorization policy

- Compromise recovery policy.

The policy

- Data protection mechanisms

An example of a policy token layout will be fully presented is specified in the Group Policy
Token Specification document.

Group Controller: [HCLM00].

Rekey: The act of changing keys within a group.

Subordinate Group Controller (GC) is a Key Server (SGCKS): Any 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 having
the group evolves, it may become desirable to have multiple
controllers perform these functions (e.g., Rekey Controller appropriate processing and Group
Key Controller).

Subordinate Controller: Any group member, trust characteristics as defined in the
group policy, policy that has the capability potential to act as a Subordinate Controller (SC) thus allowing SGCKS. This will allow
the group processing and communication requirements to be distributed
equitably throughout the network. If the network (e.g., distribute group is structured key). The
optional use of GSAKMP with Subordinate Group Controller Key Servers
will be documented in
such a way, separate paper.

3 Security Considerations

In addition to the delegated group members would be identified via specification of GSAKMP itself, the
policy token. The SCs may perform actions delegated to them security of an
implemented GSAKMP system is affected by supporting factors. These are
discussed here.

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 10]

INTERNET-DRAFT GSAKMP June 2003

3.1 Security Assumptions

The following assumptions are made as the GC
including: basis for the security discussion

1. Dissemination of GSAKMP assumes its supporting platform can provide the group key process and

2. Management of data
separation services at the status appropriate assurance level to support its
groups.

2. The key generation function of the local group. cryptographic engine will only
generate strong keys.

3. The ease security of managing a very large group may also be improved by
delegating this protocol is critically dependent on the creation randomness
of subordinate LKH arrays to the SCs. The
SCs would have the authority randomly chosen parameters. These should be generated by a
strong random or properly seeded pseudo-random source.

3.2 GSAKMP Use of Other Protocols

GSAKMP is based upon two (2) existing protocols: ISAKMP [MSST98] and mechanisms necessary to create FIPS
Pub 196 [FIPS 196]. GSAKMP MAY use Diffie-Hellman key exchange [DH77] for
two party key creation and
disseminate the MAY use LKH arrays for the members under their control. A
more detailed discussion rekey capability.

3.2.1 ISAKMP

ISAKMP provides a flexible structure of LKH arrays may be found chained payloads in the Logical Key
Hierarchy (LKH) Protocol document.

Harney/Colegrove/Harder/Meth/Fleischer [Page 10]

INTERNET-DRAFT GSAKM Protocol March 2001

Peer-to-Peer SA: Peer-to-Peer SA keys can be created by using any number support of
authenticated key generation protocols including the Internet Secure Association
Key Management Protocol (ISAKMP)/IPSec exchange and HS/SSL. These protocols security association management for pairwise
communications. GSAKMP expands upon these features to provide policy
enforcement features in support of diverse group communications.

3.2.2 FIPS Pub 196

FIPS Pub 196 provides a mutual authentication protocol.

3.2.3 LKH

GSAKMP relies upon a rekey capability, i.e., LKH, to enable group recovery
after a compromise.

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 11]

INTERNET-DRAFT GSAKMP June 2003

3.2.4 Diffie-Hellman

GSAKMP MAY rely on cooperative upon two party key generation algorithms and on peer review of
permissions. Modern SA protocols are specifically developed creation mechanisms, i.e.,
Diffie-Hellman, to support protect sensitive data during download.

The information in this task. Once the peer-to-peer SA section is established, the group borrowed heavily from [IKEv2] as this
protocol
can use that SA mechanism for secure confidential peer communications
throughout has already worked through this issue and GSAKMP is using the life
same security considerations for its purposes. This section will contain
paraphrased sections of the group.

GSA Keys: GSA keys can be created using strong randomization [IKEv2] modified for GSAKMP as appropriate.

The strength of a key
generation protocols. These protocols rely on derived from a cooperatively conferred
policy. Once Diffie-Hellman exchange using specific
p and g values depends on the group keys are created inherent strength of the values, the size of
the exponent used, and disseminated to the
group members, entropy provided by the group protocol can random number generator
used. Security Suite 1 defined in section 5, based on [IKEv2] Group 2,
with a strong random number generator and an exponent no less than 200 bits
is sufficient to use that SA mechanism for secure
confidential group communications throughout the life 3DES. An implementation should make note of this
conservative estimate when establishing policy and negotiating security
parameters.

Note that these limitations are on the group.

Group Traffic Encryption Key (GTEK): The key or keys created for
encrypting Diffie-Hellman values themselves.
There is nothing in GSAKMP which prohibits using stronger values nor is
there anything which will dilute the group data.

Logical Key Hierarchy (LKH) array: The group strength obtained from stronger values.
In fact, the extensible framework of keys created to
facilitate GSAKMP encourages the LKH compromise recovery methodology.

Compromise Recovery: The act definition of recovering a secure operating state
more Security Suites.

It is assumed that the Diffie-Hellman exponents in this exchange are erased
from memory after
detecting use. In particular, these exponents MUST NOT be derived
from long-lived secrets like the seed to a pseudo-random generator that is
not erased after use.

3.3 Denial of Service (DoS) Attack

This GSAKMP specification addresses the mitigation for a distributed IP
spoofing attack (a subset of possible DoS attacks) in section 4.2.2,
Cookies.

3.4 Proof of Trust Hierarchy

As defined by [HCM], security group member cannot policy MUST be trusted.

Harney/Colegrove/Harder/Meth/Fleischer defined in a verifiable
manner. GSAKMP anchors its trust in the creator of the group, the GO.

The Policy Token explicitly defines all the parameters that create a secure
verifiable infrastructure. The GSAKMP Policy Token is issued and signed by
the GO. The GCKS will verify it and grant access to GMs only if they meet
the rules of the Policy Token. The new GMs will accept access only if 1)
the token verifies, 2) the GCKS is an authorized disseminator, and 3) the

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 11] 12]

INTERNET-DRAFT GSAKM Protocol March 2001

3 GROUP LIFE-CYCLE GSAKMP June 2003

group mechanisms are acceptable for protecting the GMs data.

4 Group Life Cycle

The management of a cryptographic group follows a life-cycle: group
definition, group establishment, group maintenance, and security relevant group removal.
Each of these maintenance.
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. Security relevant group
maintenance messages include rekey, policy changes and member deletion.
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 to support secure communications among
a group of individuals. The activities involved necessary to create a Policy Token
in
creating support of a cryptographic group include:

1. include

- Determine Access Policy: Group Join

2. Policy - identify the entities that are authorized to
receive the group key.

- Determine Authorization Policy: Key Dissemination, Computer Trust, and
Architecture Authorization

3. Determine Mechanisms: Algorithms Policy - identify which entities are authorized
to perform security relevant actions, including key dissemination,
policy creation, and Infrastructure

4. initiation of security management actions.

- Determine Architecture: Key Dissemination Mechanisms - define the algorithms and Compromise Recovery

5. protocols used by
GSAKMP to secure the group.

- Create Group Policy Token

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

3.1
Policy Token and apply the GO signature.

4.2 Group Establishment

The

4.2.1 Standard Group Establishment

After the out-of-band receipt of a Policy Token, a potential Group
Controller Key Server (GCKS) verifies the token and its rules. This entity
then establishes that eligibility rules for GCKS creation have been met.
The GCKS is then permitted to create any needed group keys and begin to
establish the group.

The GSAKMP Ladder diagram, Diagram, Figure 1, is presented to illustrate the process

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 13]

INTERNET-DRAFT GSAKMP June 2003

of establishing a cryptographic group. The left side of the diagram
represents the actions of the GC. 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.

Potential GMs may join 4.2.1.1 - 4.2.1.3.

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 in two ways: by invitation (push) or request
(pull). For purposes of illustration, creation, the diagram presents a ``Request to
Join Group'', a ``pull'', message sent from a potential GM.

At this point, the GC must accept or deny the request. ``Process RTJ``
indicates a provision for refusing the connection due to some specified
reason (e.g., no group, group full, repetitive attempts to join). If the
results of ``Process RTJ`` indicate that the GC should reject the request,
the session is terminated.
If the results of Processing the Request to Join indicate that the GC
should accept the request, the session continues. The message traffic to
an invited potential member also begins at this point on the diagram.

Harney/Colegrove/Harder/Meth/Fleischer [Page 12]

INTERNET-DRAFT GSAKM Protocol March 2001

CONTROLLER MESSAGE MEMBER

!<------------Request to Join-------------!
<Process RTJ> ! !
!<============SA ESTABLISHMENT===========>!(Outside GSAKMP)
! !
!-------------Invitation----------------->!
! !<Process Inv.>
!<------------Invitation Response-------->!
<Process Inv. Rsp.> ! !
!-------------Key Download--------------->!
! !<Process Key DL>
!<------------Acknowledgment--------------!
<Process ACK> ! !
!<=======SHARED KEYED GROUP SESSION======>!

Figure 1: Group Establishment Ladder Diagram

The area of the diagram specified as ``Outside GSAKMP'' is merely
illustrative to show the confidentiality between the GC and GM. It is
assumed, for the purposes of this document, that the GC and GM are able to
establish a SA using protocols like ISAKMP and IPSec. The GC will specify
the security characteristics of the SA to the outside application. The
level of protection shall be as good or stronger than the SA characteristics
specified in the group policy token. A suggested minimal SA security level
is confidentiality with integrity.

To facilitate a well ordered group creation, GCKS MUST send security
policy information
must be passed between the GC and to the GMs GM using a group policy token. The group policy
token must MUST include the group's address, identification, 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 Invitation message provides no
authority to join

If the group (authorization information GCKS is contained in
the signed token), but merely provides information unable to a potential member.
Because of this, unintended receipt of this message by someone would not
cause harm. The recipient ID for correctly process the Notification message, the
GCKS MUST remove this GM from the group and handle according to policy.

For the following message is therefore optional. The
Key Download message also contains structure sections, details about payload formats
can be found in Section 6.

4.2.1.1 Request to Join

The components of a required explicit ID.

Harney/Colegrove/Harder/Meth/Fleischer Request to Join Message are shown in Table 1.

As shown by Figure 1, potential GMs join a group by initiating a request for
permission to join. In response, the GCKS accepts or denies the request
based on local configuration. <Process RTJ> indicates the GCKS actions

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 13] 14]

INTERNET-DRAFT GSAKM Protocol March 2001

3.1.1 Group Establishment without the Use GSAKMP June 2003

Table 1: Request to Join Message Definition

Message Name : Request to Join (RTJ)
Dissection : {HDR-GrpID, Key Creation, Nonce_I, [Notification]}
SigM, [Cert]
Payload Types : GSAKMP Header, Key Creation, Nonce, Signature,
[Certificate], [Notification]

SigM : Signature of an Underlying SA Group Establishment, as specified Member
Cert : Necessary Certificates, zero or more
{}SigX :Indicates minimum fields used in Section 3.1, uses Signature
[] : Indicate an underlying
Security Association to protect optional data item

that will determine if the contents RTJ will be acted upon. Reasons for refusal
of the Token and subsequent key
download.

In the cases where token contents are not sensitive, GSAKMP action can provide
secure member joins and associated secure policy include: malformed RTJ, unverifiable RTJ, GCKS processing
issues, and key downloads without state violations. NOTE: At any reliance on an underlying secure protocol subsystem.

In both of these cases, it is assumed one time, a GCKS MUST process no
more that one (1) valid RTJ from a single GM per group. If the data portion results of
<Process RTJ> indicate that the Key
Download payload is encrypted. The details of GCKS should reject the encryption of this data
is provided in request, the Key Download payload itself. session
MUST be terminated.

The key determination for GCKS processes the Request to Join. In this encryption may be done through a two-party contributory system (a la
Diffie-Hellman) using procedure, the Key Creation Payloads GCKS will
verify the signature on the message to carry ensure its authenticity. The GCKS
MUST used verified and trusted authentication material from a known root.
If the contributions message signature does not verify, the session MUST be terminated.
If the message signature verifies, then the identity of the participants to this key, or may sender is
extracted from the Signature Payload. This identity information will be transferred with
used the encrypted
contents using public key encryption and an enveloping scheme (e.g., RFC
2630 Enveloped Data with Key Transport.)

3.1.2 Create Group Key

There Download message.

The GCKS then confirms that all required payloads are two options: key generation at a single point present and shared
generation. In shared generation,
properly formatted based upon the first member must cooperate mechanisms announced with the
GC to create the group key. There are several established software-based
key creation protocols, including Diffie-Hellman
characteristics. If not, the session MUST be terminated.

If the message signature is verified, and RSA, that support two
group members cooperating to create a cryptographic key. However, for this
document, the following discussion presents single-point key generation.
Prior to GM passes the first member join, GCKS's access
control checks, the GC GCKS will have created the GTEK create and send the
Rekey array.

3.1.3 Distribute Group Key

Potential GMs may join a group and receive the group key Download message as
described in two ways: by
invitation (push) or request (pull). section 4.2.1.2.

The following message definition shows
a OPTIONAL Notification payload will be used when the GCKS requires
cookies in the Request to Join message from a potential GM. message. The initial message from the
GM would contain the following:

1. GSA request and

2. GM Certificate (optional). use of this payload will be
defined in section 4.2.2.

4.2.1.2 Key Download

The components of a Request to Join message are Key Download Message are shown in Table 1:

Harney/Colegrove/Harder/Meth/Fleischer [Page 14]

INTERNET-DRAFT GSAKM Protocol March 2001

Table 1: Request to Join Message 2:

The GM receives this message and verifies the following information:
signature on the message to ensure its authenticity, the contents of the
nonce responder and combined payloads, the contents of the key creation
payload, and verify the identity information. If the message signature,

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 15]

INTERNET-DRAFT GSAKMP June 2003

Table 2: Key Download Message Definition

Message Name : Request to Join Key Download (KD)
Dissection : {HDR, GrpID, Nonce_I, GSA RQ} SigM, [CertM] {HDR-GrpID, Member ID, Nonce_R, Nonce_C, Key
Creation, (Policy Token)*, (Key Download)*} SigC,
[Cert]
Payload Types : GSAKMP Header, Identification, Nonce, Notification, Key
Creation, Policy Token, Key Download, Signature,
[Certificate], [Certificate Request], [Vendor
ID], [Identification], [Authorization]

SigM
[Certificate]

SigC : Signature of Group Member
CertM Controller Key Server
Cert : Certificate of Group Member Necessary Certificates, zero or more
{}SigX :Indicates minimum fields used in Signature
[] : Indicate an optional data item

The following message definition shows an ``Invitation to Join'' message
from
(data)* : Indicates encrypted information

nonce, or identification information does not verify, the GC to session MUST
be terminated. GSAKMP sends a potential GM. The initial properly authenticated message from with a
Notification Payload of type NACK to indicate termination.

The Policy Token and Key Download payloads are sent encrypted in the GC would contain KEK
generated by the Key Creation payload information using the mechanisms
defined in the following:

1. Signed group announcment. This guarantees that the sensitive policy token,

2. GSA request,
and

3. GC Certificate (optional). key data for the group and potential rekey data for this individual
cannot be read by anyone but the intended recipient.

4.2.1.3 Notification

The components of an Invitation to Join message a Notification Message are shown in Table 2: 3:

Table 2: Invitation to Join 3: Notification Message Definition

Message Name : Invitation to Join Notification
Dissection : {HDR, GrpID, Policy Token, (Nonce_R, Nonce_C) OR
Nonce_I, [Key Creation], GSA RQ}SigC, [CertC],
[SigSC], [CertSC] {HDR-GrpID, Nonce_C, ACK}SigM
Payload Types : GSAKMP Header, Policy Token, Nonce, Notification,
Signature, [Certificate], [Signature],
[Certificate], [Key Creation], [Certificate
Request], [Vendor ID], [Identification],
[Authorization]

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

For purposes of discussion, this section presents a ``Invitation to Join''
as presented in Table 2.

Harney/Colegrove/Harder/Meth/Fleischer [Page 15]

INTERNET-DRAFT GSAKM Protocol March 2001

The GM will receive this message and process it according to the provisions
of Processing the Invitation. The GSA RQ contains the identity of the
message source in enough detail to allow the potential member to verify
the signature. The GSA RQ also contains the ID of the invited member. In
``Process Invitation'' GCKS receives the potential GM signed notification and will initially verify that the signature on
the message is authentic. to ensure its authenticity and the nonce value. If the message
signature or nonce does not verify, the session is MUST be terminated. GSAKMP sends a properly authenticated
message with a Notification Payload of type NACK to indicate termination.

If the message signature is authentic, and nonce are verified, then the potential GM will look
at who signed the message, verify the signer's authorization, GCKS and make
a decision to proceed. If the potential GM decides not to proceed, the
session is terminated. GSAKMP sends have
established a properly authenticated message GSA.

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 16]

INTERNET-DRAFT GSAKMP June 2003

4.2.2 Cookies - Group Establishment with
a Notification Payload Denial of type NACK Service Protection

This section defines an OPTIONAL capability that MAY be implemented into
GSAKMP. The information in this section is borrowed heavily from [IKEv2] as
this protocol has already worked through this issue and GSAKMP is copying
this concept. This section will contain paraphrased sections of [IKEv2]
modified for GSAKMP to indicate termination.

If define the GM initiated a pull by sending a Request to Join message, purpose of Cookies.

An optional Cookie mode is being defined for the
Invitation GSAKMP to Join help against DoS
attacks.

The term "cookies" originates with Karn and Simpson [RFC 2522] in Photuris,
an early proposal for key management with IPsec. The ISAKMP fixed message received must contain
header includes two eight octet fields titled "cookies". Instead of placing
this cookie data in the Nonce_R header, this data is moved into a Notification
payload.

An expected attack against GSAKMP is state and Nonce_C
payloads. If CPU exhaustion, where
the GM target GCKS is being invited flooded with Request to join the group via Join requests from forged IP
addresses. This attack can be made less effective if a push by GCKS implementation
uses minimal CPU and commits no state to the GCKS, communication until it knows
the Invitation to Join message received must contain a Nonce_I
payload.

NOTE: When not using an underlying Security Association (SA), or initiator potential GM can receive packets at the SA is
not sufficient address from which
it claims to protect be sending them. To accomplish this, the key data GCKS when operating
in the Key Download message, the
Key Creation Cookie mode, SHOULD reject initial Request to Join messages unless they
contain a Notification payload is required in this of type "cookie". It SHOULD instead send
a Cookie Download message if using as a pairwise key
determination system.

If the potential GM has decided response to continue, they will examine the
information within the policy token to determine if this is a group they are
authorized RTJ and interested include a cookie in joining. If
a notify payload of type Cookie_Requested. Potential GMs who receive such
responses MUST retry the decision is not Request to join, the
session is terminated. GSAKMP sends a properly authenticated Join message with a
Notification Payload the responder GCKS
supplied cookie in its notification payload of type NACK to indicate termination.

If Cookie, as defined by
the potential GM is satisfied with optional Notification payload of the received information and decides Request to join the group, he Join Msg as defined in
section 4.2.1.1. This initial exchange will pass back a message containing then be as shown in Figure 2
with the following:

1. Signed GSA response, and

2. GM's certificate (optional).

The components of an Invitation Response the new message are Cookie Download shown in Table 3:

The GC receives this message and processes it according to the provisions
of Processing the Invitation Response. In this procedure, the GC will
verify the signature on the message to ensure its authenticity. If the
message signature does not verify, the session is terminated. GSAKMP sends
a properly authenticated message with a Notification Payload of type NACK to
indicate termination.

Harney/Colegrove/Harder/Meth/Fleischer [Page 16]

INTERNET-DRAFT GSAKM Protocol March 2001 4.

Table 3: Invitation Response 4: Cookie Download Message Definition

Message Name : Invitation Response Cookie Download
Dissection : {HDR, GrpID, (Nonce_R, Nonce_C) OR Nonce_C, [ID_R],
[Key Creation], GSA RS}SigM, [CertM] {HDR-GrpID, COOKIE_REQUIRED}
Payload Types : GSAKMP Header, Nonce, [Identification], Notification, Signature, [Key Creation],
[Certificate], [Vendor ID], [Authorization]

SigM : Signature of Group Member
CertM : Certificate of Group Member
{}SigX :Indicates minimum fields used in Signature
[] : Indicate an optional data item

If this negotiation was initiated by

The first two messages do not affect any GM or GCKS state except for
communicating the GC via cookie.

A GSAKMP implementation SHOULD implement its GCKS cookie generation in such
a push, way as to not require any saved state to recognize its valid cookie when
the Invitation
Response second Request to Join message received must contain the Nonce_R arrives. The exact algorithms and Nonce_C payloads. If
this negotiation was initiated by the GM via a pull, the Invitation Response
message received must contain a Nonce_C payload.

NOTE: When syntax
they use to generate cookies does not using an underlying Security Association (SA), or the SA affect interoperability and hence is
not sufficient specified here. The following is an example of how an endpoint could
use cookies to protect the key data implement limited DoS protection.

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 17]

INTERNET-DRAFT GSAKMP June 2003

CONTROLLER MESSAGE MEMBER
in Cookie Mode
!<--Request to Join without Cookie Info---!
<Gen Cookie Rsp> ! !
!----------Cookie Download--------------->!
! ! <Process CD>
!<----Request to Join with Cookie Info----!
<Process RTJ> ! !
!-------------Key Download--------------->!
! ! <Process KD>
!<------Notification - Ack/Failure--------!
<Process Notif> ! !
!<=======SHARED KEYED GROUP SESSION======>!

Figure 2: GSAKMP Ladder Diagram with Cookies

A good way to do this is to set the Key Download message, the
Key Creation payload cookie to be:

Cookie = <SecretVersionNumber> ! Hash(Ni ! IPi ! <secret>)

where <secret> is required in this message if using a pairwise key
determination system.

If randomly generated secret known only to the message signature is verified, responder
GCKS and periodically changed, Ni is the GM passes Nonce value taken from the GC's access
control checks,
initiator potential GM, IPi is the GC will create and send a signed message containing supposed IP of the
GTEK and initiator potential
GM. <SecretVersionNumber> should be changed whenever <secret> is
regenerated. The cookie can be recomputed when the Rekey array "Request to Join with
Cookie Info" arrives and compared to the GM.

The components of a Key Download message are shown cookie in Table 4:

Table 4: Key Download Message Definition

Message Name : Key Download
Dissection : {HDR, GrpID, Nonce_C, ID_R, [(]Key Data[)*]}SigC,
[SigSC], [CertSC]
Payload Types : GSAKMP Header, Nonce, Identification, Key
Download, Signature, [Authorization], [Vendor ID]
SigC : Signature of Group Controller
SigSC : Signature of Subordinate Group Controller
CertC : Certificate of Group Controller
CertSC : Certificate of Subordinate Group Controller
{}SigX :Indicates minimum fields used in Signature
[] : Indicate an optional data item
(data)* : Indicates encrypted information

The GM receives this message and processes the received message.
If it according matches, the responder GCKS knows that all values have been computed
since the last change to <secret> and that IPi MUST be the provisions
of Processing same as the Key Download. In this procedure,
source address it saw the GM will verify first time. Incorporating Ni into the
following information: signature on hash
assures that an attacker who sees only the Cookie_Download message can't
successfully forge a "Request to ensure its authenticity, Join with Cookie Info" message.

If a new value for <secret> is chosen while there are connections in the contents
process of being initialized, a "Request to Join with Cookie Info" might be
returned with other than the nonce payload, and the identity information contained

Harney/Colegrove/Harder/Meth/Fleischer [Page 17]

INTERNET-DRAFT GSAKM Protocol March 2001 current <SecretVersionNumber>. The responder
GCKS in that case MAY reject the Identification payload is the GM identity information. If the
message signature, nonce, or identification information does not verify, the
session is terminated. GSAKMP sends a properly authenticated message by sending another response with
a
Notification Payload of type NACK to indicate termination.

NOTE: When not using an underlying Security Association (SA), new cookie or it MAY keep the SA old value of <secret> around for a short
time and accept cookies computed from either one. The responder GCKS SHOULD
NOT accept cookies indefinitely after <secret> is not sufficient to protect the key data in the Key Download message, changed, since that would
defeat part of the
Key Data section denial of service protection. The responder GCKS SHOULD
change the Key Download message must be encrypted. An example
format for this message is shown in Table 5:

Table 5: Key Download Message with Insufficient SA Definition

Message Name : Key Download
Dissection : {HDR, GrpID, Nonce_C, ID_R, (Key Data)*}SigC,
[SigSC], [CertSC]
Payload Types : GSAKMP Header, Nonce, Identification, Key
Download, Signature, [Authorization], [Vendor ID]

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

If the message signature, nonce, and identification are verified, the GM
will create a signed acknowledgment message to return to the GC.

The components of an Acknowledgment message are shown in Table 6:

Table 6: Acknowledgment Message Definition

Message Name : Acknowledgment
Dissection : {HDR, GrpID, Nonce_C, [ID_R], ACK}SigM, [CertM]
Payload Types : GSAKMP Header, Nonce, [Identification],
Notification, Signature, [Certificate], [Vendor
ID], [Identification], [Authorization]

SigM : Signature of Group Member
CertM : Certificate of Group Member
{}SigX :Indicates minimum fields used in Signature
[] : Indicate an optional data item

The GC receives the signed acknowledgment and processes it according to
the provision of Processing the Acknowledgement. In this procedure, the
GC 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 is terminated. GSAKMP sends a properly authenticated message with
a Notification Payload value of type NACK to indicate termination.

Harney/Colegrove/Harder/Meth/Fleischer <secret> frequently, especially if under attack.

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 18]

INTERNET-DRAFT GSAKM Protocol March 2001

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

3.2 GSAKMP June 2003

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.

3.2.1

4.3.1 Member Joins/Leaves

The addition of group members to a previously established group will closely
follow the processing presented in Section 3.1 -- Group Establishment. Sections 4.2.1. 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 Section 3.1. Sections 4.2.1.1 through 4.2.1.3.

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

3.2.2

4.3.2 Rekey Events

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

Once it an event has been identified, using identified (as defined in the group's group security policy, that a Rekey
event has occurred, policy
token), the GC must GCKS MUST create and send a signed message containing the GTEK
and Rekey array information to the group.

Each GM who receives this message must MUST verify the signature on the message
to ensure its authenticity. If the message signature does not verify,
the session is terminated. GSAKMP sends a properly authenticated message
with a Notification Payload of type NACK to indicate termination. MUST be discarded. Upon verification the GM will find the
appropriate Rekey download packet and decrypt the information with a stored
Rekey key. 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 7:

3.3 Group Removal/Destruction

At this point 5:

5 Security Suite

The Security Definition Suite 1 MUST be supported. Other security suite
definitions MAY be defined in the group's life-cycle, there has been a decision to
destroy the group and the notification is broadcast on a key management

Harney/Colegrove/Harder/Meth/Fleischer other internet specifications.

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 19]

INTERNET-DRAFT GSAKM Protocol March 2001 GSAKMP June 2003

Table 7: 5: Rekey Event Message Definition

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

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

channel or through a directory service.

The components of

5.1 Assumptions

All petential GMS will hae enough information available to them to use the
correct Security Suite to join the group. This can be accomplished by a Group Removal/Destruction message are shown in Table 8:

Table 8: Group Removal/Destruction Message
well known default suite 'Security Suite 1' or by announcing/posting another
suite.

5.2 Definition

Message Name : Group Removal/Destruction
Dissection : {HDR, GrpID, [Policy Token], Destruct}SigC,
[CertC]
Payload Types : Suite 1

GSAKMP Header, [Policy Token], Notification,
Signature, [Certificate], [Vendor ID]

SigC : Signature of Group Controller
CertC : Certificate implementations MUST support the following suite of Group Controller
{}SigX :Indicates minimum fields used in Signature
[] : Indicate an optional data item

Harney/Colegrove/Harder/Meth/Fleischer [Page 20]

INTERNET-DRAFT GSAKM Protocol March 2001

4 Message formats

4.1 GSAKMP Header algorithms and
configurations. The GSAKMP Header fields are defined in Figure 2: 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

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 20]

INTERNET-DRAFT GSAKMP June 2003

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:
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 3:

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

Group Identification Value (variable length) - Indicates the name/title

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 21]

INTERNET-DRAFT GSAKMP June 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 Type ! Group ID Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ! Next Payload ! Version ! Exchange Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Message Sequence ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

Figure 2: 3: GSAKMP Header Format

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

Table 9: 6: Group Identification Types

Grp ID Type Value
_____________________
IPSec

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

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

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

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

Harney/Colegrove/Harder/Meth/Fleischer [Page 21]

INTERNET-DRAFT GSAKM Protocol March 2001

Table 10: Payload Types
The current value is one (1).

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

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 22]

INTERNET-DRAFT GSAKMP June 2003

Table 7: Payload Types

Next_Payload_Type Value

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

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

Table 11: 8: Exchange Types

Exchange_Type Value
___________________________________

Request to Join

__________________________
Reserved 0
Invitation 1
Invitation Response 2
Key Download - 3
Acknowledgement
Notification 4
Rekey Event 5
Group Removal/Destruction
Reserved 6
Other 7-255
No Message ID (4 octets) - This field is included to keep symmetry with
ISAKMP. Currently, this value is set 7
Request to zero (0). Join 8
Key Download 9
Cookie Download 10
Other 11-255

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 23]

INTERNET-DRAFT GSAKMP June 2003

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

Harney/Colegrove/Harder/Meth/Fleischer [Page 22]

INTERNET-DRAFT GSAKM Protocol March 2001

4.2

6.2 Generic Payload Header

Each GSAKMP payload defined in the following sections begins with a generic
header, shown in Figure 3, 4, 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: 4: 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 7 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.

4.3 Data Attributes

6.3 Policy Token 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 Policy Token Payload contains group specific information that describes
the flexibility for representation of many different types of
information. There can be multiple Data Attributes within group security relevant behaviors, access control parameters, and
security mechanisms. This information may contain a payload.
The length digital signature(s) to
prove authority and integrity of the Data Attributes will either be 4 octets or defined by information. Figure 5 shows the Attribute Length field. This is done using format
of the Attribute Format bit
described in Figure 4. payload.

The Data Attributes Policy Token Payload fields are defined as follows:

Attribute Type (2 octets)

Next Payload (1 octet) - Unique identifier Identifier for each the payload type of attribute.
The most significant bit, or Attribute Format (AF), indicates whether the data attributes follow next
payload in the Type/Length/Value (TLV) format or a
shortened Type/Value (TV) format. message. If the AF bit current payload is a zero (0), then the
Data Attributes are of the Type/Length/Value (TLV) form. If last in the AF bit
is a one (1),
message, then the Data Attributes are of the Type/Value form.

Harney/Colegrove/Harder/Meth/Fleischer this field will be 0.

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

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 23] 24]

INTERNET-DRAFT GSAKM Protocol March 2001 GSAKMP June 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Attribute Type ! AF=0 Attribute Length ! Next Payload ! RESERVED ! AF=1 Attribute Value Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! AF=0 Attribute Value ~ ID Type ! AF=1 Not Transmitted Policy Token Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

Figure 4: Data Attributes 5: Policy Token Payload Format

Payload

Attribute Length (2 octets) - Length in octets of the Attribute Value.
When current payload,
including the AF bit is a one (1), generic payload header.

ID Type (1 octet) - Specifies the Attribute Value is only 2 octets and type of Policy Token being used.
Table 9 identifies the Attribute Length field is not present.

Attribute 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) - Value of the attribute associated with
the GSAKMP-specific Attribute Type. If the AF bit is a zero (0), Contains Policy Token information.
The values for this field has a variable length defined are group specific and the format is specified
by the Attribute Length ID Type field. The Policy Token format is specified in [HCLM00].

If
the AF bit this payload is a one (1), encrypted, only the Attribute Value has a length of 2 octets.

4.4 Policy Token Payload Data field is encrypted.

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

6.4 Key Download Payload

The Key Download Payload contains group specific information that describes
the keys (eg., group keys, initial
rekey keys, etc.). These key download payloads can have several security relevant behaviors, access control parameters, and
security mechanisms. This information may contain a digital signature(s)
attributes applied to
prove authority and integrity them based upon the security policy of the information. group.
Figure 5 6 shows the format of the payload.

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

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 25]

INTERNET-DRAFT GSAKMP June 2003

Figure 5: Policy Token 6: Key Download Payload Format

The Policy Token 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.

Harney/Colegrove/Harder/Meth/Fleischer [Page 24]

INTERNET-DRAFT GSAKM Protocol March 2001

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)

Key Download Data (variable length) - Specifies the type of Policy Token being used.
Table 12 identifies the types of policy tokens.

Table 12: 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).

4.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/Colegrove/Harder/Meth/Fleischer [Page 25]

INTERNET-DRAFT GSAKM Protocol March 2001

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

Table 13: 10: 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.

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 26]

INTERNET-DRAFT GSAKMP June 2003

The format of this field is specific depending on the value of
the Key Download Data field.

4.5.1 GTEK

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

For a Key Download Data value of GTEK, the Key Packet Data field format 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
defined in the Policy Token.

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

Harney/Colegrove/Harder/Meth/Fleischer [Page 26]

INTERNET-DRAFT GSAKM Protocol March 2001

data was originally generated. Section A.2.1.

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

Key Handle (4 octets) -- This is Rekey, the randomly generated value to uniquely
identify a key. Key Packet Data (variable length) -- This is the actual encryption key data,
which field format is dependent on the Key Type algorithm
defined in Section A.2.2.

The payload type for its format.

4.5.2 Rekey Key Packet

GSAKMP currently uses the Logical Key Hierarchy (LKH) protocol for Rekey
operations. This Key Download Packet Data is assumed 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 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
them based upon the Leaf Node ID security policy of the LKH sequence
contained in this Key Packet Data block.

Number of LKH Keys (2 octets) -- This value is group. Figure 7 shows 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/Colegrove/Harder/Meth/Fleischer [Page 27]

INTERNET-DRAFT GSAKM Protocol March 2001

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

4.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 format
of the payload.

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

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

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 27]

INTERNET-DRAFT GSAKMP June 2003

Table 14: 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/Colegrove/Harder/Meth/Fleischer [Page 28]

INTERNET-DRAFT GSAKM Protocol March 2001

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 this field is located defined in the appendix section.
Section A.3

The Rekey Event payload type is three (3).

4.7

6.6 Identification Payload

The Identification Payload contains entity-specific data used to exchange
identification information. This information is used for
determining to verify the
identities of negotiating members and may be used for
determining authenticity of information. members. Figure 8 shows the format of the Identification
Payload.

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,

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 28]

INTERNET-DRAFT GSAKMP June 2003

including the generic payload header.

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

Table 12: Identification Data (variable length) - 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).

Harney/Colegrove/Harder/Meth/Fleischer [Page 29]

INTERNET-DRAFT GSAKM Protocol March 2001

Table 15: 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

4.8 Authorization

6.7 Certificate Payload

The Authorization Certificate Payload contains group-specific data used provides a means to exchange role
authorization information. This 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 used for determining the
authorization of entities within a group. not available
to distribute certificates. Figure 9 shows the format of the
Authorization Certificate
Payload.

Figure 9: Authorization Certificate Payload Format

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

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 29]

INTERNET-DRAFT GSAKMP June 2003

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

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

Authorization

Certificate Type (1 octet) (2 octets) - Specifies This field indicates the type of role authorization
being used. certificate
or certificate-related information contained in the Certificate Data
field. Table 16 identifies 13 presents 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/Colegrove/Harder/Meth/Fleischer [Page 30]

INTERNET-DRAFT GSAKM Protocol March 2001 certificate payloads.

Table 16: Authorization 13: Certificate Payload Types

Auth_Type

Certificate_Type Value
________________________________________________

Group Controller
____________________________________________________________

None 0
Group and Rekey Controller
Reserved 1
Rekey Controller 2
Subordinate Group Controller - 3
Subordinate Group and Rekey Controller
X.509 Certificate -- Signature - DER Encoding 4
Subordinate Rekey Controller
Reserved 5
Member ID 6
Unassigned 7-255 -- 65534

Certificate Data (variable length) - Actual encoding of certificate data.
The payload type for the Authorization Payload of certificate is five (5).

4.9 indicated by the Certificate Payload Type/Encoding
field.

The payload type for 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. six (6).

6.8 Signature Payload

The Certificate payload MUST be accepted at
any point during an exchange. 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 10 shows the format of the Certificate Signature Payload.

Figure 10: Certificate Payload Format

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

Harney/Colegrove/Harder/Meth/Fleischer [Page 31]

INTERNET-DRAFT GSAKM Protocol March 2001
including the generic payload header.

Certificate Encoding (1 octet) - This field indicates

Signature Type (2 octets) -- Indicates the type of
certificate or certificate-related information contained in signature. This is
really treated as 2 one byte fields. The first byte is the
Certificate Data field. Signature
Type as represented by Table 17 presents 14. The second byte is the types of certificate
payloads.

Table 17: 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).

4.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/Colegrove/Harder/Meth/Fleischer [Page 32]

INTERNET-DRAFT GSAKM Protocol March 2001

0 1 2 3 format for the

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 30]

INTERNET-DRAFT GSAKMP June 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 Signature Type ! Certificate Authority Signature Payload Span ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ! Sig ID Role ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ Signature Timestamp ! Signer ID Len ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ! Signer ID Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Signature Length ! Signature Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

Figure 11: Certificate Request 10: Signature Payload Format

payload in the message. If the current payload

Signer ID data and is defined by the last values in the
message, then this field will be 0.

RESERVED (1 octet) Table 12.

Table 14: Signature Types

Signature Type - Unused, set to 0.

Payload Length (2 byte 1 Value
_____________________________________

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

Signature Payload Span (4 octets) - Length 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
zero (0). If the current payload,
including signature payload itself is not in the generic signature span,
you MUST still sign over the signature payload header.

Certificate Type up to the signature data.

Signature ID Role (1 octet) - Contains an encoding of the type of
certificate requested.

Certificate Authority (variable length) - Contains an encoding of an
acceptable certificate authority for -- Specifies the type of certificate requested.
As an example, Authorization (Role)
being used. Refer to Table 15 for an X.509 certificate this field would contain the
Distinguished Name encoding of the Issuer Name types of an X.509 certificate
authority acceptable to authorization (role).

Signature Timestamp (4 octets) -- Date and time that the sender of this payload. digital signature
was applied. This would be
included to assist field contains the responder time in determining how much of seconds from the
certificate chain would need to be sent epoch
00:00 GMT 1 January 1970.

Signer ID Length (2 octets) - Length in response to this request. If
there is no specific certificate authority requested, this field SHOULD
NOT be included. octets of the Signer' ID.

Signer ID Data (variable length) -- Data identifying the Signer's ID
(e.g., DN). The payload type format for the Certificate Request Payload this field is seven (7).

4.11 Hash Payload

The Hash Payload contains data generated by based on the hash function over some part
of second byte in the message and/or

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 31]

INTERNET-DRAFT GSAKMP state. This payload may be used June 2003

Table 15: 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 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 verify the integrity of 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 independant Notification
payloads in a single GSAKMP message or for authentication of the
negotiating entities. message. Figure 12 11 shows the format of the Hash
Notification Payload.

The Hash 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

Harney/Colegrove/Harder/Meth/Fleischer [Page 33]

INTERNET-DRAFT GSAKM Protocol March 2001

Figure 12: Hash 11: Notification Payload Format

The Notification Payload fields are defined as follows:

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 32]

INTERNET-DRAFT GSAKMP June 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.

Hash Domain (1 octet)

Notify Payload Type (2 octets) - Specifies the domain type of the hash. notification
message. Table 18
identifies 16 presents the hash domains.

Table 18: Hash Domains

Hash Domain Notify Payload Types.

Table 16: Notify Payload Types

Information Value
_____________________
_______________________________________________

None 0
Unassigned 1-255

Hash
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
Cookie Required 27
Cookie 28
Reserved (future use) 29 - 8191
Private Use 8192 -- 16383

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 33]

INTERNET-DRAFT GSAKMP June 2003

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 Payload Status Types.

Table 17: Notify Payload -- Status Types

Status Value
_______________________________

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

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

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

4.12 Signature nine (9).

6.9.1 Notification Data - Acknowledgement (ACK) Payload Type

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 portion of the Signature Data. The exception to this is if Notification payload of type ACK serves either
for confirmation of correct receipt of the signature algorithm used is DSS with ASN.1/DER encoding. Due to the
variable length of Key Download message, or, when
needed, can provide other receipt information when included in a DER encoding, the signature span across the signature
payload itself only extends up to the signature data length field, not the
signature data. signed
message. Figure 13 12 shows the format of the Signature Payload.

The Signature Notification Data - Acknowledge
Payload fields are defined as follows:

Harney/Colegrove/Harder/Meth/Fleischer [Page 34]

INTERNET-DRAFT GSAKM Protocol March 2001 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Sig Ack Type ! Signature Payload Span ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ! Sig ID Role ! Signature Timestamp ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ! Signer ID Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ Signer ID Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Signature Length ! Signature Acknowledgement Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

Figure 13: Signature 12: Notification Data - Acknowledge Payload Type Format

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

Ack Type (1 octet) - Identifier for Specifies the payload type of acknowledgement. Table 18
presents the next
payload in the message. If Notify Acknowledgement Payload Types.

Simple - Data portion null.

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 34]

INTERNET-DRAFT GSAKMP June 2003

Table 18: Acknowledgement Types

ACK_Type Value
____________________

Simple 0
Unassigned 1-255

6.9.2 Notification Data - Cookie Request and Cookie Payload Type

The data portion of the current Notification payload is the last in of types Cookie_Request and
Cookie contain the
message, then Cookie value. The value for this field will be 0.

RESERVED (1 octet) - Unused, set have been
computed by the reponder GCKS and sent to 0.

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

Signature Type (1 octet) -- Indicates value
received and place AS IS into the type Notification payload Notification Data
field of signature. Table 19
presents type Cookie that is transmitted in the Signature Types.

Table 19: Signature Types

Signature Type Value
_____________________________________

DSS "Request to Join with ASN.1/DER encoding 0
DSS without encoding 1
Other 2-255

Signature Payload Span (4 octets) - Identifies Cookie
Info" back to the information included GCKS. This value MUST NOT be modified.

The format for this is already described in the signature. discussion on cookies in
section 4.2.2.

6.10 Key Creation Payload

The first two octets define the first signature payload. Key Creation Payload contains information used to create key encryption
keys. The third and fourth octet define security attributes for this payload are provided in the Policy
Token. Figure 13 shows the format of the last payload.

Figure 13: Key Creation Payload Format

The payloads in the
message Key Creation Payload fields are an ordered sequence beginning at defined as follows:

Next Payload (1 octet) - Identifier for the header, with a value payload type of 0. If the signature next
payload itself is not in the signature span, you
must still sign over message. If the signature current payload up to is the signature data.

Harney/Colegrove/Harder/Meth/Fleischer last in the
message, then this field will be 0.

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

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 35]

INTERNET-DRAFT GSAKM Protocol March 2001

Signature ID Role (1 octet) -- Specifies the type GSAKMP June 2003

Payload Length (2 octets) - Length in octets of Authorization (Role)
being used. Refer to Table 16 for the types of authorization (role).

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

Signer generic payload header.

ID Length (2 octets) Type (1 octet) - Length in octets of Specifies the Signer' ID.

Signer ID (variable length) -- Data identifying type of Key Creation being used.
Table 19 identifies the Signer's ID (e.g.,
DN).

Signature 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) - Data that results from applying Contains Key Creation information.
The values for this field are group specific and the
digital signature function to format is specified
by the GSAKMP message and/or payload. ID Type field.

The payload type for the Signature Payload Key Creation Packet is nine (9).

4.13 Notification eleven (11).

6.11 Nonce Payload

The Notification Nonce Payload can contain both GSAKMP and group specific contains random 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. guarantee freshness during an
exchange and protect against replay attacks. Figure 14 shows the format of
the Notification 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Notify Message Nonce Type ! STATUS TYPE ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ Notification Nonce Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

Figure 14: Notification Nonce Payload Format

The Notification 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, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 36]

INTERNET-DRAFT GSAKMP June 2003

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

Harney/Colegrove/Harder/Meth/Fleischer [Page 36]

INTERNET-DRAFT GSAKM Protocol March 2001
including the generic payload header.

Notify Message

Nonce Type (2 octets) (1 octet) - Specifies the type of notification
message. Nonce being used. Table 20 presents
identifies the Notify Message Types. types of nonces.

Table 20: Notify Messages Nonce Types

Information

Nonce_Type Value
_______________________________________________

Invalid-Payload-Type Definition
________________________________________________________________________________

None 0
Situation-Not-Supported
Initiator 1
Invalid-Major-Version
Responder 2
Invalid-Version
Combined 3
Invalid-Group-ID 4
Invalid-Message-ID 5
Payload-Malformed 6
Invalid-Key-Information 7
Invalid-ID-Information 8
Invalid-Cert-Encoding 9
Invalid-Certificate 10
Cert-Type-Unsupported 11
Invalid-Cert-Authority 12
Authentication-Failed 13
Invalid-Signature 14
Notify-GSA-Lifetime 15
Certificate-Unavailable 16
Unequal-Payload-Lengths 17
Unauthorized Request 18
Unable To Take Requested Role 19
Group Deleted 20
Request To Join 21
Acknowledgement 22
Invitation 23
Invitation-Response 24
Nack 25
Reserved (future use) 26 - 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 21 presents Hash ( Append (Initiator_Value, Responder_Value) )
The hash type comes from the Notification Message Status Types.

Notification Security Suite Definition.
Unassigned 4-255

Nonce Data (variable length) - Informational or error data
transmitted in addition to Contains the Notify Message Type. Values nonce information. The values
for this field are Domain of Interpretation (DOI)-specific.

Harney/Colegrove/Harder/Meth/Fleischer [Page 37]

INTERNET-DRAFT GSAKM Protocol March 2001

Table 21: 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

The payload type for group-specific and the Notification Payload format is ten (10).

4.13.1 Notification Data - Acknowledgement (ACK) Message specified by the
Nonce Type

The data portion of field. If no group-specific information is provided, the ACK
minimum length for this field is 4 bytes.

The payload serves either type 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. Nonce Payload is twelve (12).

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 37]

INTERNET-DRAFT GSAKMP June 2003

7 GSAKMP State Diagram

Figure 15
shows the format of presents 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 15: 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 22 presents the Notify Acknowledgement Message Types.

Table 22: Acknowledgement Types

ACK_Type Value
____________________

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

Harney/Colegrove/Harder/Meth/Fleischer [Page 38]

INTERNET-DRAFT GSAKM Protocol March 2001

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.

4.14 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 16 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 states encountered in the version use of this protocol.
Table 21 defines the product.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! states. Table 22 defines the transitions.

!-----------------> ( )
! Next Payload !-------------> ( Idle ) <------------------!
! RESERVED ! Payload Length ( ) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Vendor ID (VID) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! ! ! !
! ! ! ! !
! ! (1a) (1) !
! ! ! ! !
! ! ! ! !
! ! V V !
! !---(5a)--- (Wait for ) (Wait for ) ----(5)-----!
! (Group ) (GCKS Event) <---
! (Membership) ^ ! \ \
! ! ! ! \ \
! ! ! ! \--(2)---\
! (2a) (4)(3)
! ! ! !
! ! ! !
! V ! V
!-------(4a)--- (Wait for ) (Wait for )
(Group ) (Response )
(Membership) (from Key )
/--> (Event ) (Download )
/ /
/ /
/--(3a)---/

Figure 16: Vendor ID Payload Format

The Vendor ID Payload fields are defined as follows:

Harney/Colegrove/Harder/Meth/Fleischer 15: GSAKMP State Diagram

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 39] 38]

INTERNET-DRAFT GSAKM Protocol March 2001

Next Payload (1 octet) - Identifier GSAKMP June 2003

Table 21: GSAKMP States
__________________________________________________________________________

Idle : GSAKMP Application waiting 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.

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

The payload type input
_____________________:____________________________________________________
:
Wait for the Vendor ID Payload is eleven (11).

4.15 GCKS Event : GCKS up and running, waiting for events
_____________________:____________________________________________________
:
Wait for Response : GCKS has sent Key Creation Payload

The Download,
from Key Creation Payload contains information used to create key encryption
keys Download : waiting for the key download payload. These key creation payloads can have
security attributes applied to them based upon the security policy of the
group. Figure 17 shows the format response from GM
_____________________:____________________________________________________
:
Wait for Group : GM in process of the payload.

0 1 2 3
0 joining group
Membership :
_____________________:____________________________________________________
:
Wait for Group : GM has group key, waiting for
Membership Event : group management messages.
:

__________________________________________________________________________

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 39]

INTERNET-DRAFT GSAKMP June 2003

Table 22: State Transition Events
____________________________________________________________________

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

____________________________________________________________________

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 40]

INTERNET-DRAFT GSAKMP June 2003

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 9 0 1 2 3 octets long,
4 5 6 7 8 9 0 1 2 3 octets for IPv4 internet address in network byte order, and 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! ID Type ! Key Creation Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

Figure 17: octets
for serial number in network byte order.

A.2 Key Creation Download Payload Format

The Fields

A.2.1 GTEK Key Packet Fields

For a Key Creation Payload fields are defined Download Data value of GTEK, the Key Packet Data field is
formatted as follows:

Next Payload

Key Type (1 octet) - Identifier for the payload type of -- This is the next
payload encryption algorithm for which this key
data is to be used. This value is specified in the message. If the current payload Policy Token.

Key Creation Date (4 octets) -- This is the last in the
message, then time value of when this key
data was originally generated. This field will be 0.

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

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

ID Type (1 octet) - Specifies time in seconds
from the type of epoch 00:00 GMT 1 January 1970.

Key Creation being used.
Table 23 identifies Expiration Date (4 octets) -- This is the types time value of when this key download information.

Harney/Colegrove/Harder/Meth/Fleischer [Page 40]

INTERNET-DRAFT GSAKM Protocol March 2001

Table 23: Types Of
is no longer valid for use. This field contains the time in seconds
from the epoch 00:00 GMT 1 January 1970.

Key Creation Information

ID_Type Value
________________________

Diffie-Hellman 0
other 1-255 Handle (4 octets) -- This is the randomly generated value to uniquely
identify a key.

Key Creation Data (variable length) - Contains Key Creation information.
The values for this field are group specific and -- This is the format actual encryption key data,
which is specified
by dependent on the ID Key Type field.

The payload type algorithm for the its format.

A.2.2 Rekey Key Creation Packet Fields

This field is twelve (12).

4.16 Nonce Payload

The Nonce Payload contains random data used to guarantee freshness during an
exchange and protect against replay attacks. Figure 18 shows defined within the specific type of rekey scheme used by the
group.

For LKH, the format of the Nonce Payload.

Figure 18: Nonce Payload Format

The Nonce Payload fields are this field is defined as follows:

Next in Section B.1.

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 41]

INTERNET-DRAFT GSAKMP June 2003

A.3 Rekey Event Payload (1 octet) - Identifier for Fields

This field is defined within the payload specific type of rekey event scheme used by
the next
payload in the message. If the current payload is group.

For LKH, the last in format of the
message, then this field will be 0.

RESERVED (1 octet) - Unused, set to 0. 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 (2 (4 octets) - -- Length in octets of the current payload,
including the generic payload header.

Nonce Type (1 octet) - Specifies DN Data field.

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

B APPENDIX B -- LKH Variable Length Payload Field Definitions

This appendix defines the type format of Nonce being used. Table 24
identifies the types all LKH specific variable length fields
that contain multiple items of nonces.

Harney/Colegrove/Harder/Meth/Fleischer [Page 41]

INTERNET-DRAFT GSAKM Protocol March 2001

Table 24: Nonce Types

Nonce_Type Value Definition
__________________________________________________________________________

None 0
Initiator 1
Responder 2
Combined 3 Hash ( Append (Initiator_Value, Responder_Value) )
Unassigned 4-255

Nonce information.

B.1 LKH Rekey Key Packet Fields

When using the Logical Key Hierarchy (LKH) protocol for Rekey operations,
the Key Packet Data (variable length) - is assumed to contain LKH Array data of the following
format:

LKH Version (1 octet) -- Contains the nonce information. version of the LKH protocol in which
the data is formatted. The values current value for this field are group-specific and the format is specified by the
Nonce Type field. If no group-specific information one (1).

Leaf ID (2 octets) -- This is provided, the
minimum length for Leaf Node ID of the LKH sequence
contained in this field is 4 bytes. Key Packet Data block. The payload type for leftmost leaf node ID
value is one (1).

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

For each LKH key in the sequence, the data format is thirteen (13).

Harney/Colegrove/Harder/Meth/Fleischer as follows:

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 42]

INTERNET-DRAFT GSAKM Protocol March 2001

5 GSAKMP State Diagram

Figure 19 presents June 2003

LKH ID (2 octets) -- This is the states encountered position of this key in the use binary
tree structure used by LKH. The base node of this protocol.

(1)
! -----------------------------------(17)----------------
! ! !
V V !
( )---------------------(4)---------------->( ) !
(idle) (queued) !
( )<-------------------(5)-----------------( ) !
! ^ !
! ! !
(2) (3) !
V ! !
(Establishing Group) -(10)-> (GSA Established) -(16)->(Destroy GSA)
! ^ ^ ! ^ ^
! ! ! ! ! !----(15)----
! ! ! ! -----(13)- !
(6)! ------(9)----- --(12)-- ! !
!(7) ! ! ! !
V ! ! V ! !
(Establishing Group) (GSA Established) (Destroy GSA) (Destroy GSA)

Figure 19: GSAKMP State Diagram

Table 25 defines the transitions.

Harney/Colegrove/Harder/Meth/Fleischer [Page 43]

INTERNET-DRAFT GSAKM Protocol March 2001

Table 25: State Transition Events
____________________________________________________________________
Transition 1 : Request binary tree has a
value of one (1).

Key Type (1 octet) -- This is the encryption algorithm for which this
key data is to Join be used. This value is received 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 TCP/IP
: GUI Input
_______________:_Application_Input__________________________________
:
_Transition_2__:_Group_SA_Required__________________________________
:
Transition 3 : Failure the epoch 00:00 GMT 1 January 1970.

Key Expiration Date (4 octets) -- This is the time value of Peer SA service
: Protocol Message failure
: Incorrect format
: Signature failed validation
: Certificate on CRL
: Access control invalid
: Authorization invalid
_______________:_Timeout____________________________________________
:
Transition 4 : Session required, but tables full
_______________:_Session_required,_but_processor_busy_______________

:
_Transition_5__:_Timeout____________________________________________
:
Transition 6 : Request Peer SA service
_______________:_Create_Protocol_Messages___________________________
:
_Transition_7__:_Peer_SA_established________________________________
:
_Transition_8__:_N/A________________________________________________
:
_Transition_9__:_Receipt_of_protocol_messages_______________________
:
_Transition_10_:_Group_SA_establishment_complete____________________
:
_Transition_11_:_N/A________________________________________________
:
_Transition_12_:_LKH_event_message_completed________________________
:
_Transition_13_:_Group_SA_send_failure_notification_________________
:
_Transition_14_:_N/A________________________________________________
:
_Transition_15_:_LKH_event_message__________________________________
:
_Transition_16_:_Delete_Request_validated___________________________
:
Transition 17 : Destruction complete
____________________________________________________________________

Harney/Colegrove/Harder/Meth/Fleischer [Page 44]

INTERNET-DRAFT GSAKM Protocol March 2001

6 APPENDIX A 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 Data Format Fields

This appendix 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.

6.1

B.2.1 Rekey Event Header

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

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

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 43]

INTERNET-DRAFT GSAKMP June 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 20: A.1: 16: B. 1: Rekey Event Header Format

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

Time/Date Stamp (4 octets) - This is the time value of when the Rekey
Event Data was generated.

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

Harney/Colegrove/Harder/Meth/Fleischer [Page 45]

INTERNET-DRAFT GSAKM Protocol March 2001
the Rekey Data.

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

6.2

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 21 17 shows the format of each Rekey Event Packet
with respect to LKH.

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

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 44]

INTERNET-DRAFT GSAKMP June 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 21: A.2: 17: 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.

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.

Harney/Colegrove/Harder/Meth/Fleischer [Page 46]

INTERNET-DRAFT GSAKM Protocol March 2001

6.3

B.2.3 Key Pack Data

Each Key Pack contains all the information about the key. Figure 22 18 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 22: A.3: 18: 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.

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

6.4

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 45]

INTERNET-DRAFT GSAKMP June 2003

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.

6.4.1

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

Harney/Colegrove/Harder/Meth/Fleischer [Page 47]

INTERNET-DRAFT GSAKM Protocol March 2001 actual encryption key data, which
is dependent on the Key Type algorithm for its format.

6.4.2

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

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 46]

INTERNET-DRAFT GSAKMP June 2003

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.

6.5

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:

Harney/Colegrove/Harder/Meth/Fleischer [Page 48]

INTERNET-DRAFT GSAKM Protocol March 2001
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)
Pack Length - 0xLLLL
Key Type - 0x02 (DES3)
Key Creation Date - 0xTTTTTTTC
Key Expiration Date - 0xTTTTTTTE

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 47]

INTERNET-DRAFT GSAKMP June 2003

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

Harney/Colegrove/Harder/Meth/Fleischer

C APPENDIX C -- Change History

C.1 Changes from GSAKMP-01 to GSAKMP-02 February 2003

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.

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 49] 48]

INTERNET-DRAFT GSAKM GSAKMP June 2003

C.2 Changes from GSAKMP-02 to GSAKMP-03 June 2003

1. The specification was modified to confirm that key words are used as
defined by RFC2119.

2. The Protocol March 2001

7 References and Considerations section for IANA port number was added.

3. The Cookie section for mitigation of DoS attacks was added.

4. The Protocol State Diagram was added.

D References, Authors Addresses

7.1 References Addesses, and Acknowledgements

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

D.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
Multicast: Issues and Architectures'', Internet Draft, Informational,
September 1998.

``Multicast Security

[BMS], Balenson D., McGrew D., Sherman A., ``Key Management Protocol (MSMP) Requirements for Large
Dynamic Groups: One-Way Function Trees and Policy'',
SPARTA, October, 1998.

``Logical Key Hierarchy (LKH) Protocol'', SPARTA, October, 1998. 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.

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 49]

INTERNET-DRAFT GSAKMP June 2003

[RFC 2104] Krawczyk H., Bellare M., and Canetti R., ``HMAC: Keyed-Hashing
for Message Authentication'', RFC 2104, Informational, February 1997. 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.

The Secure Multicast Research Group (SMuG), An Internet Research Task Force
Group formed to discuss issues related to multicast security.

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

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

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

Balenson D., McGrew D., Sherman A., ``Key

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

[RFC2627] D. Wallner, E. Harder, R. Agee, Kay Management for Large Dynamic
Groups: One-Way Function Trees Multicast:
Issues and Amortized Initialization'', Internet
Draft, February 1999.

Harney/Colegrove/Harder/Meth/Fleischer [Page 50]

INTERNET-DRAFT GSAKM Protocol Architectures, June 1999

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

[IKEv2], C. Kaufman, ``Internet Key Exchange (IKEv2) Protocol'',
draft-ietf-ipsec-ikev2-o6.txt, March 2001

Bhattacharya 2003

[HCM] H. Harney, A. Colegrove, P. and Pereira R., ``IPSec McDaniel, "Principles of Policy Data Model'', in Secure
Groups", Proceedings of Network and Distributed Systems Security 2001
Internet Draft, Society, San Diego, CA, February 1998.

7.2 2001

[HCLM00] H. Harney, A. Colegrove, P. Lough, U. Meth, ``GSAKMP Token
Specification'', draft-ietf-msec-tokenspec-sec-00.txt

D.2 Authors Addresses

Hugh Harney (point-of-contact)
9861 Broken Land Parkway
Suite 300
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
(410) 381-9400 872-1515 ext 203
FAX (410) 381-5559
hh@columbia.sparta.com 872-8079

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 50]

INTERNET-DRAFT GSAKMP June 2003

hh@sparta.com

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

Andrea Colegrove
9861 Broken Land Parkway
Suite 300
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
(410) 381-9400 872-1515 ext 232
FAX (410) 381-5559
acc@columbia.sparta.com

Eric J. Harder 872-8079
acc@sparta.com

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

Uri Meth
9861 Broken Land Parkway
Suite 300
Columbia, MD 21046
(410) 381-9400 ext 233
amschue@tycho.ncsc.mil

Patrick McDaniel
AT&T Labs - Research
A203, Bldg. 103
180 Park Ave.
Florham Park, NJ 07932
Office (973) 360-5721
pdmcdan@research.att.com

Gavin Kenny
LogicaCMG
Keats House
The Office Park
Springfield Drive
Leatherhead, Surrey KT22 7LP, UK
+44 1372 838043
FAX (410) 381-5559
umeth@columbia.sparta.com

Rod Fleischer
9861 Broken Land Parkway
Suite 300
Columbia, MD 21046
(410) 381-9400 ext 237 +44 1372 759196
Gavin.IA.Kenny@LogicaCMG.com

Haitham S. Cruickshan
Centre for Communication Systems Research (CCSR)
University of Surrey
Guildford, Surrey GU2 7XH, UK
+44 1483 686007 (indirect 689844)

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 51]

INTERNET-DRAFT GSAKMP June 2003

FAX (410) 381-5559
rodf@columbia.sparta.com +44 1483 686011
H.Cruickshank@surrey.ac.uk

Sunil Iyengar
Centre For Communication And Systems Research(CCSR)
School of Electronics, Computing and Mathematics
University Of Surrey, Guildford GU2 7XH
Surrey, England, United Kingdom
+44 (0)1483 876008
s.iyengar@eim.surrey.ac.uk

D.3 Acknowledgements

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

Document expiration: August 31, 2001

Harney/Colegrove/Harder/Meth/Fleischer December 30, 2003

Harney, etal. draft-ietf-msec-gsakmp-sec-02.txt [Page 51] 52]
----