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

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

Internet Engineering Task Force
INTERNET-DRAFT                                             H Harney (SPARTA)
                                                             U Meth (SPARTA)
                                                        A Colegrove (SPARTA)
                                                        G Gross (IdentAware)
draft-ietf-msec-gsakmp-sec-08.txt          SPARTA, Inc., IdentAware Security
Expires:  September 17, 2005                                      March 2005


                                   GSAKMP




                            Status of this memo



By submitting this Internet-Draft, the authors certify that any applicable
patent or other IPR claims of which I am (we are) aware have been disclosed,
or will be disclosed, and any of which I (we) become aware will be
disclosed, in accordance with RFC 3668 (BCP 79).

By submitting this Internet-Draft, the authors accept the provisions of
Section 3 of RFC 3667 (BCP 78).

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.


                                  Abstract

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


INTERNET-DRAFT                       GSAKMP                       March 2005

    during group establishment and recovery, capabilities to recover
    from the compromise of group members, delegation of group security
    functions, and capabilities to destroy the group.  It also
    generates group keys.













































  Copyright Notice Copyright (c) The Internet Society (2005).  All Rights
                                 Reserved.


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt   [Page 2]

INTERNET-DRAFT                       GSAKMP                       March 2005

Contents

1 Overview                                                                 9
  1.1 GSAKMP Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
  1.2 Document Organization . . . . . . . . . . . . . . . . . . . . . . . 10

2 Terminology                                                             11
3 Security Considerations                                                 13
  3.1 Security Assumptions  . . . . . . . . . . . . . . . . . . . . . . . 13
  3.2 Related Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 14
    3.2.1 ISAKMP  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
    3.2.2 FIPS Pub 196  . . . . . . . . . . . . . . . . . . . . . . . . . 14
    3.2.3 LKH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
    3.2.4 Diffie-Hellman  . . . . . . . . . . . . . . . . . . . . . . . . 15
  3.3 Denial of Service (DoS) Attack  . . . . . . . . . . . . . . . . . . 15
  3.4 Rekey Availability  . . . . . . . . . . . . . . . . . . . . . . . . 16
  3.5 Proof of Trust Hierarchy  . . . . . . . . . . . . . . . . . . . . . 16

4 Architecture                                                            16
  4.1 Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
    4.1.1 Components  . . . . . . . . . . . . . . . . . . . . . . . . . . 16
    4.1.2 GO  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
    4.1.3 GC/KS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
    4.1.4 Subordinate GC/KS . . . . . . . . . . . . . . . . . . . . . . . 18
    4.1.5 GM  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
    4.1.6 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 19
  4.2 Rule-Based Security Policy  . . . . . . . . . . . . . . . . . . . . 20
    4.2.1 Access Control  . . . . . . . . . . . . . . . . . . . . . . . . 20
    4.2.2 Authorizations for security relevant actions  . . . . . . . . . 21
  4.3 Distributed Operation . . . . . . . . . . . . . . . . . . . . . . . 21
  4.4 Concept of Operation  . . . . . . . . . . . . . . . . . . . . . . . 23
    4.4.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 23
    4.4.2 Creation of a PT  . . . . . . . . . . . . . . . . . . . . . . . 23
    4.4.3 Creation of a Group . . . . . . . . . . . . . . . . . . . . . . 24
    4.4.4 Discovery of GC/KS  . . . . . . . . . . . . . . . . . . . . . . 24
    4.4.5 GC/KS registration policy enforcement . . . . . . . . . . . . . 25
    4.4.6 GM registration policy enforcement  . . . . . . . . . . . . . . 25
    4.4.7 Autonomous Distributed GSAKMP Operations  . . . . . . . . . . . 25
5 Group Life Cycle                                                        27
  5.1 Group Definition  . . . . . . . . . . . . . . . . . . . . . . . . . 28
  5.2 Group Establishment . . . . . . . . . . . . . . . . . . . . . . . . 28
    5.2.1 Standard Group Establishment  . . . . . . . . . . . . . . . . . 29
        5.2.1.1 Request to Join . . . . . . . . . . . . . . . . . . . . . 30
        5.2.1.2 Key Download  . . . . . . . . . . . . . . . . . . . . . . 32
        5.2.1.3 Request to Join Error . . . . . . . . . . . . . . . . . . 33
        5.2.1.4 Key Download - Ack/Failure  . . . . . . . . . . . . . . . 34
        5.2.1.5 Lack of Ack . . . . . . . . . . . . . . . . . . . . . . . 35
    5.2.2 Cookies - Group Establishment with Denial of Service Protection 36
    5.2.3 Group Establishment for Receive-Only Members  . . . . . . . . . 38
  5.3 Group Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 39
    5.3.1 Group Management  . . . . . . . . . . . . . . . . . . . . . . . 39


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt   [Page 3]

INTERNET-DRAFT                       GSAKMP                       March 2005

        5.3.1.1 Rekey Events  . . . . . . . . . . . . . . . . . . . . . . 39
        5.3.1.2 Policy Updates  . . . . . . . . . . . . . . . . . . . . . 39
        5.3.1.3 Group Destruction . . . . . . . . . . . . . . . . . . . . 40
    5.3.2 Leaving a Group . . . . . . . . . . . . . . . . . . . . . . . . 40
        5.3.2.1Eviction . . . . . . . . . . . . . . . . . . . . . . . . . 40
        5.3.2.2Voluntary Departure without Notice . . . . . . . . . . . . 41
        5.3.2.3De-Registration  . . . . . . . . . . . . . . . . . . . . . 41
           5.3.2.3.1Request to Depart . . . . . . . . . . . . . . . . . . 41
           5.3.2.3.2Departure_Response  . . . . . . . . . . . . . . . . . 42
           5.3.2.3.3Departure_ACK . . . . . . . . . . . . . . . . . . . . 43

6 Security Suite                                                          44
  6.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
  6.2 Definition Suite 1  . . . . . . . . . . . . . . . . . . . . . . . . 45
7 GSAKMP Payload Structure                                                46
  7.1 GSAKMP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
    7.1.1 GSAKMP Header Structure . . . . . . . . . . . . . . . . . . . . 46
        7.1.1.1 GroupID Structure . . . . . . . . . . . . . . . . . . . . 50
           7.1.1.1.1 UTF-8  . . . . . . . . . . . . . . . . . . . . . . . 50
           7.1.1.1.2 Octet String . . . . . . . . . . . . . . . . . . . . 50
           7.1.1.1.3 IPv4 Group Identifier  . . . . . . . . . . . . . . . 51
           7.1.1.1.4 IPv6 Group Identifier  . . . . . . . . . . . . . . . 51
    7.1.2 GSAKMP Header Processing  . . . . . . . . . . . . . . . . . . . 52
  7.2 Generic Payload Header  . . . . . . . . . . . . . . . . . . . . . . 54
    7.2.1 Generic Payload Header Structure  . . . . . . . . . . . . . . . 54
    7.2.2 Generic Payload Header Processing . . . . . . . . . . . . . . . 54
  7.3 Policy Token Payload  . . . . . . . . . . . . . . . . . . . . . . . 55
    7.3.1 Policy Token Payload Structure  . . . . . . . . . . . . . . . . 55
    7.3.2 Policy Token Payload Processing . . . . . . . . . . . . . . . . 56
  7.4 Key Download Payload  . . . . . . . . . . . . . . . . . . . . . . . 56
    7.4.1 Key Download Payload Structure  . . . . . . . . . . . . . . . . 57
        7.4.1.1 Key Datum Structure . . . . . . . . . . . . . . . . . . . 59
        7.4.1.2 Rekey Array Structure . . . . . . . . . . . . . . . . . . 60
    7.4.2 Key Download Payload Processing . . . . . . . . . . . . . . . . 61
  7.5 Rekey Event Payload . . . . . . . . . . . . . . . . . . . . . . . . 62
    7.5.1 Rekey Event Payload Structure . . . . . . . . . . . . . . . . . 62
        7.5.1.1 Rekey Event Header Structure  . . . . . . . . . . . . . . 64
        7.5.1.2 Rekey Event Data Structure  . . . . . . . . . . . . . . . 65
           7.5.1.2.1 Key Package Structure  . . . . . . . . . . . . . . . 66
    7.5.2 Rekey Event Payload Processing  . . . . . . . . . . . . . . . . 66
  7.6 Identification Payload  . . . . . . . . . . . . . . . . . . . . . . 68
    7.6.1 Identification Payload Structure  . . . . . . . . . . . . . . . 68
        7.6.1.1 ID_U_NAME Structure . . . . . . . . . . . . . . . . . . . 71
    7.6.2 Identification Payload Processing . . . . . . . . . . . . . . . 71
        7.6.2.1 ID_U_NAME Processing  . . . . . . . . . . . . . . . . . . 72
  7.7 Certificate Payload . . . . . . . . . . . . . . . . . . . . . . . . 72
    7.7.1 Certificate Payload Structure . . . . . . . . . . . . . . . . . 72
    7.7.2 Certificate Payload Processing  . . . . . . . . . . . . . . . . 74
  7.8 Signature Payload . . . . . . . . . . . . . . . . . . . . . . . . . 75
    7.8.1 Signature Payload Structure . . . . . . . . . . . . . . . . . . 75
    7.8.2 Signature Payload Processing  . . . . . . . . . . . . . . . . . 77


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt   [Page 4]

INTERNET-DRAFT                       GSAKMP                       March 2005

  7.9 Notification Payload  . . . . . . . . . . . . . . . . . . . . . . . 78
    7.9.1 Notification Payload Structure  . . . . . . . . . . . . . . . . 78
        7.9.1.1 Notification Data - Acknowledgment (ACK) Payload Type . . 80
        7.9.1.2 Notification Data - Cookie_Required & Cookie Payload Type 80
        7.9.1.3 Notification Data - Mechanism Choices Payload Type  . . . 81
        7.9.1.4 Notification Data - IPv4 and IPv6 Value Payload Types . . 82
    7.9.2 Notification Payload Processing . . . . . . . . . . . . . . . . 82
  7.10 Vendor ID Payload  . . . . . . . . . . . . . . . . . . . . . . . . 83
    7.10.1 Vendor ID Payload Structure  . . . . . . . . . . . . . . . . . 83
    7.10.2 Vendor ID Payload Processing . . . . . . . . . . . . . . . . . 84
  7.11 Key Creation Payload . . . . . . . . . . . . . . . . . . . . . . . 85
    7.11.1 Key Creation Payload Structure . . . . . . . . . . . . . . . . 85
    7.11.2 Key Creation Payload Processing  . . . . . . . . . . . . . . . 86
  7.12 Nonce Payload  . . . . . . . . . . . . . . . . . . . . . . . . . . 87
    7.12.1 Nonce Payload Structure  . . . . . . . . . . . . . . . . . . . 87
    7.12.2 Nonce Payload Processing . . . . . . . . . . . . . . . . . . . 88

8 GSAKMP State Diagram                                                    89
9 IANA Considerations                                                     92
  9.1 IANA Port Number Assignment . . . . . . . . . . . . . . . . . . . . 92
  9.2 Initial IANA Registry Contents  . . . . . . . . . . . . . . . . . . 92
    9.2.1 GSAKMP Group Identification Types . . . . . . . . . . . . . . . 92
        9.2.1.1 Amending formula for GSAKMP Group Identification Types  . 93
    9.2.2 GSAKMP Payload Types  . . . . . . . . . . . . . . . . . . . . . 93
        9.2.2.1 Amending formula for GSAKMP Payload Types . . . . . . . . 93
    9.2.3 GSAKMP Exchange Types . . . . . . . . . . . . . . . . . . . . . 93
        9.2.3.1 Amending formula for GSAKMP Exchange Types  . . . . . . . 94
    9.2.4 GSAKMP Policy Token Types . . . . . . . . . . . . . . . . . . . 94
        9.2.4.1 Amending formula for GSAKMP Policy Token Types  . . . . . 94
    9.2.5 GSAKMP Key Download Data Item Types . . . . . . . . . . . . . . 94
        9.2.5.1 Amending formula for GSAKMP Key Download Data Item Types. 94
    9.2.6 GSAKMP Cryptographic Key Types  . . . . . . . . . . . . . . . . 95
        9.2.6.1 Amending formula for GSAKMP Cryptographic Key Types . . . 95
    9.2.7 GSAKMP Rekey Event Types  . . . . . . . . . . . . . . . . . . . 95
        9.2.7.1 Amending formula for GSAKMP Rekey Event Types . . . . . . 95
    9.2.8 GSAKMP Identification Classification  . . . . . . . . . . . . . 95
        9.2.8.1 Amending formula for GSAKMP Identification Classification 96
    9.2.9 GSAKMP Identification Types . . . . . . . . . . . . . . . . . . 96
        9.2.9.1 Amending formula for GSAKMP Identification Types  . . . . 96
    9.2.10 GSAKMP Certificate Types . . . . . . . . . . . . . . . . . . . 96
        9.2.10.1 Amending formula for GSAKMP Certificate Types  . . . . . 97
    9.2.11 GSAKMP Signature Types . . . . . . . . . . . . . . . . . . . . 97
        9.2.11.1 Amending formula for GSAKMP Signature Types  . . . . . . 97
    9.2.12 GSAKMP Notification Types  . . . . . . . . . . . . . . . . . . 97
        9.2.12.1 Amending formula for GSAKMP Notification Types . . . . . 98
    9.2.13 GSAKMP Acknowledgment Types  . . . . . . . . . . . . . . . . . 98
        9.2.13.1 Amending formula for GSAKMP Acknowledgment Types . . . . 98
    9.2.14 GSAKMP Mechanism Types . . . . . . . . . . . . . . . . . . . . 99
        9.2.14.1 Amending formula for GSAKMP Mechanism Types  . . . . . . 99
    9.2.15 GSAKMP Nonce Hash Types  . . . . . . . . . . . . . . . . . . . 99
        9.2.15.1 Amending formula for GSAKMP Nonce Hash Types . . . . . . 99


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt   [Page 5]

INTERNET-DRAFT                       GSAKMP                       March 2005

    9.2.16 GSAKMP Key Creation Types  . . . . . . . . . . . . . . . . . . 99
        9.2.16.1 Amending formula for GSAKMP Key Creation Types  . . . . 100
    9.2.17 GSAKMP Nonce Types  . . . . . . . . . . . . . . . . . . . . . 100
        9.2.17.1 Amending formula for GSAKMP Nonce Types . . . . . . . . 100

10 Acknowledgments                                                       100
11 References                                                            101
  11.1 Normative References  . . . . . . . . . . . . . . . . . . . . . . 101
  11.2 Informative References  . . . . . . . . . . . . . . . . . . . . . 102

A APPENDIX A -- LKH Information                                          103
  A.1 LKH Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
  A.2 LKH and GSAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 104
  A.3 LKH Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
    A.3.1 LKH Key Download Example . . . . . . . . . . . . . . . . . . . 105
    A.3.2 LKH Rekey Event Example  . . . . . . . . . . . . . . . . . . . 106
B APPENDIX B -- Change History (To Be Removed from RFC)                  108
  B.1 Changes from GSAKMP-00 to GSAKMP-01 February 2003  . . . . . . . . 108
  B.2 Changes from GSAKMP-01 to GSAKMP-02 June 2003  . . . . . . . . . . 108
  B.3 Changes from GSAKMP-02 to GSAKMP-03 August 2003  . . . . . . . . . 108
  B.4 Changes from GSAKMP-03 to GSAKMP-04 October 2003 . . . . . . . . . 109
  B.5 Changes from GSAKMP-04 to GSAKMP-05 February 2004  . . . . . . . . 113
    B.5.1 Major Modification/Reorganization of Specification . . . . . . 113
        B.5.1.1 Key Terms and Payloads Modified  . . . . . . . . . . . . 113
    B.5.2 Modification By Section  . . . . . . . . . . . . . . . . . . . 114
  B.6 Changes from GSAKMP-05 to GSAKMP-06 May 2004 . . . . . . . . . . . 117
  B.7 Changes from GSAKMP-06 to GSAKMP-07 December 2004  . . . . . . . . 122
  B.8 Changes from GSAKMP-07 to GSAKMP-08 March 2005 . . . . . . . . . . 123

Authors Addresses                                                        123

Full Copyright Statement                                                 124





















Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt   [Page 6]

INTERNET-DRAFT                       GSAKMP                       March 2005

List of Figures

  1   GSAKMP Ladder Diagram . . . . . . . . . . . . . . . . . . . . . . . 29
  2   GSAKMP Ladder Diagram with Cookies  . . . . . . . . . . . . . . . . 37
  3   GSAKMP Header Format  . . . . . . . . . . . . . . . . . . . . . . . 46
  4   GroupID UTF-8 Format  . . . . . . . . . . . . . . . . . . . . . . . 50
  5   GroupID Octet String Format . . . . . . . . . . . . . . . . . . . . 51
  6   GroupID IPv4 Format . . . . . . . . . . . . . . . . . . . . . . . . 51
  7   GroupID IPv6 Format . . . . . . . . . . . . . . . . . . . . . . . . 52
  8   Generic Payload Header  . . . . . . . . . . . . . . . . . . . . . . 54
  9   Policy Token Payload Format . . . . . . . . . . . . . . . . . . . . 55
  10  Key Download Payload Format . . . . . . . . . . . . . . . . . . . . 57
  11  Key Download Data Item Format . . . . . . . . . . . . . . . . . . . 58
  12  Key Datum Format  . . . . . . . . . . . . . . . . . . . . . . . . . 59
  13  Rekey Array Structure Format  . . . . . . . . . . . . . . . . . . . 61
  14  Rekey Event Payload Format  . . . . . . . . . . . . . . . . . . . . 62
  15  Rekey Event Header Format . . . . . . . . . . . . . . . . . . . . . 64
  16  Rekey Event Data Format . . . . . . . . . . . . . . . . . . . . . . 65
  17  Key Package Format  . . . . . . . . . . . . . . . . . . . . . . . . 66
  18  Identification Payload Format . . . . . . . . . . . . . . . . . . . 69
  19  Unencoded Name (ID-U-NAME) Format . . . . . . . . . . . . . . . . . 71
  20  Certificate Payload Format  . . . . . . . . . . . . . . . . . . . . 73
  21  Signature Payload Format  . . . . . . . . . . . . . . . . . . . . . 75
  22  Notification Payload Format . . . . . . . . . . . . . . . . . . . . 78
  23  Notification Data - Acknowledge Payload Type Format . . . . . . . . 80
  24  Notification Data - Mechanism Choices Payload Type Format . . . . . 81
  25  Vendor ID Payload Format  . . . . . . . . . . . . . . . . . . . . . 83
  26  Key Creation Payload Format . . . . . . . . . . . . . . . . . . . . 85
  27  Nonce Payload Format  . . . . . . . . . . . . . . . . . . . . . . . 87
  28  GSAKMP State Diagram  . . . . . . . . . . . . . . . . . . . . . . . 89
  29   A. 1:  LKH Tree . . . . . . . . . . . . . . . . . . . . . . . . . 103
  30   A. 2:  GSAKMP LKH Tree  . . . . . . . . . . . . . . . . . . . . . 105





















Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt   [Page 7]

INTERNET-DRAFT                       GSAKMP                       March 2005

List of Tables

  1   Request to Join (RTJ) Message Definition  . . . . . . . . . . . . . 30
  2   Key Download (KeyDL) Message Definition . . . . . . . . . . . . . . 32
  3   Request to Join Error (RTJ-Err) Message Definition  . . . . . . . . 33
  4   Key Download - Ack/Failure (KeyDL-A/F) Message Definition . . . . . 34
  5   Lack of Ack (LOA) Message Definition  . . . . . . . . . . . . . . . 35
  6   Cookie Download Message Definition  . . . . . . . . . . . . . . . . 37
  7   Rekey Event Message Definition  . . . . . . . . . . . . . . . . . . 40
  8   Request_to_Depart (RTD) Message Definition  . . . . . . . . . . . . 41
  9   Departure_Response (DR) Message Definition  . . . . . . . . . . . . 42
  10  Departure_ACK (DA) Message Definition . . . . . . . . . . . . . . . 43
  11  Group Identification Types  . . . . . . . . . . . . . . . . . . . . 47
  12  Payload Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
  13  Exchange Types  . . . . . . . . . . . . . . . . . . . . . . . . . . 49
  14  Policy Token Types  . . . . . . . . . . . . . . . . . . . . . . . . 56
  15  Key Download Data Item Types  . . . . . . . . . . . . . . . . . . . 58
  16  Cryptographic Key Types . . . . . . . . . . . . . . . . . . . . . . 60
  17  Rekey Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 63
  18  Identification Classification . . . . . . . . . . . . . . . . . . . 69
  19  Identification Types  . . . . . . . . . . . . . . . . . . . . . . . 70
  20  Certificate Payload Types . . . . . . . . . . . . . . . . . . . . . 74
  21  Signature Types . . . . . . . . . . . . . . . . . . . . . . . . . . 76
  22  Notification Types  . . . . . . . . . . . . . . . . . . . . . . . . 79
  23  Acknowledgment Types  . . . . . . . . . . . . . . . . . . . . . . . 80
  24  Mechanism Types . . . . . . . . . . . . . . . . . . . . . . . . . . 81
  25  Nonce Hash Types  . . . . . . . . . . . . . . . . . . . . . . . . . 82
  26  Types Of Key Creation Information . . . . . . . . . . . . . . . . . 86
  27  Nonce Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
  28  GSAKMP States . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
  29  State Transition Events . . . . . . . . . . . . . . . . . . . . . . 91






















Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt   [Page 8]

INTERNET-DRAFT                       GSAKMP                       March 2005

1 Overview


This protocol provides policy distribution, policy enforcement, key
distribution, and key management for cryptographic groups.  Cryptographic
groups all share a common (set of) key(s) for data processing.  These keys
all support a system level security policy so that the cryptographic group
can be trusted to perform security relevant services.

The ability of a group of entities to perform security services requires
that a Group Secure Association (GSA) be established.  A GSA ensures
that there is a common "group level" definition of security policy and
enforcement of that policy.  The distribution of cryptographic keys is a
mechanism utilizing the group level policy enforcements.



1.1 GSAKMP Overview


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

GSAKMP separates group security management functions and responsibilities
into three major roles:  1) Group Owner, 2) Group Controller Key Server,
and 3) Group Member.  The Group Owner is responsible for creating the
security policy rules for a group and expressing these in the Policy Token.
The Group Controller Key Server (GC/KS) is responsible for creating and
maintaining the keys and enforcing the group policy by granting access
to potential Group Members (GM) in accordance with the Policy Token.  To
enforce a group's policy the potential Group Members need to have knowledge
of the access control policy for the group, an unambiguous identification
of any party downloading keys to them, and verifiable chains of authority
for key download.  In other words, the Group Members need to know who
potentially will be in the group and to verify that the key disseminator is
authorized to act in that capacity.

In order to establish a Group Secure Association (GSA) to support these
activities, the identity of each party in the process MUST be unambiguously
asserted and authenticated.  It MUST also be verified that each party is
authorized, as defined by the Policy Token, to function in his role in the
protocol (e.g., GM or GC/KS).

The security features of the establishment protocol for the GSA include


 -  Group policy identification

 -  Group policy dissemination

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt   [Page 9]

INTERNET-DRAFT                       GSAKMP                       March 2005

 -  GM to GC/KS SA establishment to protect data

 -  Access control checking



GSAKMP provides mechanisms for cryptographic group creation and
management.  Other protocols may be used in conjunction with GSAKMP to
allow various applications to create functional groups according to their
application-specific requirements.  For example, in a small-scale video
conference the organizer might use a session invitation protocol like SIP
[RFC 3261] to transmit information about the time of the conference, the
address of the session, and the formats to be used.  For a large-scale video
transmission, the organizer might use a multicast announcement protocol like
SAP [RFC 2974].

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.  Transmission 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 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 defines the architecture of GSAKMP. Section 5 describes
the group management life-cycle.  Section 6 describes the Security Suite
Definition.  Section 7 presents the message types and formats used during
each phase of the life-cycle.  Section 8 defines the state diagram for the
protocol.





Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 10]

INTERNET-DRAFT                       GSAKMP                       March 2005

2 Terminology


The following terminology is used throughout the GSAKMP paper.



Requirements Terminology:   Keywords "MUST", "MUST NOT", "REQUIRED",
    "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be
    interpreted as described in [RFC 2119].

Certificate:   A data structure used to verifiably bind an identity to a
    cryptographic key (e.g., X.509v3).

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

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

Group Controller Key Server (GC/KS):  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:


     -  Authenticate and validate the identities and the authorizations of
        entities performing security relevant actions

     -  Accept group keys from the GC/KS

     -  Request group keys from the GC/KS

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

     -  Perform peer review of key management actions

     -  Manage 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 GC/KS to start the group.

Group Policy:   The Group Policy completely describes the protection

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 11]

INTERNET-DRAFT                       GSAKMP                       March 2005

    mechanisms and security relevant behaviors of the group.  This policy
    MUST be commonly understood and enforced by the group for coherent
    secure operations.

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

Group Traffic Protection Key (GTPK):  The key or keys created for
    protecting the group data.

Key Datum:   A single key and its associated attributes for its usage.

Key Encryption Key (KEK):  Key used in an encryption mechanism for wrapping
    another key.

Key Handle:   The identifier of a particular instance or version of a key.

Key ID:  The identifier for a key that MUST stay static throughout the
    life-cycle of this key.

Key Package:   Type/Length/Data format containing a Key Datum.

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

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



     -  GSAKMP protocol version

     -  Key creation method

     -  Key dissemination policy

     -  Access control policy

     -  Group authorization policy

     -  Compromise recovery policy

     -  Data protection mechanisms


Rekey:   The act of changing keys within a group as defined by policy.

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 12]

INTERNET-DRAFT                       GSAKMP                       March 2005

Rekey Array:   The construct that contains all the rekey information for a
    particular member.

Rekey Key:   The KEK used to encrypt keys for a subset of the group.

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

Wrapping KeyID:  - The Key ID of the key used to wrap a Key Package.

Wrapping Key Handle:   The key handle of the Key used to wrap the Key
    Package.



3 Security Considerations


In addition to the specification of GSAKMP itself, the security of an
implemented GSAKMP system is affected by supporting factors.  These are
discussed here.


3.1 Security Assumptions


The following assumptions are made as the basis for the security discussion


1.  GSAKMP assumes its supporting platform can provide the process and data
    separation services at the appropriate assurance level to support its
    groups.

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

3.  The security of this protocol is critically dependent on the randomness
    of the randomly chosen parameters.  These should be generated by a
    strong random or properly seeded pseudo-random source [RFC 1750].

4.  The security of a group can be affected by the accuracy of the system
    clock.  Therefore, GSAKMP assumes that the system clock is close to
    correct time.  If a GSAKMP host relies on a network time service to set
    its local clock, then that protocol must be secure against attackers.
    The maximum allowable clock skew across the group membership:  policy
    configurable, with a default of 5 minutes.


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 13]

INTERNET-DRAFT                       GSAKMP                       March 2005

5.  As described in the message processing section, the use of the Nonce
    value used for freshness along with a signature is the mechanism used
    to foil replay attacks.  In any use of Nonces a core requirement is
    unpredictability of the nonce, from an attackers viewpoint.  The utility
    of the Nonce relies on the inability of an attacker to either reuse old
    Nonces or predict the Nonce value.

6.  GSAKMP does not provide identity protection.

7.  The group's multicast routing infrastructure is not secured by GSAKMP,
    and therefore it may be possible to create a multicast flooding denial
    of service attack using the multicast application's data stream.  Either
    an insider (i.e.  a rogue GM) or a non-member could direct the multicast
    routers to spray data at a victim system.

8.  The compromise of a S-GC/KS forces the re-registration of all GMs under
    its control.  The GM recognizes this situation by finding the S-GC/KSs
    certificate on a CRL as supplied by a service such as LDAP.

9.  The compromise of the GO forces termination of the group.  The GM
    recognizes this situation by finding the GOs certificate on a CRL as
    supplied by a service such as LDAP.



3.2 Related Protocols


GSAKMP derives from two (2) existing protocols:  ISAKMP [MSST98] and
FIPS Pub 196 [FIPS 196].  In accordance with Security Suite 1, GSAKMP
implementations MUST support the use of Diffie-Hellman key exchange [DH77]
for two party key creation and MAY use Logical Key Hierarchy (LKH) [RFC
2627] for rekey capability.


3.2.1 ISAKMP


ISAKMP provides a flexible structure of chained payloads in support of
authenticated key exchange and security association management for pairwise
communications.  GSAKMP builds 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.





Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 14]

INTERNET-DRAFT                       GSAKMP                       March 2005

3.2.3 LKH


When group policy dictates that a recovery of the group security is
necessary after the discovery of the compromise of a GM, then GSAKMP
relies upon a rekey capability, i.e., LKH, to enable group recovery after
a compromise [RFC 2627].  This is optional since in many instances it may be
better to destroy the compromised group and rebuild a secure group.


3.2.4 Diffie-Hellman


A Group may rely upon two party key creation mechanisms, i.e.,
Diffie-Hellman, to protect sensitive data during download.

The information in this section is borrowed heavily from [IKEv2] as this
protocol has already worked through similar issues and GSAKMP is using the
same security considerations for its purposes.  This section will contain
paraphrased sections of [IKEv2] modified for GSAKMP as appropriate.

The strength of a key derived from a Diffie-Hellman exchange using
specific p and g values depends on the inherent strength of the values,
the size of the exponent used, and the entropy provided by the random
number generator used.  A strong random number generator combined with
the recommendations from [RFC 3526] on Diffie-Hellman exponent size is
recommended as sufficient.  An implementation should make note of this
conservative estimate when establishing policy and negotiating security
parameters.

Note that these limitations are on the Diffie-Hellman values themselves.
There is nothing in GSAKMP which prohibits using stronger values nor is
there anything which will dilute the strength obtained from stronger values.
In fact, the extensible framework of GSAKMP encourages the definition of
more Security Suites.

It is assumed that the Diffie-Hellman exponents in this exchange are erased
from memory after use.  In particular, these exponents MUST NOT be derived
from long-lived secrets such as 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  5.2.2,
Cookies.




Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 15]

INTERNET-DRAFT                       GSAKMP                       March 2005

3.4 Rekey Availability


In addition to GSAKMP having the capability to do rekey operations, GSAKMP
MUST also have the capability to make this rekey information highly
available to GMs.  The necessity of GMs receiving rekey messages, requires
the use of methods to increase the likelihood of receipt of Rekey Messages.
These methods MAY include multiple transmissions of the rekey message,
posting of the rekey message on a bulletin board, etc.  Compliant GSAKMP
implementations MUST support retransmission of rekey messages.



3.5 Proof of Trust Hierarchy


As defined by [HCM], security group policy MUST be 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 GC/KS 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 GC/KS is an authorized disseminator, and 3) the
group mechanisms are acceptable for protecting the GMs data.


4 Architecture


This architecture presents a trust model for GSAKMP and a concept of
operations for establishing a trusted distributed infrastructure for group
key and policy distribution.

GSAKMP conforms to the IETF MSEC architectural concepts as specified in the
MSEC Architecture document [RFC 3740].  GSAKMP uses the MSEC components to
create a trust model for operations that implement the security principles
of mutual suspicion and trusted policy creation authorities.


4.1 Trust Model


4.1.1 Components


The trust model contains four key components:


 -  Group Owners (GO),



Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 16]

INTERNET-DRAFT                       GSAKMP                       March 2005

 -  Group Controllers / Key Servers (GC/KS),

 -  Subordinate GC/KS (S-GC/KS), and

 -  Group Members (GM).



The goal of the GSAKMP trust model is to derive trust from a common trusted
policy creation authority for a group.  All security relevant decisions and
actions implemented by GSAKMP are based on information that ultimately is
traceable to and verified by the trusted policy creation authority.  There
are two trusted policy creation authorities for GSAKMP, the GO (policy
creation authority) and the PKI root that allows us to verify the GO.


4.1.2 GO


The GO is the policy creation authority for the group.  The GO has a well
defined identity that is relevant to the group.  That identity can be of a
person or of a group trusted component.  All potential entities in the group
have to recognize the GO as the individual with authority to specify policy
for the group.

The policy reflects the protection requirements of the data in a group.
Ultimately, the data and the application environment drives the security
policy for the group.

The GO has to determine the security rules and mechanisms that are
appropriate for the data being protected by the group keys.  All this
information is captured in a policy token (PT). The GO creates the PT and
signs it.


4.1.3 GC/KS


The GC/KS is authorized to perform several functions:  key creation, key
distribution, rekey, and group membership management.

As key creation authority, the GC/KS will create the set of keys for
the group.  These keys include the Group Traffic Protection Keys (GTPK)
and first tier rekey keys.  There may be second tier rekey trees if a
distributed rekey management structure is required for the group.

As the key distribution (registration) authority, it has to notify the
group of its location for registration services.  The GC/KS will have to
enforce key access control as part of the key distribution and registration
processes.

As the group rekey authority, it performs rekey in order to change the

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 17]

INTERNET-DRAFT                       GSAKMP                       March 2005

group's GTPK. Change of the GTPK limits the exposure of data encrypted with
any single GTPK.

Finally, as group membership management authority, the GC/KS can manage the
group membership (registration, eviction, de-registration, etc.).  This may
be done in part by using key tree approaches such as Logical Key Hierarchies
(LKH), as an optional approach.


4.1.4 Subordinate GC/KS


A subordinate GC/KS is used to distribute the GC/KS functionality across
multiple entities.  The S-GC/KS will have all the authorities of the GC/KS
except one:  it will not create the GTPK. It is assumed here that the group
will transmit data with a single GTPK at any one time.  This GTPK comes from
the GC/KS.

Note that relative to the GC/KS, the S-GC/KS is responsible for an
additional security check:  the S-GC/KS must register as a member with the
GC/KS, and during that process it has to verify the authority of the GC/KS.


4.1.5 GM


The GM has two jobs - make sure all security relevant actions are authorized
and properly use the group keys.  During the registration process, the GM
will verify that the PT is signed by a recognized GO. In addition, it will
verify that the GC/KS or S-GC/KS engaged in the registration process is
authorized, as specified in the PT. If rekey and new PTs are distributed
to the group, the GM will verify that they are proper and all actions are
authorized.

The GM is granted access to group data through receipt of the group keys
This carries along with it a responsibility to protect the key from
unauthorized disclosure.

GSAKMP does not offer any enforcement mechanisms to control which GM are
multicast speakers at a given moment.  This policy and its enforcement
depend on the multicast application and its protocols.  However, GSAKMP
does allow a group to have one of three Group Security Association multicast
speaker configurations:



 -  There is a single GM authorized to be the group's speaker.  There
    is one multicast application SA allocated by the GO in support of
    that speaker.  The PT initializes this multicast application SA and
    identifies the GM that has been authorized to be speaker.  All GM
    share a single TPK with that GM speaker.  Sequence number checking for
    anti-replay protection is feasible and enabled by default.  This is the

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 18]

INTERNET-DRAFT                       GSAKMP                       March 2005

    default group configuration.  GSAKMP implementations MUST support this
    configuration.

 -  The GO authorizes all of the GM to be a group speaker.  The GO allocates
    one multicast application SA in support of these speakers.  The PT
    initializes this multicast application SA and indicates that any GM
    can be a speaker.  All of the GM share a single TPK and other SA state
    information.  Consequently, some SA security features such as sequence
    number checking for anti-replay protection can not be supported by
    this configuration.  GSAKMP implementations MUST support this group
    configuration.

 -  The GO authorizes a subset of the GM to be a group speaker (which may be
    the subset comprised of all GM). The GO allocates a distinct multicast
    application SA for each of these speakers.  The PT identifies the
    authorized speakers, and initializes each of their multicast application
    Security Associations.  The speakers still share a common TPK across
    their SA, but each speaker has a separate SA state information instance
    at every peer GM. Consequently, this configuration supports SA security
    features such as sequence number checking for anti-replay protection or
    source authentication mechanisms that require per speaker state at the
    receiver.  The drawback of this configuration is that it does not scale
    to a large numbers of speakers.  GSAKMP implementations MAY support this
    group configuration.



4.1.6 Assumptions


The assumptions for this trust model are:


 -  the GCKS is assumed to be never compromised,

 -  the GO is assumed to be never compromised,

 -  the PKI, subject to certificate validation, is assumed to be
    trustworthy,

 -  The GO is capable of creating a security policy to meet the demands of
    the group,

 -  the compromises of a group member will be detectable and reported to the
    GO in a trusted manner,

 -  the subsequent recovery from a compromise will deny inappropriate access
    to protected data to the compromised member,

 -  no security relevant actions depend on a precise network time,

 -  that there is confidentiality, integrity, multicast source authentication

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 19]

INTERNET-DRAFT                       GSAKMP                       March 2005

    and anti-replay protection mechanisms for all GSAKMP control messages.



4.2 Rule-Based Security Policy


The trust model for GSAKMP revolves around the definition and enforcement
of the security policy.  In fact, the use of the key is only relevant, in
a security sense, if it represents the successful enforcement of the group
security policy.

Group operations lend themselves to rule-based security policy.  The need
for distribution of data to many endpoints often leads to the defining of
those authorized endpoints based on rules.  For example, all IETF attendees
at a given conference could be defined as a single group.

If the security policy rules are to be relevant, they must be coupled with
validation mechanisms.  The core principle here is that the level of trust
one can afford a security policy is exactly equal to the level of trust one
has in the validation mechanism used to prove that policy.  For example, if
all IETF attendees are allowed in then they could register their identity
from their certificate upon check in to the meetings.  That certificate is
issued by a trusted policy creation authority (PKI root) that is authorized
to identify someone as being an IETF attendee.  The GO could make admittance
rules to the IETF group based on the identity certificates issued from
trusted PKIs.

In GSAKMP, every security policy rule is coupled with an explicit validation
mechanism.  For interoperability considerations, GSAKMP requires its
supporting PKI implementations MUST be compliant to RFC 3280.

If a GM public key certificate is revoked, then the entity that issues
that revocation SHOULD signal the GO, so that the GO can expel that GM.
The method that signals this event to the GO is not standardized by this
specification.

A direct mapping of rule to validation mechanism allows the use of multiple
rules and PKIs to create groups.  This allows a GO to define a group
security policy that spans multiple PKI domains, each with their own
Certificate Authority public key certificate.


4.2.1 Access Control


The access control policy for the group keys is equivalent to the access
control policy for the multicast application data the keys are protecting.

In a group, each data source is responsible for ensuring that the access
to the source's data is appropriate.  This implies that every data source
should have knowledge of the access control policy for the group keys.

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 20]

INTERNET-DRAFT                       GSAKMP                       March 2005

In the general case, GSAKMP offers a suite of security services to its
applications, and does not prescribe how they use those services.

GSAKMP supports the creation of GSAs with multiple data sources.  It also
supports architectures where the GC/KS is not itself a data source.  In
the multiple data source architectures GSAKMP requires that the access
control policy is precisely defined and distributed to each data source.
The reference for this data structure is the GSAKMP Policy Token [ref CH02].


4.2.2 Authorizations for security relevant actions


A critical aspect of the GSAKMP trust model is the authorization of security
relevant actions.  Security relevant actions include - download of group
key, rekey, and PT creation and updates.  These actions could be used to
disrupt the secure group and all entities in the group must verify that they
were instigated by authorized entities within the group.



4.3 Distributed Operation


Scalability is a core feature of GSAKMP. GSAKMP's approach to scalable
operations is the establishment of S-GC/KSs.  This allows the GSAKMP systems
to distribute the workload of setting up and managing very large groups.

Another aspect of distributed S-GC/KS operations is the enabling of local
management authorities.  In very large groups, subordinate enclaves may be
best suited to provide local management of the enclaves' group membership,
due to a direct knowledge of the group members.

One of the critical issues involved with distributed operation is the
discovery of the security infrastructure location and security suite.  Many
group applications that have dynamic interactions must "find" each other
to operate.  The discovery of the security infrastructure is just another
piece of information that has to be known by the group in order to operate
securely.

There are several methods for infrastructure discovery:


 -  Announcements

 -  Anycast

 -  Rendezvous points / Registration


One method for distributing the security infrastructure location is to use
announcements.  The SAP is commonly used to announce the existence of a

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 21]

INTERNET-DRAFT                       GSAKMP                       March 2005

new multicast application or service.  If an application uses SAP[Ref RFC
2974] to announce the existence of a service on a multicast channel, that
service could be extended to include the security infrastructure location
for a particular group.

Announcements can also be used by GSAKMP in one of two modes - Expanding
Ring Searches (ERS) of security infrastructure and expanding ring searches
for infrastructure discovery.  In either case, the GSAKMP would use a
multicast broadcast that would slowly increase in its range by incremental
multicast hops.  The multicast source controls the packet's multicast range
by explicitly setting its Time To Live count.

An expanding ring announcement operates by the GC/KS announcing its
existence for a particular group.  The number of hops this announcement
would travel would be a locally configured number.  The GMs would listen
on a well know multicast address for GC/KSs that provide service for groups
of interest.  If multiple GC/KSs are found that provide service, then the
GM would pick the closest one (in terms of multicast hops).  The GM would
then send a GSAKMP Request to Join message (RTJ) to the announced GC/KS.
If the announcement is found to be spurious then that is reported to the
appropriate management authorities.  The ERA concept is slightly different
from SAP in that it could occur over the data channel multicast address,
instead of a special multicast address dedicated for the SAP service.

An expanding ring search operates in the reverse order than the ERA. In
this case, the GM is the announcing entity.  The (S-)GC/KSs listen for the
requests for service, specifically the RTJ. The (S-)GC/KS responds to the
RTJ. .  If the GM receives more than one response, it would either ignore
the responses or send NACKs based on local configuration.

Anycast is a service that is very similar to ERS. It also can be used to
provide connection to the security infrastructure.  In this case, the GM
would send the RTJ to a well-known service request address.  This anycast
service would route the RTJ to an appropriate GC/KS. The anycast service
would have security infrastructure and network connectivity knowledge to
facilitate this connection.

Registration points can be used to distribute many group relevant data,
including security infrastructure.  Many group applications rely on well
known registration points to advertise the availability of groups.  There
is no reason that GSAKMP could not use the same approach for advertising
the existence and location of the security infrastructure.  This is a simple
process if the application being supported already supports registration.
The GSAKMP infrastructure can always provide a registration site if the
existence of this security infrastructure discovery hub is needed.  The
registration of S-GC/KSs at this site could be an efficient way to allow GM
registration.

GSAKMP infrastructure discovery can use whatever mechanism suits a
particular multicast application's requirements, including mechanisms
that have not been discussed by this architecture.  However, GSAKMP


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 22]

INTERNET-DRAFT                       GSAKMP                       March 2005

infrastructure discovery is not standardized by this version of the GSAKMP
specification.



4.4 Concept of Operation


This concept of operation shows how the different roles in GSAKMP interact
to set up a secure group.  This particular concept of operation focuses on a
secure group that utilizes the distributed key dissemination services of the
S-GC/KS.


4.4.1 Assumptions


The most basic assumption here is one or more trustworthy PKI for the group.
That trusted PKI will be used to create and verify security policy rules.

There is a GO that all GMs recognize as having group policy creation
authority.  All GM must be securely pre-configured to know the GO public
key.

All GMs have access to the GO PKI information, both the trusted anchor
public keys and the certificate path validation rules.

There is sufficient connectivity between the GSAKMP entities.


 -  The registration SA requires that GM can connect to the GC/KS or S-GC/KS
    using either TCP or UDP.

 -  The rekey SA requires that the data layer multicast communication
    service be available.  This can be multicast IP, overlay networks using
    TCP, or NAT tunnels.

 -  GSAKMP can support many different data layer secure applications each
    with unique connectivity requirements.


4.4.2 Creation of a PT


The GO creates and signs the Policy Token for a group.  The policy token
contains the rules for access control and authorizations for a particular
group.

The PT consists of the following information:




Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 23]

INTERNET-DRAFT                       GSAKMP                       March 2005

 -  Identification - this allows an unambiguous identification of the PT and
    the group,

 -  Access Control Rules - these rules specify who can have access to the
    group keys,

 -  Authorization Rules - these rules specify who can be a S-GC/KS,

 -  Mechanisms - these rules specify the security mechanisms that will be
    used by the group, this is necessary to ensure there is no weak link in
    the group security profile, for example, for IPsec, this could include
    SPD/SAD configuration data,

 -  Source authentication of the PT to the GO - the PT is a CMS signed
    object and this allows all GMs to verify the PT.



4.4.3 Creation of a Group


The PT is sent to a potential GC/KS. This can occur in several ways, and
the method of transmittal is outside the scope of GSAKMP. The potential
GC/KS will verify the GO signature on the PT to ensure that it comes from a
trusted GO. Next, the GC/KS will verify that it is authorized to become the
GC/KS, based on the authorization rules in the PT. Assuming that the GC/KS
trusts the PT, is authorized to be a GC/KS, and is locally configured to
become a GC/KS for a given group and the GO, then the GC/KS will create the
keys necessary to start the group.  The GC/KS will take whatever action is
necessary (if any) to advertise its ability to distribute key for the group.
The GC/KS will then listen for RTJs.

The PT has a sequence number.  Every time a PT is distributed to the group
the group members verify that the sequence number on the PT is increasing.
The PT lifetime is not limited to a particular time interval, other than
by the lifetimes imposed by some of its attributes (e.g.  signature key
lifetime).  The current PT sequence number is downloaded to the GM in
the "Key Download" message.  Also, to avoid replay attacks, this sequence
number is never reset to a lower value (i.e.  rollover to zero) as long as
the group identifier remains valid and in use.  The GO MUST preserve this
sequence number across re-boots.


4.4.4 Discovery of GC/KS


Potential GMs will receive notice of the new group via some mechanism:
announcement, Anycast, registration look-up.  The GM will send an RTJ to the
GC/KS.




Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 24]

INTERNET-DRAFT                       GSAKMP                       March 2005

4.4.5 GC/KS registration policy enforcement


The GC/KS may or may not require cookies, depending on Denial of Service
environment and the local configuration.

Once the RTJ has been received, the GC/KS will verify that the GM is allowed
to have access to the group keys.  The GC/KS will then verify the signature
on the RTJ to ensure it was sent by the claimed identity.  If the checks
succeed, the GC/KS will ready a Key Download message for the GM. If not the
GC/KS can notify the GM of a non-security relevant problem.


4.4.6 GM registration policy enforcement


Upon receipt of the Key Download message, the GM will verify the signature
on the message.  Then the GM will retrieve the PT from the Key Download
message and verify that the GO created and signed the PT. Once the PT is
verified as valid, the GM will verify that the GC/KS is authorized to
distribute key for this group.  Then the GM will verify that the mechanisms
used in the group are available and acceptable for protection of the GMs
data (assuming the GM is a data source).  The GM will then accept membership
in this group.

The GM will then check to see if it is allowed to be a S-GC/KS for this
group.  If the GM is allowed to be a S-GC/KS AND the local GM configuration
allows the GM to act as a S-GC/KS for this group, then the GM changes
its operating state to S-GC/KS. The GO needs to assign the authority to
become a S-GC/KS in a manner that supports the overall group integrity and
operations.


4.4.7 Autonomous Distributed GSAKMP Operations


In autonomous mode, each S-GC/KS operates a largely self-contained sub-group
for which the Primary-GC/KS delegates the sub-group's membership management
responsibility to the S-GC/KS. In general, the S-GC/KS locally handles each
Group Member's registration and de- registration without any interaction
with the Primary-GC/KS. Periodically, the Primary-GC/KS multicasts a Re-Key
Event message addressed only to its one or more S-GC/KS.

After a S-GC/KS successfully processes a Rekey Event message from the
Primary-GC/KS, the S-GC/KS transmits to its sub-group its own Rekey Event
message containing a copy of the group's new GTPK and policy token.  The
S-GC/KS encrypts its Rekey Event message's sub-group key management
information using Logical Key Hierarchy or a comparable re-key protocol.
The S-GC/KS uses the re-key protocol to realize forward and backward
secrecy, such that only the authorized sub-group members can decrypt and
acquire access to the new GTPK and policy token.  The frequency at which the


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 25]

INTERNET-DRAFT                       GSAKMP                       March 2005

Primary-GC/KS transmits a Re-Key Event message is a policy token parameter.

For the special case of a S-GC/KS detecting an expelled or compromised group
member, there is a mechanism defined to trigger an immediate group re-key
rather than waiting for the group's re-key period to elapse.  See below for
details.

Each S-GC/KS will be registered by the GC/KS as a management node with
responsibility for GTPK distribution, access control policy enforcement,
LKH tree creation and distribution of LKH key arrays.  The S-GC/KS will be
registered into the primary LKH tree as an endpoint.  Each S-GC/KS will hold
an entire LKH key array for the GC's LKH key tree.

For the purpose of clarity the process of creating a distributed GSAKMP
group will be explained in chronological order.

First, the Group Owner will create a policy token that authorizes a subset
of the group's membership to assume the role of S-GC/KS.

The GO needs to ensure that the S-GC/KS rules in the policy token will be
stringent enough to ensure trust in the S-GC/KSs.  This policy token is
handed off to the primary GC.

The GC will create the GTPK and initial LKH key tree.  The GC will then wait
for a potential S-GC/KS to send a Request to Join (RTJ) message.

A potential S-GC/KS will eventually send an RTJ. The GC will enforce the
access control policy as defined in the policy token.  The S-GC/KS will
accept the role of S-GC/KS and create its own LKH key tree for its sub-group
membership.

The S-GC/KS will then offer registration services for the group.  There are
local management decisions that are optional to control the scope of group
members that can be served by a S-GC/KS. These are truly local management
issues that allow the administrators of an S-GC/KS to restrict service
to potential GMs.  These local controls do not effect the overall group
security policy, as defined in the Policy Token.

A potential Group Member will send an RTJ to the S-GC/KS. The S- GC/KS
will enforce the entire access control policy as defined in the PT. The
GM will receive an LKH key array that corresponds to the LKH tree of the
S-GC/KS. The key tree generated by the S-GC/KS is independent of the key
tree generated by the GC/KS., they share no common keys.

The GM then has the keys it needs to receive group traffic and be subject to
rekey from the S-GC/KS. For the sake of this discussion let's assume the GM
is to be expelled from the group membership.

The S-GC/KS will receive notification that the GM is to be expelled.  This
mechanism is outside the scope of this protocol.



Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 26]

INTERNET-DRAFT                       GSAKMP                       March 2005

Upon notification that a GM that holds a key array within its LKH tree is
to be expelled the S-GC/KS does two things.  First the S-GC/KS initiates
a de-registration exchange with the GC/KS identifying the member to be
expelled.  (The S-GC/KS proxies a Group Member's de- registration informing
the GC/KS that the Group Member has been expelled from the group.)  Second,
the S-GC/KS will wait for a rekey action by the GC/KS. The immediacy of the
rekey action by the GC/KS is a management decision at the GC/KS. Security is
served best by quick expulsion of untrusted members.

Upon receipt of the de-registration notification from the S-GC/KS the
GC/KS will register the member to be expelled.  The GC/KS will then follow
group procedure for initiating a rekey action (outside the scope of this
protocol).  The GC/KS will communicate to the GO the expelled members
information (outside the scope of this protocol).  With this information,
the GO will create a new PT for the group with the expelled GM identity
added to the excluded list in the groups access control rules.  The GO
provides this new PT to the GC/KS for distribution with the Rekey Event
Message.

The GC/KS will send out a rekey operation with a new PT. The S- GC/KS will
receive the rekey and process it.  At the same time, all other S-GC/KSs
will receive the rekey and note the excluded GM identity.  All S-GC/KSs
will review local identities to ensure that the excluded GM is not a local
member.  If it is, then the S-GC/KS will create a rekey message.  The
S-GC/KSs must always create a rekey message, whether the expelled Group
Member is a member of their subtrees or not.

The S-GC/KS will then create a local rekey message.  The S-GC/KS will send
the wrapped Group TPK to all members of its local LKH tree, except the
excluded member(s).



5 Group Life Cycle


The management of a cryptographic group follows a life-cycle:  group
definition, group establishment, and security relevant group 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 member deletions, and
group destruction.  Each of these life-cycle phases is discussed in the
following sections.

The use and processing of the optional Vendor ID payload for all messages
can be found in Section 7.10.






Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 27]

INTERNET-DRAFT                       GSAKMP                       March 2005

5.1 Group Definition


A cryptographic group is established to support secure communications among
a group of individuals.  The activities necessary to create a Policy Token
in support of a cryptographic group include



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

 -  Determine Authorization Policy - identify which entities are authorized
    to perform security relevant actions, including key dissemination,
    policy creation, and initiation of security management actions.

 -  Determine Mechanisms - define the algorithms and protocols used by
    GSAKMP to secure the group.

 -  Create Group Policy Token - format the policies and mechanisms into a
    Policy Token and apply the GO signature.


5.2 Group Establishment


GSAKMP Group Establishment consists of three mandatory-to-implement
messages, the Request to Join, the Key Download, and the Key Download
Ack/Failure.  The exchange may also include two OPTIONAL error messages,
the Request to Join Error and the Lack_of_Ack messages.  Operation using
the mandatory messages only is referred to as "Terse Mode", while
inclusion of the error messaging is referred to as "Verbose Mode".  GSAKMP
implementations MUST support Terse Mode and MAY support Verbose Mode.  Group
Establishment is discussed in Section 5.2.1.

A group is set in Terse or Verbose mode by a policy token parameter.  All
(S-)GC/KSs in a Verbose mode group MUST support Verbose mode.  GSAKMP allows
Verbose mode groups to have GMs that do not support Verbose mode.  Candidate
GMs that do not support Verbose mode and receive a RTJ-Error or Lack-of-Ack
message must handle these messages gracefully.  Additionally, a GM will not
know a prior that it is interacting with the (S)-GC/KS in Verbose or Terse
mode until the Policy Token is received.

For Denial of Service protection, a Cookie Exchange MAY precede the Group
Establishment exchange.  The Cookie Exchange is described in Section 5.2.2.

Regardless of mode, any error message sent between component members
indicates the first error encountered while processing the message.





Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 28]

INTERNET-DRAFT                       GSAKMP                       March 2005

5.2.1 Standard Group Establishment


After the out-of-band receipt of a Policy Token, a potential Group
Controller Key Server (GC/KS) verifies the token and its eligibility to
perform GC/KS functionality.  It is then permitted to create any needed
group keys and begin to establish the group.

The GSAKMP Ladder Diagram, Figure 1, is presented to illustrate the
process of establishing a cryptographic group.  The left side of the
diagram represents the actions of the GC/KS. The right side of the diagram
represents the actions of the GMs.  The components of each message shown in
the diagram are presented in sections 5.2.1.1 -  5.2.1.5.

          CONTROLLER   Mandatory/     MESSAGE                  MEMBER
                       Optional
                    !<-M----------Request to Join-------------!
      <Process RTJ> !                                         !
                    !--M----------Key Download--------------->!
                    !                                         ! <Process KeyDL>
                    !--O-------Request to Join Error--------->! or
                    !                                         ! <Proc RTJ-Err>
                    !<-M----Key Download - Ack/Failure--------!
 <Process KeyDL-A/F>!                                         !
                    !--O------Lack of Acknowledgment--------->!
                    !                                         ! <Proc LOA>
                    !<=======SHARED KEYED GROUP SESSION======>!




                      Figure 1:  GSAKMP Ladder Diagram

The Request to Join message is sent from a potential GM to the GC/KS to
request admission to the cryptographic group.  The message contains key
creation material, freshness data, an optional selection of mechanisms, and
the signature of the GM.

The Key Download message is sent from the GC/KS to the GM in response
to an accepted Request to Join.  This GC/KS-signed message contains the
identifier of the GM, freshness data, key creation material, encrypted keys,
and the encrypted Policy Token.  The Policy Token is used to facilitate
well-ordered group creation and MUST include the group's identification,
group permissions, group join policy, group controller key server identity,
group management information, and digital signature of the GO. This will
allow the GM to determine whether group policy is compatible with local
policy.

The Request to Join Error message is sent from the GC/KS to the GM in
response to an unaccepted Request to Join.  This message is not signed
by the GC/KS for two reasons:  1) The GM, at this point, has no knowledge


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 29]

INTERNET-DRAFT                       GSAKMP                       March 2005

of who is authorized to act as a GC/KS and so the signature would thus be
meaningless to the GM, and 2) Signing responses to denied join requests
would provide a denial of service potential.  The message contains an
indication of the error condition.  The possible values for this error
condition are:  Invalid-Payload-Type, Invalid-Version, Invalid-Group-ID,
Invalid-Sequence-ID, Payload-Malformed, Invalid-ID-Information,
Invalid-Certificate, Cert-Type-Unsupported, Invalid-Cert-Authority,
Authentication-Failed, Certificate-Unavailable, Unauthorized-Request,
Prohibited-by-Group-Policy, and Prohibited-by-Locally-Configured-Policy.

The Key Download Ack/Failure message indicates Key Download receipt status
at the GM. It is a GM-signed message containing freshness data and status.

The Lack_of_Ack message is sent from the GC/KS to the GM in response to an
invalid or absent Key Download Ack/Failure message.  The signed message
contains freshness and status data and is used to warn the GM of impending
eviction from the group if a valid Key Download Ack/Failure is not sent.
Eviction means that the member will be excluded from the group after the
next Rekey Event.  The policy of when a particular group needs to rekey
itself is stated in the Policy Token.  Eviction is discussed further in
Section 5.3.2.1.

For the following message structure sections, details about payload format
and processing can be found in Section 7.  Each message is identified by its
exchange type in the header of the message.  Nonces MUST be present in the
messages unless synchronization time is available to the system.


5.2.1.1 Request to Join


The exchange type for Request to Join is eight (8).

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


             Table 1:  Request to Join (RTJ) Message Definition

    Message Name  : Request to Join (RTJ)
    Dissection    : {HDR-GrpID, Key Creation, Nonce_I, [VendorID],
                  : [Notif_Mechanism_Choices], [Notif_Cookie],
                  : [Notif_IPValue]} SigM, [Cert]
    Payload Types : GSAKMP Header, Key Creation, [Nonce], [Vendor
                    ID], Signature, [Certificate], [Notifications]

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

As shown by Figure 1, a potential GM MUST generate and send an RTJ message
to request permission to join the group.  At a minimum, the GM MUST be

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 30]

INTERNET-DRAFT                       GSAKMP                       March 2005

able to manually configure the destination for the RTJ. As defined in the
dissection of the RTJ message, this message MUST contain a Key Creation
payload for KEK determination.  A Nonce payload MUST be included for
freshness and the Nonce_I value MUST be saved for potential later use.
Only if the Policy Token for this group defines the use of nonces versus
synchronization time, will the GC/KS use this supplied nonce.  An OPTIONAL
Notification payload of type Mechanism Choices MAY be included to identify
the mechanisms the GM wants to use.  Absence of this payload will cause the
GC/KS to select appropriate default Policy Token specified mechanisms for
the Key Download.

In response, the GC/KS accepts or denies the request based on local
configuration.  <Process RTJ> indicates the GC/KS actions that will
determine if the RTJ will be acted upon.  The following checks SHOULD be
performed in the order presented.

In this procedure, the GC/KS MUST verify that the message header is properly
formed and confirm that this message is for this group by checking the value
of the GroupID. If the header checks pass, then the identity of the sender
is extracted from the Signature payload.  This identity MUST be used to
perform access control checks, find the GMs credentials (e.g.  certificate)
for message verification, and MUST also be used in the Key Download message.
Then the GC/KS will verify the signature on the message to ensure its
authenticity.  The GC/KS MUST use verified and trusted authentication
material from a known root.  If the message signature verifies, the GC/KS
then confirms that all required payloads are present and properly formatted
based upon the mechanisms announced and/or requested.  If all checks pass,
the GC/KS will create and send the Key Download message as described in
section  5.2.1.2.

If the GM receives no response to the RTJ within the GM's locally configured
timeout value, the GM SHOULD resend the RTJ message up to three (3) times.

NOTE: At any one time, a GC/KS MUST process no more that one (1) valid RTJ
message from a given GM per group until its pending registration protocol
exchange concludes.

If any error occurs during RTJ message processing, and the GC/KS is running
in Terse mode, the registration session MUST be terminated and all saved
state information MUST be cleared.

The OPTIONAL Notification payload of type Cookie is discussed in section
5.2.2.

The OPTIONAL Notification payload of type IPValue may be used for the GM to
convey a specific IP value to the GC/KS.







Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 31]

INTERNET-DRAFT                       GSAKMP                       March 2005

5.2.1.2 Key Download


The exchange type for Key Download is nine (9).

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


             Table 2:  Key Download (KeyDL) Message Definition

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

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

In response to a properly formed and verified RTJ message, the GC/KS creates
and sends the KeyDL message.  As defined in the dissection of the message,
this message MUST contain payloads to hold the following information:  GM
identification, Key Creation material, encrypted Policy Token, encrypted
key information, and signature information.  If synchronized time is not
available, the Nonce payloads MUST be included in the message for freshness.

If present, the nonce values transmitted MUST be the GC/KSs generated
Nonce_R value and the combined Nonce_C value which was generated by using the
GC/KSs Nonce_R value and the Nonce_I value received from the GM in the RTJ.

If two party key determination is used, the key creation material supplied
by the GM and/or the GC/KS will be used to generate the key.  Generation of
this key is dependant on the key exchange, as defined in Section 7.11, Key
Creation Payload.  The Policy Token and key material are encrypted in the
generated key.

The GM MUST be able to process the Key Download message.  <Process KeyDL>
indicates the GM actions that will determine how the Key Download message
will be acted upon.  The following checks SHOULD be performed in the order
presented.

In this procedure, the GM will verify that the message header is properly
formed and confirm that this message is for this group by checking the
value of the GroupID. If the header checks pass, the GM MUST confirm that
this message was intended for itself by comparing the Member ID in the
Identification payload to its identity.


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 32]

INTERNET-DRAFT                       GSAKMP                       March 2005

After identification confirmation, the freshness values are checked.  If
using Nonces, the GM MUST use its saved Nonce_I value, extract the received
GC/KS Nonce_R value, compute the combined Nonce_C value, and compare it to
the received Nonce_C value.  If not using Nonces, the GM MUST check the
timestamp in the Signature payload to determine if the message is new.

After freshness is confirmed, the signature MUST be verified to ensure its
authenticity, The GM MUST use verified and trusted authentication material
from a known root.  If the message signature verifies, the key creation
material is extracted from the Key Creation payload to generate the KEK.
This KEK is then used to decrypt the Policy Token data.  The signature on
the policy token MUST be verified.  Access control checks MUST be performed
on both the GO and the GC/KS to determine both their authorities within this
group.  After all these checks pass, the KEK can then be used to decrypt
and process the key material from the Key Download payload.  If all is
successful, the GM will create and send the Key Download - Ack/Failure
message as described in section 5.2.1.4.

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

If any error occurs during KeyDL message processing, regardless of whether
the GM is in Terse or Verbose mode, the registration session MUST be
terminated, the GM MUST send a Key Download - Ack/Failure message, nd all
saved state information MUST be cleared.  If in Terse mode, the Notification
Payload will be of type NACK to indicate termination.  If in Verbose mode,
the Notification Payload will contain the type of error encountered.


5.2.1.3 Request to Join Error


The exchange type for Request to Join Error is eleven (11).

The components of the Request to Join Error Message are shown in Table 3:


        Table 3:  Request to Join Error (RTJ-Err) Message Definition

    Message Name  : Request to Join Error (RTJ-Err)
    Dissection    : {HDR-GrpID, [Nonce_I], Notification, [VendorID]}
    Payload Types : GSAKMP Header, [Nonce] Notification, [Vendor ID]


In response to an unacceptable RTJ, the GC/KS MAY send a Request to Join
Error (RTJ-Err) message containing an appropriate Notification payload.
Note that the RTJ-Err message is not a signed message for the following
reasons:  the lack of awareness on the GM's perspective of who is a valid
GC/KS as well as the need to protect the GC/KS from signing messages and

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 33]

INTERNET-DRAFT                       GSAKMP                       March 2005

using valuable resources.  Following the sending of an RTJ-Err, the GC/KS
MUST terminated the session and all saved state information MUST be cleared.

Upon receipt of an RTJ-Err message, the GM will validate the following:
the GroupID in the header belongs to a group to which the GM has sent
an RTJ, and, if present, the Nonce_I matches a Nonce_I sent in an RTJ to
that group.  If the above checks are successful, the GM MAY terminate the
state associated with that GroupID and Nonce.  The GM SHOULD be capable
of receiving a valid KeyDownload message for that GroupID and Nonce after
receiving an RTJ-Err for a locally-configured amount of time.


5.2.1.4 Key Download - Ack/Failure


The exchange type for Key Download - Ack/Failure is four (4).

The components of the Key Download - Ack/Failure Message are shown in
Table 4:


    Table 4:  Key Download - Ack/Failure (KeyDL-A/F) Message Definition

    Message Name  : Key Download - Ack/Failure (KeyDL-A/F)
    Dissection    : {HDR-GrpID, [Nonce_C], Notif_Ack, [VendorID]}SigM
    Payload Types : GSAKMP Header, [Nonce], Notification, [Vendor
                    ID], Signature
       SigM       : Signature of Group Member
       {}SigX      :Indicates fields used in Signature


In response to a properly processed KeyDL message, the GM creates and
sends the KeyDL-A/F message.  As defined in the dissection of the message,
this message MUST contain payloads to hold the following information:
Notification payload of type Acknowledgment (ACK) and signature information.
If synchronized time is not available, the Nonce payload MUST be present
for freshness, and the nonce value transmitted MUST be the GMs generated
Nonce_C value.  If the GM does not receive a KeyDL message within a locally
configured amount of time, the GM MAY send a new RTJ. If the GM receives a
valid LOA (see section 5.2.1.5) message from the GC/KS before receipt of a
KeyDL message, the GM SHOULD send a KeyDL-A/F message of type NACK followed
by a new RTJ.

The GC/KS MUST be able to process the KeyDL-A/F message.  <Process
KeyDL-A/F> indicates the GC/KS actions that will determine how the
KeyDL-A/F message will be acted upon.  The following checks SHOULD be
performed in the order presented.

In this procedure, the GC/KS will verify that the message header is properly
formed and confirm that this message is for this group by checking the value
of the GroupID. If the header checks pass, the GC/KS MUST check the message
for freshness.  If using Nonces, the GC/KS MUST use its saved Nonce_C value,

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 34]

INTERNET-DRAFT                       GSAKMP                       March 2005

and compare it to the received Nonce_C value.  If not using Nonces, the
GC/KS MUST check the timestamp in the Signature payload to determine if
the message is new.  After freshness is confirmed, the signature MUST
be verified to ensure its authenticity, The GC/KS MUST use verified and
trusted authentication material from a known root.  If the message signature
verifies, the GC/KS processes the Notification payload.  If the notification
type is of type ACK, then the registration has completed successfully and
both parties SHOULD remove state information associated with this GM's
registration.

If the GC/KS does not receive a KeyDL-A/F message of proper form, is unable
to correctly process the KeyDL-A/F message, the Notification payload type
is any value except ACK, or if no KeyDL-A/F message is received within the
locally configured timeout, the GC/KS MUST evict this GM from the group
in the next policy-defined Rekey Event.  The GC/KS MAY send the OPTIONAL
Lack_of_Ack message if running in Verbose Mode as defined in section 5.2.1.5.


5.2.1.5 Lack of Ack


The exchange type for Lack of Ack is twelve (12).

The components of a Lack of Ack Message are shown in Table 5:


               Table 5:  Lack of Ack (LOA) Message Definition

    Message Name  : Lack of Ack (LOA)
    Dissection    : {HDR-GrpID, Member ID, [Nonce_R, Nonce_C],
                    Notification, [VendorID]} SigC, [Cert]
    Payload Types : GSAKMP Header, Identification, [Nonce],
                    Notification, [Vendor ID], Signature,
                    [Certificate]

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

If the GC/KSs local timeout value expires prior to receiving a KeyDL-A/F
from the GM, the GC/KS MAY create and send a LOA message to the GM. As
defined in the dissection of the message, this message MUST contain payloads
to hold the following information:  GM identification, Notification of
error, and signature information.

If synchronized time is not available, the Nonce payloads MUST be present
for freshness, and the nonce values transmitted MUST be the GC/KSs generated
Nonce_R value and the combined Nonce_C value which was generated by using the
GC/KSs Nonce_R value and the Nonce_I value received from the GM in the RTJ.
These values were already generated during the Key Download message phase.


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 35]

INTERNET-DRAFT                       GSAKMP                       March 2005

The GM MAY be able to process the LOA message based upon local
configuration.  <Process LOA> indicates the GM actions that will determine
how the LOA message will be acted upon.  The following checks SHOULD be
performed in the order presented.

In this procedure, the GM MUST verify that the message header is properly
formed and confirm that this message is for this group by checking the
value of the GroupID. If the header checks pass, the GM MUST confirm that
this message was intended for itself by comparing the Member ID in the
Identification payload to its identity.  After identification confirmation,
the freshness values are checked.  If using Nonces, the GM MUST use its
save Nonce_I value, extract the received GC/KS Nonce_R value, compute the
combined Nonce_C value, and compare it to the received Nonce_C value.
If not using Nonces, the GM MUST check the timestamp in the Signature
payload to determine if the message is new.  After freshness is confirmed,
access control checks MUST be performed on the GC/KS to determine its
authority within this group.  Then signature MUST be verified to ensure its
authenticity, The GM MUST use verified and trusted authentication material
from a known root.

If the checks succeed, the GM SHOULD resend a KeyDL-A/F for that session.


5.2.2 Cookies - Group Establishment with Denial of Service Protection


This section defines an OPTIONAL capability that MAY be implemented into
GSAKMP when using IP based groups.  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 define the purpose of
Cookies.

An optional Cookie mode is being defined for the GSAKMP to 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
header includes two eight octet fields titled "cookies".  Instead of
placing this cookie data in the header, in GSAKMP this data is moved into
a Notification payload.

An expected attack against GSAKMP is state and CPU exhaustion, where the
target GC/KS is flooded with Request to Join requests from forged IP
addresses.  This attack can be made less effective if a GC/KS implementation
uses minimal CPU and commits no state to the communication until it knows
the initiator potential GM can receive packets at the address from which
it claims to be sending them.  To accomplish this, the GC/KS when operating
in Cookie mode, SHOULD reject initial Request to Join messages unless they
contain a Notification payload of type "cookie".  It SHOULD instead send
a Cookie Download message as a response to the RTJ and include a cookie in


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 36]

INTERNET-DRAFT                       GSAKMP                       March 2005

a notify payload of type Cookie_Required.  Potential GMs who receive such
responses MUST retry the Request to Join message with the responder GC/KS
supplied cookie in its notification payload of type Cookie, as defined by
the optional Notification payload of the Request to Join Msg as defined in
section 5.2.1.1.  This initial exchange will then be as shown in Figure 2
with the components of the new message Cookie Download shown in Table 6.
The exchange type for Cookie Download is ten (10).

          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 KeyDL>
                    !<-----Key Download -  Ack/Failure--------!
  <Proc KeyDL-A/F>  !                                         !
                    !<=======SHARED KEYED GROUP SESSION======>!




               Figure 2:  GSAKMP Ladder Diagram with Cookies


                Table 6:  Cookie Download Message Definition

    Message Name  : Cookie Download
    Dissection    : {HDR-GrpID, Notif_COOKIE_REQUIRED, [VendorID]}
    Payload Types : GSAKMP Header, Notification, [Vendor ID]

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

A GSAKMP implementation SHOULD implement its GC/KS cookie generation in such
a way as to not require any saved state to recognize its valid cookie when
the second Request to Join message arrives.  The exact algorithms and syntax
they use to generate cookies does not affect interoperability and hence is
not specified here.

The following is an example of how an endpoint could use cookies to
implement limited DoS protection.

A good way to do this is to set the cookie to be:

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

where <secret> is a randomly generated secret known only to the responder


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 37]

INTERNET-DRAFT                       GSAKMP                       March 2005

GC/KS and periodically changed, Ni is the Nonce value taken from the
initiator potential GM, IPi is the asserted IP address of the candidate GM.
The IP address is either the IP header's source IP address, or else if it is
present then the IP address contained in the optional Notification "IPvalue"
payload.  <SecretVersionNumber> should be changed whenever <secret> is
regenerated.  The cookie can be recomputed when the "Request to Join with
Cookie Info" arrives and compared to the cookie in the received message.  If
it matches, the responder GC/KS knows that all values have been computed
since the last change to <secret> and that IPi MUST be the same as the
source address it saw the first time.  Incorporating Ni into the hash
assures that an attacker who sees only the Cookie_Download message cannot
successfully forge a "Request to Join with Cookie Info" message.  This Ni
value MUST be the same Ni value from the original "Request to Join" message
for the calculation to be successful.

If a new value for <secret> is chosen while there are connections in the
process of being initialized, a "Request to Join with Cookie Info" might be
returned with other than the current <SecretVersionNumber>.  The responder
GC/KS in that case MAY reject the message by sending another response with a
new cookie or it MAY keep the old value of <secret> around for a short time
and accept cookies computed from either one.  The responder GC/KS SHOULD
NOT accept cookies indefinitely after <secret> is changed, since that would
defeat part of the denial of service protection.  The responder GC/KS SHOULD
change the value of <secret> frequently, especially if under attack.

An alternative example for Cookie value generation in a NAT environment is
to substitute the IPi value with the IPValue received in the Notification
payload in the RTJ message.  This scenario is indicated by the presence of
the Notification payload of type IPValue.  With this substitution, a similar
calculation as described above can be used.


5.2.3 Group Establishment for Receive-Only Members


This section describes an OPTIONAL capability that may be implemented in a
structured system where the authorized (S-)GC/KS is known in advance through
out-of-band means and where synchronized time is available.

Unlike Standard Group Establishment, in the Receive-Only system, the GMs
and (S-)GC/KSs operate in terse mode and exchange one message only:  the
Key Download.  Potential new GMs do not send an RTJ. (S)-GC/KSs do not
expect Key Download - ACK/Failure messages and do not remove GMs for lack
or receipt of the message.

Operation is as follows:  upon notification via an authorized out-of-band
event, the (S)-GC/KS forms and sends a Key Download message to the new
member with the Nonce payloads ABSENT. The GM verifies



 -  the ID payload identifies that GM

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 38]

INTERNET-DRAFT                       GSAKMP                       March 2005

 -  the timestamp in the message is fresh

 -  the message is signed by an authorized (S)-GC/KS

 -  the signature on the message verifies



When using a Diffie-Hellman Key Creation Type for receive-only members, a
static-ephemeral model is assumed:  the Key Creation payload in the Key
Download message contains the (S-)GC/KS's public component.  The member's
public component is assumed to be obtained through secure out-of-band means.


5.3 Group Maintenance


The Group Maintenance phase includes member joins and leaves, group rekey
activities, policy updates, and group destruction.  These activities are
presented in the following sections.


5.3.1 Group Management


5.3.1.1 Rekey Events


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

Once an event has been identified (as defined in the group security policy
token), the GC/KS MUST create and provide a signed message containing the
GTPK and Rekey information to the group.

Each GM who receives this message MUST verify the signature on the message
to ensure its authenticity.  If the message signature does not verify,
the message MUST be discarded.  Upon verification the GM will find the
appropriate Rekey download packet and decrypt the information with a stored
Rekey key(s).  If a new Policy Token is distributed with the message, it
MUST be encrypted in the old GTPK.

The exchange type for Rekey Event is five (5).

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


5.3.1.2 Policy Updates


New policy tokens are sent via the Rekey Event message.  These policy
updates may be coupled with an existing rekey event or may be sent in a

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 39]

INTERNET-DRAFT                       GSAKMP                       March 2005


                  Table 7:  Rekey Event Message Definition

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

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

message with the Rekey Event Type of the Rekey Event Payload set to None(0)
(see section 7.5.1.

A policy token MUST NOT be processed if the processing of the Rekey Event
message carrying it fails.  Policy token processing is type dependent and is
beyond the scope of this document.


5.3.1.3 Group Destruction


Group destruction is also accomplished via the Rekey Event message.  In
a Rekey Event message for group destruction, the Sequence ID is set to
0xFFFFFFFF. Upon receipt of this authenticated Rekey Event message, group
components MUST terminate processing of information associated with the
indicated group.


5.3.2 Leaving a Group


There are several conditions under which a member will leave a group:
eviction, voluntary departure without notice, and voluntary departure with
notice -- or De-Registration.  Each of these is discussed in this section.


5.3.2.1 Eviction


At some point in the group's lifetime, it may be desirable to evict one or
more members from a group.  From a key management viewpoint, this involves
revoking access to the group's protected data by "disabling" the departing
members' keys.  This is accomplished with a Rekey Event, which is discussed
in more detail in section 5.3.1.1.  If future access to the group is also
to be denied, the members MUST be added to a denied access control list, and
the policy token's authorization rules MUST be appropriately updated so that


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 40]

INTERNET-DRAFT                       GSAKMP                       March 2005

they will exclude the expelled GM(s).  After receipt of a new PT, GMs SHOULD
evaluate the trustworthiness of any recent application data originating from
the expelled GM(s).


5.3.2.2 Voluntary Departure without Notice


If a member wishes to leave a group for which membership imposes no cost
or responsibility to that member, then the member MAY merely delete local
copies of group keys and cease group activities.


5.3.2.3 De-Registration


If the membership in the group does impose cost or responsibility to the
departing member, then the member SHOULD de-register from the group when
that member wishes to leave.  De-Registration consists of a three-message
exchange between the GM and the member's GC/KS: the Request_to_Depart,
Departure_Response, and the Departure_Ack.  Compliant GSAKMP implementations
for GMs SHOULD support the De-Registration messages.  Compliant GSAKMP
implementations for GC/KSs MUST support the De-Registration messages.


5.3.2.3.1 Request to Depart - The Exchange Type for a Request_to_Depart
Message is thirteen (13).  The components of a Request_to_Depart Message are
shown in Table 8.


            Table 8:  Request_to_Depart (RTD) Message Definition

    Message Name  : Request_to_Depart (RTD)
    Dissection    : {HDR-GrpID, GC/KS_ID, [Nonce_I], Notif_Leave_Group,
                    [VendorID]} SigM, [Cert]
    Payload Types : GSAKMP Header, Identification, [Nonce],
                    Notification, [Vendor ID], Signature,
                    [Certificate]
       SigM       : Signature of Group Member
       Cert       : Necessary Certificates, zero or more
       {}SigX      :Indicates fields used in Signature
       []         : Indicate an optional data item


Any GM desiring to initiate the De-Registration process MUST generate and
send an RTD message to notify the GC/KS of its intent.  As defined in the
dissection of the RTD message, this message MUST contain payloads to hold
the following information:  the GC/KS identification and Notification of the
desire to leave the group.  When synchronization time is not available to
the system as defined by the Policy Token, a Nonce payload MUST be included
for freshness, and the Nonce_I value MUST be saved for later use.  This
message MUST then by signed by the GM.

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 41]

INTERNET-DRAFT                       GSAKMP                       March 2005

Upon receipt of the RTD message, the GC/KS MUST verify that the message
header is properly formed and confirm that this message is for this group
by checking the value of the GroupID. If the header checks pass, then
the identifier value in Identification payload is compared to its own,
the GC/KSs identity, to confirm that the GM intended to converse with
this GC/KS, the GC/KS who registered this member into the group.  Then
the identity of the sender is extracted from the Signature payload.  This
identity MUST be used to confirm that this GM is a member of the group
serviced by this GC/KS. Then the GC/KS will confirm from the Notification
payload that the GM is requesting to leave the group.  Then the GC/KS will
verify the signature on the message to ensure its authenticity.  The GC/KS
MUST use verified and trusted authentication material from a known root.  If
all checks pass and the message is successfully processed, then the GC/KS
MUST form a Departure_Response message as defined in section 5.3.2.3.2.

If the processing of the message fails the de-registration session MUST
be terminated and all state associated with this session is removed.
If the GC/KS is operating in Terse Mode, then no error message is sent
to the GM. If the GC/KS is operating in Verbose Mode, then the GC/KS
sends a Departure_Response Message with a Notification Payload of type
Request_to_Depart_Error.


5.3.2.3.2 Departure_Response - The Exchange Type for a Departure_Response
Message is fourteen (14).  The components of a Departure_Response Message
are shown in Table 9.


            Table 9:  Departure_Response (DR) Message Definition

    Message Name  : Departure_Response (DR)
    Dissection    : {HDR-GrpID, Member_ID, [Nonce_R, Nonce_C],
                    Notification, [VendorID]} SigC, [Cert]
    Payload Types : GSAKMP Header, Identification, [Nonce],
                    Notification, [Vendor ID], Signature,
                    [Certificate]
       SigC       : Signature of Group Member
       Cert       : Necessary Certificates, zero or more
       {}SigX      :Indicates fields used in Signature
       []         : Indicate an optional data item


In response to a properly formed and verified RTD message, the GC/KS
MUST create and send the DR message.  As defined in the dissection of
the message, this message MUST contain payloads to hold the following
information:  GM identification, Notification for acceptance of departure,
and signature information.  If synchronization time is not available, the
Nonce payloads MUST be included in the message for freshness.

If present, the nonce values transmitted MUST be the GC/KSs generated
Nonce_R value and the combined Nonce_C value which was generated by using the
GC/KSs Nonce_R value and the Nonce_I value received from the GM in the RTD.

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 42]

INTERNET-DRAFT                       GSAKMP                       March 2005

This Nonce_C value MUST be saved relative to this departing GMs ID.

The GM MUST be able to process the Departure_Response message.  The
following checks SHOULD be performed in the order presented.

The GM MUST verify that the message header is properly formed and confirm
that this message is for this group by checking the value of the GroupID. If
the header checks pass, the GM MUST confirm that this message was intended
for itself by comparing the Member ID in the Identification payload to
its identity.  After identification confirmation, the freshness values are
checked.  If using Nonces, the GM MUST use its saved Nonce_I value, extract
the received GC/KS Nonce_R value, compute the combined Nonce_C value, and
compare it to the received Nonce_C value.  If not using Nonces, the GM MUST
check the timestamp in the signature payload to determine if the message
is new.  After freshness is confirmed, confirmation of the identity of the
signer of the DR message is the GMs authorized GC/KS is performed.  Then
the signature MUST be verified to ensure its authenticity, The GM MUST use
verified and trusted authentication material from a known root.  If the
message signature verifies, then the GM MUST verify that the Notification
is of Type Departure_Accepted or Request_to_Depart_Error.

If the processing is successful, and the Notification payload is of type
Departure_Accepted, the member MUST form the Departure_ACK message as defined
in section 5.3.2.3.3.  If the processing is successful, and the Notification
payload is of type Request_to_Depart_Error, the member MUST remove all state
associated with the de-registration session.  If the member still desires
to De-Register from the group, the member MUST restart the De-Registration
process.

If the processing of the message fails the de-registration session MUST be
terminated and all state associated with this session is removed.  If the GM
is operating in Terse Mode, then a Departure_Ack Message with Notification
Payload of type NACK is sent to the GC/KS. If the GM is operating in Verbose
Mode, then the GM sends a Departure_Ack Message with a Notification Payload
of the appropriate failure type.


5.3.2.3.3 Departure_ACK - The Exchange Type for a Departure_ACK Message is
fifteen (15).  The components of the Departure_ACK Message are shown in
Table 10:


              Table 10:  Departure_ACK (DA) Message Definition

    Message Name  : Departure_ACK (DA)
    Dissection    : {HDR-GrpID, [Nonce_C], Notif_Ack, [VendorID]}SigM
    Payload Types : GSAKMP Header, [Nonce], Notification, [Vendor
                    ID], Signature
       SigM       : Signature of Group Member
       {}SigX      :Indicates fields used in Signature



Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 43]

INTERNET-DRAFT                       GSAKMP                       March 2005

In response to a properly processed Departure_Response message, the GM MUST
create and send the Departure_ACK message.  As defined in the dissection
of the message, this message MUST contain payloads to hold the following
information:  Notification payload of type Acknowledgment (ACK) and
signature information.  If synchronization time is not available, the Nonce
payload MUST be present for freshness, and the nonce value transmitted MUST
be the GMs generated Nonce_C value.

Upon receipt of the Departure_ACK, the GC/KS MUST perform the following
checks.  These checks SHOULD be performed in the order presented.

In this procedure, the GC/KS MUST verify that the message header is properly
formed and confirm that this message is for this group by checking the value
of the GroupID. If the header checks pass, the GC/KS MUST check the message
for freshness.  If using Nonces, the GC/KS MUST use its saved Nonce_C value,
and compare it to the received Nonce_C value.  If not using Nonces, the
GC/KS MUST check the timestamp in the signature payload to determine if
the message is new.  After freshness is confirmed, the signature MUST
be verified to ensure its authenticity, The GC/KS MUST use verified and
trusted authentication material from a known root.  If the message signature
verifies, the GC/KS processes the Notification payload.  If the notification
type is of type ACK, this is considered a successful processing of this
message.

If the processing of the message is successful, the GC/KS MUST remove the
member from the group.  This MAY involve initiating a Rekey Event for the
group.

If the processing of the message fails or if no Departure_Ack is received,
the GC/KS MAY issue a LOA message.



6 Security Suite


The Security Definition Suite 1 MUST be supported.  Other security suite
definitions MAY be defined in other Internet specifications.


6.1 Assumptions


All potential GMs will have enough information available to them to use the
correct Security Suite to join the group.  This can be accomplished by a
well known default suite 'Security Suite 1' or by announcing/posting another
suite.






Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 44]

INTERNET-DRAFT                       GSAKMP                       March 2005

6.2 Definition Suite 1


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

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

The GSAKMP Suite 1 definition is



Key download and Policy Token encryption algorithm definition:
Algorithm:  AES
Mode:       CBC
Key Length: 192 bits

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

Nonce Hash algorithm is:
  SHA-1

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

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


The digital signature algorithm is:
DSS-SHA1-ASN1-DER
The digital signature ID type is:
ID-DN-STRING




Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 45]

INTERNET-DRAFT                       GSAKMP                       March 2005

7 GSAKMP Payload Structure


A GSAKMP Message is composed of a GSAKMP Header (Section  7.1) followed
by at least one GSAKMP Payload.  All GSAKMP Payloads are composed of the
Generic Payload Header (Section  7.2) followed by the specific payload data.
The message is chained by a preceeding payload defining its succeeding
payload.  Payloads are not required to be in the exact order shown in the
message dissection in Sections 5 provided that all required payloads are
present.  Unless it is explicitly stated in a dissection that multiple
payloads of a single type may be present, no more than one payload of each
type allowed by the message may appear.  The final payload in a message will
point to no succeeding payload.

All fields of type integer in the Header and Payload structure that are
larger than one octet, MUST be converted into Network Byte Order prior to
data transmission.

Padding of fields MUST NOT be done as this leads to processing errors.

When a message contains a Vendor ID payload, the processing of the payloads
of that message are modified as defined in Section 7.10.



7.1 GSAKMP Header


7.1.1 GSAKMP Header Structure


The GSAKMP Header fields are shown in Figure 3 and defined as:
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! GroupID Type  ! GroupID Length!      Group ID Value           ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~               ! Next Payload  !   Version     ! Exchange Type !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Sequence ID                                                   !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Length                                                        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                      Figure 3:  GSAKMP Header Format




Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 46]

INTERNET-DRAFT                       GSAKMP                       March 2005

Group Identification Type (1 octet)  - Table 11 presents the group
    identification types.  This field is treated as an unsigned value.


                   Table 11:  Group Identification Types


Grp ID Type          Value       Description
_______________________________________________________________________________

Reserved               0
UTF-8                  1         This format is defined in Section 7.1.1.1.1.
Octet String           2         This type MUST be implemented.
                                 This format is defined in Section 7.1.1.1.2.
IPv4                   3         This format is defined in Section 7.1.1.1.3.
IPv6                   4         This format is defined in Section 7.1.1.1.4.
Reserved to IANA    5 - 192
Private Use        193 - 255

Group Identification Length (1 octet)  - Length of the Group ID field in
    octets.  This value MUST NOT be zero (0).  This field is treated as an
    unsigned value.

Group Identification Value (variable length)  - Indicates the name/title
    of the group.  All GroupID types should provide unique naming across
    groups.  GroupID types SHOULD provide this capability by including a
    random element generated by the creator (owner) of the group of at least
    eight (8) octets, providing extremely low probability of collision in
    group names.  The GroupID value is static throughout the life of the
    group.

Next Payload (1 octet)  - Indicates the type of the next payload in the
    message.  The format for each payload is defined in the following
    sections.  Table 12 presents the payload types.  This field is treated
    as an unsigned value.

Version (1 octet)  - Indicates the version of the GSAKMP protocol in use.
    The current value is one (1).  This field is treated as an unsigned
    value.

Exchange Type (1 octet)  - Indicates the type of exchange (also known as
    the message type).  Table 13 presents the exchange type values.  This
    field is treated as an unsigned value.

Sequence ID (4 octets)  - The Sequence ID is used for replay protection of
    group management messages.  If the message is not a group management
    message, this value MUST be set to zero (0).  The first value used by a
    (S-)GC/KS MUST be one (1).  For each distinct group management message
    that this (S-)GC/KS transmits, this value MUST be incremented by one
    (1).  Receivers of this group management message MUST confirm that the
    value received is greater that the value of the sequence ID received


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 47]

INTERNET-DRAFT                       GSAKMP                       March 2005


                          Table 12:  Payload Types


                     Next_Payload_Type        Value
                    ___________________________________

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


    with the last group management message from this (S-)GC/KS. Group
    Components (e.g., GMs, S-GC/KSs) MUST terminate processing upon receipt
    of an authenticated group management message containing a Sequence ID of
    0xFFFFFFFF. This field is treated as an unsigned integer in network byte
    order.

Length (4 octets)  - Length of total message (header + payloads) in octets.
    This field is treated as an unsigned integer in network byte order.





















Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 48]

INTERNET-DRAFT                       GSAKMP                       March 2005

















                         Table 13:  Exchange Types


                  Exchange_Type                 Value

                 ________________________________________
                  Reserved                      0 - 3
                  Key Download Ack/Failure        4
                  Rekey Event                     5
                  Reserved                      6 - 7
                  Request to Join                 8
                  Key Download                    9
                  Cookie Download                 10
                  Request to Join Error           11
                  Lack of Ack                     12
                  Request to Depart               13
                  Departure Response              14
                  Departure Ack                   15
                  Reserved to IANA             16 - 192
                  Private Use                193 -- 255

















Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 49]

INTERNET-DRAFT                       GSAKMP                       March 2005

7.1.1.1 GroupID Structure


This section defines the formats for the defined GroupID types.


7.1.1.1.1 UTF-8 - The format for type UTF-8 [RFC 3629] is shown in Figure 4.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Random Value                                                  ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! UTF-8 String                                                  ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                      Figure 4:  GroupID UTF-8 Format


Random Value (16 octets)  - For the UTF-8 GroupID type, the Random Value is
    represented as a string of exactly 16 hexadecimal digits converted from
    its octet values in network-byte order.  The leading zero hexadecimal
    digits and the trailing zero hexadecimal digits are always included in
    the string, rather than being truncated.

UTF-8 String (variable length)  - This field contains the human readable
    portion of the GroupID in UTF-8 format.  Its length is calculated as the
    (GroupID Length - 16) for the Random Value field.  The minimum length
    for this field is one (1) octet.



7.1.1.1.2 Octet String


The format for type Octet String is shown in Figure 5.


Random Value (8 octets)  - The 8 octet unsigned random value in network
    byte order format.

Octet String (variable length)  - This field contains the Octet String
    portion of the GroupID. Its length is calculated as the (GroupID Length
    - 8) for the Random Value field.  The minimum length for this field is

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 50]

INTERNET-DRAFT                       GSAKMP                       March 2005

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Random Value                                                  ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Octet String                                                  ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                   Figure 5:  GroupID Octet String Format


    one (1) octet.


7.1.1.1.3 IPv4 Group Identifier


The format for type IPv4 Group Identifier is shown in Figure 6.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Random Value                                                  ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! IPv4 Value                                                    !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                       Figure 6:  GroupID IPv4 Format


Random Value (8 octets)  - The 8 octet unsigned random value in network
    byte order format.

IPv4 Value (4 octets)  - The IPv4 value in network byte order format.  This
    value MAY contain the multicast address of the group.


7.1.1.1.4 IPv6 Group Identifier


The format for type IPv6 Group Identifier is shown in Figure 7.


Random Value (8 octets)  - The 8 octet unsigned random value in network

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 51]

INTERNET-DRAFT                       GSAKMP                       March 2005

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Random Value                                                  ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! IPv6 Value                                                    ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                       Figure 7:  GroupID IPv6 Format


    byte order format.

IPv6 Value (16 octets)  - The IPv6 value in network byte order format.
    This value MAY contain the multicast address of the group.


7.1.2 GSAKMP Header Processing


When processing the GSAKMP Header, the following fields MUST be checked for
correct values:


1.  Group ID Type - The Group ID Type value MUST be checked to be a valid
    group identification payload type as defined by Table 11.  If the
    value is not valid, then an error is logged and if in Verbose mode an
    appropriate message containing notification value Payload-Malformed will
    be sent.

2.  GroupID - The GroupID of the received message MUST be checked against
    the valid GroupIDs of the Group Component.  If no match is found,
    then an error is logged and if in Verbose mode an appropriate message
    containing notification value Invalid-Group-ID will be sent.

3.  Next Payload - The Next Payload value MUST be checked to be a valid
    payload type as defined by Table 12.  If the value is not valid, then an
    error is logged and if in Verbose mode an appropriate message containing
    notification value Invalid-Payload-Type will be sent.

4.  Version - The GSAKMP version number MUST be checked that its value


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 52]

INTERNET-DRAFT                       GSAKMP                       March 2005

    is one (1).  For other values, see below for processing.  The GSAKMP
    version number MUST be checked that it is consistent with the group's
    policy as specified in its Policy Token.  If the version is not
    supported or authorized, then an error is logged and if in Verbose mode
    an appropriate message containing notification value Invalid-Version
    will be sent.

5.  Exchange Type - The Exchange Type MUST be checked to be a valid exchange
    type as defined by Table 13 and MUST be of the type expected to be
    received by the GSAKMP state machine.  If the exchange type is not
    valid, then an error is logged and if in Verbose mode an appropriate
    message containing notification value Invalid-Exchange-Type will be
    sent.

6.  Sequence ID - The Sequence ID value MUST be checked for correctness.
    For negotiation messages this value MUST be zero (0).  For group
    management messages, this value MUST be greater than the last sequence
    ID received from this (S-)GC/KS. Receipt of incorrect Sequence ID
    on group management messages MUST NOT cause a reply message to be
    generated.  Receipt of incorrect Sequence ID on non-group management
    messages, then an error is logged and if in Verbose mode an appropriate
    message containing notification value Invalid-Sequence-ID to be sent.



The length fields in the GSAKMP Header (Group ID Length and Length) are used
to help process the message.  If any field is found to be incorrect, then
an error is logged and if in Verbose mode an appropriate message containing
notification value Payload-Malformed will be sent.

In order to allow a GSAKMP version one (1) (v1) implementation to
interoperate with future versions of the protocol, some ideas will be
discussed here to this affect.

A (S)-GC/KS that is operating in a multi-versioned group as defined by the
Policy Token can take many approaches on how to interact with the GMs in
this group for a Rekey Message.

One possible solution is for the (S)-GC/KS to send out multiple Rekey
Messages, one per version level that it supports.  Then each GM would only
process the message that has the version at which it is operating.

An alternative approach which all GM v1 implementations MUST support is the
embedding of a v1 message inside a version two (2) (v2) message.  If a GM
running at v1 receives a GSAKMP message that has a version value greater
than one (1), the GM will attempt to process the information immediately
after the Group Header as a Group Header for v1 of the protocol.  If this
is in fact a v1 Group Header, then the remainder of this v1 message will be
processed in place.  After processing this v1 embedded message, the data
following the v1 message should be the payload as identified by the Next
Payload field in the original header of the message and will be ignored
by the v1 member.  However, if the payload following the initial header is

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 53]

INTERNET-DRAFT                       GSAKMP                       March 2005

not a v1 Group Header, then the GM will gracefully handle the unrecognized
message.



7.2 Generic Payload Header


7.2.1 Generic Payload Header Structure


Each GSAKMP payload defined in the following sections begins with a generic
header, shown in Figure 8, 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 8:  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 12 identifies the payload types.  This
    field is treated as an unsigned value.

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

Payload Length (2 octets)  - Length in octets of the current payload,
    including the generic payload header.  This field is treated as an
    unsigned integer in network byte order format.


7.2.2 Generic Payload Header Processing


When processing the Generic Payload Header, the following fields MUST be
checked for correct values:


1.  Next Payload - The Next Payload value MUST be checked to be a valid
    payload type as defined by Table 12.  If the payload type is not valid,
    then an error is logged and if in Verbose mode an appropriate message
    containing notification value Invalid-Payload-Type will be sent.


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 54]

INTERNET-DRAFT                       GSAKMP                       March 2005

2.  RESERVED - This field MUST contain the value zero (0).  If the value
    of this field is not zero (0), then an error is logged and if in
    Verbose mode an appropriate message containing notification value
    Payload-Malformed will be sent.



The length field in the Generic Payload Header is used to process the
remainder of the payload.  If this field is found to be incorrect, then an
error is logged and if in Verbose mode an appropriate message containing
notification value Payload-Malformed will be sent.


7.3 Policy Token Payload


7.3.1 Policy Token Payload Structure


The Policy Token Payload contains authenticatable group specific information
that describes the group security relevant behaviors, access control
parameters, and security mechanisms.  Figure 9 shows the format of the
payload.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Next Payload  !   RESERVED    !         Payload Length        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Policy Token Type             ! Policy Token Data             ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                   Figure 9:  Policy Token Payload Format

The Policy Token Payload fields are defined as follows:


Next Payload (1 octet)  - Identifier for the payload type of the next
    payload in the message.  If the current payload is the last in
    the message, then this field will be 0.  This field provides the
    ``chaining`` capability.  Table 12 identifies the payload types.  This
    field is treated as an unsigned value.

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

Payload Length (2 octets)  - Length in octets of the current payload,
    including the generic payload header.  This field is treated as an
    unsigned integer in network byte order format.

Policy Token Type (2 octets)  - Specifies the type of Policy Token being

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 55]

INTERNET-DRAFT                       GSAKMP                       March 2005

    used.  Table 14 identifies the types of policy tokens.  This field is
    treated as an unsigned integer in network byte order format.


                       Table 14:  Policy Token Types

Policy_Token_Type       Value        Definition
_____________________________________________________________________________

Reserved                  0
GSAKMP_ASN.1_PT_V1        1          All implementations of GSAKMP
                                     MUST support this Policy Token format.
                                     This format is specified in [CH02].
Reserved to IANA      2 - 49152
Private Use         49153 - 65535

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


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

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


7.3.2 Policy Token Payload Processing


When processing the Policy Token Payload, the following fields MUST be
checked for correct values:


1.  Next Payload, RESERVED, Payload Length - These fields are processed as
    defined in Section 7.2.2, Generic Payload Header Processing.

2.  Policy Token Type - The Policy Token Type value MUST be checked to be
    a valid policy token type as defined by Table 14.  If the value is not
    valid, then an error is logged and if in Verbose mode an appropriate
    message containing notification value Payload-Malformed will be sent.

3.  Policy Token Data - This Policy Token Data MUST be processed according
    to the Policy Token Type specified.  The type will define the format of
    the data.



7.4 Key Download Payload


Refer to the terminology section for the different terms relating to keys
used within this section.

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 56]

INTERNET-DRAFT                       GSAKMP                       March 2005

     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        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Number of Items               ! Key Download Data Items       ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                  Figure 10:  Key Download Payload Format


7.4.1 Key Download Payload Structure


The Key Download Payload contains group keys (e.g., group keys, initial
rekey keys, etc.).  These key download payloads can have several security
attributes applied to them based upon the security policy of the group.
Figure 10 shows the format of the payload.

The security policy of the group dictates that the key download payload MUST
be encrypted with a key encryption key (KEK). The encryption mechanism 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.

The Key Download Payload fields are defined as follows:


Next Payload (1 octet)  - Identifier for the payload type of the next
    payload in the message.  If the current payload is the last in
    the message, then this field will be 0.  This field provides the
    ``chaining`` capability.  Table 12 identifies the payload types.  This
    field is treated as an unsigned value.

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

Payload Length (2 octets)  - Length in octets of the current payload,
    including the generic payload header.  This field is treated as an
    unsigned integer in network byte order format.

Number of Items (2 octets)  -- Contains the total number of traffic
    protection keys and Rekey Arrays being passed in this data block.  This
    field is treated as an unsigned integer in network byte order format.

Key Download Data Items (variable length)  - Contains Key Download
    information.  The Key Download Data is a sequence of Type/Length/Data of
    the Number of Items.  The format for each item is defined in figure 11.

    For each Key Download Data Item, the data format is as follows:



Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 57]

INTERNET-DRAFT                       GSAKMP                       March 2005

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! KDD Item Type !  Key Download Data Item Length!               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~ Data for Key Download Data Item (Key Datum/Rekey Array)       ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                 Figure 11:  Key Download Data Item Format


    Key Download Data (KDD) Item Type (1 octet)  -- Identifier for the type
        of data contained in this Key Download Data Item.  See Table 15
        for the possible values of this field.  This field is treated as an
        unsigned value.


                  Table 15:  Key Download Data Item Types

     Key Download Data     Value       Definition
     Item Type
    __________________________________________________________________

     GTPK                    0         This type MUST be implemented.
                                       This type identifies that the
                                       data contains group traffic
                                       protection key information.
     Rekey - LKH             1         Optional
     Reserved to IANA     2 - 192
     Private Use         193 - 255

    Key Download Data Item Length (2 octets)  -- Length in octets of the
        Data for the Key Download Data Item following this field.  This
        field is treated as an unsigned integer in network byte order
        format.

    Data for Key Download Data Item (variable length)  -- Contains Keys
        and related information.  The format of this field is specific
        depending on the value of the Key Download Data Item Type field.
        For KDD Item Type of GTPK, this field will contain a Key Datum as
        defined in Section 7.4.1.1 .  For KDD Item Type Rekey - LKH, this
        field will contain a Rekey Array as defined in Section 7.4.1.2 .


The encryption of this payload only covers the data subsequent to the
Generic Payload header (Number of Items and Key Download Data Items fields).

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



Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 58]

INTERNET-DRAFT                       GSAKMP                       March 2005

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Key Type                      ! Key ID                        ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                               ! Key Handle                    ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                               ! Key Creation Date             ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !               ! Key Expiration Date                           ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                               !               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~ Key Data                                                      ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                        Figure 12:  Key Datum Format


7.4.1.1 Key Datum Structure


A Key Datum contains all the information for a key.  Figure 12 shows the
format for this structure.


Key Type (2 octets)  -- This is the cryptographic algorithm for which this
    key data is to be used.  This value is specified in the Policy Token.
    See Table 16 for the possible values of this field.  This field is
    treated as an unsigned value.

Key ID (4 octets)  -- This is the permanent ID of all versions of the key.
    This value MAY be defined by the Policy Token.  This field is treated as
    an octet string.

Key Handle (4 octets)  -- This is the value to uniquely identify a version
    (particular instance) of a key.  This field is treated as an octet
    string.



Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 59]

INTERNET-DRAFT                       GSAKMP                       March 2005


                     Table 16:  Cryptographic Key Types

  Cryptographic_Key_Types     Value         Description
 _________________________________________________________________________

  Reserved                    0 - 2
  3DES_CBC64_192                3
  Reserved                    4 - 11
  AES_CBC_192                   12          This type MUST be supported.
  AES_CTR                       13
  Reserved to IANA          14 - 49152
  Private Use             49153 - 65535


Key Creation Date (15 octets)  -- This is the time value of when this key
    data was originally generated.  This field contains the timestamp in
    UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 - 9999),
    MM is the numerical value of the month (01 - 12), DD is the day of the
    month (01 - 31), HH is the hour of the day (00 - 23), MM is the minute
    within the hour (00 - 59), SS is the seconds within the minute (00 -
    59), and followed by the letter Z to indicate that this is Zulu time.
    This format is loosely based on [RFC 3161].

Key Expiration Date (15 octets)  -- This is the time value of when this
    key is no longer valid for use.  This field contains the timestamp in
    UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 - 9999),
    MM is the numerical value of the month (01 - 12), DD is the day of the
    month (01 - 31), HH is the hour of the day (00 - 23), MM is the minute
    within the hour (00 - 59), SS is the seconds within the minute (00 -
    59), and followed by the letter Z to indicate that this is Zulu time.
    This format is loosely based on [RFC 3161].

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


NOTE: The combination of the Key ID and the Key Handle MUST be unique within
the group.  This combination will be used to uniquely identify a key.


7.4.1.2 Rekey Array Structure


A Rekey Array contains the information for the set of KEKs that is
associated with a Group Member.  Figure  13 shows the format for this
structure.


Rekey Version (1 octet)  -- Contains the version of the Rekey protocol in
    which the data is formatted.  For Key Download Data Item Type of Rekey


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 60]

INTERNET-DRAFT                       GSAKMP                       March 2005

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Rekey Version#! Member ID                                     ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~               ! Number of KEK Keys            !               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~ Key Datum(s)                                                  ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                  Figure 13:  Rekey Array Structure Format


    - LKH, refer to Section A.2 for a description of this value.  This field
    is treated as an unsigned value.

Member ID (4 octets)  -- This is the Member ID of the Rekey sequence
    contained in this Rekey Array.  This field is treated as an octet
    string.  For Key Download Data Item Type of Rekey - LKH, refer to
    Section A.2 for a description of this value.

Number of KEK Keys (2 octets)  -- This value is the number of distinct KEK
    keys in this sequence.  This value is treated as an unsigned integer in
    network byte order format.

Key Datum(s) (variable length)  -- The sequence of KEKs in Key Datum
    format.  The format for each Key Datum in this sequence is defined in
    section 7.4.1.1.


     Key ID - For Key ID within the Rekey - LKH space, refer to Section A.2
        for a description of this value.


7.4.2 Key Download Payload Processing


Prior to processing its data, the payload contents MUST be decrypted.

When processing the Key Download Payload, the following fields MUST be
checked for correct values:


1.  Next Payload, RESERVED, Payload Length - These fields are processed as
    defined in Section 7.2.2, Generic Payload Header Processing.

2.  KDD Item Type - All KDD Item Type fields MUST be checked to be a valid
    Key Download Data Item type as defined by Table 15.  If the value is
    not valid, then an error is logged and if in Verbose mode an appropriate


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 61]

INTERNET-DRAFT                       GSAKMP                       March 2005

    message containing notification value Payload-Malformed will be sent.

3.  Key Type - All Key Type fields MUST be checked to be a valid encryption
    type as defined by table 16.  If the value is not valid, then an error
    is logged and if in Verbose mode an appropriate message containing
    notification value Invalid-Key-Information will be sent.

4.  Key Expiration Date - All Key Expiration Date fields MUST be checked
    confirm that their values represent a future and not a past time
    value.  If the value is not valid, then an error is logged and if in
    Verbose mode an appropriate message containing notification value
    Invalid-Key-Information will be sent.



The length and counter fields in the payload are used to help process the
payload.  If any field is found to be incorrect, then an error is logged
and if in Verbose mode an appropriate message containing notification value
Payload-Malformed will be sent.


7.5 Rekey Event Payload


Refer to the terminology section for the different terms relating to keys
used within this section.


7.5.1 Rekey Event Payload Structure


The Rekey Event Payload MAY contain multiple keys encrypted in Wrapping
KEKs.  Figure 14 shows the format of the payload.  If the data to be
contained within a Rekey Event Payload is too large for the payload, the
sequence can be split across multiple Rekey Event Payloads at a Rekey Event
Data boundary.

     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        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! RekeyEvnt Type!  Rekey Event Header                           ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~ Rekey Event Data(s)                                           ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                   Figure 14:  Rekey Event Payload Format

The Rekey Event Payload fields are defined as follows:

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 62]

INTERNET-DRAFT                       GSAKMP                       March 2005

Next Payload (1 octet)  - Identifier for the payload type of the next
    payload in the message.  If the current payload is the last in
    the message, then this field will be 0.  This field provides the
    ``chaining`` capability.  Table 12 identifies the payload types.  This
    field is treated as an unsigned value.

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

Payload Length (2 octets)  - Length in octets of the current payload,
    including the generic payload header.  This field is treated as an
    unsigned integer in network byte order format.

Rekey Event Type (1 octet)  - Specifies the type of Rekey Event being used.
    Table 17 presents the types of Rekey events.  This field is treated as
    an unsigned value.


                        Table 17:  Rekey Event Types

Rekey_Event_Type     Value       Definition
_______________________________________________________________________________

None                   0         This type MUST be implemented.
                                 In this case, the size of the Rekey Event
                                 Data field will be zero bytes long.
                                 The purpose of a Rekey Event Payload with
                                 type None is when it is necessary to send
                                 out a new token with no rekey information.
                                 GSAKMP Rekey Msg requires a Rekey Event
                                 Payload, and in this instance it would
                                 have rekey data of type None.
GSAKMP_LKH             1         The rekey data will be of type LKH formatted
                                 according to GSAKMP. The format for
                                 this field is defined in Section 7.5.1.2.
Reserved to IANA    2 - 192
Private Use        193 - 255

Rekey Event Header (variable length)  - This is the header information for
    the Rekey Event.  The format for this is defined in Section 7.5.1.1,
    Rekey Event Header Structure.

Rekey Event Data(s) (variable length)  - This is the rekey information for
    the Rekey Event.  The format for this is defined in Section 7.5.1.2,
    Rekey Event Data(s) Structure.


The Rekey Event payload type is three (3).






Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 63]

INTERNET-DRAFT                       GSAKMP                       March 2005

7.5.1.1 Rekey Event Header Structure


The format for the Rekey Event Header is shown in Figure 15.

     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                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                               ! RekeyEnt Type ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Algorithm Ver ! # of Rekey Event Data(s)      !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                   Figure 15:  Rekey Event Header Format


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

Time/Date Stamp (15 octets)  -- This is the time value when the Rekey
    Event Data was generated.  This field contains the timestamp in UTF-8
    format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 - 9999), MM is
    the numerical value of the month (01 - 12), DD is the day of the month
    (01 - 31), HH is the hour of the day (00 - 23), MM is the minute within
    the hour (00 - 59), SS is the seconds within the minute (00 - 59),
    and followed by the letter Z to indicate that this is Zulu time.  This
    format is loosely based on [RFC 3161].

Rekey Event Type (1 octet)  - This is the Rekey algorithm being used for
    this group.  The values for this field can be found in Table 17.  This
    field is treated as an unsigned value.

Algorithm Version (1 octet)  - Indicates the version of the Rekey Type
    being used.  For Rekey Event Type of GSAKMP_LKH, refer to Section A.2
    for a description of this value.  This field is treated as an unsigned
    value.

# of Rekey Event Data(s) (2 octets)  - The number of Rekey Event Data(s)
    contained in the Rekey Data.  This value is treated as an unsigned


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 64]

INTERNET-DRAFT                       GSAKMP                       March 2005

    integer in network byte order.



7.5.1.2 Rekey Event Data Structure


As defined in the Rekey Event Header, # of Rekey Data(s) field, multiple
pieces of information are sent in a Rekey Event Data.  Each end user, will
be interested in only one Rekey Event Data among all of the information
sent.  Each Rekey Event Data, will contain all the Key Packages that a user
requires.  For each Rekey Event Data, the data following the Wrapping fields
is encrypted with the key identified in the Wrapping Header.  Figure 16
shows the format of each Rekey Event Data.
     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                 ! Wrapping KeyID                ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                               ! Wrapping Key Handle           ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                               ! # of Key Packages             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Key Packages(s)                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                    Figure 16:  Rekey Event Data Format



Packet Length (2 octets)  - Length in octets of the Rekey Event Data, which
    consists of the # of Key Packages and the Key Packages(s).  This value
    is treated as an unsigned integer in network byte order.

Wrapping KeyID (4 octets)  - This is the Key ID of the KEK that is being
    used for encryption/decryption of the new (rekeyed) keys.  For Rekey
    Event Type of Rekey - LKH, refer to Section A.2 for a description of
    this value.

Wrapping Key Handle (4 octets)  - This is a Key Handle of the KEK that is
    being used for encryption/decryption of the new (rekeyed) keys.  Refer
    to Section 7.4.1.1 for the values of this field.

# of Key Packages (2 octets)  - The number of key packages contained in
    this Rekey Event Data.  This value is treated as an unsigned integer in
    network byte order.

Key Package(s) (variable length)  - The type/length/value format of a Key
    Datum.  The format for this is defined in Section 7.5.1.2.1.



Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 65]

INTERNET-DRAFT                       GSAKMP                       March 2005

7.5.1.2.1 Key Package Structure


Each Key Package contains all the information about the key.  Figure 17
shows the format for a Key Package.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! KeyPkg Type   ! Key Package Length            ! Key Datum     ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                       Figure 17:  Key Package Format


Key Package Type (1 octet)  - The type of key in this key package.  Legal
    values for this field are defined in Table 15, Key Download Data Types.
    This field is treated as an unsigned value.

Key Package Length (2 octets)  - The length of the Key Datum.  This field
    is treated as an unsigned integer in network byte order format.

Key Datum (variable length)  - The actual data of the key.  The format for
    this field is defined in Section 7.4.1.1, Key Datum.



7.5.2 Rekey Event Payload Processing


When processing the Rekey Event Payload, the following fields MUST be
checked for correct values:


1.  Next Payload, RESERVED, Payload Length - These fields are processed as
    defined in Section 7.2.2, Generic Payload Header Processing.

2.  Rekey Event Type field within "Rekey Event" payload header - The Rekey
    Event Type MUST be checked to be a valid rekey event type as defined by
    Table 17.  If the Rekey Event Type is not valid, then regardless of mode
    (e.g., Terse or Verbose) an error is logged.  No response error message
    is generated for receipt of a Group Management Message.

3.  Group ID Value - The Group ID value of the Rekey Event Header received
    message MUST be checked against the GroupID of the Group Component.  If
    no match is found, the payload is discarded, then regardless of mode
    (e.g., Terse or Verbose) an error is logged.  No response error message
    is generated for receipt of a Group Management Message.

4.  Date/Time Stamp - The Date/Time Stamp value of the Rekey Event Header
    MAY be checked to determine if the Rekey Event generation time is recent

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 66]

INTERNET-DRAFT                       GSAKMP                       March 2005

    relative to network delay and processing times.  If the TimeStamp is
    judged not to be recent, an error is logged.  No response error message
    is generated for receipt of a Group Management Message.

5.  Rekey Event Type field within the "Rekey Event Header" - The Rekey Event
    Type of the Rekey Event Header received message MUST be checked to be
    a valid rekey event type as defined by Table 17 and the same value of
    the Rekey Event Type earlier in this payload.  If the Rekey Event Type
    is not valid or not equal to the previous value of the Rekey Event Type,
    then regardless of mode (e.g., Terse or Verbose) an error is logged.  No
    response error message is generated for receipt of a Group Management
    Message.

6.  Algorithm Version - The Rekey Algorithm Version number MUST be checked
    that it is supported.  If the version is not supported, then regardless
    of mode (e.g., Terse or Verbose) an error is logged.  No response error
    message is generated for receipt of a Group Management Message.



The length and counter fields are used to help process the message.  If
any field is found to be incorrect, then termination processing MUST be
initiated.

A GM MUST process all the Rekey Event Datas as based on the Rekey method
used there is a potential that multiple Rekey Event Datas are for this GM.
The Rekey Event Datas are processed in order until all Rekey Event Datas are
consumed.


1.  Wrapping KeyID - The Wrapping KeyID MUST be checked against the list
    of stored KEKs that this GM holds.  If a match is found, then continue
    processing this Rekey Event Data.  Otherwise, skip to the next Rekey
    Event Data.

2.  Wrapping Handle - If a matching Wrapping KeyID was found, then the
    Wrapping Handle MUST be checked against the handle of the KEK for which
    the KeyID was a match.  If the handles match, then the GM will process
    the Key Packages associated with this Rekey Event Data.  Otherwise, skip
    to the next Rekey Event Data.


If a GM has found a matching Wrapping KeyID and Wrapping Handle, the GM
decrypts the remaining data in this Rekey Event Data according to policy
using the KEK defined by the Wrapping KeyID and Handle.  After decrypting
the data, the GM extracts the # of Key Packages field to help process the
subsequent Key Packages.  The Key Packages are processed as follows:


1.  Key Package Type - The Key Package Type MUST be checked to be a valid
    key package type as defined by Table 15.  If the Key Package Type is
    not valid, then regardless of mode (e.g., Terse or Verbose) an error is

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 67]

INTERNET-DRAFT                       GSAKMP                       March 2005

    logged.  No response error message is generated for receipt of a Group
    Management Message.

2.  Key Package Length - The Key Package Length is used to process the
    subsequent Key Datum information.

3.  Key Type - The Key Type MUST be checked to be a valid key type as
    defined by Table 16.  If the Key Package Type is not valid, then
    regardless of mode (e.g., Terse or Verbose) an error is logged.  No
    response error message is generated for receipt of a Group Management
    Message.

4.  Key ID - The Key ID MUST be checked against the set of Key IDs that this
    user maintains for this Key Type.  If no match is found, then regardless
    of mode (e.g., Terse or Verbose) an error is logged.  No response error
    message is generated for receipt of a Group Management Message.

5.  Key Handle - The Key Handle is extracted as is and is used to be the new
    Key Handle for the Key currently associated with the Key Package's Key
    ID.

6.  Key Creation Date - The Key Creation Date MUST be checked that it is
    subsequent to the Key Creation Date for the currently held key.  If
    this date is prior to the currently held key, then regardless of mode
    (e.g., Terse or Verbose) an error is logged.  No response error message
    is generated for receipt of a Group Management Message.

7.  Key Expiration Date - The Key Expiration Date MUST be checked that it
    is subsequent to the Key Creation Date just received and that the time
    rules conform with policy.  If the expiration date is not subsequent
    to the creation date or does not conform with policy, then regardless
    of mode (e.g., Terse or Verbose) an error is logged.  No response error
    message is generated for receipt of a Group Management Message.

8.  Key Data - The Key Data is extracted based on the length information in
    the key package.



If there were no errors when processing the Key Package, the key represented
by the KeyID will have all of its data updated based upon the received
information.


7.6 Identification Payload


7.6.1 Identification Payload Structure


The Identification Payload contains entity-specific data used to exchange
identification information.  This information is used to verify the

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 68]

INTERNET-DRAFT                       GSAKMP                       March 2005

identities of members.  Figure 18 shows the format of the Identification
Payload.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Next Payload  !   RESERVED    !         Payload Length        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! ID Classif    !  ID Type      !      Identification Data      ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                 Figure 18:  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.  This field provides the
    ``chaining`` capability.  Table 12 identifies the payload types.  This
    field is treated as an unsigned value.

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

Payload Length (2 octets)  - Length in octets of the current payload,
    including the generic payload header.  This field is treated as an
    unsigned integer in network byte order format.

Identification (ID) Classification (1 octet)  - Classifies the ownership of
    the Identification Data.  Table 18 identifies possible values for this
    field.  This field is treated as an unsigned value.


                  Table 18:  Identification Classification

                       ID_Classification    Value
                      _______________________________

                       Sender                 0
                       Receiver               1
                       Third Party            2
                       Reserved to IANA    3 - 192
                       Private Use        193 - 255

Identification (ID) Type (1 octet)  - Specifies the type of Identification
    being used.  Table 19 identifies possible values for this type.  This
    field is treated as an unsigned value.  All defined types are OPTIONAL
    unless otherwise stated.

Identification Data (variable length)  - Contains identity information.

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 69]

INTERNET-DRAFT                       GSAKMP                       March 2005


                      Table 19:  Identification Types

ID_Type              Value       PKIX Cert           Description
                                 Field
_______________________________________________________________________________

Reserved               0
ID_IPV4_ADDR           1         SubjAltName         See [IKEv2] sec 3.5.
                                 iPAddress
ID_FQDN                2         SubjAltName         See [IKEv2] sec 3.5.
                                 dNSName
ID_RFC822_ADDR         3         SubjAltName         See [IKEv2] sec 3.5.
                                 rfc822Name
Reserved               4
ID_IPV6_ADDR           5         SubjAltName         See [IKEv2] sec 3.5.
                                 iPAddress
Reserved             6 - 8
ID_DER_ASN1_DN         9         Entire Subject,     See [IKEv2] sec 3.5.
                                 bitwise Compare
Reserved               10
ID_KEY_ID              11        N/A                 See [IKEv2] sec 3.5.
Reserved            12 - 29
Unencoded Name         30        Subject             The format for this type
 (ID_U_NAME)                                         is defined in
                                                     Section 7.6.1.1.
ID_DN_STRING           31        Subject             See [OpenLDAP].
                                                     This type MUST be
                                                     implemented.
Reserved to IANA    32 - 192
Private Use        193 - 255


    The values for this field are group-specific and the format is
    specified by the ID Type field.  The format for this field is stated in
    conjunction with the type in Table 19.


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














Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 70]

INTERNET-DRAFT                       GSAKMP                       March 2005

7.6.1.1 ID_U_NAME Structure


The format for type Unencoded Name (ID_U_NAME) is shown in Figure 19.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Serial Number                                                 ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Length                                                        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! DN Data                                                       ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



               Figure 19:  Unencoded Name (ID-U-NAME) Format


Serial Number (20 octets)  -- The certificate serial number.  This field is
    treated as an unsigned integer in network byte order format.

Length (4 octets)  -- Length in octets of the DN Data field.  This field is
    treated as an unsigned integer in network byte order format.

DN Data (variable length)  -- The actual UTF-8 DN value (Subject
    field) using the slash (/) character for field delimiters.  (e.g.,
    "/C=US/ST=MD/L=Somewhere/O=ACME, Inc./OU=DIV1/CN=user1/Email=user1@acme.com"
    without the surrounding quotes)



7.6.2 Identification Payload Processing


When processing the Identification Payload, the following fields MUST be
checked for correct values:


1.  Next Payload, RESERVED, Payload Length - These fields are processed as
    defined in Section 7.2.2, Generic Payload Header Processing.

2.  Identification Classification - The Identification Classification value

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 71]

INTERNET-DRAFT                       GSAKMP                       March 2005

    MUST be checked to be a valid identification classification type as
    defined by Table 18.  If the value is not valid, then an error is logged
    and if in Verbose mode an appropriate message containing notification
    value Payload-Malformed will be sent.

3.  Identification Type - The Identification Type value MUST be checked to
    be a valid identification type as defined by Table 19.  If the value is
    not valid, then an error is logged and if in Verbose mode an appropriate
    message containing notification value Payload-Malformed will be sent.

4.  Identification Data - This Identification Data MUST be processed
    according to the identification type specified.  The type will define
    the format of the data.  If the identification data is being used to
    find a match and no match is found, then an error is logged and if
    in Verbose mode an appropriate message containing notification value
    Invalid-ID-Information will be sent.



7.6.2.1 ID_U_NAME Processing


When processing the Identification Data of type ID_U_NAME, the following
fields MUST be checked for correct values:


1.  Serial Number - The serial number MUST be a greater than or equal to one
    (1) to be a valid serial number from a conforming CA [RFC 3280].  If the
    value is not valid, then an error is logged and if in Verbose mode an
    appropriate message containing notification value Payload-Malformed will
    be sent.

2.  DN Data - The DN data is processed as a UTF-8 string.

3.  The CA MUST be a valid trusted policy creation authority as defined by
    the Policy Token.


These 2 pieces of information, Serial Number and DN Data, in conjunction
will then be used for party identification.  These values are also used to
help identify the certificate when necessary.


7.7 Certificate Payload


7.7.1 Certificate Payload Structure


The Certificate Payload provides a means to transport certificates or other
certificate-related information via GSAKMP and can appear in any GSAKMP


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 72]

INTERNET-DRAFT                       GSAKMP                       March 2005

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.  Multiple certificate payloads MAY be sent to
enable verification of certificate chains.  Conversely, zero (0) certificate
payloads may be sent and the receiving GSAKMP MUST rely on some other
mechanism to retrieve certificates for verification purposes.  Figure 20
shows the format of the Certificate Payload.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Next Payload  !   RESERVED    !         Payload Length        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Cert Type                     !    Certificate Data           ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                   Figure 20:  Certificate Payload Format

The Certificate Payload fields are defined as follows:


Next Payload (1 octet)  - Identifier for the payload type of the next
    payload in the message.  If the current payload is the last in
    the message, then this field will be 0.  This field provides the
    ``chaining`` capability.  Table 12 identifies the payload types.  This
    field is treated as an unsigned value.

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

Payload Length (2 octets)  - Length in octets of the current payload,
    including the generic payload header.  This field is treated as an
    unsigned integer in network byte order format.

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

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



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






Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 73]

INTERNET-DRAFT                       GSAKMP                       March 2005


                    Table 20:  Certificate Payload Types

Certificate_Type                   Value         Description
_______________________________________________________________________________

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


7.7.2 Certificate Payload Processing


When processing the Certificate Payload, the following fields MUST be
checked for correct values:


1.  Next Payload, RESERVED, Payload Length - These fields are processed as
    defined in Section 7.2.2, Generic Payload Header Processing.

2.  Certificate Type - The Certificate Type value MUST be checked to be a
    valid certificate type as defined by Table 20.  If the value is not
    valid, then an error is logged and if in Verbose mode an appropriate
    message containing notification value Cert-Type-Unsupported will be
    sent.

3.  Certificate Data - This Certificate Data MUST be processed according
    to the certificate type specified.  The type will define the format
    of the data.  Receipt of a certificate of the trusted policy creation
    authority in a Certificate payload causes the payload to be discarded.
    This received certificate MUST NOT be used to verify the message.  The
    certificate of the trusted policy creation authority MUST be retrieved
    by other means.




Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 74]

INTERNET-DRAFT                       GSAKMP                       March 2005

7.8 Signature Payload


7.8.1 Signature Payload Structure


The Signature Payload contains data generated by the digital signature
function.  The digital signature, as defined by the dissection of each
message, covers the message from the GSAKMP Message Header through the
Signature Payload up to but not including the Signature Data Length.
Figure 21 shows the format of the Signature Payload.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Next Payload  !   RESERVED    !         Payload Length        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Signature Type                ! Sig ID Type   !               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~ Signature Timestamp                                           ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                               ! Signer ID Length              !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                    Signer ID Data                             ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !     Signature Length          !     Signature Data            ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                    Figure 21:  Signature Payload Format

The Signature Payload fields are defined as follows:


Next Payload (1 octet)  - Identifier for the payload type of the next
    payload in the message.  If the current payload is the last in
    the message, then this field will be 0.  This field provides the
    ``chaining`` capability.  Table 12 identifies the payload types.  This
    field is treated as an unsigned value.

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

Payload Length (2 octets)  - Length in octets of the current payload,
    including the generic payload header.  This field is treated as an


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 75]

INTERNET-DRAFT                       GSAKMP                       March 2005

    unsigned integer in network byte order format.

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


                         Table 21:  Signature Types

  Signature Type                         Value         Description
 ________________________________________________________________________

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

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

Signature Timestamp (15 octets)  -- This is the time value when the digital
    signature was applied.  This field contains the timestamp in UTF-8
    format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 - 9999), MM is
    the numerical value of the month (01 - 12), DD is the day of the month
    (01 - 31), HH is the hour of the day (00 - 23), MM is the minute within
    the hour (00 - 59), SS is the seconds within the minute (00 - 59),
    and followed by the letter Z to indicate that this is Zulu time.  This
    format is loosely based on [RFC 3161].

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

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

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

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


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


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 76]

INTERNET-DRAFT                       GSAKMP                       March 2005

7.8.2 Signature Payload Processing


When processing the Signature Payload, the following fields MUST be checked
for correct values:



1.  Next Payload, RESERVED, Payload Length - These fields are processed as
    defined in Section 7.2.2, Generic Payload Header Processing.

2.  Signature Type - The Signature Type value MUST be checked to be a valid
    signature type as defined by Table 21.  If the value is not valid,
    then an error is logged and if in Verbose mode an appropriate message
    containing notification value Payload-Malformed will be sent.

3.  Signature ID Type - The Signature ID Type value MUST be checked to be
    a valid signature ID type as defined by Table 19.  If the value is not
    valid, then an error is logged and if in Verbose mode an appropriate
    message containing notification value Payload-Malformed will be sent.

4.  Signature Timestamp - This field MAY be checked to determine if the
    transaction signing time is fresh relative to expected network delays.
    Such a check is appropriate for systems in which archived sequences of
    events is desired.

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

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

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


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



Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 77]

INTERNET-DRAFT                       GSAKMP                       March 2005

7.9 Notification Payload


7.9.1 Notification Payload Structure


The Notification Payload can contain both GSAKMP and group specific data
and is used to transmit informational data, such as error conditions, to
a GSAKMP peer.  It is possible to send multiple independent Notification
payloads in a single GSAKMP message.  Figure 22 shows the format of the
Notification Payload.

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



                  Figure 22:  Notification Payload Format

The Notification Payload fields are defined as follows:


Next Payload (1 octet)  - Identifier for the payload type of the next
    payload in the message.  If the current payload is the last in
    the message, then this field will be 0.  This field provides the
    ``chaining`` capability.  Table 12 identifies the payload types.  This
    field is treated as an unsigned value.

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

Payload Length (2 octets)  - Length in octets of the current payload,
    including the generic payload header.  This field is treated as an
    unsigned integer in network byte order format.

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

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



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



Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 78]

INTERNET-DRAFT                       GSAKMP                       March 2005








                       Table 22:  Notification Types

         Notification Type                              Value
        __________________________________________________________

         None                                             0
         Invalid-Payload-Type                             1
         Reserved                                       2 - 3
         Invalid-Version                                  4
         Invalid-Group-ID                                 5
         Invalid-Sequence-ID                              6
         Payload-Malformed                                7
         Invalid-Key-Information                          8
         Invalid-ID-Information                           9
         Reserved                                      10 - 11
         Cert-Type-Unsupported                           12
         Invalid-Cert-Authority                          13
         Authentication-Failed                           14
         Reserved                                      15 - 16
         Certificate-Unavailable                         17
         Reserved                                        18
         Unauthorized-Request                            19
         Reserved                                      20 - 22
         Acknowledgment                                  23
         Reserved                                      24 - 25
         Nack                                            26
         Cookie-Required                                 27
         Cookie                                          28
         Mechanism Choices                               29
         Leave Group                                     30
         Departure Accepted                              31
         Request to Depart Error                         32
         Invalid Exchange Type                           33
         IPv4 Value                                      34
         IPv6 Value                                      35
         Prohibited by Group Policy                      36
         Prohibited by Locally Configured Policy         37
         Reserved to IANA                            38 - 49152
         Private Use                               49153 -- 65535







Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 79]

INTERNET-DRAFT                       GSAKMP                       March 2005

7.9.1.1 Notification Data - Acknowledgment (ACK) Payload Type


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

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Ack Type      !       Acknowledgment Data                     ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



      Figure 23:  Notification Data - Acknowledge Payload Type Format

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


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


                      Table 23:  Acknowledgment Types

            ACK_Type             Value       Definition
           _____________________________________________________

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


7.9.1.2 Notification Data - Cookie_Required and Cookie Payload Type


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

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



Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 80]

INTERNET-DRAFT                       GSAKMP                       March 2005

7.9.1.3 Notification Data - Mechanism Choices Payload Type


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

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Mech Type     ! Mechanism Choice Data         !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...



   Figure 24:  Notification Data - Mechanism Choices Payload Type Format

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


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


                         Table 24:  Mechanism Types

     Mechanism_Type             Value       Mechanism Choice
                                            Data Value Table Reference
    ___________________________________________________________________

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

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





Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 81]

INTERNET-DRAFT                       GSAKMP                       March 2005


                        Table 25:  Nonce Hash Types

     Nonce_Hash_Type        Value         Description
    ___________________________________________________________________

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


7.9.1.4 Notification Data - IPv4 and IPv6 Value Payload Types


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


7.9.2 Notification Payload Processing


When processing the Notification Payload, the following fields MUST be
checked for correct values:


1.  Next Payload, RESERVED, Payload Length - These fields are processed as
    defined in Section 7.2.2, Generic Payload Header Processing.

2.  Notification Type - The Notification type value MUST be checked to be a
    notification type as defined by Table 22.  If the value is not valid,
    then an error is logged and if in Verbose mode an appropriate message
    containing notification value Payload-Malformed will be sent.

3.  Notification Data - This Notification Data MUST be processed according
    to the notification type specified.  The type will define the format of
    the data.  When processing this data, any type field MUST be checked
    against the appropriate table for correct values.  If the contents of
    the Notification Data are not valid, then an error is logged and if
    in Verbose mode an appropriate message containing notification value
    Payload-Malformed will be sent.










Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 82]

INTERNET-DRAFT                       GSAKMP                       March 2005

7.10 Vendor ID Payload


7.10.1 Vendor ID Payload Structure


The Vendor ID Payload contains a vendor defined constant.  The constant
is used by vendors to identify and recognize remote instances of their
implementations.  This mechanism allows a vendor to experiment with new
features while maintaining backwards compatibility.  Figure 25 shows the
format of the payload.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Next Payload  !   RESERVED    !         Payload Length        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                         Vendor ID (VID)                       ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                    Figure 25:  Vendor ID Payload Format

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

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

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

The VendorID Payload fields are defined as follows:


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


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 83]

INTERNET-DRAFT                       GSAKMP                       March 2005

    ``chaining`` capability.  Table 12 identifies the payload types.  This
    field is treated as an unsigned value.

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

Payload Length (2 octets)  - Length in octets of the current payload,
    including the generic payload header.  This field is treated as an
    unsigned integer in network byte order format.

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



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


7.10.2 Vendor ID Payload Processing


When processing the Vendor ID Payload, the following fields MUST be checked
for correct values:


1.  Next Payload, RESERVED, Payload Length - These fields are processed as
    defined in Section 7.2.2, Generic Payload Header Processing.

2.  Vendor ID - The Vendor ID Data MUST be processed to determine if the
    Vendor ID value is recognized by the implementation.  If the Vendor
    ID value is not recognized, then regardless of mode (e.g., Terse or
    Verbose) this information is logged.  Processing of the message MUST
    continue regardless of recognition of this value.


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









Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 84]

INTERNET-DRAFT                       GSAKMP                       March 2005

7.11 Key Creation Payload


7.11.1 Key Creation Payload Structure


The Key Creation Payload contains information used to create key encryption
keys.  The security attributes for this payload are provided in the Policy
Token.  Figure 26 shows the format of the payload.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Next Payload  !   RESERVED    !         Payload Length        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Key Creation Type             ! Key Creation Data             ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                  Figure 26:  Key Creation Payload Format

The Key Creation Payload fields are defined as follows:


Next Payload (1 octet)  - Identifier for the payload type of the next
    payload in the message.  If the current payload is the last in
    the message, then this field will be 0.  This field provides the
    ``chaining`` capability.  Table 12 identifies the payload types.  This
    field is treated as an unsigned value.

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

Payload Length (2 octets)  - Length in octets of the current payload,
    including the generic payload header.  This field is treated as an
    unsigned integer in network byte order format.

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

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



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





Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 85]

INTERNET-DRAFT                       GSAKMP                       March 2005


                Table 26:  Types Of Key Creation Information

  Key Creation Type          Value         Definition
 _________________________________________________________________________

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


7.11.2 Key Creation Payload Processing


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

When processing the Key Creation Payload, the following fields MUST be
checked for correct values:


1.  Next Payload, RESERVED, Payload Length - These fields are processed as
    defined in Section 7.2.2, Generic Payload Header Processing.

2.  Key Creation Type - The Key Creation Type value MUST be checked to be
    a valid key creation type as defined by Table 26.  If the value is not
    valid, then an error is logged and if in Verbose mode an appropriate
    message containing notification value Payload-Malformed will be sent.

3.  Key Creation Data - This Key Creation Data MUST be processed according
    to the key creation type specified to generate the KEK to protect the
    information to be sent in the appropriate message.  The type will define
    the format of the data.


Implementations that want to derive other keys from the initial Key Creation
keying material, for example, DH Secret keying material, MUST define a
Key Creation Type other than one of those shown in Table 26.  The new Key


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 86]

INTERNET-DRAFT                       GSAKMP                       March 2005

Creation Type must specify that derivation's algorithm, for which the KEK
MAY be one of the keys derived.



7.12 Nonce Payload


7.12.1 Nonce Payload Structure


The Nonce Payload contains random data used to guarantee freshness during an
exchange and protect against replay attacks.  Figure 27 shows the format of
the Nonce Payload.
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Next Payload  !   RESERVED    !         Payload Length        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Nonce Type    !            Nonce Data                         ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                      Figure 27:  Nonce Payload Format

The Nonce Payload fields are defined as follows:



Next Payload (1 octet)  - Identifier for the payload type of the next
    payload in the message.  If the current payload is the last in
    the message, then this field will be 0.  This field provides the
    ``chaining`` capability.  Table 12 identifies the payload types.  This
    field is treated as an unsigned value.

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

Payload Length (2 octets)  - Length in octets of the current payload,
    including the generic payload header.  This field is treated as an
    unsigned integer in network byte order format.

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

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



Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 87]

INTERNET-DRAFT                       GSAKMP                       March 2005


                           Table 27:  Nonce Types

Nonce_Type              Value       Definition
_____________________________________________________________________________

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


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


7.12.2 Nonce Payload Processing


When processing the Nonce Payload, the following fields MUST be checked for
correct values:


1.  Next Payload, RESERVED, Payload Length - These fields are processed as
    defined in Section 7.2.2, Generic Payload Header Processing.

2.  Nonce Type - The Nonce Type value MUST be checked to be a valid nonce
    type as defined by Table 27.  If the value is not valid, then an error
    is logged and if in Verbose mode an appropriate message containing
    notification value Payload-Malformed will be sent.

3.  Nonce Data - This is the nonce data and it must be checked according
    to its content.  The size of this field is defined in Nonce Payload
    section 7.12.  Refer to the Message Processing Group Establishment
    section (Section 5.2) for interpretation of this field.













Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 88]

INTERNET-DRAFT                       GSAKMP                       March 2005

8 GSAKMP State Diagram


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

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


                      Figure 28:  GSAKMP State Diagram



















Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 89]

INTERNET-DRAFT                       GSAKMP                       March 2005
















                          Table 28:  GSAKMP States
___________________________________________________________________________

Idle                 : GSAKMP Application waiting for input
_____________________:_____________________________________________________
                     :
Wait for GC/KS Event : GC/KS up and running, waiting for events
_____________________:_____________________________________________________
                     :
Wait for Response    : GC/KS has sent Key Download,
 from Key Download   :  waiting for response from GM
_____________________:_____________________________________________________
                     :
Wait for Group       : GM in process of joining group
 Membership          :
_____________________:_____________________________________________________
                     :
Wait for Group       : GM has group key, waiting for
 Membership Event    :  group management messages.
                     :

___________________________________________________________________________
















Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 90]

INTERNET-DRAFT                       GSAKMP                       March 2005






                     Table 29:  State Transition Events
   ____________________________________________________________________

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

   ____________________________________________________________________






Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 91]

INTERNET-DRAFT                       GSAKMP                       March 2005

9 IANA Considerations



9.1 IANA Port Number Assignment


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


9.2 Initial IANA Registry Contents


The following registry entries should be created:


GSAKMP Group Identification Types
GSAKMP Payload Types
GSAKMP Exchange Types
GSAKMP Policy Token Types
GSAKMP Key Download Data Item Types
GSAKMP Cryptographic Key Types
GSAKMP Rekey Event Types
GSAKMP Identification Classification
GSAKMP Identification Types
GSAKMP Certificate Types
GSAKMP Signature Types
GSAKMP Notification Types
GSAKMP Acknowledgment Types
GSAKMP Mechanism Types
GSAKMP Nonce Hash Types
GSAKMP Key Creation Types
GSAKMP Nonce Types


9.2.1 GSAKMP Group Identification Types


The Group Identification occurs in the GSAKMP header.


     Group ID Type                    Value
     ==========================================
     Reserved                           0
     UTF-8                              1
     Octet String                       2
     IPv4                               3
     IPv6                               4
     Reserved to IANA                 5 - 192
     Private Use                    193 - 255


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 92]

INTERNET-DRAFT                       GSAKMP                       March 2005

9.2.1.1 Amending formula for GSAKMP Group Identification Types


GSAKMP Group Identification Types may be allocated by Specification
Required.


9.2.2 GSAKMP Payload Types


     Next Payload Type        Value
     ===================================
     None                       0
     Policy Token               1
     Key Download Packet        2
     Rekey event                3
     Identification             4
     Reserved                   5
     Certificate                6
     Reserved                   7
     Signature                  8
     Notification               9
     Reserved                  10
     Key Creation              11
     Nonce                     12
     Reserved to IANA       13 - 192
     Private Use           193 -- 255



9.2.2.1 Amending formula for GSAKMP Payload Types


GSAKMP Payload Types may be allocated by Specification Required.


9.2.3 GSAKMP Exchange Types


The Exchange Type occurs in the GSAKMP header.


     Exchange`Type                 Value
     ========================================
     Reserved                      0 - 3
     Key Download Ack/Failure        4
     Rekey Event                     5
     Reserved                      6 - 7
     Request to Join                 8
     Key Download                    9
     Cookie Download                 10
     Request to Join Error           11

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 93]

INTERNET-DRAFT                       GSAKMP                       March 2005

     Lack of Ack                     12
     Request to Depart               13
     Departure Response              14
     Departure Ack                   15
     Reserved to IANA             16 - 192
     Private Use                193 -- 255



9.2.3.1 Amending formula for GSAKMP Exchange Types


GSAKMP Exchange Types may be allocated by Specification Required.


9.2.4 GSAKMP Policy Token Types


     Policy Token Type       Value        Defined In
     ====================================================
     Reserved                  0
     GSAKMP`ASN.1`PT`V1        1          (CH02)
     Reserved to IANA      2 - 49152
     Private Use         49153 - 65535


9.2.4.1 Amending formula for GSAKMP Policy Token Types


GSAKMP Policy Token Types may be allocated by Specification Required.


9.2.5 GSAKMP Key Download Data Item Types


The Key Download Data Item Type occurs in the Key Download Payload.


     Key Download Data Item Type     Value
     =========================================

     GTPK                              0
     Rekey - LKH                       1
     Reserved to IANA               2 - 192
     Private Use                   193 - 255


9.2.5.1 Amending formula for GSAKMP Key Download Data Item Types


GSAKMP Key Download Data Item Types may be allocated by Specification
Required.

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 94]

INTERNET-DRAFT                       GSAKMP                       March 2005

9.2.6 GSAKMP Cryptographic Key Types


The Cryptographic Key Type occurs in the Key Type field of the Key Datum.



     Cryptographic Key Types  Value         Defined In
     =======================================================
     Reserved                 0 - 2
     3DES`CBC64`192             3           (RFC2451)
     Reserved                 4 - 11
     AES`CBC`192                12          (IKEv2)
     AES`CTR                    13          (IKEv2)
     Reserved to IANA       14 - 49152
     Private Use          49153 - 65535


9.2.6.1 Amending formula for GSAKMP Cryptographic Key Types


GSAKMP Cryptographic Key Types may be allocated by Specification Required.


9.2.7 GSAKMP Rekey Event Types


     Rekey`Event`Type    Value
     ============================
     None                  0
     GSAKMP`LKH            1
     Reserved to IANA   2 - 192
     Private Use       193 - 255


9.2.7.1 Amending formula for GSAKMP Rekey Event Types


GSAKMP Rekey Event Types may be allocated by Specification Required.


9.2.8 GSAKMP Identification Classification


      Identification Classification    Value
      ========================================
      Sender                            0
      Receiver                          1
      Third Party                       2
      Reserved to IANA                3 - 192
      Private Use                   193 - 255


Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 95]

INTERNET-DRAFT                       GSAKMP                       March 2005

9.2.8.1 Amending formula for GSAKMP Identification Classification


GSAKMP Identification Classification may be allocated by Specification
Required.


9.2.9 GSAKMP Identification Types


     Identification Type  Value      Defined In
     ===============================================
     Reserved               0
     ID`IPV4`ADDR           1        (IKEv2, sec 3.5)
     ID`FQDN                2        (IKEv2, sec 3.5)
     ID`RFC822`ADDR         3        (IKEv2, sec 3.5)
     Reserved               4
     ID`IPV6`ADDR           5        (IKEv2, sec 3.5)
     Reserved             6 - 8
     ID`DER`ASN1`DN         9        (IKEv2, sec 3.5)
     Reserved               10
     ID`KEY`ID              11       (IKEv2, sec 3.5)
     Reserved            12 - 29
     ID`U`NAME              30
     ID`DN`STRING           31       (OpenLDAP)
     Reserved to IANA    32 - 192
     Private Use        193 - 255




9.2.9.1 Amending formula for GSAKMP Identification Types


GSAKMP Identification Types may be allocated by Specification Required.


9.2.10 GSAKMP Certificate Types


     Certificate Type               Value       Defined In
     =================================================================
     None                             0
     Reserved                       1 - 3
     X.509v3 Certificate              4
       -- Signature - DER Encoding
     Reserved                       5 - 6
     Certificate Revocation List      7
     Reserved                       8 - 9
     X.509 Certificate               10         (IKEv2, sec 3.6)
       -- Attribute
     Raw RSA Key                     11         (IKEv2, sec 3.6)

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 96]

INTERNET-DRAFT                       GSAKMP                       March 2005

     Hash and URL of X.509           12         (IKEv2, sec 3.6)
      Certificate
     Hash and URL of X.509 bundle    13         (IKEv2, sec 3.6)
     Reserved to IANA              5 -- 49152
     Private Use               49153 -- 65535



9.2.10.1 Amending formula for GSAKMP Certificate Types


GSAKMP Certificate Types may be allocated by Specification Required.


9.2.11 GSAKMP Signature Types


     Signature Type       Value        Defined In
     ==============================================
     DSS-SHA1-ASN1-DER      0
     RSA1024-MD5            1          (RFC 3447)
     ECDSA-P384-SHA3        2          (FIPS 186-2)
     Reserved to IANA     3 - 41952
     Private Use      41953 - 65536


9.2.11.1 Amending formula for GSAKMP Signature Types


GSAKMP Signature Types may be allocated by Specification Required.


9.2.12 GSAKMP Notification Types


     Notification Type                       Value
     ================================================
     None                                      0
     Invalid-Payload-Type                      1
     Reserved                                2 - 3
     Invalid-Version                           4
     Invalid-Group-ID                          5
     Invalid-Sequence-ID                       6
     Payload-Malformed                         7
     Invalid-Key-Information                   8
     Invalid-ID-Information                    9
     Reserved                              10  - 11
     Cert-Type-Unsupported                    12
     Invalid-Cert-Authority                   13
     Authentication-Failed                    14
     Reserved                              15  - 16
     Certificate-Unavailable                  17

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 97]

INTERNET-DRAFT                       GSAKMP                       March 2005

     Unequal-Payload-Lengths                  18
     Unauthorized-Request                     19
     Reserved                              20  - 22
     Acknowledgment                           23
     Reserved                              24  - 25
     Nack                                     26
     Cookie-Required                          27
     Cookie                                   28
     Mechanism Choices                        29
     Leave Group                              30
     Departure Accepted                       31
     Request to Depart Error                  32
     Invalid Exchange Type                    33
     IPv4 Value                               34
     IPv6 Value                               35
     Prohibited by Group Policy               36
     Prohibited by Locally Configured Policy  37
     Reserved to IANA                      38  - 49152
     Private Use                        49153 -- 65535



9.2.12.1 Amending formula for GSAKMP Notification Types


GSAKMP Notification Types may be allocated by Specification Required.


9.2.13 GSAKMP Acknowledgment Types


The Acknowledgment Type occurs in the Notification Payload of type
Acknowledgment.


     ACK Type              Value
     ================================
     Simple                  0
     Reserved to IANA      1 - 192
     Private Use         193 - 255


9.2.13.1 Amending formula for GSAKMP Acknowledgment Types


GSAKMP Acknowledgment Types may be allocated by Specification Required.







Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 98]

INTERNET-DRAFT                       GSAKMP                       March 2005

9.2.14 GSAKMP Mechanism Types


The Mechanism Type occurs in the Notification Payload of type Mechanism
Choices.



     Mechanism Type             Value
     ====================================
     Key Creation Algorithm       0
     Encryption Algorithm         1
     Nonce Hash Algorithm         2
     Reserved to IANA          3 - 192
     Private Use              193 - 255


9.2.14.1 Amending formula for GSAKMP Mechanism Types


GSAKMP Mechanism Types may be allocated by Specification Required.


9.2.15 GSAKMP Nonce Hash Types


The Nonce Hash Type occurs in the Notification Payload of type Mechanism
Choices of type Nonce Hash Algorithm.


     Nonce Hash Type      Value
     ================================
     Reserved               0
     SHA-1                  1
     Reserved to IANA   2 - 49152
     Private Use      49153 - 65535


9.2.15.1 Amending formula for GSAKMP Nonce Hash Types


GSAKMP Nonce Hash Types may be allocated by Specification Required.


9.2.16 GSAKMP Key Creation Types


     Key Creation Type          Value     Defined In
     ===============================================
     Reserved                   0 - 1
     Diffie-Hellman               2       (IKEv2 B.2)
       1024-bit MODP Group

Harney, Meth, Colegrove, Gross  draft-ietf-msec-gsakmp-sec-08.txt  [Page 99]

INTERNET-DRAFT                       GSAKMP                       March 2005

     Reserved                   3 - 13
     Diffie-Hellman               14      (RFC3526)
       2048-bit MODP Group
     Reserved                 15 - 49152
     Private Use            49153 - 65535



9.2.16.1 Amending formula for GSAKMP Key Creation Types


GSAKMP Key Creation Types may be allocated by Specification Required.


9.2.17 GSAKMP Nonce Types


     Nonce Type              Value
     =================================
     None                      0
     Initiator (Nonce`I)       1
     Responder (Nonce`R)       2
     Combined (Nonce`C)        3
     Reserved to IANA       4 - 192
     Private Use           192 - 255



9.2.17.1 Amending formula for GSAKMP Nonce Types


GSAKMP Nonce Types may be allocated by Specification Required.


10 Acknowledgments


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

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


Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 100]

INTERNET-DRAFT                       GSAKMP                       March 2005

of the specification.  Ran Canetti analyzed the security of the protocol
and provided denial of service suggestions leading to optional "cookie
protection".



11 References


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


11.1 Normative References


[CH02] Colegrove A., Harney H., ``Group Policy Token Version 1 with
Application to GSAKMP'', draft-ietf-msec-policy-token-sec-02.txt, March 2005

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

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

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

[IKEv2] C. Kaufman, ``Internet Key Exchange (IKEv2) Protocol'',
draft-ietf-ipsec-ikev2-12.txt, January 2004

[OpenLDAP] Zeilenga, K., ``LDAP: String Representation of Distinguished
Names'', draft-ietf-ldapbis-dn-16.txt, February 2005

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

[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

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

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

[RFC 3629] F. Yergeau, UTF-8, a transformation format of ISO 10646, November


Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 101]

INTERNET-DRAFT                       GSAKMP                       March 2005

2003



11.2 Informative References


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

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

[HHMCD01] 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

[RFC 1750] Eastlake D., Crocker S. Schiller J., ``Randomness Recommendations
for Security'', RFC 1750, Informational, December 1994

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

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

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

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

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

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

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

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

[RFC 3161] C. Adams, P. Cain, D. Pinkas, R. Zuccherato, Internet X.509

Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 102]

INTERNET-DRAFT                       GSAKMP                       March 2005

Public Key Infrastructure Time-Stamp Protocol (TSP), August 2001

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

[RFC 3447] J. Jonsson, B. Kaliski, Public-Key Cryptography Standards (PKCS)
#1:  RSA Cryptography Specifications Version 2.1, February 2003

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

[RFC 3740] Hardjono T., Weis B., ``The Multicast Group Security
Architecture'', RFC 3740, March 2004, Informational



A APPENDIX A -- LKH Information


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


A.1 LKH Overview


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

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



                        Figure 29:   A. 1:  LKH Tree


Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 103]

INTERNET-DRAFT                       GSAKMP                       March 2005

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



A.2 LKH and GSAKMP


When using LKH with GSAKMP the following issues require attention:


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

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

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

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

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


For the following discussion, refer to Figure 30.

To guarantee uniqueness of KeyID, the Rekey Controller SHOULD build a
virtual tree and label the KeyID of each node doing a breadth first search
of a fully populated tree regardless of whether or not the tree is actually
full.  For simplicity of this example, the root of the tree was given
KeyID value of one (1).  These KeyID values will be static throughout
the life of this tree.  Additionally, the rekey arrays distributed to GMs
requires a MemberID value associated with them to be distributed with the
KeyDownload Payload.  These MemberID values MUST be unique.  Therefore,
the set associated with each leaf node (the nodes from that leaf back to
the root) are given a MemberID. In this example, the leftmost leaf node
is given MemberID value of one (1).  These 2 sets of values, the KeyIDs
(represented on lines N) and the MemberIDs (represented on line L) will

Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 104]

INTERNET-DRAFT                       GSAKMP                       March 2005

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

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



                    Figure 30:   A. 2:  GSAKMP LKH Tree


give sufficient information in the KeyDownload and RekeyEvent Payloads
to disseminate information.  The KeyHandle associated with these keys is
regenerated each time the key is replace in the tree due to compromise.


A.3 LKH Examples


Definition of values:

0xLLLL          - length value
0xHHHHHHH#      - handle value
YYYYMMDDHHMMSSZ - Time Value


A.3.1 LKH Key Download Example


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

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


Number of Items                   - 0x0002


Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 105]

INTERNET-DRAFT                       GSAKMP                       March 2005

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



A.3.2 LKH Rekey Event Example


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

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

This data shows that three packets are being transmitted.  Read each
packet as:
a) GTPK wrapped in LKH KeyID 2

Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 106]

INTERNET-DRAFT                       GSAKMP                       March 2005

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

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

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



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



Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 107]

INTERNET-DRAFT                       GSAKMP                       March 2005

B APPENDIX B -- Change History (To Be Removed from RFC)



B.1 Changes from GSAKMP-00 to GSAKMP-01 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.


B.2 Changes from GSAKMP-01 to GSAKMP-02 June 2003


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

2.  The Protocol 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.


B.3 Changes from GSAKMP-02 to GSAKMP-03 August 2003


1.  Clarified Nonce value in Request to Join With Cookie msg.

2.  Added Signature ID Type to Security Suite 1 definition.

3.  Clarified format of Identification information used in Signature and
    Identification Payloads.

4.  Split Signature Type field into it's two appropriate fields.  This was
    not a change in the payload, just cleaning up the definition.



Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 108]

INTERNET-DRAFT                       GSAKMP                       March 2005

B.4 Changes from GSAKMP-03 to GSAKMP-04 October 2003


1.  Terminology Section


   (a)  Rekey definition was made more verbose.


2.  Security Considerations Section


   (a)  ISAKMP Section


        i.  Corrected GSAKMPs relationship definition to ISAKMP.


   (b)  Rekey Availability Section


        i.  Added this new section.


3.  Architecture Section


   (a)  This section in its entirety was added for this revision of the
        specification.


4.  Group Life Cycle Section


   (a)  Group Establishment Section


        i.  Introduced Verbose and Terse concept.


   (b)  Standard Group Establishment Section


        i.  Added messages Request to Join Error and Lack_of_Ack to ladder
            diagram to show verbose error messaging.

       ii.  Modified definition of Ack message on ladder diagram to be
            consistent with new naming convention.

      iii.  Reworked all section wording to convey the new message
            transmissions.


Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 109]

INTERNET-DRAFT                       GSAKMP                       March 2005

   (c)  Request to Join Section


        i.  Completely reworked to better define the process of building
            and processing the RTJ message by the GM and GC/KS.


   (d)  Key Download Section


        i.  Completely reworked to better define the process of building
            and processing the KeyDL message by the GC/KS and GM.


   (e)  Request to Join Error Section


        i.  New section added for this new verbose message.


   (f)  Key Download = Ack/Failure Section


        i.  Completely reworked to better define the process of building
            and processing the KeyDL-A/F message by the GM and GC/KS.


   (g)  Lack_of_Ack Section


        i.  New section added for this new verbose message.


   (h)  Added the following new Sub-sections to this section.


        i.  Leaving Group

       ii.  Eviction

      iii.  Voluntary Departure without Notice

       iv.  De-registration

        v.  Request to Depart Message

       vi.  Departure Response Message

      vii.  Departure Ack Message




Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 110]

INTERNET-DRAFT                       GSAKMP                       March 2005

5.  GSAKMP Payload Structure Section


   (a)  Added note that all all integer fields larger than one octet MUST
        be converted to Network Byte Order prior to transmission.

   (b)  GSAKMP Header Section



        i.  Existing section became the Structure subsection.

       ii.  Added the Processing subsection.

      iii.  GroupID Type was modified to GroupID Length with the
            appropriate definitions.

       iv.  New Exchange Types added for verbose mode.

        v.  Sequence ID definition was modified for:


            A.  New initial value.

            B.  Rollover handling responsibility.


   (c)  GSAKMP Payload Header Section


        i.  Existing section became the Structure subsection.

       ii.  Added the Processing subsection.


   (d)  Policy Token Payload Section


        i.  The header paragraph was corrected to not levy any requirements
            from GSAKMP on the Policy Token.

       ii.  The PT Type field was expanded from one (1) to two (2) octets.

      iii.  The values of the PT Types were modified and defined to reflect
            the true purpose.


   (e)  Rekey Event Payload Section


        i.  Renamed Type field to be unique within specification.


Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 111]

INTERNET-DRAFT                       GSAKMP                       March 2005

       ii.  The values of the Rekey Type field were modified and defined to
            reflect their true purpose.


   (f)  Signature Payload Section


        i.  Existing section became the Structure subsection.

       ii.  Added the Processing subsection.

      iii.  Removed the one (1) octet field Signature ID Role from the
            payload, it contained irrelevant data.

       iv.  Expanded the definition of Singer ID Data to inform the user
            how to interpret this field.


   (g)  Notification Payload Section


        i.  Removed the one (1) octet Status Type field from the payload.
            It was irrelevant information.  Additionally, all references to
            Status Type were removed from the payload definition.

       ii.  Added new Notification Payload Type "Mechanism Choices".

      iii.  Added section "Notification Data - Mechanism Choices Payload
            Type" to define the format of a Notification Payload of type
            Mechanism Choices.


   (h)  Key Creation Payload Section


        i.  Existing section became the Structure subsection.

       ii.  Added the Processing subsection.

      iii.  Renamed Type field to be unique within specification.


   (i)  Nonce Payload Section


        i.  Existing section became the Structure subsection.

       ii.  Added the Processing subsection.





Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 112]

INTERNET-DRAFT                       GSAKMP                       March 2005

B.5 Changes from GSAKMP-04 to GSAKMP-05 February 2004


B.5.1 Major Modification/Reorganization of Specification


B.5.1.1 Key Terms and Payloads Modified


In the previous version of the specification, there was a lot of confusion
with respect to the terminology used for anything to do with keys and
rekey.  Therefore, all the terminology has been modified to make this more
comprehensible.  Additionally, all key information that was found in the
appendices was generalized and incorporated into the main sections of the
specification.

Following is a list of old terms mapped to new terms:


 -  LKH ID - Key ID, this field is now also in a GTPK, was not there
    previously.

 -  Key Pack - Key Datum

 -  Key Pack Data - Key Package

 -  Rekey Event Packet Data - Rekey Event Data


To accommodate all these changes, the Key Download Payload, Rekey Event
Payload, and LKH Appendix sections were completely reworked to reflect these
changes.

Other major changes in these sections with respect to bits on the wire:


 -  KeyID - All keys now have a 4 octet ID field.  This was not so before.
    Also, this field is now 4 octets long, it was previously 2 octets.

 -  Date Fields - These fields are now 15 bytes long and ascii format.


THEREFORE, look closely at the Key Download Payload and Rekey Event Payload
as the formats for these payloads have both changed dramatically the bits on
the wire.








Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 113]

INTERNET-DRAFT                       GSAKMP                       March 2005

B.5.2 Modification By Section


1.  Protocol Considerations Section - Moved to new section entitled IANA
    Considerations Section.

2.  Terminology Section


   (a)  Modified the following terms:  GTEK became GTPK

   (b)  Added the following terms:  Key Datum, KEK, Key Handle, Key ID,
        Key Package, Rekey Array, Rekey Key, Wrapping KeyID, Wrapping Key
        Handle


3.  Security Considerations Section


   (a)  Security Assumptions Section


        i.  Added an assumption with respect to system clock.


   (b)  Rekey Availability Section


        i.  Stated retransmission of rekey messages required for
            implementations.


4.  Group Establishment Section



   (a)  Added phrase concerning error message always indicates first error
        found.

   (b)  Key Download Section


        i.  Fixed second paragraph.


   (c)  Rekey Events Section - Made as subsection under new section Group
        Management.


5.  GSAKMP Payload Structure Section



Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 114]

INTERNET-DRAFT                       GSAKMP                       March 2005

   (a)  Added verbiage that no padding in any payloads.

   (b)  All processing sections updated to indicate error processing.


6.  Split following sections into Structure and Processing subsections:


   (a)  Policy Token Payload

   (b)  Key Download Payload

   (c)  Rekey Event Payload

   (d)  Identification Payload

   (e)  Certificate Payload


7.  GSAKMP Header Section


   (a)  Group ID Length and Sequence ID - Fixed definitions.

   (b)  Updated values in tables.

   (c)  Reworded processing section to be more precise.


8.  Policy Token Payload Section


   (a)  PT Type field in diagram was updated to reflect that this is really
        a 2 octet field and not a 1 octet field.

   (b)  Updated tables.


9.  Key Download and Rekey Event Payload Sections


   (a)  Completely reworked sections.  Refer to Section B.5.1.1 above for
        the modifications to these sections.

   (b)  Basically, reread these sections closely as a lot has changed.


10. Identification Payload Section


   (a)  U-NAME Definition was incorporated directly into this section.


Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 115]

INTERNET-DRAFT                       GSAKMP                       March 2005

   (b)  Updated tables.


11. Certificate Payload Section


   (a)  Added words to structure section about zero or multiple certificate
        payloads within a GSAKMP message.

   (b)  Updated tables.


12. Signature Payload Section


   (a)  Updated Tables.

   (b)  Signature Type field is now 2 octets long.

   (c)  Signature Payload Span field has been removed, it no longer exists.

   (d)  Signature Timestamp field is now 15 bytes long to conform to the

   (e)  Processing section was updated.  new date/time format begin used
        throughout the spec.


13. Notification Payload Section


   (a)  Updated Tables.

   (b)  Removed Length field from Notification Data Mechanism Choices
        Payload Types format.

   (c)  Made field Mechanism Choice Data field to be a static length of 2
        octets.


14. Key Creation Payload Section


   (a)  Updated Tables.

   (b)  Key Creation Type field is now 2 octets long.

   (c)  Updated Processing subsection.


15. Nonce Payload Section



Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 116]

INTERNET-DRAFT                       GSAKMP                       March 2005

   (a)  Updated Tables.

   (b)  Updated Processing subsection.


16. Added new section IANA Considerations.



B.6 Changes from GSAKMP-05 to GSAKMP-06 May 2004


NOTE: Minor editorial modifications are not listed here.


1.  Security Considerations Section


   (a)  Security Assumptions Section


        i.  Added considerations as pointed out by gmg.


   (b)  Protocol Considerations Section


        i.  Fixed wording between subsections to remove contradiction of
            how and when to use Diffie-Hellman.



2.  Architecture Section


   (a)  S-GC/KS Operations section replaced with Autonomous Distributed
        GSAKMP Operations Section

   (b)  GSAKMP Interactions with NAT Traversal section removed.


3.  Group Life Cycle Section


   (a)  To all subsection, modified the message dissection and discussion
        for Nonces.  Nonces are now an optional payload with a caveat.
        Systems that have synchronized time do not use Nonce payloads.
        Systems that do not have synchronized time MUST use Nonce payloads.

   (b)  Added information concerning Vendor ID payload processing.

   (c)  Added optional VendorID payload to all messages.

Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 117]

INTERNET-DRAFT                       GSAKMP                       March 2005

   (d)  Group Establishment Section


        i.  Added paragraph that Verbose mode is controlled by policy and
            how to handle it.

       ii.  Standard Group Establishment Section


            A.  Defined all possible error conditions.

            B.  Verbosely identified that message identification is via the
                exchange type within the header.

            C.  Introduced concept of synchronized time.


      iii.  RTJ Section


            A.  Added the NotifPL of type IPValue and explanation to this
                message type and discussion.


       iv.  Key Download - Ack/Failure Section


            A.  Added that upon successful registration all state
                information should be removed.


        v.  Cookie Section


            A.  Added information for calculation of cookie value in a
                NATted environment.


   (e)  Group Maintenance Section


        i.  Group Management Section


            A.  Added sections Policy Update and Group Destruction.


       ii.  Leaving a Group Section


            A.  De-Registration Section - Added the GM SHOULD support and


Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 118]

INTERNET-DRAFT                       GSAKMP                       March 2005

                GC/KS MUST support.

            B.  De-Registration Section - Fixed with respect to
                Terse/Verbose mode processing.


4.  GSAKMP Payload Structure Section


   (a)  Added pointed to VendorID section on how to process messages that
        contain this payload.

   (b)  GSAKMP Header Section


        i.  GSAKMP Header Structure Section


            A.  Updated GroupID Types table and added subsections to define
                the format for each type.

            B.  Added VendorID value to Payload Types table.


       ii.  GSAKMP Header Processing Section


            A.  Updated processing rule for GroupID and Version.

            B.  Added discussion for interoperability with future versions.


   (c)  Key Download Payload Section


        i.  Key Datum Structure Section


            A.  Fixed Key Type to be a 2 byte field as indicated by the
                table which shows its values.

            B.  Updated structure definition for Key ID, Key Handle, Key
                Creation Date, and Key Expiration Date.


   (d)  Rekey Event Payload Section


        i.  Rekey Event Payload Structure Section




Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 119]

INTERNET-DRAFT                       GSAKMP                       March 2005

            A.  Defined how to break up the data across multiple payloads.

            B.  Rekey Event Header Structure Section - Update structure
                definition of Time/Date Stamp.

            C.  Rekey Event Data Structure Section - Clarified information
                of which/how many Rekey Event Datas each user is interested
                in.



        i.  Rekey Event Payload Processing Section


            A.  Updated Date/Time Stamp processing rules.


   (e)  Identification Payload Section


        i.  Added ID Classification octet to payload, associated table, and
            associated processing information.

       ii.  Updated Identification Types table.

      iii.  ID-U-NAME Structure Section


            A.  Updated DN Data definition for UTF-8.


       iv.  ID-U-NAME Processing Section


            A.  Updated Serial Number and DN Data processing rules.

            B.  Added a new rule for CA being a trust anchor.


   (f)  Certificate Payload Section


        i.  Certificate Payload Structure Section


            A.  Updated Certificate Type values.


   (g)  Signature Payload Section


        i.  Signature Payload Structure Section

Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 120]

INTERNET-DRAFT                       GSAKMP                       March 2005

            A.  Updated Signature Timestamp definition for UTF-8 and how to
                deal with time differential from local.

            B.  Updated Signature Type table values.

            C.  Signature ID type is now aligned with IdentificationPL ID
                Type.


       ii.  Signature Payload Processing Section


            A.  Updated processing instructions for Signature Timestamp,
                Signature ID Data, and Signature Data.


   (h)  Notification Payload Section


        i.  Notification Payload Structure Section


            A.  Updated Notification Types table.


   (i)  Vendor ID Payload Section


        i.  This whole section was added.


   (j)  Key Creation Payload Section


        i.  Key Creation Payload Structure Section


            A.  Updated Key Creation Type table.


       ii.  Key Creation Payload Processing Section


            A.  Updated Key Creation Data processing instructions.


5.  GSAKMP State Diagram Section


   (a)  Updated State Transition Events table.



Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 121]

INTERNET-DRAFT                       GSAKMP                       March 2005

6.  IANA Considerations Section


   (a)  Updated all types sections for new values.



B.7 Changes from GSAKMP-06 to GSAKMP-07 December 2004


NOTE: Minor editorial modifications are not listed here.


1.  General/Global Revisions


   (a)  Wherever necessary, was more verbose in that LKH is an optional
        feature.

   (b)  Outstanding references fixed.

   (c)  Added/Modified references, both normative and informative.

   (d)  Replaced term 'trust anchor' with 'trusted policy creation
        authority'.

   (e)  Removed reference to draft policy token which is no longer in
        effect [HCLM00].


2.  Overview section now has introductory remarks to the paper.

3.  Security Considerations Section


   (a)  Security Assumptions Section


        i.  Updated information about Nonce with respect to replay attacks.


   (b)  Related Protocols - Diffie-Hellman


        i.  Updated discussion on key size to be generic to more algorithm
            types.







Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 122]

INTERNET-DRAFT                       GSAKMP                       March 2005

B.8 Changes from GSAKMP-07 to GSAKMP-08 March 2005


This draft was generated specifically to address the comments brought up
during IESG review.  In addition to addressing these comments, some of the
references were updated as some of the RFCs/Drafts had been replaced by
newer RFCs.



1.  Grp Life Cycle/Grp Est/Std Grp Est/Request to Join Section


   (a)  Added words to description that GM MUST be able to manually
        configure the destination of the RTJ.

   (b)  Fixed dissection and added words to description that Nonces are
        required and the GC/KS will determine if they will be used.

   (c)  Reordered GM resend of RTJ 3 times and GC/KS processing no more
        than one RTJ from this GM to clear up this interaction.


2.  Cryptographic Key Types Table updated to make AES the MUST instead of
    3DES.

3.  Certificate Payload Processing section Certificate Data definition was
    fixed from root CA certificate to certificate of the trusted policy
    creation authority.

4.  Identification Types was modified to add LDAP DN string representation.
    This was made the MUST type.  Security Suite 1 was updated to now use
    this type.  Reference to this document was added.


Authors Addresses

Hugh Harney (point-of-contact)
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
(410) 872-1515 ext 203
FAX (410) 872-8079
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

Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 123]

INTERNET-DRAFT                       GSAKMP                       March 2005

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

George Gross
IdentAware Security
82 Old Mountain Road
Lebanon, NJ 08833
(908) 268 - 1629
gmgross@identaware.com

Full Copyright Statement

Copyright (C) The Internet Society (2005).  This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as set
forth therein, the authors retain all their rights.

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

Document expiration:  September 17, 2005























Harney, Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-08.txt  [Page 124]


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