WDIFF

draft-ietf-msec-gsakmp-sec-04.txt --> draft-ietf-msec-gsakmp-sec-05.txt

Internet Engineering Task Force
INTERNET-DRAFT H Harney, Harney (SPARTA)
U Meth, Meth (SPARTA)
A Colegrove (SPARTA)
A Schuett (NSA)
P McDaniel (AT&T)
G Kenny (Logica)
H Cruickshank, S Iyengar (UoS)
G Gross (IdentAware)
draft-ietf-msec-gsakmp-sec-04.txt
draft-ietf-msec-gsakmp-sec-05.txt SPARTA, Inc., National Security Agency
AT&T Labs, LogicaCMG, University of Surrey IdentAware Security
Expires: April 24, August 16, 2004 February 2004 October 2003

GSAKMP

Status of this memo

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

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

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

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

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
during group establishment and recovery, capabilities to recover
from the compromise of group members, delegation of group security

INTERNET-DRAFT GSAKMP October 2003
functions, and capabilities to destroy the group. It also
generates group keys.

INTERNET-DRAFT GSAKMP February 2004

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

INTERNET-DRAFT GSAKMP October 2003 February 2004

Contents

1 Overview 8 9
1.1 GSAKMP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Protocol Considerations . . . . . . . . . . . . . . . . . . . . . . 9
1.3
1.2 Document Organization . . . . . . . . . . . . . . . . . . . . . . . 9 10

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

4 Architecture 14 15
4.1 Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.1Components . . 15
4.1.1 Components . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.2GO . 15
4.1.2 GO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.3GC/KS 16
4.1.3 GC/KS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.4Subordinate 16
4.1.4 Subordinate GC/KS . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.5GM . 17
4.1.5 GM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.6Assumptions 17
4.1.6 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 17 18
4.2 Rule-Based Security Policy . . . . . . . . . . . . . . . . . . . . 17
4.2.1Access 19
4.2.1 Access Control . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.2Authorizations 19
4.2.2 Authorizations for security relevant actions . . . . . . . . . . 19 20
4.3 Distributed Operation . . . . . . . . . . . . . . . . . . . . . . . 19 20
4.4 Concept of Operation . . . . . . . . . . . . . . . . . . . . . . . 20
4.4.1Assumptions 22
4.4.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.2Creation 22
4.4.2 Creation of a PT . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.3Creation 22
4.4.3 Creation of a Group . . . . . . . . . . . . . . . . . . . . . . 22
4.4.4Discovery 23
4.4.4 Discovery of GC/KS . . . . . . . . . . . . . . . . . . . . . . . 22
4.4.5GC/KS 23
4.4.5 GC/KS registration policy enforcement . . . . . . . . . . . . . 22
4.4.6GM 24
4.4.6 GM registration policy enforcement . . . . . . . . . . . . . . . 23
4.4.7S-GC/KS 24
4.4.7 S-GC/KS operations . . . . . . . . . . . . . . . . . . . . . . . 23 24
4.5 GSAKMP Interactions With NAT Traversal . . . . . . . . . . . . . . 24
4.5.1Non-Transparent 25
4.5.1 Non-Transparent Network Address Translation Behaviors . . . . . 24
4.5.2GSAKMP 25
4.5.2 GSAKMP Avoidance of NAT Using an IP-v6 Over IP-v4 Network . . . 25
4.5.3GSAKMP 27
4.5.3 GSAKMP Multicast IP-v4 NAT Architectural Assumptions . . . . . . 26
4.5.4Representative 28
4.5.4 Representative Example GSAKMP Multi-Realm Configuration . . . . 27
4.5.5GSAKMP 29
4.5.5 GSAKMP Registration Security Association NAT Traversal . . . . . 30
4.5.6GSAKMP 31
4.5.6 GSAKMP Re-key Security Association NAT Traversal . . . . . . . . 31
4.5.7Multicast 32
4.5.7 Multicast Application Security Association NAT Traversal . . . . 31 32
5 Group Life Cycle 32 33
5.1 Group Definition . . . . . . . . . . . . . . . . . . . . . . . . . 32 33
5.2 Group Establishment . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.1Standard 34
5.2.1 Standard Group Establishment . . . . . . . . . . . . . . . . . . 33

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

INTERNET-DRAFT GSAKMP October 2003

5.2.1.1Request to Join 34
5.2.1.1 Request to Join . . . . . . . . . . . . . . . . . . . . . . 34
5.2.1.2Key 35

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

INTERNET-DRAFT GSAKMP February 2004

5.2.1.2 Key Download . . . . . . . . . . . . . . . . . . . . . . . 35
5.2.1.3Request 37
5.2.1.3 Request to Join Error . . . . . . . . . . . . . . . . . . . 37
5.2.1.4Key 38
5.2.1.4 Key Download - Ack/Failure . . . . . . . . . . . . . . . . 37
5.2.1.5Lack 39
5.2.1.5 Lack of Ack . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.2Cookies 40
5.2.2 Cookies - Group Establishment with Denial of Service Protection 39 41
5.3 Group Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.1Rekey Events 43
5.3.1 Group Management . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.1.1 Rekey Events . . . . . . 42
5.3.2Leaving . . . . . . . . . . . . . . . . 43
5.3.2 Leaving a Group . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.2.1Eviction . 43
5.3.2.1 Eviction . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.2.2Voluntary 44
5.3.2.2 Voluntary Departure without Notice . . . . . . . . . . . . 43
5.3.2.3De-Registration . 44
5.3.2.3 De-Registration . . . . . . . . . . . . . . . . . . . . . 43
5.3.2.3.1Request 44
5.3.2.3.1 Request to Depart - . . . . . . . . . . . . . . . . . . 43
5.3.2.3.2Departure_Response 44
5.3.2.3.2 Departure_Response - . . . . . . . . . . . . . . . . . 44
5.3.2.3.3Departure_ACK 45
5.3.2.3.3 Departure_ACK - . . . . . . . . . . . . . . . . . . . . 45 46

6 Security Suite 46 47
6.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 47
6.2 Definition Suite 1 . . . . . . . . . . . . . . . . . . . . . . . . 46 47
7 GSAKMP Payload Structure 47 48
7.1 GSAKMP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.1.1GSAKMP 49
7.1.1 GSAKMP Header Structure . . . . . . . . . . . . . . . . . . . . 47
7.1.2GSAKMP 49
7.1.2 GSAKMP Header Processing . . . . . . . . . . . . . . . . . . . . 50 51
7.2 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . . 51
7.2.1Generic 52
7.2.1 Generic Payload Header Structure . . . . . . . . . . . . . . . . 51
7.2.2Generic 52
7.2.2 Generic Payload Header Processing . . . . . . . . . . . . . . . 51 53
7.3 Policy Token Payload . . . . . . . . . . . . . . . . . . . . . . . 52
7.4 Key Download 53
7.3.1 Policy Token Payload Structure . . . . . . . . . . . . . . . . 53
7.3.2 Policy Token Payload Processing . . . . . . . 53
7.5 Rekey Event Payload . . . . . . . . . 55
7.4 Key Download Payload . . . . . . . . . . . . . . . . . 54
7.6 Identification Payload . . . . . . 55
7.4.1 Key Download Payload Structure . . . . . . . . . . . . . . . . 55
7.7 Certificate Payload
7.4.1.1 Key Datum Structure . . . . . . . . . . . . . . . . . . . 57
7.4.1.2 Rekey Array Structure . . . . . 56
7.8 Signature Payload . . . . . . . . . . . . . 59
7.4.2 Key Download Payload Processing . . . . . . . . . . . . 58
7.8.1Signature Payload Structure . . . . 60
7.5 Rekey Event Payload . . . . . . . . . . . . . . 58
7.8.2Signature Payload Processing . . . . . . . . . . 61
7.5.1 Rekey Event Payload Structure . . . . . . . . 59
7.9 Notification Payload . . . . . . . . . 61
7.5.1.1 Rekey Event Header Structure . . . . . . . . . . . . . . 60
7.9.1Notification 62
7.5.1.2 Rekey Event Data - Acknowledgement (ACK) Payload Type Structure . . . . . 62
7.9.2Notification Data - Cookie_Required and Cookie Payload Type . . 62
7.9.3Notification Data - Mechanism Choices Payload Type . . . . . . . 63
7.10Key Creation Payload . 64
7.5.1.2.1 Key Package Structure . . . . . . . . . . . . . . . 65
7.5.2 Rekey Event Payload Processing . . . . . . . 64
7.10.1Key Creation Payload Structure . . . . . . . . . 65
7.6 Identification Payload . . . . . . . . . 64
7.10.2Key Creation Payload Processing . . . . . . . . . . . . . 67
7.6.1 Identification Payload Structure . . . 65
7.11Nonce Payload . . . . . . . . . . . . 67
7.6.1.1 U-NAME Structure . . . . . . . . . . . . . . . 66
7.11.1Nonce Payload Structure . . . . . 69
7.6.2 Identification Payload Processing . . . . . . . . . . . . . . . 66
7.11.2Nonce Payload 70
7.6.2.1 U-NAME Processing . . . . . . . . . . . . . . . . . . . . 67

8 GSAKMP State Diagram 68
A APPENDIX A -- Variable Length Payload Field Definitions 71
A.1 Key Download 70
7.7 Certificate Payload Fields . . . . . . . . . . . . . . . . . . . . 71
A.1.1GTEK Key Packet Fields . . . . 71
7.7.1 Certificate Payload Structure . . . . . . . . . . . . . . . . . 71
A.1.2Rekey Key Packet Fields
7.7.2 Certificate Payload Processing . . . . . . . . . . . . . . . . 72
7.8 Signature Payload . . . . 71
A.2 Signature Payload Fields . . . . . . . . . . . . . . . . . . . . . 72

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

INTERNET-DRAFT GSAKMP October 2003

A.2.1Signature ID Data Field Format
7.8.1 Signature Payload Structure . . . . . . . . . . . . . . . . . . 72

B APPENDIX B -- LKH Variable Length
7.8.2 Signature Payload Field Definitions 72
B.1 LKH Rekey Key Packet Fields Processing . . . . . . . . . . . . . . . . . 75

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

INTERNET-DRAFT GSAKMP February 2004

7.9 Notification Payload . . . 72
B.2 LKH Rekey Packet Data Format Fields . . . . . . . . . . . . . . . . 73
B.2.1Rekey Event Header . . . . 75
7.9.1 Notification Payload Structure . . . . . . . . . . . . . . . . 75
7.9.1.1 Notification Data - Acknowledgment (ACK) Payload Type . . 78
7.9.1.2 Notification Data - Cookie_Required and Cookie Payload Type 78
7.9.1.3 Notification Data - Mechanism Choices Payload Type . 73
B.2.2Rekey Event Packet Data(s) . . 79
7.9.2 Notification Payload Processing . . . . . . . . . . . . . . . . 80
7.10Key Creation Payload . 74
B.2.3Key Pack Data . . . . . . . . . . . . . . . . . . . . . . 80
7.10.1 Key Creation Payload Structure . . . 75
B.2.4Pack Data Formats . . . . . . . . . . . . . 80
7.10.2 Key Creation Payload Processing . . . . . . . . . . 75
B.2.4.1GTEK Pack Data . . . . . 82
7.11Nonce Payload . . . . . . . . . . . . . . . . . 76
B.2.4.2LKH Pack Data . . . . . . . . . . 82
7.11.1 Nonce Payload Structure . . . . . . . . . . . . . 76
B.2.5Example . . . . . . 82
7.11.2 Nonce Payload Processing . . . . . . . . . . . . . . . . . . . 83

8 GSAKMP State Diagram 85
9 IANA Considerations 88
9.1 IANA Port Number Assignment . . . 77
C APPENDIX C -- Change History 78
C.1 Changes from GSAKMP-00 to GSAKMP-01 February 2003 . . . . . . . . . 78
C.2 Changes from GSAKMP-01 to GSAKMP-02 June 2003 . . . . . . . . 88
9.2 Initial IANA Registry Contents . . . 78
C.3 Changes from GSAKMP-02 to GSAKMP-03 August 2003 . . . . . . . . . . 79
C.4 Changes from GSAKMP-03 to GSAKMP-04 October 2003 . . . . . . . . 88
9.2.1 GSAKMP Group Identification Types . 79

D References, Authors Addesses, and Acknowledgements 83
D.1 References . . . . . . . . . . . . . . 88
9.2.1.1 Amending formula for GSAKMP Group Identification Types . 89
9.2.2 GSAKMP Payload Types . . . . . . . . . . . . . 83
D.2 Authors Addresses . . . . . . . . 89
9.2.2.1 Amending formula for GSAKMP Payload Types . . . . . . . . 89
9.2.3 GSAKMP Exchange Types . . . . . . . . . 84
D.3 Acknowledgements . . . . . . . . . . . . 89
9.2.3.1 Amending formula for GSAKMP Exchange Types . . . . . . . 90
9.2.4 GSAKMP Policy Token Types . . . . . . 86

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

INTERNET-DRAFT GSAKMP October 2003

List of Figures

1 GSAKMP NAT Example . . . . . . . . . . . . . 90
9.2.4.1 Amending formula for GSAKMP Policy Token Types . . . . . 90
9.2.5 GSAKMP Key Download Data Item Types . . . . . . 29
2 GSAKMP Ladder Diagram . . . . . . . . 90
9.2.5.1 Amending formula for GSAKMP Key Download Data Item Types. 90
9.2.6 GSAKMP Encryption Types . . . . . . . . . . . . . . . 34
3 GSAKMP Ladder Diagram with Cookies . . . . . 91
9.2.6.1 Amending formula for GSAKMP Encryption Types . . . . . . 91
9.2.7 GSAKMP Rekey Event Types . . . . . 40
4 GSAKMP Header Format . . . . . . . . . . . . . . 91
9.2.7.1 Amending formula for GSAKMP Rekey Event Types . . . . . . 91
9.2.8 GSAKMP Identification Types . . . 48
5 Generic Payload Header . . . . . . . . . . . . . . . 91
9.2.8.1 Amending formula for GSAKMP Identification Types . . . . 92
9.2.9 GSAKMP Certificate Types . . . 51
6 Policy Token Payload Format . . . . . . . . . . . . . . . . 92
9.2.9.1 Amending formula for GSAKMP Certificate Types . . . . 52
7 Key Download Payload Format . . 92
9.2.10 GSAKMP Signature Types . . . . . . . . . . . . . . . . . . 53
8 Rekey Event Payload Format . . 92
9.2.10.1 Amending formula for GSAKMP Signature Types . . . . . . 92
9.2.11 GSAKMP Signature ID Types . . . . . . . . . . . . 55
9 Identification Payload Format . . . . . . 92
9.2.11.1 Amending formula for GSAKMP Signature ID Types . . . . . 93
9.2.12 GSAKMP Notification Types . . . . . . . . 56
10 Certificate Payload Format . . . . . . . . . . 93
9.2.12.1 Amending formula for GSAKMP Notification Types . . . . . 93
9.2.13 GSAKMP Acknowledgment Types . . . . . 57
11 Signature Payload Format . . . . . . . . . . . . 94
9.2.13.1 Amending formula for GSAKMP Acknowledgment Types . . . . 94
9.2.14 GSAKMP Mechanism Types . . . . . 58
12 Notification Payload Format . . . . . . . . . . . . . . . 94
9.2.14.1 Amending formula for GSAKMP Mechanism Types . . . . . 60
13 Notification Data - Acknowledge Payload Type Format . 94
9.2.15 GSAKMP Nonce Hash Types . . . . . . . 62
14 Notification Data - Mechanism Choices Payload Type Format . . . . . 63
15 Key Creation Payload Format . . . . . . . 94
9.2.15.1 Amending formula for GSAKMP Nonce Hash Types . . . . . . 95
9.2.16 GSAKMP Key Creation Types . . . . . . . 64
16 Nonce Payload Format . . . . . . . . . . . 95
9.2.16.1 Amending formula for GSAKMP Key Creation Types . . . . . 95
9.2.17 GSAKMP Nonce Types . . . . . . . 66
17 GSAKMP State Diagram . . . . . . . . . . . . . . . 95
9.2.17.1 Amending formula for GSAKMP Nonce Types . . . . . . . . 68
18 B. 1: Rekey Event Header Format 96

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

INTERNET-DRAFT GSAKMP February 2004

10 Acknowledgments 96

11 References 96
11.1 Normative References . . . . . . . . . . . . . . . . . 74
19 B. 2: Rekey Event Packet Data Format . . . . . . 96
11.2 Informative References . . . . . . . . 74
20 B. 3: Key Pack Data Format . . . . . . . . . . . . . . 97
A APPENDIX A -- LKH Information 98
A.1 LKH Overview . . . . . 75

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

INTERNET-DRAFT GSAKMP October 2003

List of Tables

1 Request to Join (RTJ) Message Definition . . . . . . . . . . . . . 35
2 Key Download (KeyDL) Message Definition . . . . . . . . . 98
A.2 LKH and GSAKMP . . . . . 36
3 Request to Join Error (RTJ-Err) Message Definition . . . . . . . . 37
4 Key Download - Ack/Failure (KeyDL-A/F) Message Definition . . . . . 38
5 Lack of Ack (LOA) Message Definition . . . . . . . . 99
A.3 LKH Examples . . . . . . . 39
6 Cookie Download Message Definition . . . . . . . . . . . . . . . . 40
7 Rekey Event Message Definition . . . . 100
A.3.1 LKH Key Download Example . . . . . . . . . . . . . . 42
8 Request_to_Depart (RTD) Message Definition . . . . . 100
A.3.2 LKH Rekey Event Example . . . . . . . . 43
9 Departure_Response (DR) Message Definition . . . . . . . . . . . . 44
10 Departure_ACK (DA) Message Definition 101

B APPENDIX B -- Change History (To Be Removed from RFC) 103
B.1 Changes from GSAKMP-00 to GSAKMP-01 February 2003 . . . . . . . . . 103
B.2 Changes from GSAKMP-01 to GSAKMP-02 June 2003 . . . . . . 45
11 Group Identification Types . . . . . 103
B.3 Changes from GSAKMP-02 to GSAKMP-03 August 2003 . . . . . . . . . . 103
B.4 Changes from GSAKMP-03 to GSAKMP-04 October 2003 . . . . . 48
12 Payload Types . . . . 104
B.5 Changes from GSAKMP-04 to GSAKMP-05 February 2004 . . . . . . . . . 108
B.5.1 Major Modification/Reorganization of Specification . . . . . . 108
B.5.1.1 Key Terms and Payloads Modified . . . . . . . . 49
13 Exchange Types . . . . . 108
B.5.2 Modification By Section . . . . . . . . . . . . . . . . . . . . 109

Authors Addresses 112

Full Copyright Statement 112

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

INTERNET-DRAFT GSAKMP February 2004

List of Figures

1 GSAKMP NAT Example . 49
14 Policy Token Types . . . . . . . . . . . . . . . . . . . . . . . 30
2 GSAKMP Ladder Diagram . 52
15 Key Download Data Types . . . . . . . . . . . . . . . . . . . . . . 54
16 Rekey Event Types 35
3 GSAKMP Ladder Diagram with Cookies . . . . . . . . . . . . . . . . 42
4 GSAKMP Header Format . . . . . . . . . 55
17 Identification Types . . . . . . . . . . . . . . 49
5 Generic Payload Header . . . . . . . . . 56
18 Certificate . . . . . . . . . . . . . 52
6 Policy Token Payload Types Format . . . . . . . . . . . . . . . . . . . . 54
7 Key Download Payload Format . 57
19 Signature Types . . . . . . . . . . . . . . . . . . . 56
8 Key Download Data Item Format . . . . . . . 59
20 Signature Types . . . . . . . . . . . . 56
9 Key Datum Format . . . . . . . . . . . . . . 59
21 Notify Payload Types . . . . . . . . . . . 58
10 Rekey Array Structure Format . . . . . . . . . . . . . . . . . . . 60
11 Rekey Event Payload Format . . . . . . . . . . . . . . . . . . . . 61
22 Acknowledgement Types
12 Rekey Event Header Format . . . . . . . . . . . . . . . . . . . . . 63
13 Rekey Event Data Format . . 62
23 Mechanism Types . . . . . . . . . . . . . . . . . . . . 64
14 Key Package Format . . . . . . 63
24 Encryption Types . . . . . . . . . . . . . . . . . . 65
15 Identification Payload Format . . . . . . . 64
25 Nonce Hash Types . . . . . . . . . . . . 68
16 Unencoded Name (U-NAME) Format . . . . . . . . . . . . . 64
26 Types Of Key Creation Information . . . . . 69
17 Certificate Payload Format . . . . . . . . . . . . 65
27 Nonce Types . . . . . . . . 71
18 Signature Payload Format . . . . . . . . . . . . . . . . . . . . 66
28 GSAKMP States . 73
19 Notification Payload Format . . . . . . . . . . . . . . . . . . . . 76
20 Notification Data - Acknowledge Payload Type Format . . . . . . 69
29 State Transition Events . . 78
21 Notification Data - Mechanism Choices Payload Type Format . . . . . 79
22 Key Creation Payload Format . . . . . . . . . . . . . . . . . 70

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

INTERNET-DRAFT . . . 81
23 Nonce Payload Format . . . . . . . . . . . . . . . . . . . . . . . 82
24 GSAKMP October 2003

1 Overview

1.1 State Diagram . . . . . . . . . . . . . . . . . . . . . . . 85
25 A. 1: LKH Tree . . . . . . . . . . . . . . . . . . . . . . . . . 99
26 A. 2: 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 LKH Tree . . . . . . . . . . . . . . . . . . . . . . 100

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

INTERNET-DRAFT GSAKMP February 2004

List of Tables

1 Request 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 Join (RTJ) Message Definition . . . . . . . . . . . . . 36
2 Key Server (GC/KS) is responsible for creating and
maintaining the keys and enforcing the group policy by granting access Download (KeyDL) Message Definition . . . . . . . . . . . . . . 37
3 Request 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 SA include

- Group policy identification

- Group policy dissemination

- GM to GC/KS SA establishment to protect data Join Error (RTJ-Err) Message Definition . . . . . . . . 38
4 Key Download - 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
[RFC2543] to transmit information about the time of the conference, the
address Ack/Failure (KeyDL-A/F) Message Definition . . . . . 39
5 Lack of the session, and the formats Ack (LOA) Message Definition . . . . . . . . . . . . . . . 40
6 Cookie Download Message Definition . . . . . . . . . . . . . . . . 41
7 Rekey Event Message Definition . . . . . . . . . . . . . . . . . . 43
8 Request_to_Depart (RTD) Message Definition . . . . . . . . . . . . 44
9 Departure_Response (DR) Message Definition . . . . . . . . . . . . 45
10 Departure_ACK (DA) Message Definition . . . . . . . . . . . . . . . 46
11 Group Identification Types . . . . . . . . . . . . . . . . . . . . 49
12 Payload Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
13 Exchange Types . . . . . . . . . . . . . . . . . . . . . . . . . . 51
14 Policy Token Types . . . . . . . . . . . . . . . . . . . . . . . . 54
15 Key Download Data Item Types . . . . . . . . . . . . . . . . . . . 57
16 Encryption Types . . . . . . . . . . . . . . . . . . . . . . . . . 59
17 Rekey Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 62
18 Identification Types . . . . . . . . . . . . . . . . . . . . . . . 68
19 Certificate Payload Types . . . . . . . . . . . . . . . . . . . . . 72
20 Signature Types . . . . . . . . . . . . . . . . . . . . . . . . . . 74
21 Signature ID Types . . . . . . . . . . . . . . . . . . . . . . . . 74
22 Notification Types . . . . . . . . . . . . . . . . . . . . . . . . 77
23 Acknowledgment Types . . . . . . . . . . . . . . . . . . . . . . . 78
24 Mechanism Types . . . . . . . . . . . . . . . . . . . . . . . . . . 79
25 Nonce Hash Types . . . . . . . . . . . . . . . . . . . . . . . . . 80
26 Types Of Key Creation Information . . . . . . . . . . . . . . . . . 81
27 Nonce Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
28 GSAKMP States . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
29 State Transition Events . . . . . . . . . . . . . . . . . . . . . . 87

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

INTERNET-DRAFT GSAKMP February 2004

1 Overview

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.

The security features of the establishment protocol for the SA include

- Group policy identification

- Group policy dissemination

- GM to GC/KS SA establishment to protect data

- Access control checking

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

INTERNET-DRAFT GSAKMP February 2004

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

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

Distributed architectures support large scale cryptographic groups. Secure
distributed architectures require authorized delegation of GSA actions to
network resources. The fully specified Policy Token is the mechanism to
facilitate this authorization. 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 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.

2 Terminology

The following terminology is used throughout the GSAKMP paper.

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

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

INTERNET-DRAFT GSAKMP February 2004

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

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

INTERNET-DRAFT GSAKMP February 2004

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

An example of a policy token is specified in [HCLM00].

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

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.

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

INTERNET-DRAFT GSAKMP February 2004

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.

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.

3.2 Related Protocols

GSAKMP derives from two (2) existing protocols: ISAKMP [MSST98] and FIPS
Pub 196 [FIPS 196]. GSAKMP MUST use Diffie-Hellman key exchange [DH77] for
two party key creation and MAY use Logical Key Hierarchy (LKH) 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.

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

INTERNET-DRAFT GSAKMP February 2004

3.2.2 FIPS Pub 196

FIPS Pub 196 provides a mutual authentication protocol.

3.2.3 LKH

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

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. Security Suite 1 defined in section 6, based on [IKEv2] Group 2,
with a strong random number generator and an exponent no less than 200 bits
is sufficient to use for 3DES. 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 like the seed to a pseudo-random generator that is
not erased after use.

3.3 Denial of Service (DoS) Attack

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

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

INTERNET-DRAFT GSAKMP February 2004

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 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 xxxx]. GSAKMP uses the MSEC components to
create a trust model for operations that implement the security principles
of mutual suspicion and trust anchors.

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-05.txt [Page 15]

INTERNET-DRAFT GSAKMP February 2004

- 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 trust
anchor for a group. All security relevant decisions and actions implemented
by GSAKMP are based on information that ultimately is traceable to and
verified by a core trust anchor. There are two pieces of the trust anchors
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 Traffic Protection Keys (TPK) 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-05.txt [Page 16]

INTERNET-DRAFT GSAKMP February 2004

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

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

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 TPK. It is assumed here that the group
will transmit data with a single TPK at any one time. This TPK 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
GCKS, 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-05.txt [Page 17]

INTERNET-DRAFT GSAKMP February 2004

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 used. For 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 large-scale video 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, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 8] 18]

INTERNET-DRAFT GSAKMP October 2003

transmission, February 2004

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 organizer might use of the key is only relevant, in
a multicast announcement protocol like
SAP [RFC2974].

This document describes a useful default set security sense, if it represents the successful enforcement of the group
security algorithms and
configurations, Security Suite 1. This suite allows an entire set policy.

Group operations lend themselves to rule-based security policy. The need
for distribution of
algorithms and settings data to be described many endpoints often leads to prospective group members in the defining of
those authorized endpoints based on rules. For example, all IETF attendees
at a
concise manner. Other security suites MAY given conference could be defined as needed and MAY a single group.

If the security policy rules are to be
disseminated during relevant, they must be coupled with
validation mechanisms. The core principle here is that the out-of-band announcement level of trust
one can afford a group.

Distributed architectures support large scale cryptographic groups. Secure
distributed architectures require authorized delegation security policy is exactly equal to the level of GSA actions trust one
has in the validation mechanism used to
network resources. 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 trust anchor (PKI root) that is authorized to identify someone
as being an IETF attendee. The fully specified Policy Token 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 mechanism entity that issues
that revocation SHOULD signal the GO, so that the GO can expel that GM.
The method that signals this event to
facilitate the GO is not standardized by this authorization. Trasmission
specification.

A direct mapping of this Policy Token rule to all
joining GMs validation mechanism 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 use of a policy token multiple
rules and
policy payloads allow group members PKIs to review the 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 and
authorization parameters. This member review process gives each member
(each potential source of data), policy for the ability group keys is equivalent to determine if the group
provides adequate protection access
control policy for member data.

1.2 Protocol Considerations

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

1.3 Document Organization

The remainder of this document keys are protecting.

In a group, each data source is organized as follows: Section 5.2.1.5
presents responsible for ensuring that the terminology and concepts used access
to present the requirements source's data is appropriate. This implies that every data source
should have knowledge of
this protocol. Section 3 outlines the security considerations with respect
to GSAKMP. Section 5 describes access control policy for the group management life-cycle. Section 6
describes the Security Suite Definition. Section 7 presents keys.

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

INTERNET-DRAFT GSAKMP February 2004

In the message
types general case, GSAKMP offers a suite of security services to its
applications, and formats used during each phase does not prescribe how they use those services.

GSAKMP supports the creation of GSAs with multiple data sources. It also
supports architectures where the life-cycle. Section 8
defines GC/KS is not itself a data source. In
the state diagram for multiple data source architectures GSAKMP requires that the protocol.

2 Terminology access
control policy is precisely defined and distributed to each data source.
The following terminology reference for this data structure is used throughout the GSAKMP paper.

Certificate: Policy Token [ref TBD].

4.2.2 Authorizations for security relevant actions

A data structure used to verifiably bind an identity to a

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

INTERNET-DRAFT critical aspect of the GSAKMP October 2003

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

Compromise Recovery: The act trust model is the authorization of security
relevant actions. Security relevant actions include - download of recovering a secure operating state
after detecting that a group member cannot be trusted. This can
key, rekey, and PT creation and updates. These actions could be
accomplished used to
disrupt the secure group and all entities in the group must verify that they
were instigated by rekey.

Cryptographic Group: A set of authorized entities sharing or desiring to share within the group.

4.3 Distributed Operation

Scalability is a
GSA.

Group Controller Key Server (GC/KS): A group member with authority core feature of GSAKMP. GSAKMP's approach to
perform critical protocol actions including creating and distributing
keys and building and maintaining scalable
operations is the rekey structures. As establishment of S-GC/KSs. This allows the group
evolves, it MAY become desirable GSAKMP systems
to have multiple controllers perform
these functions.

Group Member (GM): A Group Member distribute the workload of setting up and managing very large groups.

Another aspect of distributed S-GC/KS operations is any entity with access the enabling of local
management authorities. In very large groups, subordinate enclaves may be
best suited to provide local management of the enclaves' group
keys. Regardless of how a member becomes membership,
due to a part direct knowledge of the group or how members.

One of the
group critical issues involved with distributed operation is structured, GMs will perform the following actions:

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

- Accept group keys from the GC/KS

- Request suite. Many
group keys from applications that have dynamic interactions must "find" each other
to operate. The discovery of the GC/KS

- Enforce security infrastructure is just another
piece of information that has to be known by the cooperative group policies as stated in the group
policy token order to operate
securely.

There are several methods for infrastructure discovery:

- Perform peer review of key management actions Announcements

- Manage local local key

Group Owner (GO): A Group Owner Anycast

- Rendezvous points / Registration

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

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

INTERNET-DRAFT GSAKMP February 2004

new multicast application or service. If an authenticatable policy token for the group, and
notifying application uses SAP[Ref RFC
2974] to announce the GC/KS existence of a service on a multicast channel, that
service could be extended to start include the security infrastructure location
for a particular group.

Group Policy:

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 Group Policy completely describes the protection
mechanisms and security relevant behaviors of multicast source controls the group. This policy
MUST be commonly understood and enforced packet's multicast range
by explicitly setting its Time To Live count.

An expanding ring announcement operates by the group GC/KS announcing its
existence for coherent
secure operations.

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

Group Traffic Encryption Key (GTEK): a locally configured number. The key or keys created GMs would listen
on a well know multicast address for
encrypting the group data.

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

INTERNET-DRAFT GSAKMP October 2003

Logical Key Hierarchy (LKH) Array: The group GC/KSs that provide service for groups
of keys created to
facilitate interest. If multiple GC/KSs are found that provide service, then the LKH compromise recovery methodology.

Policy Token:
GM would pick the closest one (in terms of multicast hops). The policy token is GM would
then send a data structure used GSAKMP Request to Join message (RTJ) to disseminate
group policy and the mechanisms announced GC/KS.
If the announcement is found to enforce it. be spurious then that is reported to the
appropriate management authorities. The policy token ERA concept is issued and signed by an authorized source. Each member slightly different
from SAP in that it could occur over the data channel multicast address,
instead of a special multicast address dedicated for the
group MUST verify SAP service.

An expanding ring search operates in the reverse order than the ERA. In
this case, the token, meet GM is the group join policy, and enforce announcing entity. The (S-)GC/KSs listen for the policy of
requests for service, specifically the group, (e.g., encrypt application data with a
specific algorithm). RTJ. 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

An example of a policy token (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 specified in [HCLM00].

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

Subordinate Group Controller Key Server (S-GC/KS): Any group member having service that is very similar to ERS. It also can be used to
provide connection to the appropriate processing and trust characteristics as defined in security infrastructure. In this case, the
group policy that has GM
would send the potential RTJ to act as a S-GC/KS. well-known service request address. This will allow anycast
service would route the group processing RTJ to an appropriate GC/KS. The anycast service
would have security infrastructure and communication requirements network connectivity knowledge to
facilitate this connection.

Registration points can be distributed
equitably throughout 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 network (e.g., distribute group key). application being supported already supports registration.
The
optional use of GSAKMP with Subordinate Group Controller Key Servers
will be documented in infrastructure can always provide a separate paper.

3 Security Considerations

In addition to registration site if the specification
existence of GSAKMP itself, the this security infrastructure discovery hub is needed. The
registration of S-GC/KSs at this site could be an
implemented efficient way to allow GM
registration.

GSAKMP system is affected by supporting factors. These are infrastructure discovery can use whatever mechanism suits a
particular multicast application's requirements, including mechanisms
that have not been discussed here. by this architecture. However, GSAKMP

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 11] 21]

INTERNET-DRAFT GSAKMP October 2003

3.1 Security February 2004

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 following assumptions are made as the basis most basic assumption here is one or more trustworthy PKI for the group.
That trusted PKI will be used to create and verify security discussion

1. GSAKMP assumes its supporting platform can provide 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 process GO public
key.

All GMs have access to the GO PKI information, both the trusted anchor
public keys and data
separation services at the appropriate assurance level to support its
groups.

2. certificate path validation rules.

There is sufficient connectivity between the GSAKMP entities.

- The key generation function of registration SA requires that GM can connect to the cryptographic engine will only
generate strong keys.

3. GC/KS or S-GC/KS
using either TCP or UDP.

- The security of this protocol is critically dependent on the randomness
of rekey SA requires that the randomly chosen parameters. These should data layer multicast communication
service be generated by a
strong random available. This can be multicast IP, overlay networks using
TCP, or properly seeded pseudo-random source.

3.2 NAT tunnels.

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

4.4.2 Creation of Other Protocols

GSAKMP is based upon two (2) existing protocols: ISAKMP [MSST98] a PT

The GO creates and FIPS
Pub 196 [FIPS 196]. GSAKMP MAY use Diffie-Hellman key exchange [DH77] signs the Policy Token for
two party key creation a group. The policy token
contains the rules for access control and MAY use LKH authorizations for rekey capability.

3.2.1 ISAKMP

ISAKMP provides a flexible structure particular
group.

The PT consists of chained payloads in support the following information:

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

INTERNET-DRAFT GSAKMP February 2004

- Identification - this allows an unambiguous identification of
authenticated key exchange the PT and security association management for pairwise
communications. GSAKMP builds upon
the group,

- Access Control Rules - these features to provide policy
enforcement features in support of diverse group communications.

3.2.2 FIPS Pub 196

FIPS Pub 196 provides a mutual authentication protocol.

3.2.3 LKH

GSAKMP relies upon a rekey capability, i.e., LKH, rules specify who can have access to enable the
group recovery
after keys,

- Authorization Rules - these rules specify who can be a compromise.

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

INTERNET-DRAFT GSAKMP October 2003

3.2.4 Rekey Availability

In addition to GSAKMP having S-GC/KS,

- Mechanisms - these rules specify the capability to do rekey operations, GSAKMP
MUST aslo have security mechanisms that will be
used by the capability to make group, this rekey information available is necessary to
GMs. The necessity of GMs receiving rekey messages, requires ensure there is no weak link in
the use group security profile

- Source authentication of
methods to increase the likelyhood of receipt of Rekey Messages. These
methods MAY include multiple transmissions of PT to the rekey message, posting of GO - the rekey message on PT is a bulliten board, etc.

3.2.5 Diffie-Hellman

GSAKMP MAY rely upon two party key creation mechanisms, i.e.,
Diffie-Hellman, CMS signed
object and this allows all GMs to protect sensitive data during download. verify the PT

4.4.3 Creation of a Group

The information in this section PT is borrowed heavily from [IKEv2] as this
protocol has already worked through this issue sent to a potential GC/KS. This can occur in several ways, and GSAKMP
the method of transmittal is using outside the
same security considerations for its purposes. This section will contain
paraphrased sections scope of [IKEv2] modified for GSAKMP as appropriate. GSAKMP. The strength of a key derived potential
GC/KS will verify the GO signature on the PT to ensure that it comes from a Diffie-Hellman exchange using specific
p and g values depends on
trusted GO. Next, the inherent strength of GC/KS will verify that it is authorized to become the values,
GC/KS, based on the size of authorization rules in the exponent used, and PT. Assuming that the entropy provided by GC/KS
trusts the random number generator
used. Security Suite 1 defined in section 6, based on [IKEv2] Group 2,
with PT, is authorized to be a strong random number generator GC/KS, and an exponent no less than 200 bits is sufficient locally configured to use
become a GC/KS for 3DES. An implementation should make note of this
conservative estimate when establishing policy a given group 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 GO, then the strength obtained from stronger values.
In fact, GC/KS will create the extensible framework of GSAKMP encourages
keys necessary to start the definition of
more Security Suites.

It group. The GC/KS will take whatever action 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 like the seed
necessary (if any) to a pseudo-random generator that is
not erased after use.

3.3 Denial of Service (DoS) Attack

This GSAKMP specification addresses advertise its ability to distribute key for the mitigation group.
The GC/KS will then listen for RTJs.

The PT has a distributed IP
spoofing attack (a subset of possible DoS attacks) in section 5.2.2,
Cookies.

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

INTERNET-DRAFT GSAKMP October 2003

3.4 Proof of Trust Hierarchy

As defined by [HCM], security group policy MUST be defined in sequence number. Every time a verifiable
manner. GSAKMP anchors its trust in PT is distributed to the creator of group
the group, group members verify that the GO.

The Policy Token explicitly defines all sequence number on the parameters that create a secure
verifiable infrastructure. PT is increasing.
The GSAKMP Policy Token PT lifetime is issued and signed not limited to a particular time interval, other than
by the GO. lifetimes imposed by some of its attributes (e.g. signature key
lifetime). The GC/KS will verify it and grant access current PT sequence number is downloaded to GMs only if they meet the rules of GM in the Policy Token.
"Key Download" message. Also, to avoid replay attacks, you should indicate
that 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 new GO must
preserve this sequence number across re-boots.

4.4.4 Discovery of GC/KS

Potential GMs will accept access only if 1)
the token verifies, 2) the GC/KS is an authorized disseminator, and 3) receive notice of the new group mechanisms are acceptable for protecting via some mechanism:
announcement, Anycast, registration look-up. The GM will send an RTJ to the GMs data.

4 Architecture

This architecture presents a trust model for
GC/KS.

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

INTERNET-DRAFT GSAKMP and a concept February 2004

4.4.5 GC/KS registration policy enforcement

The GC/KS may or may not require cookies, depending on Denial of
operations for establishing a trusted distributed infrastructure for group
key Service
environment and policy distribution.

GSAKMP conforms to the IETF MSEC architectural concepts as specified in local configuration.

Once the
MSEC Architecture document [RFC xxxx]. GSAKMP uses RTJ has been received, the GC/KS will verify that the MSEC components GM is allowed
to have access to
create a trust model for operations that implement the security principles
of mutual suspicion and trust anchors.

4.1 Trust Model

4.1.1 Components group keys. The trust model contains four key components:

- Group Owners (GO),

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

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

- Group Members (GM).

The goal of will then verify the GSAKMP trust model is signature
on the RTJ to derive trust from ensure it was sent by the claimed identity. If the checks
succeed, the GC/KS will ready a common trust
anchor Key Download message for the GM. If not the
GC/KS can notify the GM of a group. All security non-security relevant decisions and actions implemented
by GSAKMP are based on information that ultimately is traceable to and
verified by a core trust anchor. There are two pieces problem.

4.4.6 GM registration policy enforcement

Upon receipt of the trust anchors
for GSAKMP, Key Download message, the GO (policy creation authority) and GM will verify the PKI root that allows

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

INTERNET-DRAFT GSAKMP October 2003

us to signature
on the message. Then the GM will retrieve the PT from the Key Download
message and verify that the GO.

4.1.2 GO

The GO is created and signed the policy creation authority for PT. Once the group. The GO has a well
defined identity PT is
verified as valid, the GM will verify that the GC/KS is relevant authorized to the
distribute key for this group. That identity can be of a
person or of a group trusted component. All potential entities Then the GM will verify that the mechanisms
used in the group
have to recognize the GO as the individual with authority to specify policy are available and acceptable for the group.

The policy reflects the protection requirements 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.
Ultimately, If the data and GM is allowed to be a S-GC/KS AND the application environment drives local GM configuration
allows the security
policy GM to act as a S-GC/KS for this group, then the group. GM changes
its operating state to S-GC/KS. The GO has needs to determine the security rules and mechanisms that are
appropriate for the data being protected by assign the group keys. All this
information is captured authority to
become a S-GC/KS in a policy token (PT). The GO creates manner that supports 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 overall group membership management. integrity and
operations.

4.4.7 S-GC/KS operations

As key creation authority, a S-GC/KS, the GC/KS host will create the set of keys for the
group. These now distribute keys include the Traffic Protection Keys (TPK) and the PT. The first tier
rekey keys. There may be second tier rekey trees if a distributed rekey
management structure action
is required for the group.

As the key distribution (registration) authority, it has to notify the
group potential GMs of its location for registration services. The GS/KS will have ability to
enforce distribute key access control for the
group. This can be accomplished in exactly the same manner as part of the key distribution GC/KS
notifications.

The S-GC/KS may be authorized to be a local management GC and registration
processes.

As the group rekey authority, as such, it performs
can be authorized to create its own rekey in order trees. There are several ways
to change architect S-GC/KS operations that include rekey trees. Rekey operations
with S-GC/KSs can use:

- the
group's TPK. Change of S-GC/KS to distribute the TPK limits rekey arrays generated at the exposure of data encrypted with
any single TPK.

Finally, as group membership management authority, GC/KS,

- the GC/KS S-GC/KS can manage the
group membership (registration, eviction, de-registration, etc.). This may
be done in part by using key create and distribute it's sub tree approaches such as Logical Key Hierarchies
(LKH). and report those
keys back to the GC/KS, The GSAKMP message that sends those keys from

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 15] 24]

INTERNET-DRAFT GSAKMP October 2003

4.1.4 Subordinate GC/KS

A subordinate GC/KS is used to distribute February 2004

the GC/KS functionality across
multiple entities. The S-GC/KS will have all the authorities of to the GC/KS
except one: it will is not create standardized in this version of the TPK. It is assumed here that
specification. or

- the group
will transmit data with a single TPK at any one time. This TPK comes from S-GC/KS can act as an independent rekey authority passing on the GC/KS.

Note that relative
group keys to its subscribers.

In the GC/KS, independent mode of operation, the S-GC/KS is responsible holds the rekey key it
received upon group registration. It will then create rekey messages for an
additional security check:
its subscribers using the S-GC/KS must register as a member with rekey key it creates.

Once the notification mechanisms have been activated and key trees created,
the
GCKS, and during that process it has to verify S-GC/KS waits for RTJs. GMs will join the authority of group via the GC/KS.

4.1.5 GM S-GC/KS. The GM has two jobs - make sure all
S-GC/KS will then manage its rekey group based on notification of local
rekey needs.

4.5 GSAKMP Interactions With NAT Traversal

GSAKMP security relevant actions are authorized association endpoints services may straddle any combination
of IP-v4 public addresses and properly use the group keys. During the registration process, private addresses [RFC1918]. In such cases,
GSAKMP endpoint identifiers may be embedded within the GM
will verify that GSAKMP policy token's
security association Security Policy Database (SPD) traffic selector rules.
These GSAKMP endpoint identifiers when resolved to their equivalent private
or public IP-v4 addresses entangle the PT is signed by a recognized GO. GSAKMP protocol with Network Address
Translation (NAT) [RFC2663] [RFC3022] gateway behaviors. In addition, it will
verify that
the GC/KS or S-GC/KS engaged in NAT translation of IP-v4 header addresses also impacts the GSAKMP
registration process is
authorized, as specified in SA, the PT. If rekey GSAKMP re-key SA, and new PTs are distributed
to the group, multicast application SA.

This section defines the GM will verify GSAKMP mechanisms that they are proper partially mitigate
the inherent complexity spawned by IP-v4 NAT and all actions are
authorized. Network Address Port
Translation (NAPT) traversal. However, given the large number of
documented NAT problems and its erosion of end-to-end security, [reference
okazaki-v6ops-natpt-security-00.txt] new GSAKMP applications and deployments
SHOULD strongly prefer the use of IP-v6. This specification offers IP-v4 to
IP-v6 transitional guidance in support of that objective.

4.5.1 Non-Transparent Network Address Translation Behaviors

The GM is granted access following NAT side effects are known to group data through receipt of the group keys
This carries along interact 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
protocol and its enforcement
depend three security association types (Registration, Rekey, and
Data Layer (specifically IPSec in this example):

The following NAT behavior adversely impacts source-specific secure
multicast IPSec groups. When a NAT gateway is on the path between a
multicast application source endpoint residing behind a NAT and its protocols. However, GSAKMP
does allow a group public IP-v4 multicast
destination, the NAT alters the private source address to have one of three Group a public IP-v4
address. This translation must be coordinated with every GSAKMP IPSec

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

INTERNET-DRAFT GSAKMP February 2004

receiver's inbound Security Association Policy Database (SPD) multicast
speaker configurations:

- There is entries that
uses that source address as a single GM authorized traffic selector [RFC2401bis]. In addition
to be its impact on the group's speaker. There
is one inbound SPD, this NAT behavior also impacts the
source-specific multicast application SA allocated by routing. The GCKS must set up the GO in support of GSAKMP receiver
with a SPD entry that speaker. anticipates the value(s) that the NAT translates the
packet's source address. However, there are known cases where this address
translation can change without warning:

- NAT gateways may re-boot and lose their address translation state
information.

- The NAT gateway may de-allocate its address translation state after
an inactivity timer expires. The PT initializes this multicast application SA and
identifies address translation used by the GM NAT
gateway after the resumption of data flow may differ than that has been authorized known 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
default group configuration. SPD selectors at the GSAKMP implementations MUST support this
configuration. endpoints.

- The GO authorizes all GCKS may not have global consistent knowledge 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 GSAKMP endpoint's
current public and indicates that any GM
can be private address mappings due to network errors or
race conditions. For example, an endpoint's address may change due to
a speaker. All DHCP assigned address lease expiration.

- Alternate paths may exist between a given pair of GSAKMP endpoints.
If there are parallel NAT gateways along those paths, then the GM share address
translation state information at each NAT gateway may produce different
translations on a per packet basis.

- When multiple multicast source endpoints reside behind a NAT with a
single TPK and other SA state
information. Consequently, some SA security features such as sequence
number checking for anti-replay protection public IP-v4 address, the NAT gateway can not do UDP or TCP
port translation (i.e. NAPT) because the ESP encryption conceals the
transport layer protocol headers. The use of UDP encapsulated ESP [ref
XXXXX] avoids this problem. However, this capability must be configured
at the GCKS as a group policy, and it must be supported in unison by

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

INTERNET-DRAFT all
of the GSAKMP October 2003 endpoints within the group, even those that reside in the
public Internet. Note that at the time of this configuration. GSAKMP implementations MUST support writing this group
configuration. solution
has IPR.

- The GO authorizes In a subset of transport mode multicast application SA, the GM to be a group speaker (which UDP checksum operation
may be require the subset comprised origin endpoint's IP address to complete successfully.
In IKE-v2 [IKE-v2], this information is exchanged between the endpoints
by a NAT-OA payload (NAT original address). See section X.Y of all GM). The GO allocates
reference [ipsec-nat-t-v03.txt]. A comparable facility must exist in a distinct
GSAKMP PT payload that defines the multicast application SA attributes
for each of these speakers. multicast source endpoint.

- The PT identifies GSAKMP receiver endpoints must authenticate the
authorized speakers, and initializes each source of their multicast application
Security Associations. all key
management packets and they must not trust a packet's IP addresses or
port numbers.

- The speakers still share presence of a common TPK across
their SA, but each speaker has NAT gateway makes it impossible to use an
Authentication Header, keyed by 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 group-wide key, to protect the

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

INTERNET-DRAFT GSAKMP February 2004

integrity of the IP header, from individuals within the cryptographic
group.

4.5.2 GSAKMP Avoidance of NAT Using an IP-v6 Over IP-v4 Network

A straight forward and standards-based architecture that require per speaker state at effectively
avoids the
receiver. The drawback GSAKMP use of this configuration NAT gateways is the IP-v6 over IP-v4 transition
mechanism [RFC2529]. In IP-v6 over IP-v4 (a.k.a. "6over4"), the underlying
IP-v4 network is treated as a virtual multicast-capable Local Area
Network. The IP-v6 traffic tunnels over that it does not scale
to IP-v4 virtual link layer.
Applying GSAKMP in a large numbers of speakers. 6over4 architecture leverages the fact that an
administrative domain deploying GSAKMP implementations MAY support this
group configuration.

4.1.6 Assumptions would already be planning to deploy
IP-v4 multicast router(s). The assumptions for this trust model are:

- the GCKS is assumed GSAKMP group's IP-v6 multicast routing
can execute in parallel to be never compromised,

- IP-v4 multicast routing on that same physical
router infrastructure. In particular, the GO is assumed to be never compromised,

- NAT gateways at administrative
domain public/private boundaries are replaced by IP-v6 multicast routers
operating with 6over4 mode enabled on their network interfaces. This
yields a substantial reduction in complexity and error cases over the PKI, subject
NAT-based approaches. This reduction in complexity can translate into
better security. The following factors may effect the decision to certificate validation, is assumed deploy
GSAKMP 6over4 rather than GSAKMP with IP-v4 NAT:

When traversing NAT, application layer protocols that contain IP-v4
addresses in their payload need the intervention of an Application Layer
Gateway (ALG) that understands that application layer protocol [RFC3027]
[RFC3235]. The ALG massages the payload's private IP-v4 addresses into
equivalent public IP-v4 addresses. However, when encrypted by end-to-end
ESP such payloads are opaque to be
trustworthy,,

- application layer gateways.

The GO is capable primary drawback of creating a security policy the GSAKMP 6over4 approach is that the secure
multicast application must be (re-)written to meet an IP-v6 multicast socket API
or equivalent, and it must interact with the demands Multicast Listener Discovery
(MLD) API [reference vida-mld-v2-07.txt] [reference magma-msf-api-05.txt]
rather than IGMP. For new applications, this may not be of consequence; it
usually only becomes an issue if the group,

- the compromises application has an embedded base. An
embedded base of a group member GSAKMP multicast IP-v4 applications that are only available
in binary form will not be detectable and reported able to the
GO in a trusted manner,

- the subsequent recovery from a compromise will deny inappropriate access migrate to protected data these transitional IP-v6
mechanisms.

The secondary drawbacks of GSAKMP 6over4 are that the IP hosts must be
upgraded to dual-stack, the compromised member,

- no security relevant actions depend on a precise attendant overlay IP-v6 multicast network time,

- that there
operational costs, and the difficulty of finding commercial wide-area IP-v6
multicast services.

Reliable scalable GSAKMP 6over4 deployment is confidentiality, integrity, far more practical than
GSAKMP/NAT. In particular, new GSAKMP multicast source authentication
and anti-replay protection mechanisms for all applications should prefer
GSAKMP control messages,

4.2 Rule-Based Security Policy 6over4. However, GSAKMP supports either choice.

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

INTERNET-DRAFT GSAKMP February 2004

4.5.3 GSAKMP Multicast IP-v4 NAT Architectural Assumptions

To make the GSAKMP NAT interaction problem tractable to a solution, this
specification makes the following simplifying assumptions:

The trust model for secure multicast group destination address is a statically allocated
public IP-v4 multicast address known to all GSAKMP revolves around the definition and enforcement
of endpoints.

Wherever they are present in the security policy. In fact, GSAKMP policy token, GSAKMP IPSec endpoint
identifiers are expressed as permanent IP-v6 "6to4" addresses [RFC3056] to
assure that the use GSAKMP endpoints that refer to hosts assigned private IP-v4
addresses are globally unique.

The GCKS resides within one of the key is only relevant, in

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

INTERNET-DRAFT GSAKMP October 2003

a security sense, if private networks, but it represents the successful enforcement also has a
permanent public IP-v4 address on at least one of the group
security policy.

Group operations lend themselves to rule-based security policy. its network interfaces.
The need
for distribution of data GCKS domain name RR record should point to many endpoints often leads that public IP-v4 address,
and it should be protected by DNS-SEC.

Each private address space has one or more NAT gateways directly connected
to the defining of
those authorized endpoints based on rules. For example, all IETF attendees
at IP-v4 public Internet, and a given conference could packet does not have to traverse
multiple private networks to reach the public Internet. This can be defined thought
of as a single group.

If "spoke and hub" configuration wherein the security policy rules public Internet is the
hub.

Each of an administrative domain's NAT gateways are to be relevant, they must be coupled explicitly configured
with
validation mechanisms. static private/public address translation mappings for the GCKS's
GSAKMP re-key multicast UDP packets inbound from the public Internet
[RFC2588].

The NAT gateways/firewalls are explicitly configured with stateless filter
rules that simply pass through without any address translation the group's
inbound multicast application packets arriving from the public Internet.
The core principle here is that NAT gateway does not translate the level of trust
one can afford multicast application packet's public
multicast IP destination address into a security policy is exactly equal to private IP multicast address.

In the level of trust one
has in outbound direction, NAT gateways generally translate the validation mechanism used multicast
application packet's private source IP address into a dynamically selected
public IP address. Exceptions to prove that policy. For example, if
all IETF attendees this policy for source specific multicast
are allowed in then they could register their identity
from their certificate upon check noted in to the meetings. That certificate is
issued by subsequent sections.

Within each administrative domain, a trust anchor (PKI root) that is authorized to identify someone
as being an IETF attendee. The GO could make admittance rules to the IETF
group multicast routing protocol domain
routes packets based on the identity certificates issued from trusted PKIs.

If a GM group's destination multicast public key certificate is revoked, then the entity that issues
that revocation SHOULD signal IP-v4
address. The multicast routers will distribute the GO, so that group's packets to all
of the GO can expel group's GSAKMP endpoints residing in that GM. administrative domain. The method that signals this event to the GO is not standardized by this
specification.

A direct mapping
border routers of rule to validation mechanism allows the use each of multiple
rules the administrative domains spanned by the group do
cross-realm multicast routing and PKIs to create groups. This allows distribution on behalf of the group. The
IP-v4 multicast routers that exchange reachability information regarding the
group across trust boundaries authenticate that information.

GSAKMP IPSec group security associations are end-to-end transport mode,

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

INTERNET-DRAFT GSAKMP February 2004

rather than tunnels terminated at a GO to define combined NAT/security gateway [RFC2709].

4.5.4 Representative Example GSAKMP Multi-Realm Configuration

Figure 1 illustrates a representative group "Z" wherein a GSAKMP group
security policy that association spans multiple PKI domains, each with their own
Certificate Authority two private IP-v4 networks and the public key certificate.

4.2.1 Access Control IP-v4
Internet. The access control policy for Group "Z" GCKS has two network interfaces, one attached to
the group keys is equivalent public Internet and the other interface attached to the access
control policy for administrative
domain "B" private network.

The group members GM1 and GM2 reside within the multicast application data administrative domain "A"
private network. They communicate with the keys are protecting.

In a group, each data GCKS and the group Z multicast
source is responsible for ensuring that endpoint(s) through the access administrative domain "A" NAT gateway. When
GM1 or GM2 send multicast application SA traffic to the source's data is appropriate. This implies group Z public
multicast address, the Group Z peer members (i.e. GM3, GM4, GM5, and GM6)
receive that every data multicast with the source
should have knowledge of address translated by NAT gateway
"A" processing. In the inverse direction, the administrative domain "A" NAT
gateway/firewall must be configured to allow Group Z multicast application
SA and re-key SA traffic to enter the access control policy for private network "A" from the public
Internet (e.g. a multicast originating from GM6).

The group keys.

In members GM5 and GM6 reside within the general case, GSAKMP offers a suite of security services administrative domain "B"
private network. Their interactions with Group Z are very similar to its
applications, those
discussed for members GM1 and does not prescribe how GM2. The only difference is that they use those services.

GSAKMP supports
private addresses when communicating with the creation of GSAs GCKS, as they are both in
private network "B".

The group members GM3 and GM4 are in a public Internet administrative domain
operated by an ISP. They communicate with multiple data sources. It also
supports architectures where the GC/KS is not itself GCKS using public IP-v4
addresses without passage through a data source. In NAT gateway. When GM3 or GM4 send
multicast application SA traffic to the group Z public multicast address,
the Group Z peer members behind NAT gateways receive that multicast with the multiple data
source architectures address unchanged by NAT processing.

Each administrative domain operates an IP-v4 multicast routing domain
instance. The multicast routers distribute both GSAKMP re-key event
messages and multicast application SA data traffic. The multicast routing
for group "Z" peers between these three multicast routing domains.

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

INTERNET-DRAFT GSAKMP February 2004

. .
"A" Admin Domain . ISP Admin Domain . "B" Administrative domain
+-------------------.---------------------.-----------------------------+
! . .
!
! P U B L.I C I P - v 4 . I N T E R N E T
!
! . .
!
+-------/\\----------.-----A-------A----A--.---------/\\--------------/\\--+

!! public . ! ! ! . !! public !!
!! IP-v4 . ! ! ! . !! IP-v4 !!
+-------\\/--------+ . ! ! ! . +-------\\/--------+
+---\\/--+
! NAT gateway ! . ! ! ! . ! Group "Z" ! !NAT
"B"!
! domain A ! . ! ! ! . ! GSAKMP requires that the access
control policy is precisely defined and distributed to each data source.
The reference for this data structure is the GCKS !
!gateway!
+---A------A----A-+ . ! ! ! . +-A------A------A-+
+---A---+
! ! ! . ! ! ! . ! ! ! !
registration SA! . registration SA ! . registration SA ! !
! ! ! . ! ! ! . ! ! ! !
+-V-+ +-V-+ ! . +-V-+ +-V-+ ! . +-V-+ +-V-+ ! !
!GM1! !GM2! ! . !GM3! !GM4! ! . !GM5! !GM6! ! !
+-A-+ +-A-+ ! . +-A-+ +-A-+ ! . +-A-+ +-A-+ ! !
! ! ! . ! ! ! . ! ! ! !
Group data/rekey SA . Group data/rekey SA . Group data/rekey Sec. Assoc.
! ! ! . ! ! ! . ! ! ! !
+-V------V----V-+ . +---V-------V----V+ . +-V------V------V-------V--+
! Group "Z" ! . ! Group "Z" ! . ! Group "Z" !
! multicast ! . ! multicast ! . ! multicast !
!routing domain ! . ! routing domain ! . ! routing domain !
+---------------+ . +-----------------+ . +--------------------------+
. .
. .

Figure 1: GSAKMP Policy Token [ref TBD]. NAT Example

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 18] 30]

INTERNET-DRAFT GSAKMP October 2003

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

4.5.5 GSAKMP Registration Security Association NAT Traversal

This class of GSAKMP unicast messages are exchanged between a
new multicast application or service. If an application uses SAP[Ref RFC
2974] to announce GCKS in
the existence of a service on public IP-v4 Internet and a multicast channel, group member that
service could may be extended to include the security infrastructure location
for in a particular group.

Announcements can also be used by private
network. The following GSAKMP in one of two modes - Expanding
Ring Searches (ERS) of security infrastructure message types are sent and expanding ring searches
for infrastructure discovery. In either case, received over
the GSAKMP would use registration security association as UDP packets with an authenticated
payload:

- Request-To-Join

- Key Download - This message contains a
multicast broadcast Policy Token that would slowly increase in its range by incremental
multicast hops. The includes a
multicast source controls application SA initialization payload. If IPSec is used, this
includes IPSec SPD traffic selector rules that refer to GSAKMP endpoint
identifiers. It also contains the packet's multicast range

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

INTERNET-DRAFT re-key SA initialization payload,
which also refers to GSAKMP October 2003

by explicitly setting its Time To Live count.

An expanding ring announcement operates by IPSec endpoint identifiers. These IPSec
endpoint identifiers may require translation or other processing before
they are used in the GC/KS announcing its
existence for a particular group. The number of hops this announcement
would travel would be IPSec Security Policy Database.

- Notification - Request To Join Acknowledge/Negative Acknowledge

- Request-To-Depart

- Departure-Response

- Notification - Departure Acknowledgment

A group member sends a locally configured registration SA GSAKMP message to the GCKS public
IP-v4 address and the GSAKMP reserved port number. The GMs would listen
on group member assigns
a well know multicast address for GC/KSs that provide service unique GSAKMP UDP source port number for groups
of interest. If multiple GC/KSs are found each GSAKMP registration SA
that provide service, then the
GM would pick the closest one (in terms of multicast hops). it participates in. The GM would
then group member MUST send a the GSAKMP Request UDP packet
without a checksum to Join message (RTJ) avoid NAT alterations to that field. The UDP packet's
transmission error detection depends on the announced GC/KS.
If GSAKMP signature payload. A
NAT gateway on the announcement is found path leading to be spurious the GCKS translates the private source IP
address and source UDP port number into a public address and a temporary UDP
port number (assuming NAPT), then that is reported forwards the packet to the
appropriate management authorities. GCKS. The ERA concept is slightly different
from SAP in NAT
gateway creates state information for that public/private address mapping so
it could occur over can do the data channel multicast address,
instead of a special multicast address dedicated for inverse translation on the SAP service.

An expanding ring search operates in GSAKMP messages sent from the reverse order than GCKS
to that group member.

The GCKS must process the ERA. In
this case, GSAKMP messages that it receives from group
members originating from any source IP address or source port number, even
if those two values have changed since the last time that the GCKS had
interacted with a given group member. This could cause problems if the GM
GC/KS is operating in the announcing entity. The (S-)GC/KSs listen for mandatory cookie exchange mode. To identify the
requests for service, specifically
group member, the RTJ. The (S-)GC/KS responds to GCKS MUST use the
RTJ. . If GSAKMP signature payload's identifying
information and validate the GM receives more than one message's digital signature.

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

INTERNET-DRAFT GSAKMP February 2004

After processing a message from a group member that requires a GCKS
response, it would either ignore the responses or send NACKs based on local configuration.

Anycast is a service GCKS creates the GSAKMP UDP message destined for the same
IP-v4 address and UDP port that is very similar to ERS. It also can be used to
provide connection to the security infrastructure. In this case, GCKS found in the GM
would send group member message's
source IP address and UDP source port.

4.5.6 GSAKMP Re-key Security Association NAT Traversal

The GCKS multicasts the RTJ GSAKMP Re-key Event message to the re-key SA in a well-known service request
UDP packet addressed to group's destination public IP-v4 multicast address. This anycast
service would route
Both the RTJ UDP source port and the UDP destination port are set to an appropriate GC/KS. the GSAKMP
reserved port number. The anycast service
would have security infrastructure UDP checksum is optional. The GCKS sends two
copies of the GSAKMP Re-key Event message, one originating from its public
Internet interface, 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 other copy originating from one of groups. There
is no reason its private
network interfaces. Group members behind a NAT gateway will receive the
Re-key Event message unchanged provided that GSAKMP could not use the same approach for advertising intervening NAT gateway has
been configured correctly to allow the existence packet through without translation.

4.5.7 Multicast Application Security Association NAT Traversal

Each such SA has a group-wide unique SPI, its own sequence number, and location of
associated group keying material. Unlike the security infrastructure. This is a simple
process if Re-key Event message multicast
to the re-key SA, a multicast application being supported already supports registration.
The message sent to the group may
originate from a GSAKMP infrastructure can always provide endpoint located behind a registration site if NAT gateway. Since the
existence of this security infrastructure discovery hub
application's message is needed. The
registration of S-GC/KSs at this site could be encrypted within an efficient way to allow GM
registration.

GSAKMP infrastructure discovery ESP payload, the transport
layer protocol header port fields are concealed from NAT gateways and
they can use whatever mechanism suits a
particular multicast application's requirements, including mechanisms
that have not been discussed by this architecture. However, GSAKMP
infrastructure discovery is not standardized by this version of participate in NAPT. The multicast application IPSec SA
must be handled differently depending on whether the GSAKMP
specification.

4.4 Concept of Operation application requires
source-specific multicast.

If the application requires IPSec source-specific multicast routing, then
there must be a separate public IP-v4 address statically reserved at the NAT
gateway for each multicast source endpoint private/public address mapping.
This concept of operation shows how constraint allows the different roles in GSAKMP interact GCKS to set up specify at every group member the inbound
SPD traffic selector with a secure pre-determined public source address for each
multicast source GSAKMP endpoint in the group. This particular concept of operation focuses on a
secure group The traffic selector's
public source address in combination with the group's destination multicast
address and SPI selects the inbound SA. Keeping the NAT gateway's source
address mapping static rather than dynamic also allows the multicast
routers along the packet's path to apply source-specific routing policies.
Note that utilizes the distributed key dissemination services use of a static source address mapping NAT avoids the

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

INTERNET-DRAFT GSAKMP October 2003

S-GC/KS.

4.4.1 Assumptions

The most basic assumption here is one or more trustworthy PKI need
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 token to specify UDP encapsulated ESP. The GCKS SPD
configuration database must be securely pre-configured to know kept synchronized with the GO public
key.

All GMs have access to group's NAT
gateway address mapping configurations.

If source-specific multicast routing is not required by the GO PKI information, both application,
then the trusted anchor NAT gateway's source address translation can use dynamically
allocated public keys and the certificate path validation rules.

There is sufficient connectivity between the IP-v4 addresses rather than statically allocated IP-v4

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

INTERNET-DRAFT GSAKMP entities.

- The registration SA requires that GM can connect to February 2004

addresses. However, unless the group uses UDP encapsulated ESP, then
the GC/KS or S-GC/KS
using either TCP or UDP.

- The rekey SA requires NAT gateway must have a pool of public IP-v4 addresses reserved that
is at least as large as the data layer number of multicast communication
service be available. source GSAKMP endpoints
within its private network. This can be multicast IP, overlay networks using
TCP, or allows the NAT tunnels.

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

4.4.2 Creation of gateway to do a PT

The GO creates and signs the Policy Token for one-to-one
mapping from every GSAKMP endpoint's private source address to a group. dynamically
allocated public source address. The policy token
contains GCKS specifies the rules for access control and authorizations for a particular
group.

The PT consists of SPD inbound traffic
selector as the following information:

- Identification - this allows an unambiguous identification combination of the PT group's destination multicast address 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 SPI.

In some deployments, the group, this is necessary number of public IP-v4 addresses assigned to ensure there a NAT
gateway is no weak link in
the group security profile

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

INTERNET-DRAFT GSAKMP October 2003

- Source authentication of the PT very limited (e.g. only one public address). Also, it may be
difficult to predict how many multicast source endpoints will reside within
the GO - private network before the PT is a CMS signed
object and this allows all GMs to verify group begins its operation. For these cases,
the PT

4.4.3 Creation of a Group group MAY use UDP encapsulated ESP. The PT is sent NAT gateway applies NAPT to a potential GC/KS. This can occur in several ways, and the method of transmittal is outside
UDP header's source port field, sidestepping the scope constraint of GSAKMP. its limited
public address pool. The potential
GC/KS will verify the GO signature on GCKS modifies the PT group policy token to ensure specify
that it comes from the outbound SPD processing must pre-append a
trusted GO. Next, UDP header in front of
the GC/KS will verify that ESP header. When a GSAKMP endpoint originates a multicast application
packet, it is authorized to become the
GC/KS, based on the authorization rules inserts a UDP header in front of the PT. Assuming that the GC/KS
trusts the PT, is authorized to be a GC/KS, and is locally configured to
become ESP header, as per reference
[XXXXX].

5 Group Life Cycle

The management of a GC/KS for cryptographic group follows a given life-cycle: group
definition, group establishment, and security relevant group maintenance.
Group definition involves defining the GO, then the GC/KS will create the
keys parameters necessary to start the group. The GC/KS will take whatever action support
a secure group, including its policy token. Group establishment is
necessary (if any) the
process of granting access to advertise its ability new members. Security relevant group
maintenance messages include rekey, policy changes and member deletion.
Each of these life-cycle phases is discussed in the following sections.

5.1 Group Definition

A cryptographic group is established to distribute key for the group.
The GC/KS will then listen for RTJs. support secure communications among
a group of individuals. The PT has activities necessary to create a sequence number. Every time Policy Token
in support of a PT is distributed to the cryptographic group include

- Determine Access Policy - identify the group members verify entities that are authorized to
receive the sequence number on the PT is increasing.
The PT lifetime is not limited group key.

- Determine Authorization Policy - identify which entities are authorized
to a particular time interval, other than
by perform security relevant actions, including key dissemination,
policy creation, and initiation of security management actions.

- Determine Mechanisms - define the lifetimes imposed algorithms and protocols used by some of its attributes (e.g. signature key
lifetime). The current PT sequence number is downloaded

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

INTERNET-DRAFT GSAKMP February 2004

GSAKMP to secure the GM in group.

- Create Group Policy Token - format the
"Key Download" message. Also, to avoid replay attacks, you should indicate
that this sequence number is never reset to policies and mechanisms into a lower value (i.e. rollover
Policy Token and apply the GO signature.

5.2 Group Establishment

GSAKMP Group Establishment consists of three mandatory-to-implement
messages, the Request to
zero) as long as Join, the group identifier remains valid Key Download, and in use. the Key Download
Ack/Failure. The GO must
preserve this sequence number across re-boots.

4.4.4 Discovery of GC/KS

Potential GMs will receive notice 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 new group via some mechanism:
announcement, Anycast, registration look-up. The GM will send an RTJ error messaging is referred to the
GC/KS.

4.4.5 GC/KS registration policy enforcement

The GC/KS may or may not require cookies, depending on as "Verbose Mode". GSAKMP
implementations MUST support Terse Mode and MAY support Verbose Mode. Group
Establishment is discussed in Section 5.2.1.

For Denial of Service
environment and protection, a Cookie Exchange MAY precede the local configuration.

Once 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 RTJ has been received, first error encountered while processing the GC/KS will verify that message.

5.2.1 Standard Group Establishment

After the GM 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 allowed then permitted to have access create any needed
group keys and begin to establish the group keys. group.

The GC/KS will then verify the signature
on the RTJ GSAKMP Ladder Diagram, Figure 2, is presented to ensure it was sent by illustrate the claimed identity. If
process of establishing a cryptographic group. The left side of the checks
succeed,
diagram represents the GC/KS will ready a Key Download message for actions of the GM. If not GC/KS. The right side of the
GC/KS can notify diagram
represents the GM actions of a non-security relevant problem.

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

INTERNET-DRAFT GSAKMP October 2003

4.4.6 the GMs. The components of each message shown in
the diagram are presented in sections 5.2.1.1 - 5.2.1.5.

The Request to Join message is sent from a potential GM registration policy enforcement

Upon receipt of to the Key Download message, GC/KS to
request admission to the GM will verify cryptographic group. The message contains key
creation material, freshness data, an optional selection of mechanisms, and
the signature
on the message. Then the GM will retrieve the PT from of the GM.

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 sent from the GC/KS is authorized to
distribute key for this group. Then the GM will verify that in response
to an accepted Request to Join. This GC/KS-signed message contains the mechanisms
identifier of the GM, freshness data, key creation material, encrypted keys,
and the encrypted Policy Token. The Policy Token is used in to facilitate
well-ordered group creation and MUST include the group's identification,
group are available permissions, group join policy, group controller key server identity,
group management information, and acceptable for protection digital signature of the GMs
data (assuming the GM is a data source). The GM will then accept membership
in this group.

The GM GO. This will then check

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

INTERNET-DRAFT GSAKMP February 2004

CONTROLLER Mandatory/ MESSAGE MEMBER
Optional
!<-M----------Request to see if it is allowed Join-------------!
<Process RTJ> ! !
!--M----------Key Download--------------->!
! ! <Process KeyDL>
!--O-------Request to be a S-GC/KS for this
group. If 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 2: GSAKMP Ladder Diagram

allow the GM to determine whether group policy is compatible with local
policy.

The Request to Join Error message is allowed sent from the GC/KS to be a S-GC/KS AND the local GM configuration
allows in
response to an unaccepted Request to Join. This message is not signed
by the GM GC/KS for two reasons: 1) The GM, at this point, has no knowledge
of who is authorized to act as a S-GC/KS for this group, then GC/KS and so the GM changes its
operating state to S-GC/KS. The GO needs signature would thus be
meaningless to take care when assigning the
authority GM, and 2) Signing responses to become an S-GC/KS.

4.4.7 S-GC/KS operations

As denied join requests
would provide a S-GC/KS, denial of service potential. The message contains an
indication of the host will now distribute keys and error condition.

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

The first action Lack_of_Ack message is to notify sent from the potential GMs of its ability GC/KS to distribute key for the
group. This can be accomplished GM in exactly the same manner as the GC/KS
notifications. response to an
invalid or absent Key Download Ack/Failure message. The S-GC/KS may be authorized signed message
contains freshness and status data and is used to be warn the GM of impending
eviction from the group if a local management GC valid Key Download Ack/Failure is not sent.

For the following message structure sections, details about payload format
and as such, it processing can be authorized found in Section 7.

5.2.1.1 Request to create its own rekey trees. There Join

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

As shown by Figure 2, a potential GM MUST generate and send an RTJ message
to architect S-GC/KS operations that include rekey trees. Rekey operations
with S-GC/KSs can use:

- the S-GC/KS request permission to distribute join the rekey arrays generated at group. As defined in the GC/KS,

- dissection of
the S-GC/KS can create and distribute it's sub tree and report those
keys back RTJ message, this message MUST contain payloads to hold the GC/KS, The following

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

INTERNET-DRAFT GSAKMP message that sends those keys from
the S-GC/KS February 2004

Table 1: Request to the GC/KS is not standardized in this version Join (RTJ) Message Definition

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

SigM : Signature of the
specification. Group Member
Cert : Necessary Certificates, zero or

- the S-GC/KS can act as more
{}SigX :Indicates fields used in Signature
[] : Indicate an independent rekey authority passing on the
group keys to its subscribers.

In the independent mode optional data item

information: Key Creation payload for KEK generation and Nonce payload
for freshness. The Nonce_I value MUST be saved for later use. An OPTIONAL
Notification payload of operation, type Mechanism Choices MAY be included to identify
the S-GC/KS holds mechanisms the rekey key it
received upon group registration. It GM wants to use. Absence of this payload will then create rekey messages for
its subscribers using the rekey key it creates.

Once cause the notification
GC/KS to select appropriate mechanisms have been activated and key trees created,
the S-GC/KS waits for RTJs. GMs will join the group via Key Download.

In response, the S-GC/KS. The
S-GC/KS will then manage its rekey group GC/KS accepts or denies the request based on notification of local

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

INTERNET-DRAFT GSAKMP October 2003

rekey needs.

4.5 GSAKMP Interactions With NAT Traversal

GSAKMP security association endpoints services
configuration. <Process RTJ> indicates the GC/KS actions that may straddle any
combination of IP-v4 public addresses and private addresses [RFC1918].
In such cases, GSAKMP endpoint identifiers may be embedded within will
determine if the
GSAKMP policy token's security association Security Policy Database (SPD)
traffic selector rules. These GSAKMP endpoint identifiers when resolved
to their equivalent private or public IP-v4 addresses entangle RTJ will be acted upon. The following checks SHOULD be
performed in the GSAKMP
protocol with Network Address Translation (NAT) [RFC2663] [RFC3022] gateway
behaviors. order presented.

In addition, the NAT translation of IP-v4 header addresses also
impacts this procedure, the GSAKMP registration SA, GC/KS MUST verify that the GSAKMP re-key SA, message header is properly
formed and the multicast
application SA.

This section defines the GSAKMP mechanisms confirm that partially mitigate
the inherent complexity spawned this message is for this group by IP-v4 NAT and Network Address Port
Translation (NAPT) traversal. However, given checking the large number of
documented NAT problems and its erosion value
of end-to-end security, [reference
okazaki-v6ops-natpt-security-00.txt] new GSAKMP applications and deployments
SHOULD strongly prefer the use of IP-v6. This specification offers IP-v4 to
IP-v6 transitional guidance in support GroupID. If the header checks pass, then the identity of that objective.

4.5.1 Non-Transparent Network Address Translation Behaviors

The following NAT side effects are known the sender
is extracted from the Signature payload. This identity MUST be used to interact with
perform access control checks, find the GSAKMP
protocol and its three security association types (Registration, Rekey, GMs credentials (e.g. certificate)
for message verification, and
Data Layer (specifically IPSec MUST also be used in this example):

The following NAT behavior adversely impacts source-specific secure
multicast IPSec groups. When a NAT gateway is the Key Download message.
Then the GC/KS will verify the signature on the path between a
multicast source endpoint residing behind a NAT message to ensure its
authenticity. The GC/KS MUST use verified and trusted authentication
material from a public IP-v4 multicast
destination, known root. If the NAT alters message signature verifies, the private source address to a public IP-v4
address. This translation must be coordinated with every GSAKMP IPSec
receiver's inbound Security Policy Database (SPD) multicast entries that
uses GC/KS
then confirms that source address 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.

NOTE: At any one time, a traffic selector [RFC2401bis]. In addition GC/KS MUST process no more that one (1) valid RTJ
message from a single GM per group.

If the GM receives no response to its impact on the inbound SPD, this NAT behavior also impacts RTJ within the
source-specific multicast routing. The GCKS must set up GM's locally configured
timeout value, the GSAKMP receiver
with a SPD entry that anticipates GM SHOULD resend the value(s) that RTJ message up to three (3) times.

If any error occurs during RTJ message processing, and the NAT translates GC/KS is
running in Terse mode, the
packet's source address. However, there are known cases where this address
translation can change without warning:

NAT gateways may re-boot session MUST be terminated and lose their address translation state
information.

The NAT gateway may de-allocate its address translation all saved state after an
inactivity timer expires.
information MUST be cleared.

The address translation used by the NAT gateway OPTIONAL Notification payload of type Cookie is discussed in section

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 24] 36]

INTERNET-DRAFT GSAKMP October 2003

after the resumption of data flow may differ than that known to the SPD
selectors at the GSAKMP endpoints. February 2004

5.2.2.

5.2.1.2 Key Download

The GCKS may not have global consistent knowledge components of a GSAKMP endpoint's
current public and private address mappings due to network errors or race
conditions. For example, an endpoint's address may change due to a DHCP
assigned address lease expiration.

Alternate paths may exist between a given pair of GSAKMP endpoints. If
there Key Download Message are parallel NAT gateways along those paths, then the address
translation state information at each NAT gateway may produce different
translations on a per packet basis.

When multiple multicast source endpoints reside behind a NAT with a single
public IP-v4 address, the NAT gateway can not do UDP or TCP port translation
(i.e. NAPT) because the ESP encryption conceals the transport layer
protocol headers. The use 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)*} SigC,
[Cert]
Payload Types : GSAKMP Header, Identification, Nonce, Key
Creation, Policy Token, Key Download, Signature,
[Certificate]

SigC : Signature of UDP encapsulated ESP [ref XXXXX] avoids this
problem. However, this capability must be configured at the GCKS as 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 group
policy, properly formed and it must be supported in unison by all of verified RTJ message, the GSAKMP endpoints
within GC/KS
creates and sends the group, even those that reside KeyDL message. As defined in the public Internet. Note that
at the time dissection of this writing this solution has IPR.

In a transport mode multicast application SA, the UDP checksum operation
may require
the origin endpoint's IP address to complete successfully. In
IKE-v2 [IKE-v2], message, this information is exchanged between the endpoints by
a NAT-OA payload (NAT original address). See section X.Y of reference
[ipsec-nat-t-v03.txt]. A comparable facility must exist in a GSAKMP PT
payload that defines message MUST contain payloads to hold the multicast application SA attributes following
information: GM identification, Nonce payloads for each
multicast source endpoint.

The GSAKMP receiver endpoints must authenticate the source of all freshness, Key Creation
material, encrypted Policy Token, encrypted key
management packets information, and they must not trust a packet's IP addresses or port
numbers. signature
information.

The presence of a NAT gateway makes it impossible to use an Authentication
Header, keyed nonce values transmitted MUST be the GC/KSs generated Nonce_R value and
the combined Nonce_C value which was generated by a group-wide key, to protect using the integrity of GC/KSs Nonce_R
value and the IP
header, Nonce_I value received from individuals within the cryptographic group.

4.5.2 GSAKMP Avoidance of NAT Using an IP-v6 Over IP-v4 Network

A straight forward and standards-based architecture that effectively
avoids GM in the GSAKMP use of NAT gateways RTJ.

If two party key determination is used, the IP-v6 over IP-v4 transition
mechanism [RFC2529]. In IP-v6 over IP-v4 (a.k.a. "6over4"), key creation material supplied
by the underlying
IP-v4 network GM and/or the GC/KS will be used to generate the key. Generation of
this key is treated dependant on t he key exchange, as a virtual multicast-capable Local Area
Network. defined in Section 7.10, Key
Creation Payload. The IP-v6 traffic tunnels over that IP-v4 virtual link layer.
Applying GSAKMP Policy Token and key material are encrypted in a 6over4 architecture leverages the fact that an
administrative domain deploying GSAKMP would already
generated key.

The GM MUST be planning able to deploy
IP-v4 multicast router(s). process the Key Download message. <Process KeyDL>
indicates the GM actions that will determine how the Key Download message
will be acted upon. The GSAKMP group's IP-v6 multicast routing
can execute following checks SHOULD be performed in parallel to IP-v4 multicast routing on that same physical

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

INTERNET-DRAFT GSAKMP October 2003

router infrastructure. the order
presented.

In particular, this procedure, the NAT gateways at administrative
domain public/private boundaries are replaced 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 IP-v6 multicast routers
operating with 6over4 mode enabled on their network interfaces. This
yields a substantial reduction in complexity and error cases over comparing the
NAT-based approaches. This reduction Member ID in complexity can translate into
better security. The following factors may effect the decision
Identification payload to deploy
GSAKMP 6over4 rather than its identity. After identification confirmation,

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

INTERNET-DRAFT GSAKMP with IP-v4 NAT:

When traversing NAT, application layer protocols that contain IP-v4
addresses in their payload need February 2004

the intervention of an Application Layer
Gateway (ALG) that understands that application layer protocol [RFC3027]
[RFC3235]. freshness values are checked. The ALG massages GM MUST use its save Nonce_I value,
extract the payload's private IP-v4 addresses into
equivalent public IP-v4 addresses. However, when encrypted by end-to-end
ESP such payloads are opaque received GC/KS Nonce_R value, compute the combined Nonce_C value,
and compare it to application layer gateways.

The primary drawback of the GSAKMP 6over4 approach received Nonce_C value. After freshness is that confirmed,
the secure
multicast application must signature MUST be (re-)written verified to an IP-v6 multicast socket API
or equivalent, ensure its authenticity, The GM MUST use
verified and it must interact with trusted authentication material from a known root. If the Multicast Listener Discovery
(MLD) API [reference vida-mld-v2-07.txt] [reference magma-msf-api-05.txt]
rather than IGMP. For new applications, this may not be of consequence; it
usually only becomes an issue if
message signature verifies, the application has an embedded base. An
embedded base of GSAKMP multicast IP-v4 applications that are only available
in binary form will not be able key creation material is extracted from the
Key Creation payload to migrate generate the KEK. This KEK is then used to these transitional IP-v6
mechanisms. decrypt
the Policy Token data. The secondary drawbacks of GSAKMP 6over4 are that signature on the IP hosts must policy token MUST be
upgraded verified.
Access control checks MUST be performed on both the GO and the GC/KS to dual-stack,
determine both their authorities within this group. After all these checks
pass, the attendant overlay IP-v6 multicast network
operational costs, KEK can then be used to decrypt and process the difficulty of finding commercial wide-area IP-v6
multicast services.

Reliable scalable GSAKMP 6over4 deployment key material from
the Key Download payload. If all is far more practical than
GSAKMP/NAT. In particular, new GSAKMP multicast applications should prefer
GSAKMP 6over4. However, GSAKMP supports either choice.

4.5.3 GSAKMP Multicast IP-v4 NAT Architectural Assumptions

To make successful, the GSAKMP NAT interaction problem tractable to a solution, this
specification makes GM will create and send
the following simplifying assumptions: Key Download - Ack/Failure message as described in section 5.2.1.4.

The secure multicast 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 destination address 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, and the GM is running
in Terse mode, the session MUST be terminated, the GM MUST send a statically allocated
public IP-v4 multicast address known Key
Download - Ack/Failure message with a Notification Payload of type NACK to
indicate termination, and all GSAKMP endpoints.

Wherever they saved state information MUST be cleared.

5.2.1.3 Request to Join Error

The components of the Request to Join Error Message are present shown in the GSAKMP policy token, 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}
Payload Types : GSAKMP IPSec endpoint
identifiers are expressed as permanent IP-v6 "6to4" addresses [RFC3056] Header, Nonce, Notification

In response to
assure that an unacceptable RTJ, the GSAKMP endpoints that refer GC/KS MAY send a Request to hosts assigned private IP-v4
addresses are globally unique.

The GCKS resides within one of Join
Error (RTJ-Err) message containing an appropriate Notification payload.
Note that the private networks, but it also has RTJ-Err message is not a
permanent public IP-v4 address signed message for the following
reasons: the lack of awareness on at least one the GM's perspective of its network interfaces.

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

INTERNET-DRAFT GSAKMP October 2003

The GCKS domain name RR record should point who is a valid
GC/KS as well as the need to that public IP-v4 address, protect the GC/KS from signing messages and it should be protected by DNS-SEC.

Each private address space has one or more NAT gateways directly connected
to
using valuable resources. Following the IP-v4 public Internet, sending of an RTJ-Err, the GC/KS
MUST terminated the session and a packet does not have to traverse
multiple private networks to reach all saved state information MUST be cleared.

Upon receipt of an RTJ-Err message, the GM will validate the following:
the GroupID in the public Internet. This can be thought
of as header belongs to a "spoke and hub" configuration wherein group to which the public Internet is GM has sent an
RTJ, and the
hub.

Each of Nonce_I matches a Nonce_I sent in an administrative domain's NAT gateways RTJ to that group. If
the above checks are explicitly configured
with static private/public address translation mappings for successful, the GCKS's
GSAKMP re-key multicast UDP packets inbound from GM MAY terminate the public Internet
[RFC2588].

The NAT gateways/firewalls are explicitly configured state associated
with stateless filter
rules that simply pass through without any address translation the group's
inbound multicast application packets arriving from the public Internet. GroupID and Nonce. The NAT gateway does not translate the multicast application packet's public
multicast IP destination address into a private IP multicast address.

In the outbound direction, NAT gateways generally translate the multicast
application packet's private source IP address into GM SHOULD be capable of receiving a dynamically selected
public IP address. Exceptions to this policy valid

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

INTERNET-DRAFT GSAKMP February 2004

KeyDownload message for source specific multicast 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 components of the Key Download - Ack/Failure Message are noted shown in subsequent sections.

Within each administrative domain,
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}SigM
Payload Types : GSAKMP Header, Nonce, Notification, Signature
SigM : Signature of Group Member
{}SigX :Indicates fields used in Signature

In response to a multicast routing protocol domain
routes packets based on the group's destination multicast public IP-v4
address. The multicast routers will distribute properly processed KeyDL message, the group's packets to all
of GM creates and sends
the group's GSAKMP endpoints residing KeyDL-A/F message. As defined in that administrative domain. The
border routers of each of the administrative domains spanned by the group do
cross-realm multicast routing and distribution on behalf dissection of the group. The
IP-v4 multicast routers that exchange reachability information regarding message, this
message MUST contain payloads to hold the
group across trust boundaries authenticate that information.

GSAKMP IPSec group security associations are end-to-end transport mode,
rather than tunnels terminated at a combined NAT/security gateway [RFC2709].

4.5.4 Representative Example GSAKMP Multi-Realm Configuration

Figure 1 illustrates a representative group "Z" wherein a GSAKMP group
security association spans two private IP-v4 networks following information: Nonce
payload for freshness, Notification payload of type Acknowledgment (ACK).
and signature information. The nonce value transmitted MUST be the public IP-v4
Internet. GMs
generated Nonce_C value.

The Group "Z" GCKS has two network interfaces, one attached GC/KS MUST be able to process the public Internet and KeyDL-A/F message. <Process
KeyDL-A/F> indicates the other interface attached to GC/KS actions that will determine how the administrative
domain "B" private network.
KeyDL-A/F message will be acted upon. The group members GM1 and GM2 reside within the administrative domain "A"
private network. They communicate with the GCKS and the group Z multicast
source endpoint(s) through following checks SHOULD be
performed in the administrative domain "A" NAT gateway. When
GM1 or GM2 send multicast application SA traffic to order presented.

In this procedure, the group Z public

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

INTERNET-DRAFT GSAKMP October 2003

multicast address, GC/KS will verify that the Group Z peer members (i.e. GM3, GM4, GM5, message header is properly
formed and GM6)
receive confirm that multicast with the source address translated this message is for this group by NAT gateway
"A" processing. In checking the inverse direction, value
of the administrative domain "A" NAT
gateway/firewall must be configured to allow Group Z multicast application
SA and re-key SA traffic to enter GroupID. If the private network "A" from header checks pass, the public
Internet (e.g. a multicast originating from GM6). GC/KS MUST check the message
for freshness. The group members GM5 GC/KS MUST use its saved Nonce_C value, and GM6 reside within compare it
to the administrative domain "B"
private network. Their interactions with Group Z are very similar received Nonce_C value. After freshness is confirmed, the signature
MUST be verified to those
discussed for members GM1 and GM2. ensure its authenticity, The only difference is that they GC/KS MUST use
private addresses when communicating with verified and
trusted authentication material from a known root. If the GCKS, as they are both in
private network "B".

The group members GM3 message signature
verifies, the GC/KS processes the Notification payload. If the notification
type is of type ACK, then the GC/KS and GM4 are in GM have established a public Internet administrative domain
operated by an ISP. They communicate with GSA.

If the GCKS using public IP-v4
addresses without passage through GC/KS does not receive a NAT gateway. When GM3 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 GM4 send
multicast application SA traffic to if no KeyDL-A/F message is received within the group Z public multicast address,
locally configured timeout, the Group Z peer members behind NAT gateways receive that multicast with GC/KS MUST remove this GM from the
source address unchanged by NAT processing.

Each administrative domain operates an IP-v4 multicast routing domain
instance. The multicast routers distribute both GSAKMP re-key event
messages group
and multicast application SA data traffic. handle according to policy. The multicast routing
for group "Z" peers between these three multicast routing domains. GC/KS MAY send the OPTIONAL Lack_of_Ack
message if running in Verbose Mode as defined in section 5.2.1.5.

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 28] 39]

INTERNET-DRAFT GSAKMP October 2003

!! public . ! ! ! . !! public !!
!! IP-v4 . ! ! ! . !! IP-v4 !!
+-------\\/--------+ . ! ! ! . +-------\\/--------+
+---\\/--+
! NAT gateway ! . ! ! ! . ! Group "Z" ! !NAT
"B"!
! domain A ! . ! ! ! . ! February 2004

5.2.1.5 Lack of Ack

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} SigC, [Cert]
Payload Types : GSAKMP GCKS !
!gateway!
+---A------A----A-+ . ! ! ! . +-A------A------A-+
+---A---+
! ! ! . ! ! ! . ! ! ! !
registration SA! . registration SA ! . registration SA ! !
! ! ! . ! ! ! . ! ! ! !
+-V-+ +-V-+ ! . +-V-+ +-V-+ ! . +-V-+ +-V-+ ! !
!GM1! !GM2! ! . !GM3! !GM4! ! . !GM5! !GM6! ! !
+-A-+ +-A-+ ! . +-A-+ +-A-+ ! . +-A-+ +-A-+ ! !
! ! ! . ! ! ! . ! ! ! !
Group data/rekey SA . Group data/rekey SA . Group data/rekey Sec. Assoc.
! ! ! . ! ! ! . ! ! ! !
+-V------V----V-+ . +---V-------V----V+ . +-V------V------V-------V--+
! Group "Z" ! . ! Group "Z" ! . ! Header, Identification, Nonce,
Notification, Signature, [Certificate]

SigC : Signature of Group "Z" !
! multicast ! . ! multicast ! . ! multicast !
!routing domain ! . ! routing domain ! . ! routing domain !
+---------------+ . +-----------------+ . +--------------------------+
. .
. .

Figure 1: GSAKMP NAT Example 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, Nonce payloads for
freshness, Notification of error, and signature information.

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.

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

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 29] 40]

INTERNET-DRAFT GSAKMP October 2003

4.5.5 February 2004

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 Registration Security Association NAT Traversal is copying this concept. This class section will contain
paraphrased sections of [IKEv2] modified for GSAKMP unicast messages are exchanged between a GCKS in to define the public IP-v4 Internet 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 a group member that may be Simpson [RFC 2522] in a private
network. Photuris,
an early proposal for key management with IPSec. The following GSAKMP ISAKMP fixed message types are sent
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 received over CPU exhaustion, where the registration security association as UDP packets
target GC/KS is flooded with an authenticated
payload:

- Request-To-Join

- Key Download - Request to Join requests from forged IP
addresses. This message contains a Policy Token that includes attack can be made less effective if a
multicast application SA initialization payload, including IPSec SPD
traffic selector rules that refer GC/KS implementation
uses minimal CPU and commits no state to GSAKMP endpoint identifiers. It
also contains the re-key SA initialization payload, communication until it knows
the initiator potential GM can receive packets at the address from which also refers
it claims to
GSAKMP IPSec endpoint identifiers.

- Notification - Request be sending them. To accomplish this, the GC/KS when operating
in Cookie mode, SHOULD reject initial Request to Join Acknowledge/Negative Acknowledge

- Request-To-Depart

- Departure-Response

- messages unless they
contain a Notification - Departure Acknowledgement

A group member sends payload of type "cookie". It SHOULD instead send
a registration SA GSAKMP Cookie Download message as a response to the GCKS public
IP-v4 address RTJ and the GSAKMP reserved port number. The group member assigns include a unique GSAKMP UDP source port number for each GSAKMP registration SA
that it participates in. The group member MUST send the GSAKMP UDP packet
without cookie in
a checksum to avoid NAT alterations to that field. The UDP packet's
transmission error detection depends on the GSAKMP signature payload. A
NAT gateway on notify payload of type Cookie_Required. Potential GMs who receive such
responses MUST retry the path leading Request to Join message with the GCKS translates responder GC/KS
supplied cookie in its notification payload of type Cookie, as defined by
the private source IP
address and source UDP port number into a public address and a temporary UDP
port number (assuming NAPT), then forwards optional Notification payload of the packet Request to Join Msg as defined in
section 5.2.1.1. This initial exchange will then be as shown in Figure 3
with the GCKS. The NAT
gateway creates state information for that public/private address mapping so
it can do the inverse translation on components of the new message Cookie Download shown in Table 6.

Table 6: Cookie Download Message Definition

Message Name : Cookie Download
Dissection : {HDR-GrpID, COOKIE_REQUIRED}
Payload Types : GSAKMP messages sent from the GCKS
to that group member. Header, Notification

The GCKS must process the GSAKMP first two messages that it receives from group
members originating from do not affect any source IP address GM or source port number, even
if those two values have changed since the last time that the GCKS had
interacted with a given group member. This could cause problems if the GC/KS is operating in the mandatory cookie exchange mode. To identify the
group member, the GCKS MUST use state except for
communicating the cookie.

A GSAKMP signature payload's identifying
information and validate the message's digital signature.

After processing a message from a group member that requires implementation SHOULD implement its GC/KS cookie generation in such
a GCKS
response, the GCKS creates way as to not require any saved state to recognize its valid cookie when
the GSAKMP UDP second Request to Join message destined for the same
IP-v4 address arrives. The exact algorithms and UDP port that the GCKS found in the group member message's 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.

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 30] 41]

INTERNET-DRAFT GSAKMP October 2003

source IP address and UDP source port.

4.5.6 GSAKMP Re-key Security Association NAT Traversal

The GCKS multicasts the February 2004

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 3: GSAKMP Re-key Event message Ladder Diagram with Cookies

A good way to do this is to set the re-key SA in cookie to be:

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

where <secret> is a
UDP packet addressed randomly generated secret known only to group's destination public IP-v4 multicast address.
Both the UDP source port responder
GC/KS and periodically changed, Ni is the UDP destination port are set to Nonce value taken from the GSAKMP
reserved port number. The UDP checksum
initiator potential GM, IPi is optional. The GCKS sends two
copies the supposed IP of the GSAKMP Re-key Event message, one originating from its public
Internet interface, initiator potential
GM. <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 other copy originating from one of its private
network interfaces. Group members behind a NAT gateway will receive cookie in the
Re-key Event message unchanged provided that received message. If
it matches, the intervening NAT gateway has responder GC/KS knows that all values have been configured correctly to allow computed
since the packet through without translation.

4.5.7 Multicast Application Security Association NAT Traversal

Each such SA has a group-wide unique SPI, its own sequence number, last change to <secret> and
associated group keying material. Unlike 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 Re-key Event Cookie_Download message multicast
to the re-key SA, cannot
successfully forge a multicast application message sent "Request to Join with Cookie Info" message. This Ni
value MUST be the group may
originate same Ni value from a GSAKMP endpoint located behind a NAT gateway. Since the
application's original "Request to Join" message is encrypted within an ESP payload,
for the transport
layer protocol header port fields are concealed from NAT gateways and
they can not participate in NAPT. The multicast application IPSec SA
must calculation to be handled differently depending on whether the application requires
source-specific multicast. successful.

If the application requires IPSec source-specific multicast routing, then
there must be a separate public IP-v4 address statically reserved at the NAT
gateway new value for each multicast source endpoint private/public address mapping.
This constraint allows <secret> is chosen while there are connections in the GCKS
process of being initialized, a "Request to specify at every group member Join with Cookie Info" might be
returned with other than the inbound
SPD traffic selector current <SecretVersionNumber>. The responder
GC/KS in that case MAY reject the message by sending another response with a pre-determined public source address
new cookie or it MAY keep the old value of <secret> around for each
multicast source GSAKMP endpoint in 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 group. denial of service protection. The traffic selector's
public source address in combination with responder GC/KS SHOULD
change the group's destination multicast
address value of <secret> frequently, especially if under attack.

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

INTERNET-DRAFT GSAKMP February 2004

5.3 Group Maintenance

The Group Maintenance phase includes member joins and leaves, group rekey
activities, and SPI selects the inbound SA. Keeping the NAT gateway's source
address mapping static rather than dynamic also allows the multicast
routers along management of Rekey events. These activities are
presented in the packet's path to apply source-specific routing policies.
Note 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 use creation of a static source address mapping NAT avoids the need
for new group key and/or Rekey information.

Once an event has been identified (as defined in the group security policy token to specify UDP encapsulated ESP. The GCKS SPD
configuration database must be kept synchronized with the group's NAT
gateway address mapping configurations.

If source-specific multicast routing is not required by the application,
then
token), the NAT gateway's source address translation can use dynamically
allocated public IP-v4 addresses rather than statically allocated IP-v4
addresses. However, unless GC/KS MUST create and provide a signed message containing the group uses UDP encapsulated ESP, then
GTPK and Rekey information to the NAT gateway must have a pool of public IP-v4 addresses reserved that
is at least as large as group.

Each GM who receives this message MUST verify the number of multicast source GSAKMP endpoints

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

INTERNET-DRAFT GSAKMP October 2003

within its private network. This allows signature on the NAT gateway to do a one-to-one
mapping from every GSAKMP endpoint's private source address message
to a dynamically
allocated public source address. The GCKS specifies ensure its authenticity. If the SPD inbound traffic
selector as message signature does not verify,
the combination of message MUST be discarded. Upon verification the group's destination multicast address and GM will find the SPI.

In some deployments,
appropriate Rekey download packet and decrypt the number of public IP-v4 addresses assigned to information with a NAT
gateway stored
Rekey key(s). If a new Policy Token is very limited (e.g. only one public address). Also, distributed with the message, it may
MUST be
difficult to predict how many multicast source endpoints will reside within
the private network before the group begins its operation. For these cases, encrypted in the group MAY use UDP encapsulated ESP. old GTPK.

The NAT gateway applies NAPT to the
UDP header's source port field, sidestepping the constraint components of its limited
public address pool. The GCKS modifies the group policy token to specify
that the outbound SPD processing must pre-append a UDP header Rekey Event message are shown in Table 7:

Table 7: Rekey Event Message Definition

Message Name : Rekey Event
Dissection : {HDR-GrpID, ([Policy Token])*, Rekey Array}SigC,
[Cert]
Payload Types : GSAKMP Header, [Policy Token], Rekey Event,
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

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.

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

INTERNET-DRAFT GSAKMP February 2004

5.3.2.1 Eviction

At some point in front of the ESP header. When group's lifetime, it may be desirable to evict one or
more members from a GSAKMP endpoint originates group. From a multicast application
packet, it inserts key management viewpoint, this involves
revoking access to the group's protected data by "disabling" the departing
members' keys. This is accomplished with a UDP header Rekey Event, which is discussed
in front of more detail in section 5.3.1.1. If future access to the ESP header, as per reference
[XXXXX].

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 is also
to be denied, the parameters necessary members MUST be added to support a secure group, including its denied access control list, and
the policy token. Group establishment is token's authorization rules MUST be appropriately updated so that
they will exclude the
process expelled GM(s). After receipt of granting access to a new members. Security relevant group
maintenance messages include rekey, policy changes and member deletion.
Each PT, GMs SHOULD
evaluate the trustworthiness of these life-cycle phases is discussed in any recent application data originating from
the following sections.

5.1 Group Definition

A cryptographic group is established expelled GM(s).

5.3.2.2 Voluntary Departure without Notice

If a member wishes to support secure communications among leave a group of individuals. The activities necessary for which membership imposes no cost
or responsibility to create a Policy Token
in support that member, then the member MAY merely delete local
copies of a cryptographic group include

- Determine Access Policy - identify keys and cease group activities.

5.3.2.3 De-Registration

If the membership in the entities that are authorized group does impose cost or responsibility to
receive
the departing member, then the member SHOULD de-register from the
group key.

- Determine Authorization Policy - identify which entities are authorized when that the member wishes to perform security relevant actions, including key dissemination,
policy creation, and initiation leave. De-Registration consists
of security management actions.

- Determine Mechanisms - define a three-message exchange between the algorithms GM and protocols used by
GSAKMP to secure the group. member's GCKS: the
Request_to_Depart, Departure_Response, and the Departure_Ack. These messages
SHOULD be done under the protection of the GSA.

5.3.2.3.1 Request to Depart - Create 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}
SigM, [Cert]
Payload Types : GSAKMP Header, Identification, Nonce,
Notification, Signature, [Certificate]
SigM : Signature of Group Policy Token - format Member
Cert : Necessary Certificates, zero or more
{}SigX :Indicates fields used in Signature
[] : Indicate an optional data item

Any GM desiring to initiate the policies De-Registration process MUST generate and mechanisms into a

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 32] 44]

INTERNET-DRAFT GSAKMP October 2003

Policy Token February 2004

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, Nonce payload for
freshness, and apply Notification of the GO signature.

5.2 Group Establishment

GSAKMP Group Establishment consists desire to leave the group. The Nonce_I
value MUST be saved for later use. This message MUST then by signed by the
GM.

Upon receipt of three mandatory-to-implement
messages, the Request to Join, RTD message, the Key Download, GC/KS MUST verify that the message
header is properly formed and confirm that this message is for this group
by checking the Key Download
Ack/Failure. The exchange may also include two OPTIONAL error messages, value of the Request to Join Error and GroupID. If the Lack_of_Ack messages. Operation using header checks pass, then
the mandatory messages only identifier value in Identification payload is referred compared to as "Terse Mode", while
inclusion 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 error messaging sender is referred to as "Verbose Mode". GSAKMP
implementations extracted from the Signature payload. This
identity MUST support Terse Mode and MAY support Versbose Mode.
Group Establishment be used to confirm that this GM is discussed in Section 5.2.1.

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

5.2.1 Standard Group Establishment

After group
serviced by this GC/KS. Then the out-of-band receipt of a Policy Token, a potential Group
Controller Key Server (GC/KS) verifies GC/KS will confirm from the token and its eligibility Notification
payload that the GM is requesting to
perform leave the group. Then the GC/KS functionality. It is then permitted will
verify the signature on the message to create any needed
group keys ensure its authenticity. The GC/KS
MUST use verified and begin to establish trusted authentication material from a known root. If
all checks pass and the message is successfully processed, and/or the group.

The GSAKMP Ladder Diagram, Figure 2, GC/KS
is presented to illustrate in Verbose Mode, then the
process of establishing GCKS MUST form a cryptographic group. The left side of the
diagram represents the actions of Departure_Response message as
defined in section 5.3.2.3.2.

If the GC/KS. The right side processing of the diagram
represents message fails and/or the actions of GC/KS is in Terse Mode,
then the GMs. session MUST be terminated and all state associated with this
session is removed.

5.3.2.3.2 Departure_Response - The components of each message a Departure_Response
Message are shown in
the diagram are presented Table 9.

Table 9: Departure_Response (DR) Message Definition

Message Name : Departure_Response (DR)
Dissection : {HDR-GrpID, Member_ID, Nonce_R, Nonce_C,
Notification} SigC, [Cert]
Payload Types : GSAKMP Header, Identification, Nonce,
Notification, Signature, [Certificate]

SigC : Signature of Group Member
Cert : Necessary Certificates, zero or more
{}SigX :Indicates fields used in sections 5.2.1.1 - 5.2.1.5.

The Request Signature
[] : Indicate an optional data item

In response to Join message is sent from a potential GM to properly formed and verified RTD message, the GC/KS to
request admission to
MUST create and send the cryptographic group. The DR message. As defined in the dissection of
the message, this message contains key
creation material, freshness data, an optional selection MUST contain payloads to hold the following
information: GM identification, Nonce payloads for freshness, Notification
for acceptance of mechanisms, departure, and signature information.

The nonce values transmitted MUST be the GC/KSs generated Nonce_R value and

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

INTERNET-DRAFT GSAKMP February 2004

the combined Nonce_C value which was generated by using the GC/KSs Nonce_R
value and the signature of the GM.

The Key Download message is sent Nonce_I value received from the GC/KS to the GM in response the RTD. This Nonce_C
value MUST be saved relative to an accepted Request this departing GMs ID.

The GM MUST be able to Join. This GC/KS-signed message contains the
identifier of process the GM, freshness data, key creation material, encrypted keys,
and Departure_Response message. The
following checks SHOULD be performed in the encrypted Policy Token. order presented.

The Policy Token is used to facilitate
well-ordered group creation and GM MUST include verify that the group's identification,
group permissions, group join policy, group controller key server identity,
group management information, message header is properly formed and digital signature confirm
that this message is for this group by checking the value of the GO. This will
allow GroupID. If
the header checks pass, the GM to determine whether group policy is compatible with local
policy.

The Request to Join Error MUST confirm that this message is sent from was intended
for itself by comparing the GC/KS Member ID in the Identification payload to
its identity. After identification confirmation, the freshness values are
checked. The GM in
response to an unaccepted Request to Join. This message is not signed
by MUST use its saved Nonce_I value, extract the received
GC/KS for two reasons: 1) The GM, at this point, has no knowledge

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

INTERNET-DRAFT GSAKMP October 2003

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 Nonce_R value, compute the combined Nonce_C value, and compare it to
the received Nonce_C value. After freshness is confirmed, confirmation of Ackknowledgement------->!
! ! <Proc LOA>
!<=======SHARED KEYED GROUP SESSION======>!

Figure 2: GSAKMP Ladder Diagram
the identity of who the signer of the DR message is the GMs authorized to act as a GC/KS and so is
performed. Then the signature would thus MUST be
meaningless verified to the GM, ensure its authenticity,
The GM MUST use verified and 2) Signing responses to denied join requests
would provide trusted authentication material from a denial of service potential. The message contains an
indication of known
root. If the error condition.

The Key Download Ack/Failure message indicates Key Download receipt status
at signature verifies, then the GM. It GM MUST verify that the
Notification is a GM-signed message containing freshness data of Type Departure_Accepted or Request_to_Depart_Error.

If the processing is successful, and status.

The Lack_of_Ack message the Notification payload is sent from of type
Departure_Accepted, the GC/KS to member MUST form the GM in response to an
invalid or absent Key Download Ack/Failure message. The signed Departure_ACK message
contains freshness and status data and as defined
in section 5.3.2.3.3. If the processing is used to warn successful, and the GM Notification
payload is of impending
eviction from type Request_to_Depart_Error, the group if a valid Key Download Ack/Failure is not sent.

For member MUST remove all state
associated with the following message structure sections, details about payload format
and processing can be found in Section 7.

5.2.1.1 Request action. If the member still desires to Join De-Register from
the group, the member MUST restart the De-Registration process.

5.3.2.3.3 Departure_ACK - The components of a Request to Join the Departure_ACK Message are
shown in Table 10:

Table 10: Departure_ACK (DA) Message are shown Definition

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

As shown by Figure 2, Signature

In response to a potential properly processed Departure_Response message, the
GM MUST generate create and send an RTJ message
to request permission to join the group. Departure_ACK message. As defined in the disection
dissection of the RTJ message, this message MUST contain payloads to hold the
following information: Key Creation payload for KEK generation and Nonce payload for freshness. freshness, Notification payload
of type Acknowledgment (ACK), and signature information. The Nonce_I nonce value
transmitted MUST be saved for later use. An OPTIONAL
Notification payload the GMs generated Nonce_C value.

Upon receipt of type Mechanism Choices MAY the Departure_ACK, the GCKS MUST perform the following
checks. These checks SHOULD be included performed in the order presented.

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

INTERNET-DRAFT GSAKMP February 2004

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. The GC/KS MUST use its saved Nonce_C value, and compare it
to identify the mechanisms received Nonce_C value. After freshness is confirmed, the GM wants signature
MUST be verified to use. Absence 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 payload will cause is considered a successful processing of this
message.

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

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

INTERNET-DRAFT GSAKMP October 2003

Table 1: Request to Join (RTJ) Message Definition

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

SigM : Signature
group.

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

In response, the GC/KS accepts message fails or denies the request based on local
configuration. <Process RTJ> indicates the GC/KS actions that will
determine if no Departure_Ack is received,
the RTJ will be acted upon. GC/KS MAY issue a LOA message.

6 Security Suite

The following checks SHOULD Security Definition Suite 1 MUST be
performed 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 order presented.

In this procedure,
correct Security Suite to join the GC/KS group. This can be accomplished by a
well known default suite 'Security Suite 1' or by announcing/posting another
suite.

6.2 Definition Suite 1

GSAKMP implementations MUST verify that support the message header is properly
formed following suite of algorithms and confirm
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 this message GSAKMP does not negotiate these cryptographic
mechanisms. This definition is for this group set by checking the value
of the GroupID. If the header checks pass, then the identity of the sender
is extracted from Group Owner via the Signature payload. This identity MUST be used to
perform access control checks, find Policy Token
(passed during the GMs credentials (e.g. certificate) GSAKMP exchange for message verification, member verification purposes).

The GSAKMP Suite 1 definition is

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

INTERNET-DRAFT GSAKMP February 2004

Key download and MUST also be used in the Policy Token encryption algorithm definition:
Algorithm: 3DES
Mode: CBC64
Key Download message.
Then the GC/KS will verify the Length: 192 bits

Policy Token digital signature on the message to ensure its
authenticity. algorithm is:
DSS-ASN1-DER
Hash algorithm is:
SHA-1

Nonce Hash algorithm is:
SHA-1

The GC/KS MUST use verified 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 trusted authentication
material g values comes from a known root. If the message IKE [RFC 2409], section 6.2 Second
Oakley Group, and p is 1024 bits long.

The digital signature verifies, the GC/KS
then confirms that all required payloads algorithm is:
DSS-SHA1-ASN1-DER
The digital signature ID type is:
U-NAME

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 present and properly formatted
based upon the mechanisms announced and/or requested. If all checks pass, composed of the GC/KS will create and send
Generic Payload Header (Section 7.2) followed by the Key Download specific payload data.
The message as described in
section 5.2.1.2.

NOTE: At any one time, is chained by a GC/KS MUST process no more that one (1) valid RTJ
message from preceeding payload defining its succeeding
payload. The final payload in a single GM per group.

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 will point to three (3) times.

If any error occurs during RTJ message processing, and the GC/KS is
running no succeeding
payload.

All fields of type integer in Terse mode, the session MUST be terminated Header and all saved state
information Payload structure that are
larger than one octet, MUST be cleared.

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

5.2.1.2 Key Download

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

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

INTERNET-DRAFT GSAKMP October 2003

Table 2: Key Download (KeyDL) Message Definition

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

In response transmission.

Padding of fields MUST NOT be done as this leads to a properly formed and verfied RTJ message, the GC/KS creates processing errors.

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

INTERNET-DRAFT GSAKMP February 2004

7.1 GSAKMP Header

7.1.1 GSAKMP Header Structure

The GSAKMP Header fields are shown in Figure 4 and sends the KeyDL message. As defined in 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 4: GSAKMP Header Format

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

Table 11: Group Identification Types

Grp ID Type Value
__________________________________________

Network Byte Ordered Integer 0
ASCII 1
Reserved 2 - 192
Private Use 193 - 255

Group Identification Length (1 octet) - Length of the message,
this message Group ID field
in octets. This value MUST contain payloads to hold NOT be zero (0). If the following information:
GM identification, Nonce payloads for freshness, Key Creation material,
encrypted Policy Token, enctyped key information, and signature information.

The nonce values transmitted GroupID Type is
"Network Byte Ordered Integer", the length MUST be four (4). This field
is treated as an unsigned value.

Group Identification Value (variable length) - Indicates the GC/KSs generated Nonce_R value
and the conbined Nonce_C value which was generated by using name/title of
the GS/KSs
Nonce_R group. This value and MUST be unique per Group Owner.

Next Payload (1 octet) - Indicates the Nonce_I value received from type of the GM next payload in the RTJ.
message. The
key creation material supplied by the GM and/or format for each payload is defined in the GC/KS will be used to
generate following

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

INTERNET-DRAFT GSAKMP February 2004

sections. Table 12 presents the KEK. Generation of this KEK payload types. This field is defined by policy. The treated
as an unsigned value.

Table 12: Payload Types

Next_Payload_Type Value
___________________________________

None 0
Policy Token and 1
Key material are encrypted in Download Packet 2
Rekey event 3
Identification 4
Reserved 5
Certificate 6
Reserved 7
Signature 8
Notification 9
Reserved 10
Key Creation 11
Nonce 12
Reserved 13 - 192
Private Use 193 -- 255

Version (1 octet) - Indicates the generated KEK. version of the GSAKMP protocol in use.
The GM MUST be able to process current value is one (1). This field is treated as an unsigned
value.

Exchange Type (1 octet) - Indicates the Key Download message. <Process KeyDL>
indicates type of exchange (also known as
the GM actions that will determine how 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 Key Download message
will is not a group management
message, this value MUST be acted upon. set to zero (0). The following checks SHOULD first value used by a
(S-)GC/KS MUST be performed in the order
presented.

In this procedure, the GM will verify that the one (1). For each distinct group management message header is properly
formed and confirm
that this message is for (S-)GC/KS transmits, this group by checking the value of the GroupID. If the header checks pass, the GM MUST confirm that be incremented by one
(1). Receivers of this group management 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. The GM MUST use its save Nonve_I value,
extract confirm that the
value received GC/KS Nonce_R value, compute is greater that the combined Nonce_C value,
and compare it to value of the sequence ID received Nonce_C value. After freshness is confirmed,
with the signature MUST be verified to ensure its authenticity, The GM MUST use
verified and trusted authentication material 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 known root. If the Sequence ID of
0xFFFFFFFF. This field is treated as an unsigned integer in network byte
order.

Length (4 octets) - Length of total message signature verifies, the key creation material (header + payloads) in octets.
This field is extracted from the treated as an unsigned integer in network byte order.

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

INTERNET-DRAFT GSAKMP February 2004

Table 13: Exchange Types

Exchange_Type Value
________________________________________

Reserved 0 - 3
Key Creation payload Download Ack/Failure 4
Rekey Event 5
Reserved 6 - 7
Request to generate the KEK. This KEK is then used Join 8
Key Download 9
Cookie Download 10
Request to Join Error 11
Lack of Ack 12
Request to decrypt Depart 13
Departure Response 14
Departure Ack 15
Reserved 16 - 192
Private Use 193 -- 255

7.1.2 GSAKMP Header Processing

When processing the Policy Token data. The signature on GSAKMP Header, the policy token following fields MUST be verified.
Access control checks checked for
correct values:

1. Group ID Type - The Group ID Type value MUST be performed on both the GO and the GC/KS checked to
determine both their authorities within this group. After all these checks
pass, be a valid
payload type as defined by Table 11. If the KEK can value is not valid,
then depending upon mode (e.g., Terse or Verbose) either an error
is logged or an appropriate message containing notification value
Payload-Malformed will be used to decrypt and process sent.

2. GroupID - The GroupID of the key material from

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 36]

INTERNET-DRAFT GSAKMP October 2003 received message MUST checked against the Key Download payload.
GroupID of the Group Component. If all no match is successful, the GM found, then depending
upon mode (e.g., Terse or Verbose) either an error is logged or an
appropriate message containing notification value Invalid-Group-ID will create and send
the Key Download
be sent.

3. Next Payload - 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 Next Payload value MUST be checked to be a valid
payload information using the mechanisms type as defined in the group announcment. This guarantees that the sensitive policy
and key data for the group and potential rekey data for this individual
cannot be read by anyone but the intended recipient. Table 12. If any error occurs during KeyDL message processing, and the GM value is running
in not valid,
then depending upon mode (e.g., Terse mode, the session or Verbose) either an error
is logged or an appropriate message containing notification value
Invalid-Payload-Type will be sent.

4. Version - The GSAKMP version number MUST be terminated, checked that it is
supported. If the GM MUST send a Key
Download - Ack/Failure version is not supported, then depending upon mode
(e.g., Terse or Verbose) either an error is logged or an appropriate

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

INTERNET-DRAFT GSAKMP February 2004

message with containing notification value Invalid-Version will be sent.

5. Exchange Type - The Exchange Type MUST be checked to be a Notification Payload of valid exchange
type NACK to
indicate termination, as defined by Table 13 and all saved state information MUST be cleared.

5.2.1.3 Request to Join Error

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 type expected to Join Error (RTJ-Err)
Dissection : {HDR-GrpID, Nonce_I, Notification}
Payload Types : be
received by the GSAKMP Header, Nonce, Notification

In response to an unacceptable RTJ, state machine. If the GC/KS MAY send a Request to Join
Error (RTJ-Err) message containing exchange type is not
valid, then depending upon mode (e.g., Terse or Verbose) either an
error is logged or an appropriate Notification payload.
Note that the RTJ-Err message is not a signed 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 following reasons:
the lack last sequence
ID received from this (S-)GC/KS. Receipt of awareness incorrect Sequence ID
on the GM's perspective of who is group management messages MUST NOT cause a valid GC/KS as
well as the need reply message to protect the GC/KS from signing messages and using
valuable resources. Following the sending be
generated. Receipt of incorrect Sequence ID on non-group management
messages, depending upon mode (e.g., Terse or Verbose), causes either
an RTJ-Err, the GC/KS MUST
terminated error to be logged or an appropriate message containing notification
value Invalid-Sequence-ID to be sent.

The length fields in the session GSAKMP Header (Group ID Length and all saved state information MUST Length) are used
to help process the message. If any field is found to be cleared.

Upon receipt of incorrect, then
depending upon mode (e.g., Terse or Verbose) either an RTJ-Err message, the GM error is logged or an
appropriate message containing notification value Payload-Malformed will validate the following:
the GroupID be
sent.

7.2 Generic Payload Header

7.2.1 Generic Payload Header Structure

Each GSAKMP payload defined in the header belongs to following sections begins with a group to generic
header, shown in Figure 5, 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 5: Generic Payload Header

Next Payload (1 octet) - Identifier for the GM has sent an
RTJ, and payload type of the Nonce_I matches a Nonce_I sent next
payload in an RTJ to that group. If
the above checks are successful, the GM MAY terminate message. If 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 components of current payload is the Key Download - Ack/Failure Message are shown last in
Table 4:

In response to a properly processed KeyDL message, the GM creates and sends

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 37] 52]

INTERNET-DRAFT GSAKMP October 2003 February 2004

the message, then this field will be 0. This field provides the
``chaining`` capability. Table 4: Key Download - Ack/Failure (KeyDL-A/F) Message Definition

Message Name : Key Download 12 identifies the payload types. This
field is treated as an unsigned value.

RESERVED (1 octet) - Ack/Failure (KeyDL-A/F)
Dissection : {HDR-GrpID, Nonce_C, Notif_Ack}SigM Unused, set to 0.

Payload Types : GSAKMP Header, Nonce, Notification, Signature

SigM : Signature of Group Member
{}SigX :Indicates minimum fields used Length (2 octets) - Length in Signature octets of the KeyDL-A/F message. As defined 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 dissection of Generic Payload Header, the message, this
message following fields MUST contain payloads be
checked for correct values:

1. Next Payload - The Next Payload value MUST be checked to hold be a valid
payload type as defined by Table 12. If the following information: Nonce
payload for freshness, Notification payload of type Acknowledgment (ACK).
and signature information. The nonce is not valid,
then depending upon mode (e.g., Terse or Verbose) either an error
is logged or an appropriate message containing notification value transmitted MUST
Invalid-Payload-Type will be the GMs
generated Nonce_C value.

The GC/KS sent.

2. RESERVED - This field MUST be able to process the KeyDL-A/F message. <Process
KeyDL-A/F> indicates contain the GC/KS actions that will determine how value zero (0). If the
KeyDL-A/F value
of this field is not zero (0), then depending upon mode (e.g., Terse or
Verbose) either an error is logged or an appropriate message containing
notification value Payload-Malformed will be acted upon. sent.

The following checks SHOULD be
performed length field in the order presented.

In this procedure, Generic Payload Header is used to process the GC/KS
remainder of the payload. If this field is found to be incorrect, then
depending upon mode (e.g., Terse or Verbose) either an error is logged or
an appropriate message containing notification value Payload-Malformed will verify
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 message header is properly
formed group security relevant behaviors, access control
parameters, and confirm that this message is security mechanisms. Figure 6 shows the format of the
payload.

The Policy Token Payload fields are defined as follows:

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

INTERNET-DRAFT GSAKMP February 2004

Figure 6: Policy Token Payload Format

Next Payload (1 octet) - Identifier for this group by checking the value payload type of the GroupID. If the header checks pass, the GC/KS MUST check the message
for freshness. The GC/KS MUST use its saved Nonve_C value, and compare it
to the received Nonce_C value. After freshness is confirmed, next
payload in the signature
MUST be verified to ensure its authenticity, The GC/KS MUST use verified and
trusted authentication material from a known root. message. If the message signature
verifies, the GC/KS processes current payload is the Notification payload. If last in
the notification
type is of type ACK, message, then this field will be 0. This field provides the GC/KS and GM have established a GSA.

If
``chaining`` capability. Table 12 identifies the GC/KS does not receive a KeyDL-A/F message of proper form, payload types. This
field is unable treated as an unsigned value.

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

Payload Length (2 octets) - Length in octets of the KeyDL-A/F message, current payload,
including the Notification generic payload type
is any value excpet ACK, or if no KeyDL-A/F message header. This field is received within the
locally configured timeout, the GC/KS MUST remove this GM from treated as an
unsigned integer in network byte order format.

Policy Token Type (2 octets) - Specifies the group
and handle according to policy. The GC/KS MAY send type of Policy Token being
used. Table 14 identifies the OPTIONAL Lack_of_Ack
message if running in Verbose Mode types of policy tokens. This field is
treated as defined an unsigned integer in section 5.2.1.5.

5.2.1.5 Lack of Ack network byte order format.

Table 14: Policy Token Types

Policy_Token_Type Value Definition
_____________________________________________________________________________

GSAKMP_PT_V1 0 The components of a Lack format for this Policy Token is
specified in [HCLM00].
GSAKMP_ASN.1_PT_V1 1 All implementations of Ack Message are shown GSAKMP
MUST support this Policy Token format.
This format is specified in Table 5:

If the GC/KSs local timeout value expires prior to receiving a KeyDL-A/F
from the GM, the GC/KS MAY create TBD.
Reserved 2 - 49152
Private Use 49153 - 65535

Policy Token Data (variable length) - Contains Policy Token information.
The values for this field are token specific and send a LOA message to the GM. As
defined in the dissection of format is specified
by the message, PT Type field.

If this message MUST contain payloads
to hold payload is encrypted, only the following information: GM identification, Nonce payloads for
freshness, Notification of error, and signature information. Policy Token Data field is encrypted.

The nonce values transmitted MUST be payload type for the GC/KSs generated Nonce_R value and Policy Token Payload is one (1).

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 38] 54]

INTERNET-DRAFT GSAKMP October 2003

Table 5: Lack of Ack (LOA) Message Definition

Message Name : Lack of Ack (LOA)
Dissection : {HDR-GrpID, Member ID, Nonce_R, Nonce_C,
Notification} SigC, [Cert] February 2004

7.3.2 Policy Token Payload Types : GSAKMP Header, Identification, Nonce,
Notification, Signature, [Certificate]

SigC : Signature of Group Controller Key Server
Cert : Necessary Certificates, zero or more
{}SigX :Indicates minimum Processing

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

1. Next Payload, RESERVED, Payload Length - These fields used are processed as
defined in Signature
[] : Indicate an optional data item

the conbined Nonce_C Section 7.2.2, Generic Payload Header Processing.

2. Policy Token Type - The Policy Token Type value which was generated MUST be checked to be
a valid policy token type as defined by using Table 14. If the GS/KSs Nonce_R value and the Nonce_I is
not valid, then depending upon mode (e.g., Terse or Verbose) either an
error is logged or an appropriate message containing notification value received from
Payload-Malformed will be sent.

3. Policy Token Data - This Policy Token Data MUST be processed according
to the GM in Policy Token Type specified. The type will define the RTJ. These values
were already generated during format of
the data.

7.4 Key Download message phase.

The GM MAY be able Payload

Refer to process the LOA message based upon local
configuration. <Process LOA> indicates the GM actions that will determine
how terminology section for the LOA message will be acted upon. different terms relating to keys
used within this section.

7.4.1 Key Download Payload Structure

The following checks SHOULD be
performed in 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 order presented.

In this procedure, security policy of the GM MUST verify that group.
Figure 7 shows the message header is properly
formed and confirm that this message is for this group by checking format of the
value payload.

The security policy of the GroupID. If group dictates that the header checks pass, key download payload MUST
be encrypted with a key encryption key (KEK). The encryption mechanism used
is specified in the GM Policy Token. The group members MUST confirm that
this message was intended for itself by comparing create the Member ID in KEK
using the
Identification payload to its identity. After identification confirmation, key creation method identified in the freshness values are checked. Key Creation Payload.

The GM MUST use its save Nonve_I value,
extract Key Download Payload fields are defined as follows:

Next Payload (1 octet) - Identifier for the received GC/KS Nonce_R value, compute payload type of the combined Nonce_C value,
and compare it to next
payload in the received Nonce_C value. After freshness message. If the current payload is confirmed,
access control checks MUST be performed on the GC/KS to determine its
authority within last in
the message, then this group. Then signature MUST field will be verified to ensure its
authenticity, The GM MUST use verified and trusted authentication material
from a known root.

If 0. This field provides the checks succeed,
``chaining`` capability. Table 12 identifies the GM SHOULD resend a KeyDL-A/F payload types. This
field is treated as an unsigned value.

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

INTERNET-DRAFT GSAKMP February 2004

Figure 7: Key Download Payload Format

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 that session.

5.2.2 Cookies Key Download Data Item (Key Datum/Rekey Array) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

Figure 8: Key Download Data Item Format

RESERVED (1 octet) - Group Establishment with Denial Unused, set to 0.

Payload Length (2 octets) - Length in octets of Service Protection the current payload,
including the generic payload header. This section defines field is treated as an OPTIONAL capability that MAY be implemented into
GSAKMP when using IP based groups. The information
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 section data block. This
field is
borrowed heavily from [IKEv2] treated as this protocol has already worked through
this issue and GSAKMP an unsigned integer in network byte order format.

Key Download Data Items (variable length) - Contains Key Download
information. The Key Download Data is copying this concept. This section will contain
paraphrased sections a sequence of Type/Length/Data of [IKEv2] modified for GSAKMP to define
the purpose Number of
Cookies.

An optional Cookie mode Items. The format for each item is being defined for the GSAKMP to help against DoS
attacks.

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

INTERNET-DRAFT GSAKMP October 2003

The term "cookies" originates with Karn and Simpson [RFC 2522] in Photuris,
an early proposal figure 8.

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

Key Download Data (KDD) Item Type (1 octet) -- Identifier for key management with IPsec. The ISAKMP fixed message
header includes two eight octet fields titled "cookies". Instead the type
of placing
this cookie data contained in this Key Download Data Item. See Table 15
for the header, possible values of this data is moved into a Notification
payload.

An expected attack against GSAKMP field. This field is state and CPU exhaustion, where treated as an
unsigned value.

Key Download Data Item Length (2 octets) -- Length in octets of the
target GC/KS
Data for the Key Download Data Item following this field. This
field is flooded with Request to Join requests from forged IP
addresses. treated as an unsigned integer in network byte order
format.

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

INTERNET-DRAFT GSAKMP February 2004

Table 15: Key Download Data Item Types

Key Download Data Value Definition
Item Type
__________________________________________________________________

GTPK 0 This attack can type MUST be made less effective if a GC/KS implementation
uses minimal CPU and commits no state to the communication until it knows implemented.
This type identifies that the initiator potential GM can receive packets at
data contains group traffic
protection key information.
Rekey - LKH 1
Reserved 2 - 192
Private Use 193 - 255

Data for Key Download Data Item (variable length) -- Contains Keys
and related information. The format of this field is specific
depending on the address from which
it claims to be sending them. To accomplish this, value of the GC/KS when operating
in Cookie mode, SHOULD reject initial Request to Join messages unless they
contain a Notification payload Key Download Data Item Type field.
For KDD Item Type of type "cookie". It SHOULD instead send GTPK, this field will contain a Cookie Download message Key Datum as
defined in Section 7.4.1.1 . For KDD Item Type Rekey - LKH, this
field will contain a response to the RTJ and include a cookie Rekey Array as defined in
a notify 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 Cookie_Required. Potential GMs who receive such
responses MUST retry for the Request to Join message with Key Download Packet is two (2).

7.4.1.1 Key Datum Structure

A Key Datum contains all the responder GC/KS
supplied cookie information for a key. Figure 9 shows the
format for this structure.

Key Type (1 octet) -- This is the encryption algorithm for which this key
data is to be used. This value is specified in its notification payload the Policy Token. See
Table 16 for the possible values of type Cookie, this field. This field is treated
as an unsigned value.

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

Key Handle (4 octets) -- This is the Request value to Join Msg as defined in
section 5.2.1.1. uniquely identify a key.
This initial exchange will then be field is treated as shown in Figure 3
with an octet string.

Key Creation Date (15 octets) -- This is the components time value of when this key
data was originally generated. This field contains the new message Cookie Download shown timestamp in Table 6.

CONTROLLER MESSAGE MEMBER
in Cookie Mode
!<--Request to Join without Cookie Info---!
<Gen Cookie Rsp> !
the ascii format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 - 9999),

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

INTERNET-DRAFT GSAKMP February 2004

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
!
!----------Cookie Download--------------->! Key Type ! Key ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ! <Process CD>
!<----Request to Join with Cookie Info----!
<Process RTJ> Key Handle ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ! Key Creation Date ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ !
!-------------Key Download--------------->!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Key Expiration Date ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ! <Process KeyDL>
!<-----Key Download - Ack/Failure--------!
<Proc KeyDL-A/F>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ !
!<=======SHARED KEYED GROUP SESSION======>! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ Key Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

Figure 3: GSAKMP Ladder Diagram with Cookies

Table 6: Cookie Download Message Definition

Message Name : Cookie Download
Dissection : {HDR-GrpID, COOKIE_REQUIRED}
Payload Types : GSAKMP Header, Notification

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

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 40] 58]

INTERNET-DRAFT GSAKMP October 2003

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
GC/KS and periodically changed, Ni February 2004

Table 16: Encryption Types

Encryption_Types Value Description
___________________________________________________________________

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

MM is the Nonce numerical value taken from of the
initiator potential GM, IPi month (01 - 12), DD is the supposed IP day of the initiator potential
GM. <SecretVersionNumber> should be changed whenever <secret>
month (01 - 31), HH 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 hour of the same Ni value from day (00 - 23), MM is the original "Request to Join" message
for minute
within the calculation to be successful.

If a new value for <secret> hour (00 - 59), SS 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 seconds within the message minute (00 -
59), and followed 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 letter Z to indicate that would
defeat part of this is Zulu time.

Key Expiration Date (15 octets) -- This is the denial time value of service protection. The responder GC/KS SHOULD
change when this
key is no longer valid for use. This field contains the timestamp in
the ascii format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 - 9999),
MM is the numerical value of <secret> frequently, especially if under attack.

5.3 Group Maintenance

The Group Maintenance phase includes member joins and leaves, group rekey
activities, and the management month (01 - 12), DD is the day of Rekey events. These activities are
presented in the following sections.

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

INTERNET-DRAFT GSAKMP October 2003

5.3.1 Rekey Events

A Rekey Event
month (01 - 31), HH is any action, including compromise report or key expiration,
that requires the creation hour of a new group key and/or Rekey information.

Once an event has been identified (as defined in the group security policy
token), day (00 - 23), MM is the GC/KS MUST create and provide a signed message containing minute
within the
GTEK hour (00 - 59), SS is the seconds within the minute (00 -
59), and Rekey information to followed by the group.

Each GM who receives letter Z to indicate that this message MUST verify is Zulu time.

Key Data (variable length) -- This is the signature actual key data, which is
dependent on the message
to ensure Key Type algorithm for its authenticity. If format.

NOTE: The combination of the message signature does not verify, Key ID and the message Key Handle MUST be discarded. Upon verification unique within
the GM group. This combination will find be used to uniquely identify a key.

7.4.1.2 Rekey Array Structure

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

Rekey download packet and decrypt Version (1 octet) -- Contains the version of the Rekey protocol in
which the information with a stored data is formatted. For Key Download Data Item Type of Rekey key(s). If
- LKH, refer to Section A.2 for a new Policy Token description of this value. This field
is treated as an unsigned value.

Member ID (4 octets) -- This is distributed with the message, it
MUST be encrypted in the old GTEK.

The components Member ID of a the Rekey Event message are shown sequence
contained in Table 7:

Table 7: Rekey Event Message Definition

Message Name : Rekey Event
Dissection : {HDR-GrpID, ([Policy Token])*, this Rekey Array}SigC,
[Cert]
Payload Types : Array. This field is treated as an octet

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

INTERNET-DRAFT GSAKMP Header, [Policy Token], February 2004

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 Event,
Signature, [Certificate],

SigC : Signature Version#! Member ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ! Number of Group Controller KEK Keys ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ Key Server
Cert : Necessary Certificates, zero or more
{}SigX :Indicates minimum fields used in Signature
(data)* : Indicates encrypted information
[] : Indicate an optional data item

5.3.2 Leaving a Group

Figure 10: Rekey Array Structure Format

string. For Key Download Data Item Type of these is discussed in this section.

5.3.2.1 Eviction

At some point in the group's lifetime, it may be desireable Rekey - LKH, refer to evict one or
more members from a group. From
Section A.2 for a key management viewpoint, description of this involves
revoking access to the group's protected data by "disabling" the departing
members' keys. value.

Number of KEK Keys (2 octets) -- This value is accomplished with a Rekey Event, which the number of distinct KEK
keys in this sequence. This value is discussed treated as an unsigned integer in more detail
network byte order format.

Key Datum(s) (variable length) -- The sequence of KEKs in section 5.3.1. If future access to the group Key Datum
format. The format for each Key Datum in this sequence is also to
be denied, defined in
section 7.4.1.1.

Key ID - For Key ID within the members MUST be added Rekey - LKH space, refer to Section A.2
for a denied access control list, and

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

INTERNET-DRAFT GSAKMP October 2003 description of this value.

7.4.2 Key Download Payload Processing

Prior to processing its data, the tokens authorization rules payload contents MUST be appropriately updated so that they
will exclude the expelled GM(s). After receipt of a new PT, GMs SHOULD
evaluate decrypted.

When processing the trustworthiness of any recent application data originating from Key Download Payload, the expelled GM(s).

5.3.2.2 Voluntary Departure without Notice

If a member wishes to leave a group following fields MUST be
checked for which membership imposes no cost
or responsibility 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 that member, then the member MAY merely delete local
copies of group keys and cease group activities.

5.3.2.3 De-Registration be a valid
Key Download Data Item type as defined by Table 15. If the membership in the group does impose cost value is
not valid, then depending upon mode (e.g., Terse or responsibility Verbose) either an
error is logged or an appropriate 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
departing member, value is not valid,

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

INTERNET-DRAFT GSAKMP February 2004

then the member SHOULD de-register from the group depending upon mode (e.g., Terse or Verbose) either an error
is logged or 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
the member wishes to leave. De-Registration consists of their values represent a three-message
exchange between the GM and the member's GCKS: the Request_to_Depart,
Departure_Reponse, future and not a past time value.
If the Departure_Ack. These messages SHOULD value is not valid, then depending upon mode (e.g., Terse or
Verbose) either an error is logged or an appropriate message containing
notification value Invalid-Key-Information will be done
under the protection of the GSA.

5.3.2.3.1 Request to Depart - sent.

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, GS/KS_ID, Nonce_I, Notif_Leave_Group}
SigM, [Cert]
Payload Types : GSAKMP Header, Identification, Nonce,
Notification, Signature, [Certificate]
SigM : Signature of Group Member
Cert : Necessary Certificates, zero or more
{}SigX :Indicates minimum length and counter fields used in Signature
[] : Indicate an optional data item

Any GM desiring to initiate in the De-Registration payload are used to help process MUST generate and
send the
payload. If any field is found to be incorrect, then depending upon mode
(e.g., Terse or Verbose) either an RTD error is logged or an appropriate message
containing notification value Payload-Malformed will be sent.

7.5 Rekey Event Payload

Refer to notify the GC/KS of its intent. As defined in the
disection of terminology section for the RTD message, different terms relating to keys
used within this message MUST section.

7.5.1 Rekey Event Payload Structure

The Rekey Event Payload MAY contain payloads to hold
the following information: multiple keys encrypted in Wrapping
KEKs. Figure 11 shows the GC/KS identification, Nonce payload for
freshness, and Notification format of the desire payload. If the data to leave be
contained within a Rekey Event Payload is too large for the group. The Nonce_I
value MUST payload, the
data can be saved split across multiple Rekey Event Payloads.

Figure 11: Rekey Event Payload Format

The Rekey Event Payload fields are defined as follows:

Next Payload (1 octet) - Identifier for later use. This message MUST then by signed by the
GM.

Upon receipt payload type of the RTD message, next
payload in the GC/KS MUST verify that message. If the message
header is properly formed and confirm that this message current payload is for this group the last in

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 43] 61]

INTERNET-DRAFT GSAKMP October 2003

by checking the value of the GroupID. If February 2004

the header checks pass, message, then this field will be 0. This field provides the
``chaining`` capability. Table 12 identifies the identifier value in Identification payload types. This
field is compared to its own,
the GC/KSs identity, to confirm that the GM intended treated as an unsigned value.

RESERVED (1 octet) - Unused, set to converse with
this GC/KS, 0.

Payload Length (2 octets) - Length in octets of the GC/KS who registered this member into current payload,
including the group. Then generic payload header. This field is treated as an
unsigned integer in network byte order format.

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

Table 17: Rekey Event Types

Rekey_Event_Type Value Definition
______________________________________________________________________________

None 0 This
identity type MUST be used to confirm that implemented.
In this GM 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 member 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 2 - 192
Private Use 193 - 255

Rekey Event Header (variable length) - This is the header information for
the group
serviced by Rekey Event. The format for this GC/KS. Then is defined in Section 7.5.1.1,
Rekey Event Header Structure.

Rekey Event Data(s) (variable length) - This is the GC/KS will confirm from rekey information for
the Notification Rekey Event. The format for this is defined in Section 7.5.1.2,
Rekey Event Data(s) Structure.

The Rekey Event payload that the GM type is requesting to leave the group. Then the GC/KS will
verify the signature on the message to ensure its authenticity. three (3).

7.5.1.1 Rekey Event Header Structure

The GC/KS
MUST use verified and trusted authentication material from a known root. If
all checks pass and format for the message Rekey Event Header is successfully processed, and/or shown in Figure 12.

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

INTERNET-DRAFT GSAKMP February 2004

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 12: Rekey Event Header Format

Group Identification Value (variable length) - Indicates the GC/KS name/title
of the group to be rekeyed. This is in Verbose Mode, then the GCKS MUST form a Departure_Response message same format as
defined the Group
Identification Value in section 5.3.2.3.2.

If Section 7.1 GSAKMP Message Header.

Time/Date Stamp (15 octets) -- This is the processing of time value when the message fails and/or Rekey Event
Data was generated. This field contains the GC/KS is timestamp in Terse Mode,
then the session MUST be terminated and all state associated with this
session ascii
format YYYYMMDDHHMMSSZ, where YYYY is removed.

5.3.2.3.2 Departure_Response the year (0000 - The components of a Departure_Response
Message are shown in Table 9.

Table 9: Departure_Response (DR) Message Definition

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

In response to a properly formed and verfied RTD message, 9999), MM is
the GC/KS
MUST create and send numerical value of the DR message. As defined in month (01 - 12), DD is the dissection day of the message, this message MUST contain payloads to hold month
(01 - 31), HH is the following
information: GM identification, Nonce payloads for freshness, Notification
for acceptance hour of departure, and signature information.

The nonce values transmitted MUST be the GC/KSs generated Nonce_R value and day (00 - 23), MM is the conbined Nonce_C value which was generated by using minute within
the GS/KSs Nonce_R
value and hour (00 - 59), SS is the Nonce_I value received from seconds within the GM in minute (00 - 59), and
followed by the RTD. This Nonce_C
value MUST be saved relative letter Z to indicate that this departing GMs ID.

The GM MUST be able to process is Zulu time.

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

Algorithm Version (1 octet) - Indicates the order presented.

The GM MUST verify that version of the message header is properly formed and confirm
that this message is Rekey Type
being used. For Rekey Event Type of GSAKMP_LKH, refer to Section A.2
for a description of this group by checking the value 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 GroupID. If Rekey Data. This value is treated as an unsigned
integer in network byte order.

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 44] 63]

INTERNET-DRAFT GSAKMP October 2003 February 2004

7.5.1.2 Rekey Event Data Structure

As defined in the header checks pass, 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 of the GM MUST confirm information sent. Each
Rekey Event Data, will contain all the Key Packages that this message was intended
for itself by comparing a user requires.
For each Rekey Event Data, the Member ID data following the Wrapping fields is
encrypted with the key identified in the Identification payload to
its identity. After identification confirmation, Wrapping Header. Figure 13 shows
the freshness values are
checked. The GM MUST use its saved Nonve_I value, extract 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 13: Rekey Event Data Format

Packet Length (2 octets) - Length in octets of the received
GC/KS Nonce_R value, compute Rekey Event Data, which
consists of the combined Nonce_C value, # of Key Packages and compare it to the received Nonce_C value. After freshness Key Packages(s). This value
is treated as an unsigned integer in network byte order.

Wrapping KeyID (4 octets) - This is confirmed, confirmation of the identity Key ID of the signer KEK that is being
used for encryption/decryption of the DR message 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 GMs authorized GC/KS KEK that is
performed. Then
being used for encryption/decryption of the signature MUST be verified new (rekeyed) keys. Refer
to ensure its authenticity, Section 7.4.1.1 for the values of this field.

# of Key Packages (2 octets) - The GM MUST use verified and trusted authentication material from 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 known
root. If Key
Datum. The format for this is defined in Section 7.5.1.2.1.

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

INTERNET-DRAFT GSAKMP February 2004

7.5.1.2.1 Key Package Structure

Each Key Package contains all the message signature verifies, then information about the GM MUST verify that key. Figure 14
shows the
Notification is of 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 14: Key Package Format

Key Package Type Departure_Accepted or Request_to_Depart_Error.

If the processing is successful, and the Notification payload is of (1 octet) - The type
Departure_Accepted, the member MUST form the Departure_ACK message as of key in this key package. Legal
values for this field are defined in section 5.3.2.3.3. If the processing Table 15, Key Download Data Types.
This field is successful, and treated as an unsigned value.

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

Key Datum (variable length) - The actual data of type Request_to_Depart_Error, the member MUST remove all state
associated with the action. If the member still desires to De-Register from 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 group, Rekey Event Payload, the member following fields MUST restart the De-Registration process.

5.3.2.3.3 Departure_ACK be
checked for correct values:

1. Next Payload, RESERVED, Payload Length - The components of the Departure_ACK Message These fields are
shown processed as
defined in Table 10:

Table 10: Departure_ACK (DA) Message Definition

Message Name : Departure_ACK (DA)
Dissection : {HDR-GrpID, Nonce_C, Notif_Ack}SigM Section 7.2.2, Generic Payload Types : GSAKMP Header, Nonce, Notification, Signature
SigM : Signature of Group Member
{}SigX :Indicates minimum fields used in Signature

In response Header Processing.

2. Rekey Event Type - The Rekey Event Type MUST be checked to be a properly processed Departure_Response message, the
GM MUST create and send the Departure_ACK message. As valid
rekey event type as defined in by Table 17. If the
dissection Rekey Event Type is
not valid, then regardless of the message, this mode (e.g., Terse or Verbose) an error is
logged. No response error message MUST contain payloads to hold the
following information: Nonce payload is generated for freshness, Notification payload receipt of type Acknowledgment (ACK), and signature information. a Group
Management Message.

3. Group ID Value - The nonce Group ID value
transmitted MUST be the GMs generated Nonce_C value.

Upon receipt of the Departure_ACK, the GCKS Rekey Event Header received
message MUST perform the following
checks. These checks SHOULD be performed in the order presented.

In this procedure, checked against the GC/KS will verify that GroupID of the message header Group Component. If
no match is properly
formed and confirm that this found, then regardless of mode (e.g., Terse or Verbose) an
error is logged. No response error message is generated for this group by checking the value receipt of the GroupID. If the header checks pass, the GC/KS MUST check the message
for freshness.
a Group Management Message.

4. Date/Time Stamp - The GC/KS MUST use its saved Nonve_C value, and compare it
to the received Nonce_C value. After freshness is confirmed, Date/Time Stamp value of the signature
MUST Rekey Event Header
MAY be verified checked 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 determine if the notification
type is of type ACK, this Rekey Event generation time is considered a successful processing of this

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 45] 65]

INTERNET-DRAFT GSAKMP October 2003

message. February 2004

adequate. If the processing of the time is determined not to be adequate, an error is
logged. No response error message is successful, the GC/KS MUST remove the
member from the group. This MAY involve initiating generated for receipt of a Group
Management Message.

5. Rekey Event for the
group.

If the processing Type - The Rekey Event Type of the Rekey Event Header
received 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 checked to join the group. This can be accomplished by a
well known default suite 'Security Suite 1' or valid rekey event type as
defined by announcing/posting another
suite.

6.2 Definition Suite 1

GSAKMP implementations MUST support the following suite of algorithms Table 17 and
configurations. The following definition the same value 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 Rekey Event Type earlier
in this payload. If the Rekey Event Type is
important to note that GSAKMP does not negotiate these cryptographic
mechanisms. This definition is set by the Group Owner via valid or not equal
to the Policy Token
(passed during previous value of the GSAKMP exchange for member verification purposes).

The GSAKMP Suite 1 definition Rekey Event Type, then regardless of mode
(e.g., Terse or Verbose) an error is

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

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

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

INTERNET-DRAFT GSAKMP October 2003

SHA-1

Nonce Hash algorithm is:
SHA-1 logged. No response error message
is generated for receipt of a Group Management Message.

6. Algorithm Version - The Key Creation definition is: Rekey Algorithm type Version number MUST be checked
that it 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 supported. If the version is 1024 bits long.

The digital signature algorithm is:
DSS-ASN1-DER
Hash algorithm is:
SHA-1
The digital signature ID type is:
U-NAME

7 GSAKMP Payload Structure

A GSAKMP Message not supported, then regardless
of mode (e.g., Terse or Verbose) an error is composed logged. No response error
message is generated for receipt of a GSAKMP Header (Section 7.1) followed
by at least one GSAKMP Payload. All GSAKMP Payloads Group Management Message.

The length and counter fields are composed of used to help process the
Generic Payload Header (Section 7.2) followed by message. If
any field is found to be incorrect, then termination processing MUST be
initiated.

A GM MUST process all the specific payload data. Rekey Event Datas as based on the Rekey method
used there is a potential that multiple Rekey Event Datas are for this GM.
The message 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 chained by found, then continue
processing this Rekey Event Data. Otherwise, skip to the next Rekey
Event Data.

2. Wrapping Handle - If a preceeding payload defining its succeeding
payload. The final payload in matching Wrapping KeyID was found, then the
Wrapping Handle MUST be checked against the handle of the KEK for which
the KeyID was a message match. If the handles match, then the GM will point process
the Key Packages associated with this Rekey Event Data. Otherwise, skip
to no succeeding
payload.

All fields of type integer 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 Header KEK defined by the Wrapping KeyID and Payload structure that Handle. After decrypting
the data, the GM extracts the # of Key Packages field to help process the
subsequent Key Packages. The Key Packages are
larger than one octet, processed as follows:

1. Key Package Type - The Key Package Type MUST be converted into Network Byte Order prior checked to
data transmission.

7.1 GSAKMP Header

7.1.1 GSAKMP Header Structure

The GSAKMP Header fields are be a valid
key package type as defined in Figure 4:

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

INTERNET-DRAFT GSAKMP October 2003

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! GroupID by Table 15. If the Key Package Type ! GroupID Length! 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 ID Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ! Next Payload ! Version ! Exchange Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Sequence ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

Figure 4:

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

INTERNET-DRAFT GSAKMP Header Format

Group Identification February 2004

Management Message.

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

3. Key Type (1 octet) - The Key Type MUST be checked to be a valid key type as
defined by Table 11 presents 16. If the group
identification types.

Table 11: Group Identification Types

Grp ID Key Package Type Value
______________________________________

Network Byte Ordered Integer 0
Ascii 1
Other 2-255

Group Identification Length (1 octet) - Length 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 field in
octets.

Group Identification Value (variable length) - Indicates The Key ID MUST be checked against the name/title 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 group.

Next Payload (1 octet) new
Key Handle for the Key currently associated with the Key Package's Key
ID.

6. Key Creation Date - Indicates 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 type of time
rules conform with policy. If the first payload in expiration date is not subsequent
to the
message. The format 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 each payload receipt of a Group Management Message.

8. Key Data - The Key Data is defined extracted based on the length information in
the following
sections. Table 12 presents key package.

If there were no errors when processing the payload types.

Version (1 octet) - Indicates Key Package, the version key represented
by the KeyID will have all of its data updated based upon the GSAKMP protocol in use. received
information.

7.6 Identification Payload

7.6.1 Identification Payload Structure

The current value Identification Payload contains entity-specific data used to exchange
identification information. This information is one (1).

Exchange Type (1 octet) - Indicates used to verify the type
identities of exchange (also known as members. Figure 15 shows the message type). Table 13 presents format of the exchange type values. Identification

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 48] 67]

INTERNET-DRAFT GSAKMP October 2003

Table 12: Payload Types

Next_Payload_Type Value
___________________________________

None February 2004

Payload.

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

Table 13: Exchange Types

Exchange_Type Value
___________________________________

Reserved 0 - 1 2 3
Key Download Ack/Failure 4
Rekey Event 5
Reserved 6
No Message 7
Request to Join 8
Key Download 9
Cookie Download 10
Request to Join Error 11
Ack Error 12
Other 13-255

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

INTERNET-DRAFT GSAKMP October 2003

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

Figure 15: Identification Payload Format

The Identification Payload fields are defined as follows:

Next Payload (1 octet) - Group Management replay protection field.
Sequence ID Identifier for group management messages. If not a group management
message, this value MUST be set to zero (0). When a (S-)GC/KS is
initiated, it MUST set its initial sequence ID value to one (1). For
each distinct group management message that this (S-)GC/KS transmits,
this value MUST be incremented by one (1). Receivers the payload type of this group
management message MUST confirm that the value received is greater that next
payload in the value of message. If the sequence ID received with current payload is the last group management
message from in
the message, then this (S-)GC/KS. GMs MUST also recognize receipt of a Group
Management messages that suffer from rolloever and handle accordingly. 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 (4 (2 octets) - Length of total message (header + payloads) in octets.

7.1.2 GSAKMP Header Processing

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

1. GroupID - The GroupID octets of the received message MUST match the GroupID of current payload,
including the processing member.

2. Next Payload - The Next Payload value MUST be a valid generic payload header. This field is treated as an
unsigned integer in network byte order format.

Identification (ID) Type (1 octet) - Specifies the type of Identification
being used. Table 18 identifies possible values for this type. This
field is treated as
defined by an unsigned value.

Table 12.

3. Version - The GSAKMP version numbers MUST match.

4. Exchange Type 18: Identification Types

ID_Type Value Description
_______________________________________________________________________________

Reserved 0 - The Exchange Type 29
Sender Unencoded Name 30 This type MUST be a valid exchange implemented.
(S-U-NAME) The format for this type as
defined by Table 13 is identical
to U-NAME, and is defined in
Section 7.6.1.1.
Receiver Unencoded Name 31 This type MUST be of the implemented.
(R-U-NAME) The format for this type expected is identical
to receive.

5. Sequence ID U-NAME, and is defined in
Section 7.6.1.1.
Reserved 32 - 192
Private Use 193 - 255

Identification Data (variable length) - Contains identity information.

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

INTERNET-DRAFT GSAKMP February 2004

The Sequence ID value MUST be of the correct value. For
negotiation messages this value MUST be zero (0). For group management
messages, values for this value MUST be greater than field are group-specific and the format is
specified by the last sequence ID received
from this (S-)GC/KS. Type field. The length fields in the GSAKMP Header are used to help process the message.
If any format for this field is found to be incorrect, then termination processing MUST be
initiated.

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

INTERNET-DRAFT GSAKMP October 2003

7.2 Generic Payload Header

7.2.1 Generic Payload Header Structure

Each GSAKMP payload defined stated in the following sections begins
conjunction with a generic
header, shown the type in Figure 5, which provides a Table 18.

The payload ``chaining`` capability
and clearly defines type for the boundaries of a payload. The Generic Identification Payload Header
fields are defined as follows: is four (4).

7.6.1.1 U-NAME Structure

The format for type Unencoded Name (U-NAME) is shown in Figure 16.
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 Serial Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ! RESERVED
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DN Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

Figure 5: Generic Payload Header

Next Payload (1 octet) - Identifier for the payload type of the next
payload 16: Unencoded Name (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 message. If the current payload DN Data field. This field is the last
treated as an unsigned integer in network byte order format.

DN Data (variable length) -- The actual ascii DN value (Subject
field) using the message, then this field will be 0. This slash (/) character for field provides delimiters. (e.g.,
"/C=US/ST=MD/L=Somewhere/O=ACME, Inc./OU=DIV1/CN=user1/Email=user1@acme.com"
without the
``chaining`` capability. Table 12 identifies surrounding quotes)

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

INTERNET-DRAFT GSAKMP February 2004

7.6.2 Identification Payload Processing

When processing the payload types.

RESERVED (1 octet) - Unused, set to 0. Identification Payload, the following fields MUST be
checked for correct values:

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

2. Identification Type - The Identification Type value MUST be checked to
be a valid identification type as defined by Table 18. If the value is
not valid, then depending upon mode (e.g., Terse or Verbose) either an
error is logged or an appropriate message containing notification value
Payload-Malformed will be sent.

3. Identification Data - This Identification Data MUST be processed
according to the identification type specified. The type will define
the format of the current payload,
including data. If the generic payload header.

7.2.2 Generic Payload Header identification data is being used to
find a match an no match is found, then depending upon mode (e.g.,
Terse or Verbose) either an error is logged or an appropriate message
containing notification value Invalid-ID-Information will be sent.

7.6.2.1 U-NAME Processing

When processing the Generic Payload Header, Identification Data of type U-NAME, the following fields
MUST be checked for correct values:

1. Next Payload Serial Number - The Next Payload value serial number MUST be a valid payload type as
defined by Table 12.

2. RESERVED - This field MUST contain the positive value zero (0).

The length field in the Generic Payload Header is used to process the
remainder of the payload. be a
valid serial number from a conforming CA. If any field the value is found to be incorrect, not valid,
then
termination processing MUST depending upon mode (e.g., Terse or Verbose) either an error
is logged or an appropriate message containing notification value
Payload-Malformed will be initiated.

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

INTERNET-DRAFT GSAKMP October 2003

7.3 Policy Token Payload

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

Figure 6: Policy Token Payload Format sent.

2. DN Data - The Policy Token Payload fields are defined DN data is process as follows:

Next Payload (1 octet) - Identifier for the payload type an ascii string.

These 2 pieces of the next
payload in the message. If the current payload is the last information, Serial Number and DN Data, in the
message, then this field conjunction
will then be 0.

RESERVED (1 octet) - Unused, set used for party identification. These values are also used to 0.

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

Policy Token (PT) Type (2 octets) - Specifies the type of Policy Token
being used. Table 14 identifies
help identify the types of policy tokens.

Table 14: Policy Token Types

PT_Type Value Definition
____________________________________________________________________________

GSAKMP_V1_PT 0 certificate when necessary.

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

INTERNET-DRAFT GSAKMP February 2004

7.7 Certificate Payload

7.7.1 Certificate Payload Structure

The format for this Policy Token is specified Certificate Payload provides a means to transport certificates or other
certificate-related information via GSAKMP and can appear in [HCLM00].
GSAKMP_ASN.1_PT 1 All implementations any GSAKMP
message. Certificate payloads SHOULD be included in an exchange whenever an
appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available
to distribute certificates. 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 support
this Policy Token format. This format is
specified in TBD.
Reserved 2-65535

Policy Token Data (variable length) - Contains Policy Token information.
The values rely on some other
mechanism to retrieve certificates for this field are token specific and verification purposes. Figure 17
shows the format is specified
by format of the PT Type field.

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

INTERNET-DRAFT GSAKMP October 2003 Certificate Payload.

Figure 7: Key Download 17: Certificate Payload Format

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.4 Key Download Payload

The Key Download Payload contains group keys (eg., group keys, initial
rekey keys, etc.). These key download payloads can have several security
attributes applied to them based upon the security policy of the group.
Figure 7 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 type of encryption used is
specified in the Policy Token. The group members MUST create the KEK using
the key creation method identified in the Key Creation Payload.

The Key Download 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.

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

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

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

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 53]

INTERNET-DRAFT GSAKMP October 2003

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

Table 15: Key Download Data Types

Key Download Data an
unsigned integer in network byte order format.

Certificate Type Value
________________________________

GTEK 0
Rekey - LKH 1
Unassigned 2-255

Key Download Length (2 octets) -- Length in octets - This field indicates the type of certificate
or certificate-related information contained in the Key
Packet data following this Certificate Data
field.

Key Packet Table 19 presents the types of certificate payloads. This field
is treated as an unsigned integer in network byte order format.

Certificate Data (variable length) -- Contains Key information. - Actual encoding of certificate data.
The format type of this field certificate is specific depending on the value of indicated by the Key Download Data Certificate Type/Encoding
field.

If this

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

INTERNET-DRAFT GSAKMP February 2004

Table 19: Certificate Payload Types

Certificate_Type Value
__________________________________________________________________

None 0
Reserved 1 - 3
X.509v3 Certificate -- Signature - DER Encoding 4
Reserved 5 -- 49152
Private Use 49153 -- 65535

The payload is encrypted, only type for the Key Download Data field Certificate Payload is encrypted.

For a Key Download Data value of GTEK, six (6).

7.7.2 Certificate Payload Processing

When processing the Key Packet Data field format is 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 A.1.1.

For a Key Download Data 7.2.2, Generic Payload Header Processing.

2. Certificate Type - The Certificate Type value of Rekey, MUST be checked to be a
valid certificate type as defined by Table 19. If the Key Packet Data field format value is
defined in Section A.1.2. not
valid, then depending upon mode (e.g., Terse or Verbose) either an
error is logged or 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 payload type for will define the Key Download Packet is two (2).

7.5 Rekey Event format of the
data.

7.8 Signature Payload

7.8.1 Signature Payload Structure

The Rekey Event Signature Payload MAY contain multiple keys encrypted in Rekey keys.
These Rekey Event payloads can have several security attributes applied to
them based upon contains data generated by the security policy digital signature
function. The digital signature, as defined by the dissection of each
message, covers the group. message from the GSAKMP Message Header through the
Signature Payload up to but not including the Signature Data Length.
Figure 8 18 shows the format of the payload. Signature Payload.

The Rekey Event Signature Payload fields are defined as follows:

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

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

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

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 54] 72]

INTERNET-DRAFT GSAKMP October 2003 February 2004

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 18: Signature Payload Format

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

Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Rekey Type ! Rekey Event Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

Figure 8: Rekey Event Payload Format (2 octets) - Length in octets of the current payload,
including the generic payload header.

Rekey This field is treated as an
unsigned integer in network byte order format.

Signature Type (1 octet) - Specifies (2 octets) -- Indicates the type of Rekey Event being used. signature. Table 16 20
presents the types of Rekey events.

Table 16: Rekey Event Types

Rekey_Type Value Definition
______________________________________________________________________________

None 0 allowable signature types. This type MUST be implemented. In this case, field is treated as an
unsigned integer in network byte order format.

Signature ID Type (1 octet) -- Indicates the
size of format for the Rekey Event Data field will be zero byes
long. Signature ID
Data. Table 21 presents the allowable signature ID types. The purpose of a Rekey Event Payload with
type None formats
for these types are defined within the table. This field is treated as
an unsigned value.

Signature Timestamp (15 octets) -- This is the time value when it the digital
signature was applied. This field contains the timestamp in the ascii
format YYYYMMDDHHMMSSZ, where YYYY is necessary to send out a new
token the year (0000 - 9999), MM is

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

INTERNET-DRAFT GSAKMP February 2004

Table 20: Signature Types

Signature Type Value Description
________________________________________________________________________

DSS/SHA1 with no rekey information. GSAKMPekey Msg
requires a Rekey Event PL, and in this instance it
would have rekey data of ASN.1/DER encoding 0 This type None.
GSAKMP_LKH MUST be
(DSS-SHA1-ASN1-DER) supported.
Reserved 1 The rekey data will by of - 41952
Private Use 41953 - 65536

Table 21: Signature ID Types

Signature ID Type Value Description
_______________________________________________________________________________

Unencoded Name (U-NAME) 0 This type LKH formatted
according to GSAKMP. MUST be supported.
The format for this field type is defined
in Section B.2.
Unassigned 2-255

Rekey Event Data (variable length) 7.6.1.1, U-NAME Structure.
Reserved 1 - Contains Rekey Event information.
The values for this field are group specific and 192
Private Use 193 - 255

the format is specified
by numerical value of the Rekey Type field.

The Rekey Event payload type is three (3).

7.6 Identification Payload

The Identification Payload contains entity-specific data used to exchange
identification information. This information month (01 - 12), DD is used to verify the
identities day of members. Figure 9 shows the format month
(01 - 31), HH is the hour of the Identification
Payload.

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 55]

INTERNET-DRAFT GSAKMP October 2003

Figure 9: Identification Payload Format

The Identification Payload fields are defined as follows:

Next Payload (1 octet) day (00 - Identifier for 23), MM is the payload type 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.

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

Signer ID Data (variable length) -- Data identifying the message. If Signer's ID
(e.g., DN). The format for this field is based on the current payload Signature ID
Type field and is shown where that type is the last in the
message, then defined. The contents of
this field will MUST be 0.

RESERVED (1 octet) - Unused, set checked against the Policy Token to 0.

Payload determine the
authority and access of the Signer within the context of the group.

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

Identification (ID) Type (1 octet) - Specifies the type of Identification
being used. Table 17 identifies possible values for this type.

Table 17: Identification Types

ID_Type Value

____________________________________________
Sender Unencoded Name (S-U-NAME) 0
Receiver Unencoded Name (R-U-NAME) 1
Unassigned 2-255

Identification Signature Data.
This field is treated as an unsigned integer in network byte order
format.

Signature Data (variable length) - Contains identity information.
The values for this field are group-specific and Data that results from applying the format is
specified by
digital signature function to the ID Type field. The format for this field is defined in
Section A.2.1 GSAKMP message and/or payload.

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

7.7 Certificate Payload

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

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 56] 74]

INTERNET-DRAFT GSAKMP October 2003

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. Figure 10 shows the format of the Certificate
Payload.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next GSAKMP February 2004

7.8.2 Signature Payload ! RESERVED ! Processing

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

1. Next Payload, RESERVED, Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Cert Type ! Certificate Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

Figure 10: Certificate Payload Format

The Certificate Payload - These fields are defined processed as follows:

Next
defined in Section 7.2.2, Generic Payload (1 octet) Header Processing.

2. Signature Type - Identifier for the payload The Signature Type value MUST be checked to be a
valid signature type of the next
payload in the message. as defined by Table 20. If the current payload value is the last in the
message, not
valid, then this field depending upon mode (e.g., Terse or Verbose) either an
error is logged or an appropriate message containing notification value
Payload-Malformed will be 0.

RESERVED (1 octet) sent.

3. Signature ID Type - Unused, set The Signature ID Type value MUST be checked to 0.

Payload Length (2 octets) - Length in octets of be
a valid signature ID type as defined by Table 21. If the current payload,
including value is
not valid, then depending upon mode (e.g., Terse or Verbose) either an
error is logged or an appropriate message containing notification value
Payload-Malformed will be sent.

4. Signature Timestamp - This field MAY be checked to determine if the generic payload header.

Certificate Type (2 octets)
transaction signing time is adequate.

5. Signature ID Data - This field indicates will be used to identify the type of certificate
or certificate-related sending
party. This information contained in MUST then be used to confirm that the Certificate Data
field. Table 18 presents correct
party sent us this information. This field is also used to retrieve the types
appropriate public key of the certificate payloads.

Table 18: Certificate Payload Types

Certificate_Type Value
____________________________________________________________

None 0
Reserved 1 - 3
X.509 Certificate -- to verify the message.

6. Signature - DER Encoding 4
Reserved 5 -- 65534

Certificate Data (variable length) - Actual encoding of certificate data.
The type 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 is indicated identified by the Certificate Type/Encoding
field.

The payload type Signature ID Data is
verified can the signature be computed to compare to the signature data
for signature verification.

The length fields in the Certificate Signature Payload are used to process the remainder
of the payload. If any field is six (6).

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 57]

INTERNET-DRAFT GSAKMP October 2003

7.8 Signature found to be incorrect, then termination
processing MUST be initiated.

7.9 Notification Payload

7.8.1 Signature

7.9.1 Notification Payload Structure

The Signature Notification Payload contains can contain both GSAKMP and group specific data generated by the digital signature
function. The digital signature covers the Signature Payload Span
and
the Signature Payload up is used to but not including the Signature Data Length. transmit informational data, such as error conditions, to

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

INTERNET-DRAFT GSAKMP February 2004

a GSAKMP peer. It is possible to send multiple independent Notification
payloads in a single GSAKMP message. Figure 11 19 shows the format of the Signature
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Signature Type! Sig ID Type ! Signature Payload Span ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ! Signature Timestamp ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ ! Signer ID Lenth !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Signer ID Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Signature Payload Length ! Signature Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~
! Notification Type ! Notification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

Figure 11: Signature 19: Notification Payload Format

The Signature Notification Payload fields are defined as follows:

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

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

Signature This field is treated as an
unsigned integer in network byte order format.

Notification Type (1 octet) -- Indicates (2 octets) - Specifies the type of signature. Table 19
presents the allowable signature types.

Signature ID Type (1 octet) -- Indicates the format for the Signature ID
Data. notification message.
Table 20 22 presents the allowable signature ID types. The formats
for these types are defined in Section A.2.1

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 58]

INTERNET-DRAFT GSAKMP October 2003

Table 19: Signature Types

Signature Type Value
____________________________________________________

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

Table 20: Signature Types

Signature ID Type Value
_________________________________

Unencoded Name (U-NAME) 0
Other 1-255

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

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

Signer ID Length (2 octets) - Length is treated as an
unsigned integer in octets of the Signer' ID.

Signer ID network byte order format.

Notification Data (variable length) -- Data identifying - Informational or error data
transmitted in addition to the Signer's ID
(e.g., DN). The format Notify Payload Type. Values for this
field is based on the Signature ID
Type field and is shown where that are Domain of Interpretation (DOI)-specific.

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

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

INTERNET-DRAFT GSAKMP February 2004

Table 22: Notification Types

Notification Type Value
________________________________________________

None 0
Invalid-Payload-Type 1
Situation-Not-Supported 2
Reserved 3
Invalid-Version 4
Invalid-Group-ID 5
Invalid-Sequence-ID 6
Payload-Malformed 7
Invalid-Key-Information 8
Invalid-ID-Information 9
Invalid-Cert-Encoding 10
Invalid-Certificate 11
Cert-Type-Unsupported 12
Invalid-Cert-Authority 13
Authentication-Failed 14
Invalid-Signature 15
Notify-GSA-Lifetime 16
Certificate-Unavailable 17
Unequal-Payload-Lengths 18
Unauthorized-Request 19
Unable-To-Take-Requested-Role 20
Reserved 21 - 22
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
Reserved 34 - 49152
Private Use 49153 -- 65535

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

INTERNET-DRAFT GSAKMP February 2004

7.9.1.1 Notification Data - Acknowledgment (ACK) Payload Type

The contents data portion of
this field MUST be checked against the Policy Token to determine the
authority and access Notification payload of the Signer within the context type ACK serves either
for confirmation of correct receipt of the group.

Signature Length (2 octets) -- Length Key Download message, or, when
needed, can provide other receipt information when included in octets a signed
message. Figure 20 shows the format of the Signature Data.

Signature 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 (variable length) - ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

Figure 20: Notification Data that results from applying the
digital signature function to the GSAKMP message and/or payload.

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

7.8.2 Signature - Acknowledge Payload Processing

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

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 59]

INTERNET-DRAFT GSAKMP October 2003

1. Signature Type - Format

The Signature Notification Data - Acknowledgment Payload Type value MUST be a valid signature type
as data fields are defined by Table 19.

2. Signature ID
as follows:

Ack Type (1 octet) - The Signature ID Type value MUST be a valid
signature ID Specifies the type of acknowledgment. Table 23
presents the Notify Acknowledgment Payload Types. This field is treated
as defined by an unsigned value.

Table 20.

3. Signature Span 23: Acknowledgment Types

ACK_Type Value Definition
________________________________________________

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

7.9.1.2 Notification Data - Cookie_Required and Cookie Payload Type

The signature span values MUST encompass data portion of the payloads
as defined by Notification payload of types Cookie_Required and
Cookie contain the message disection Cookie value. The value for this message type.

4. Signature ID Data - This field will be used to identify have been
computed by the sending
party. This information MUST then be used, when applicable, responder GC/KS and sent to confirm
that the correct party sent us this information.

5. Signature GM. The GM will take the
value received and copy it into the Notification payload Notification Data - This
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 compared to the recomputed signature
to verify the message. modified.

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

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

INTERNET-DRAFT GSAKMP February 2004

7.9.1.3 Notification Data - Mechanism Choices Payload are used to process Type

The data portion of the remainder Notification payload of types Mechanism Choices
contains the payload. If any field mechanisms the GM is found requesting to use for the negotiation with
the GC/KS. This information will be incorrect, then termination
processing MUST be initiated.

7.9 Notification Payload

The Notification Payload can contain both GSAKMP and group specific data
and is used to transmit informational data, such as error conditions, to
a GSAKMP peer. It is possible to send multiple independant Notification
payloads supplied by the GM in a single GSAKMP RTJ message.
Figure 12 21 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.

Figure 12: Notification Payload Format

The 21: Notification Payload fields are defined as follows:

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

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

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 60]

INTERNET-DRAFT GSAKMP October 2003 Mechanism Choices Payload Length (2 octets) Type Format

The Notification Data - Length in octets of the current payload,
including the generic payload header.

Notify Mechanism Choices Payload Type (2 octets) data fields are
defined as follows:

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

Table 21: Notify Payload 24: Mechanism Types

Notification Type

Mechanism_Type Value
_______________________________________________

None Mechanism Choice
Data Value Table Reference
___________________________________________________________________

Key Creation Algorithm 0
Invalid-Payload-Type Table 26
Encryption Algorithm 1
Situation-Not-Supported 2
Invalid-Major-Version 3
Invalid-Version 4
Invalid-Group-ID 5
Invalid-Sequence-ID 6
Payload-Malformed 7
Invalid-Key-Information 8
Invalid-ID-Information 9
Invalid-Cert-Encoding 10
Invalid-Certificate 11
Cert-Type-Unsupported 12
Invalid-Cert-Authority 13
Authentication-Failed 14
Invalid-Signature 15
Notify-GSA-Lifetime Table 16
Certificate-Unavailable 17
Unequal-Payload-Lengths 18
Unauthorized-Request 19
Unable-To-Take-Requested-Role 20
Nonce Hash Algorithm 2 Table 25
Reserved 21 3 - 22
Acknowledgement 23
Reserved 24 192
Private Use 193 - 25
Nack 26
Cookie-Required 27
Cookie 28 255

Mechanism Choices 29
Leave Group 30
Departure Accepted 31
Request Choice Data (2 octets) - The data value for the mechanism type
being selected. The values are specific to Depart Error 32 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-05.txt [Page 79]

INTERNET-DRAFT GSAKMP February 2004

Table 25: Nonce Hash Types

Nonce_Hash_Type Value Description
_________________________________________________________________

Reserved (future use) 33 0
SHA-1 1 This type MUST be supported.
Reserved 2 - 8191 49152
Private Use 8192 -- 16383 49153 - 65535

7.9.2 Notification Data (variable length) Payload Processing

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

1. Next Payload, RESERVED, Payload Length - Informational or error data
transmitted These fields are processed as
defined in addition to the Notify Section 7.2.2, Generic Payload Type. Values for this
field are Domain of Interpretation (DOI)-specific.

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 61]

INTERNET-DRAFT GSAKMP October 2003 Header Processing.

2. Notification Type - The payload Notification type for value MUST be checked to
be a notification type as defined by Table 22. If the Notification Payload value is nine (9).

7.9.1 not
valid, then depending upon mode (e.g., Terse or Verbose) either an
error is logged or an appropriate message containing notification value
Payload-Malformed will be sent.

3. Notification Data - Acknowledgement (ACK) Payload Type This Notification Data MUST be processed according
to the notification type specified. The data portion of type will define the Notification payload format of
the data. When processing this data, any type ACK serves either field MUST be checked
against the appropriate table for confirmation of correct receipt values. If the contents of
the Notification Data are not valid, then depending upon mode (e.g.,
Terse or Verbose) either an error is logged or an appropriate message
containing notification value Payload-Malformed will be sent.

7.10 Key Download message, or, when
needed, can provide other receipt Creation Payload

7.10.1 Key Creation Payload Structure

The Key Creation Payload contains information when included used to create key encryption
keys. The security attributes for this payload are provided in a signed
message. the Policy
Token. Figure 13 22 shows the format of the Notification Data - Acknowledge payload.

The Key Creation Payload Type. fields are defined as follows:

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

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

INTERNET-DRAFT GSAKMP February 2004

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 Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Key Creation Type ! Acknowledgement Key Creation Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

Figure 13: Notification Data - Acknowledge 22: Key Creation Payload Type Format

The Notification Data

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) - Acknowledgement Unused, set to 0.

Payload Type data fields are defined Length (2 octets) - Length in octets of the current payload,
including the generic payload header. This field is treated as follows:

Ack an
unsigned integer in network byte order format.

Key Creation Type (1 octet) (2 octets) - Specifies the type of acknowledgement. Key Creation being
used. Table 22
presents 26 identifies the Notify Acknowledgement Payload Types. types of key creation information. This
field is treated as an unsigned integer in network byte order format.

Table 22: Acknowledgement 26: Types

ACK_Type Of Key Creation Information

Key Creation Type Value Definition
___________________________________________

Simple
_________________________________________________________________________

Reserved 0 Data portion null.
Unassigned 1-255

7.9.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 1
Diffie-Hellman 2 This 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. supported.
1024-bit MODP Group This is defined in IKEv2 B.2.
Reserved 3 - 13
Diffie-Hellman 14 This is defined in RFC 3526.
2048-bit MODP Group
Reserved 15 - 49152
Private Use 49153 - 65535

Key Creation Data (variable length) - Contains Key Creation information.
The format values for this field are group specific and the format is already described in specified
by the discussion on cookies in
section 5.2.2. key creation type field.

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

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 62] 81]

INTERNET-DRAFT GSAKMP October 2003

7.9.3 Notification Data - Mechanism Choices February 2004

7.10.2 Key Creation Payload Type Processing

The data portion specifics of the Notification payload of types Mechanism Choices
contains Key Creation Payload are defined in section 7.10.

When processing the mechanisms Key Creation Payload, the GM 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 requesting
not valid, then depending upon mode (e.g., Terse or Verbose) either an
error is logged or an appropriate message containing notification value
Payload-Malformed will be sent.

3. Key Creation Data - This Key Creation Data MUST be processed according
to use for the negotiation with key creation type specified to generate the KEK to protect the GC/KS. This
information will to be supplied by the GM sent in a RTJ appropriate message.
Figure 14 shows The type will define the
format of the Notification Data - Mechanism Choices data.

7.11 Nonce Payload Type. Multiple type!length!data choices are strung togther in one
notification payload to allow a user to transmit all relevant information
within one Notification Payload.

7.11.1 Nonce Payload Structure

The length of the payload will contol Nonce Payload contains random data used to guarantee freshness during an
exchange and protect against replay attacks. Figure 23 shows the
parsing format of
the Notification Data Mechanism Choices field. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Mech Type Next Payload ! RESERVED ! Payload Length ! Mechanism Choice
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Nonce Type ! Nonce Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ...

Figure 14: Notification Data 23: Nonce Payload Format

The Nonce Payload fields are defined as follows:

Next Payload (1 octet) - Mechanism Choices Identifier for the payload type of the next
payload in the message. If the current payload is the last in

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

INTERNET-DRAFT GSAKMP February 2004

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 Format (1 octet) - Specifies the type of Nonce being used. Table 27
identifies the types of nonces. This field is treated as an unsigned
value.

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 4 - 192
Private Use 192 - 255

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

The Notification Data - Mechanism Choices payload type for the Nonce Payload Type data is twelve (12).

7.11.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
defined processed as follows:

Mechanism
defined in Section 7.2.2, Generic Payload Header Processing.

2. Nonce Type (1 octet) - Specifies the The Nonce Type value MUST be checked to be a valid nonce

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

INTERNET-DRAFT GSAKMP February 2004

type of mechanism. as defined by Table 23
presents 27. If the Notify Mechanism Choices Mechanism Types.

Table 23: Mechanism Types

Mechanism_Type Value Mechanism Choice Data Value Table Reference
________________________________________________________________________________

Key Creation Algorithm 0 Table 26
Encryption Algorithm 1 Table 24 value is not valid, then depending
upon mode (e.g., Terse or Verbose) either an error is logged or an
appropriate message containing notification value Payload-Malformed will
be sent.

3. Nonce Hash Algorithm 2 Table 25
Unassigned 1-255

Length (1 octet) -- Length in octets of the Mechanism Choice Data.

Mechanism Choice Data (variable length) - The data value for This is the mechanism
type being selected. The values are specific nonce data and it must be checked according
to each Mechanism Type
defined. All tables necessary its content. The size of this field is defined in Nonce Payload
section 7.11. Refer to define the values that are not defined
elsewhere (in Message Processing Group Establishment
section (Section 5.2) for interpretation of this field.

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

INTERNET-DRAFT GSAKMP February 2004

8 GSAKMP State Diagram

Figure 24 presents the states encountered in the use of this specification or others) are defined here. 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 24: GSAKMP State Diagram

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 63] 85]

INTERNET-DRAFT GSAKMP October 2003

Table 24: Encryption Types

Encryption_Types Value
____________________________

Reserved 0 - 2
3DES_CBC64_192 3
Unassigned 4 - 16k February 2004

Table 25: Nonce Hash Types

Nonce_Hash_Type Value
__________________________

Reserved 0
SHA-1 1
Unassigned 2 - 16k

7.10 Key Creation Payload

7.10.1 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 Creation Payload Structure

The Download,
from Key Creation Payload contains information used to create key encryption
keys. The security attributes Download : waiting for this payload are provided in the Policy
Token. Figure 15 shows the format response from GM
_____________________:_____________________________________________________
:
Wait for Group : GM in process 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 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-05.txt [Page 86]

INTERNET-DRAFT GSAKMP February 2004

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
_______________:____________________________________________________
:
Transition 3 : Receive valid RTJ
_______________:____________________________________________________
:
Transition 4 : Timeout
: Receive Ack
: Receive Nack
_______________:____________________________________________________
:
Transition 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Key Crtn Type ! Key Creation Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

Figure 15: Key Creation Payload Format

The Key Creation Payload fields are defined as follows:

Next Payload (1 octet) - Identifier for the payload type : Delete group command
_______________:____________________________________________________
:
Transition 1a : Join group command
_______________:____________________________________________________
:
Transition 2a : Send Ack
_______________:____________________________________________________
:
Transition 3a : Receipt of the next
payload in the message. If the current payload is the last in the
message, then this field will be 0.

RESERVED (1 octet) - Unused, set to 0. group management messages
_______________:____________________________________________________
:
Transition 4a : Delete group command
_______________:____________________________________________________
:
Transition 5a : Time out
: Msg failure
: errors
:

____________________________________________________________________

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 64] 87]

INTERNET-DRAFT GSAKMP October 2003

Payload Length (2 octets) - Length February 2004

9 IANA Considerations

9.1 IANA Port Number Assignment

IANA has provided GSAKMP port number 3761 in octets of the current payload,
including the generic payload header.

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

Table 26: Types Of Key Creation Information

Key Creation Type Value Definition
____________________________________________________________

Reserved 0
Diffie-Hellman 1 This type UDP and TCP spaces.
All implementations MUST be supported.
other 2-255

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

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

7.10.2 Key Creation Payload Processing

The specifics of the Key Creation Payload are defined port assignment in section 7.10.

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

1. Key Creation Type - appropriate manner.

9.2 Initial IANA Registry Contents

The Key Creation Type value MUST following registry entries should be a valid key
creation type as defined by Table 26.

2. created:

GSAKMP Group Identification Types
GSAKMP Payload Types
GSAKMP Exchange Types
GSAKMP Policy Token Types
GSAKMP Key Creation Download Data - This data will be used to compute the key encryption
key (KEK).

If any field is found to be incorrect, then termination processing MUST be
initiated.

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 65]

INTERNET-DRAFT Item Types
GSAKMP Encryption Types
GSAKMP Rekey Event Types
GSAKMP Identification Types
GSAKMP Certificate Types
GSAKMP Signature Types
GSAKMP Signature ID Types
GSAKMP Notification Types
GSAKMP Acknowledgment Types
GSAKMP Mechanism Types
GSAKMP October 2003

7.11 Nonce Payload

7.11.1 Hash Types
GSAKMP Key Creation Types
GSAKMP Nonce Payload Structure Types

9.2.1 GSAKMP Group Identification Types

The Nonce Payload contains random data used to guarantee freshness during an
exchange and protect against replay attacks. Figure 16 shows the format of Group Identification occurs in the Nonce Payload.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 GSAKMP header.

Group ID Type Value
==========================================
Network Byte Ordered Integer 0
ASCII 1
Reserved to IANA 2 3 4 5 6 7 8 9 - 192
Private Use 193 - 255

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

INTERNET-DRAFT GSAKMP February 2004

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 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Nonce Type ! Nonce Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

Figure 16: Nonce Payload Format

The
Reserved 10
Key Creation 11
Nonce Payload fields are defined as follows:

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

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

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

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

Table 27: Nonce 192
Private Use 193 -- 255

9.2.2.1 Amending formula for GSAKMP Payload Types

Nonce_Type

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

None
========================================
Reserved 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
Security Suite Definition.
Unassigned 4-255

Nonce Data (variable length)
Key Download Ack/Failure 4
Rekey Event 5
Reserved 6 - Contains the nonce information. The values 7
Request to Join 8
Key Download 9
Cookie Download 10
Request to Join Error 11

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 66] 89]

INTERNET-DRAFT GSAKMP October 2003

for this field are group-specific and the format is specified by the
Nonce Type field. If no group-specific information is provided, the
minimum length for this field is 4 bytes.

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

7.11.2 Nonce Payload Processing

The specifics February 2004

Lack of the Nonce Payload are defined in section 7.11.

When processing the Nonce Payload, the following fields MUST be checked 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
correct values:

1. Nonce 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
====================================================
GSAKMP`PT`V1 0 (HCLM00)
GSAKMP`ASN.1`PT`V1 1 (TBD)
Reserved to IANA 2 - The Nonce Type value MUST 49152
Private Use 49153 - 65535

9.2.4.1 Amending formula for GSAKMP Policy Token Types

GSAKMP Policy Token Types may be a valid key creation type as
defined allocated by Table 27.

2. Nonce Specification Required.

9.2.5 GSAKMP Key Download Data - This is the nonce data and it must be checked according
to its type. Item Types

The size of this field is defined Key Download Data Item Type occurs in Nonce Payload
section 7.11.

It any value is found 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 incorrect, then termination processing MUST be
initiated. allocated by Specification
Required.

Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt Meth, Colegrove, Gross draft-ietf-msec-gsakmp-sec-05.txt [Page 67] <