idnits 2.17.1 draft-ietf-msec-tgsakmp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 369 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1245: '...ificate payloads SHOULD be included in...' RFC 2119 keyword, line 1247: '...ertificate payload MUST be accepted at...' RFC 2119 keyword, line 1306: '... Request payload MUST be accepted at a...' RFC 2119 keyword, line 1307: '...tificate Request payload MUST send its...' RFC 2119 keyword, line 1310: '...Request payloads SHOULD be transmitted...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2003) is 7645 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'CertM' on line 678 looks like a reference -- Missing reference section? 'Certificate' on line 761 looks like a reference -- Missing reference section? 'Identification' on line 681 looks like a reference -- Missing reference section? 'Authorization' on line 681 looks like a reference -- Missing reference section? 'CertC' on line 759 looks like a reference -- Missing reference section? 'SigSC' on line 658 looks like a reference -- Missing reference section? 'CertSC' on line 658 looks like a reference -- Missing reference section? 'Signature' on line 533 looks like a reference -- Missing reference section? 'Vendor ID' on line 761 looks like a reference -- Missing reference section? 'ID_R' on line 678 looks like a reference -- Missing reference section? 'DNSSEC' on line 1305 looks like a reference -- Missing reference section? 'RFC 2093' on line 2013 looks like a reference -- Missing reference section? 'RFC 2094' on line 2016 looks like a reference -- Missing reference section? 'RFC 2104' on line 2019 looks like a reference -- Missing reference section? 'RFC 2408' on line 2022 looks like a reference -- Missing reference section? 'RFC 2409' on line 2026 looks like a reference -- Missing reference section? 'RFC 2412' on line 2029 looks like a reference -- Missing reference section? 'RFC 2402' on line 2035 looks like a reference -- Missing reference section? 'RFC 2401' on line 2038 looks like a reference -- Missing reference section? 'RFC 2406' on line 2041 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 24 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPARTA, Inc. H Harney (SPARTA) 3 INTERNET-DRAFT A Colegrove (SPARTA) 4 E Harder (NSA) 5 U Meth (SPARTA) 6 R Fleischer (SPARTA) 7 SPARTA, Inc., National Security Agency 8 draft-ietf-msec-tgsakmp-00.txt May 2003 10 Tunneled Group Secure Association Key Management Protocol 12 Status of this memo 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC2026. Internet-Drafts are working documents 16 of the Internet Engineering Task Force (IETF), its areas, and its working 17 groups. Note that other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months and 21 may be updated, replaced, or obsoleted by other documents at any time. It 22 is inappropriate to use Internet-Drafts as reference material or to cite 23 them other than as ``work in progress''. 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Document expiration: October 31, 2003 33 Abstract 35 The Tunneled Group Secure Association Key Management Protocol 36 (T-GSAKMP) provides a security framework for creating cryptographic 37 groups on a network. It is designed to provide key distribution 38 services under the cryptographic protection of a pairwise SA, 39 like IPSec. T-GSAKMP relies on the pairwise SA to provide data 40 confidentiality services for policy, DoS mitigation services, 41 and protection from "man-in-the-middle" attacks. It provides 42 mechanisms to disseminate group security policy, perform access 43 control based upon PKI certificates, generate group keys, 44 and recover from compromise. This framework addresses group 45 scalability issues by facilitating delegation of process-intensive 46 actions in a secure and controlled manner. 48 Copyright Notice 50 Copyright (c) The Internet Society (2003). All Rights Reserved. 52 Contents 54 1 Background 7 56 2 Overview 7 57 2.1 T-GSAKMP Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 2.3 Document Organization . . . . . . . . . . . . . . . . . . . . . . . 9 60 3 Terminology 10 61 3.1 T-GSAKMP Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 63 4 GROUP LIFE-CYCLE 13 64 4.1 Group Establishment . . . . . . . . . . . . . . . . . . . . . . . . 13 65 4.1.1Group Establishment without the Use of an Underlying SA . . . . 15 66 4.1.2Create Group Key . . . . . . . . . . . . . . . . . . . . . . . 15 67 4.1.3Distribute Group Key . . . . . . . . . . . . . . . . . . . . . . 15 68 4.2 Group Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 20 69 4.2.1Member Joins/Leaves . . . . . . . . . . . . . . . . . . . . . . 20 70 4.2.2Rekey Events . . . . . . . . . . . . . . . . . . . . . . . . . . 20 71 4.3 Group Removal/Destruction . . . . . . . . . . . . . . . . . . . . . 20 72 5 Message formats 22 73 5.1 T-GSAKMP Header . . . . . . . . . . . . . . . . . . . . . . . . . . 22 74 5.2 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . . 25 75 5.3 Data Attributes Payload . . . . . . . . . . . . . . . . . . . . . . 25 76 5.4 Policy Token Payload . . . . . . . . . . . . . . . . . . . . . . . 26 77 5.5 Key Download Payload . . . . . . . . . . . . . . . . . . . . . . . 27 78 5.5.1GTEK Key Packet . . . . . . . . . . . . . . . . . . . . . . . . 28 79 5.5.2Rekey Key Packet . . . . . . . . . . . . . . . . . . . . . . . . 29 80 5.6 Rekey Event Payload . . . . . . . . . . . . . . . . . . . . . . . . 30 81 5.7 Identification Payload . . . . . . . . . . . . . . . . . . . . . . 31 82 5.8 Authorization Payload . . . . . . . . . . . . . . . . . . . . . . . 32 83 5.9 Certificate Payload . . . . . . . . . . . . . . . . . . . . . . . . 33 84 5.10Certificate Request Payload . . . . . . . . . . . . . . . . . . . . 34 85 5.11Signature Payload . . . . . . . . . . . . . . . . . . . . . . . . . 35 86 5.12Notification Payload . . . . . . . . . . . . . . . . . . . . . . . 37 87 5.12.1Notification Data - Acknowledgement (ACK) Message Type . . . . 39 88 5.13Vendor ID Payload . . . . . . . . . . . . . . . . . . . . . . . . . 40 89 5.14Key Creation Payload . . . . . . . . . . . . . . . . . . . . . . . 41 90 5.15Nonce Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 92 6 T-GSAKMP State Diagram 44 94 7 APPENDIX A -- Rekey Packet data format 46 95 7.1 Rekey Event Header . . . . . . . . . . . . . . . . . . . . . . . . 46 96 7.2 Rekey Event Packet Data(s) . . . . . . . . . . . . . . . . . . . . 47 97 7.3 Key Pack Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 98 7.4 Pack Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . 48 99 7.4.1GTEK Pack Data . . . . . . . . . . . . . . . . . . . . . . . . . 48 100 7.4.2LKH Pack Data . . . . . . . . . . . . . . . . . . . . . . . . . 49 101 7.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 102 8 References and Authors Addresses 51 103 8.1 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 104 8.2 Authors Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 52 106 List of Figures 108 1 Group Establishment Ladder Diagram . . . . . . . . . . . . . . . . 14 109 2 T-GSAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . 22 110 3 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . . 25 111 4 Data Attributes Payload . . . . . . . . . . . . . . . . . . . . . . 26 112 5 Policy Token Payload Format . . . . . . . . . . . . . . . . . . . . 26 113 6 Key Download Payload Format . . . . . . . . . . . . . . . . . . . . 27 114 7 Rekey Event Payload Format . . . . . . . . . . . . . . . . . . . . 30 115 8 Identification Payload Format . . . . . . . . . . . . . . . . . . . 31 116 9 Authorization Payload Format . . . . . . . . . . . . . . . . . . . 32 117 10 Certificate Payload Format . . . . . . . . . . . . . . . . . . . . 33 118 11 Certificate Request Payload Format . . . . . . . . . . . . . . . . 35 119 12 Signature Payload Format . . . . . . . . . . . . . . . . . . . . . 36 120 13 Notification Payload Format . . . . . . . . . . . . . . . . . . . . 37 121 14 Notification Data - Acknowledge Message Type Format . . . . . . . . 39 122 15 Vendor ID Payload Format . . . . . . . . . . . . . . . . . . . . . 41 123 16 Key Creation Payload Format . . . . . . . . . . . . . . . . . . . . 41 124 17 Nonce Payload Format . . . . . . . . . . . . . . . . . . . . . . . 42 125 18 T-GSAKMP State Diagram . . . . . . . . . . . . . . . . . . . . . . 44 126 19 A.1: Rekey Event Header Format . . . . . . . . . . . . . . . . . . 46 127 20 A.2: Rekey Event Packet Data Format . . . . . . . . . . . . . . . 47 128 21 A.3: Key Pack Data Format . . . . . . . . . . . . . . . . . . . . 48 130 List of Tables 132 1 Request to Join Message Definition . . . . . . . . . . . . . . . . 16 133 2 Invitation to Join Message Definition . . . . . . . . . . . . . . . 16 134 3 Invitation Response Message Definition . . . . . . . . . . . . . . 18 135 4 Key Download Message Definition . . . . . . . . . . . . . . . . . . 18 136 5 Key Download Message with Insufficient SA Definition . . . . . . . 19 137 6 Acknowledgment Message Definition . . . . . . . . . . . . . . . . . 19 138 7 Rekey Event Message Definition . . . . . . . . . . . . . . . . . . 21 139 8 Group Removal/Destruction Message Definition . . . . . . . . . . . 21 140 9 Group Identification Types . . . . . . . . . . . . . . . . . . . . 22 141 10 Payload Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 142 11 Exchange Types . . . . . . . . . . . . . . . . . . . . . . . . . . 24 143 12 Policy Token Types . . . . . . . . . . . . . . . . . . . . . . . . 27 144 13 Key Download Data Types . . . . . . . . . . . . . . . . . . . . . . 28 145 14 Rekey Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 30 146 15 Identification Types . . . . . . . . . . . . . . . . . . . . . . . 32 147 16 Authorization Types . . . . . . . . . . . . . . . . . . . . . . . . 33 148 17 Certificate Payload Types . . . . . . . . . . . . . . . . . . . . . 34 149 18 Signature Types . . . . . . . . . . . . . . . . . . . . . . . . . . 36 150 19 Notify Messages Types . . . . . . . . . . . . . . . . . . . . . . . 38 151 20 Notify Messages -- Status Types . . . . . . . . . . . . . . . . . . 39 152 21 Acknowledgement Types . . . . . . . . . . . . . . . . . . . . . . . 40 153 22 Types Of Key Creation Information . . . . . . . . . . . . . . . . . 42 154 23 Nonce Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 155 24 State Transition Events . . . . . . . . . . . . . . . . . . . . . . 45 157 1 Background 159 T-GSAKMP is the forebearer of GSAKMP. It was first proposed in 1999 in the 160 IRTF Secure Multicast Group and later was proposed to the IETF Multcast 161 Security Group. T-GSAKMP was replaced with a simplified GSAKMP in 2002. 162 GSAKMP does not rely on a secure underlying SA for any protections and 163 reduces the number of messages in the key distribution protocol from five 164 (5) to three (3). T-GSAKMP, unlike GSAKMP, provides no default initial 165 security parameters nor does it make assumptions about the announcement 166 of those parameters through supporting infrastructure. GSAKMP is more 167 compliant with the IETF MSEC charter. 169 In order to retain the original design concept and to provide key management 170 for those groups wishing to create groups under a secure association, the 171 original GSAKMP specification is now being transferred to the experimental 172 rfc area. The specification is titled Tunneled Group Secure Association Key 173 Managment Protocol (T-GSAKMP) to reflect that this version of GSAKMP relies 174 on the existance of a secure tunnel to protect the initial communication. 176 2 Overview 178 The Tunneled Group Secure Association Key Management Protocol (T-GSAKMP) 179 provides symmetric key to groups of users on a network. It provides 180 mechanisms to disseminate group policy, perform access control decisions 181 during group establishment, generate group keys, recover from the compromise 182 of group members, delegate group security functions and destroy the group. 184 The goals of the T-GSAKMP are to create a protocol that: 186 1. Distributes group policy, 188 2. Provides mechanisms for distributing the group key, and 190 3. Provides mechanisms for a Rekey of the group. 192 2.1 T-GSAKMP Overview 194 Protecting information requires the definition of a security policy and the 195 enforcement of that policy by capable parties. Control and access to the 196 cryptographic key is the primary mechanism to enforce the access control 197 policy. The T-GSAKMP provides these mechanisms to control access to the 198 group key. 200 This document identifies the T-GSAKMP Message Passing Requirements. The 201 group key(s) are created by the group controller. The group controller 202 must start the group access control, policy enforcement process. The group 203 controller needs to have the access rules defined for joining the group 204 and should be able to identify and verify the permissions of the members to 205 which they will distribute keys. 207 The potential group members need to have ``knowledge'' of the access control 208 policy for the group, an unambiguous identification of any party downloading 209 keys to them, and verifiable chain of authority for key download. The group 210 members also need to verify that the key creator is authorized to act in 211 that capacity. 213 In order to establish a group Secure Association (SA) to support these 214 activities, the identity of each party in the security/access control 215 process must be unambiguously stated/asserted and authenticated to ensure 216 that they are authorized to be a member of the group as defined by the 217 group's security policy. The security characteristics of the establishment 218 protocol for the SA should include: 220 1. Coherent permission topology, 222 2. Group policy, 224 3. Group policy dissemination, 226 4. Peer SA to protect data, and 228 5. Access control checking. 230 2.2 Assumptions 232 T-GSAKMP makes the following assumptions of the underlying host: 234 1. The operating system can provide the process and data separation 235 services to support software encryption. 237 2. A separate SA mechanism is present that is sufficient to protect the 238 distribution of the group key. 240 3. The host and all the applications on that host share the same 241 certificate identities (at least initially). 243 2.3 Document Organization 245 Section 1 presents an overview of secure group communications. Section 2 246 presents the terminology and concepts used to present the requirements of 247 this protocol. Section 3 describes the group management life-cycle and 248 Section 4 presents the message types and formats used during each phase of 249 the life-cycle. Section 5 presents a discussion of the states encountered 250 in the protocol. 252 3 Terminology 254 The following terminology is used throughout the T-GSAKMP paper. 256 3.1 T-GSAKMP Terminology 258 Group Member: A group member (GM) is any entity with access to the group 259 keys. Regardless of how a member becomes a part of the group or how the 260 group is structured, GMs will perform the following actions: 262 1. Validate the GC's authorization to perform actions; 264 2. Accept group keys from the GC; 266 3. Request group keys from the GC; 268 4. Maintain local Certificate Revocation Lists (CRLs); 270 5. Enforce the cooperative group policies as stated in the group 271 policy token; 273 6. Perform peer review of key management actions; and 275 7. Manage their local key. 277 Group Secure Association (GSA): A cryptographic group is a logical 278 association of users or hosts that share cryptographic key(s). This 279 group may be established to support associations between applications or 280 communication protocols. 282 Group Policy: The group policy completely describes the protection 283 mechanisms and security relevant behaviors of the group. This policy 284 must be commonly understood and enforced by the group for coherent 285 secure operations. 287 Policy Token/Certificate: The policy token is a mechanism used to 288 disseminate the group policy. The policy token is issued and signed 289 by an authorized source. Each member of the group must verify the 290 token, meet the group join policy , and enforce the policy of the group. 291 The group policy data element will contain a variety of information 292 including: 294 1. T-GSAKMP protocol format, 295 2. Key creation method, 297 3. Key dissemination policy, 299 4. Access control policy, 301 5. Group architecture policy, and 303 6. Compromise recovery policy. 305 The policy token layout will be fully presented in the Group Policy 306 Token Specification document. 308 Group Controller: The Group Controller (GC) is a group member with 309 authority to perform any critical protocol actions including: 311 1. Creating and distributing keys; 313 2. Maintain the Rekey infrastructure; and 315 3. Building and maintaining the Rekey arrays. 317 As the group evolves, it may become desirable to have multiple 318 controllers perform these functions (e.g., Rekey Controller and Group 319 Key Controller). 321 Subordinate Controller: Any group member, as defined in the group policy, 322 has the capability to act as a Subordinate Controller (SC) thus allowing 323 the group processing and communication requirements to be distributed 324 equitably throughout the network. If the group is structured in 325 such a way, the delegated group members would be identified via the 326 policy token. The SCs may perform actions delegated to them by the GC 327 including: 329 1. Dissemination of the group key and 331 2. Management of the status of the local group. 333 The ease of managing a very large group may also be improved by 334 delegating the creation of subordinate LKH arrays to the SCs. The 335 SCs would have the authority and mechanisms necessary to create and 336 disseminate the LKH arrays for the members under their control. A 337 more detailed discussion of LKH arrays may be found in the Logical Key 338 Hierarchy (LKH) Protocol document. 340 Peer-to-Peer SA: Peer-to-Peer SA keys can be created by using any number 341 of key generation protocols including the Internet Secure Association 342 Key Management Protocol (ISAKMP)/IPSec and HS/SSL. These protocols 343 rely on cooperative key generation algorithms and on peer review of 344 permissions. Modern SA protocols are specifically developed to support 345 this task. Once the peer-to-peer SA is established, the group protocol 346 can use that SA mechanism for secure confidential peer communications 347 throughout the life of the group. 349 GSA Keys: GSA keys can be created using strong randomization key 350 generation protocols. These protocols rely on a cooperatively conferred 351 policy. Once the group keys are created and disseminated to the 352 group members, the group protocol can use that SA mechanism for secure 353 confidential group communications throughout the life of the group. 355 Group Traffic Encryption Key (GTEK): The key or keys created for 356 encrypting the group data. 358 Logical Key Hierarchy (LKH) array: The group of keys created to 359 facilitate the LKH compromise recovery methodology. 361 Compromise Recovery: The act of recovering a secure operating state after 362 detecting that a group member cannot be trusted. 364 4 GROUP LIFE-CYCLE 366 The management of a cryptographic group follows a life-cycle: group 367 definition, group establishment, group maintenance, and group removal. 368 Each of these life-cycle phases is discussed in the following sections. 369 A cryptographic group is established based on some need for secure 370 communications among a group of individuals. The activities involved in 371 creating a cryptographic group include: 373 1. Determine Access Policy: Group Join 375 2. Determine Authorization Policy: Key Dissemination, Computer Trust, and 376 Architecture Authorization 378 3. Determine Mechanisms: Algorithms and Infrastructure 380 4. Determine Architecture: Key Dissemination and Compromise Recovery 382 5. Create Group Policy Token 384 For the purposes of this document, it is assumed that the group definition 385 activity has occurred and the group information has been broadcast on a key 386 management channel or through a directory service. 388 4.1 Group Establishment 390 The Group Establishment Ladder diagram, Figure 1, is presented to illustrate 391 the process of establishing a cryptographic group. The left side of the 392 diagram represents the actions of the GC. The right side of the diagram 393 represents the actions of the GMs. The components of each message shown in 394 the diagram are presented in the Message Definitions sections following the 395 diagram. 397 Potential GMs may join a group in two ways: by invitation (push) or request 398 (pull). For purposes of illustration, the diagram presents a ``Request to 399 Join Group'', a ``pull'', message sent from a potential GM. 401 At this point, the GC must accept or deny the request. ``Process RTJ`` 402 indicates a provision for refusing the connection due to some specified 403 reason (e.g., no group, group full, repetitive attempts to join). If the 404 results of ``Process RTJ`` indicate that the GC should reject the request, 405 the session is terminated. 406 If the results of Processing the Request to Join indicate that the GC 407 should accept the request, the session continues. The message traffic to 408 an invited potential member also begins at this point on the diagram. 410 CONTROLLER MESSAGE MEMBER 412 !<------------Request to Join-------------! 413 ! ! 414 !<============SA ESTABLISHMENT===========>!(Outsid T-GSAKMP) 415 ! ! 416 !-------------Invitation----------------->! 417 ! ! 418 !<------------Invitation Response-------->! 419 ! ! 420 !-------------Key Download--------------->! 421 ! ! 422 !<------------Acknowledgment--------------! 423 ! ! 424 !<=======SHARED KEYED GROUP SESSION======>! 426 Figure 1: Group Establishment Ladder Diagram 428 The area of the diagram specified as ``Outside T-GSAKMP'' is merely 429 illustrative to show the confidentiality between the GC and GM. It is 430 assumed, for the purposes of this document, that the GC and GM are able to 431 establish a SA using protocols like ISAKMP and IPSec. The GC will specify 432 the security characteristics of the SA to the outside application. The 433 level of protection shall be as good or stronger than the SA characteristics 434 specified in the group policy token. A suggested minimal SA security level 435 is confidentiality with integrity. 437 To facilitate a well ordered group creation, security policy information 438 must be passed between the GC and the GMs using a group policy token. The 439 group policy token must include the group's address, group permissions, 440 group join policy, group controller identity, group management information, 441 and digital signature of the policy creation authority. 443 Standard design principles for secure protocols mandate the use of explicit 444 identification of senders and recipients of messages. The signature payload 445 of each message identifies the signer of the message and therefore satisfies 446 the sender requirement. Within the T-GSAKMP header is a group ID. Because 447 the member may be served by any Key Server within a group, this ID provides 448 sufficient granularity for the recipient ID for the Request to Join message. 449 Other messages sent by the potential member will contain the recipient 450 ID for the GCKS serving that member. The Invitation message provides no 451 authority to join the group (authorization information is contained in 452 the signed token), but merely provides information to a potential member. 453 Because of this, unintended receipt of this message by someone would not 454 cause harm. The recipient ID for this message is therefore optional. The 455 Key Download message also contains a required explicit ID. 457 4.1.1 Group Establishment without the Use of an Underlying SA 459 Group Establishment, as specified in Section 3.1, uses an underlying 460 Security Association to protect the contents of the Token and subsequent key 461 download. 463 In the cases where token contents are not sensitive, T-GSAKMP can provide 464 secure member joins and associated secure policy and key downloads without 465 any reliance on an underlying secure protocol subsystem. 467 In both of these cases, it is assumed that the data portion of the Key 468 Download payload is encrypted. The details of the encryption of this data 469 is provided in the Key Download payload itself. The key determination for 470 this encryption may be done through a two-party contributory system (a la 471 Diffie-Hellman) using the Key Creation Payloads to carry the contributions 472 of the participants to this key, or may be transferred with the encrypted 473 contents using public key encryption and an enveloping scheme (e.g., RFC 474 2630 Enveloped Data with Key Transport.) 476 4.1.2 Create Group Key 478 There are two options: key generation at a single point and shared 479 generation. In shared generation, the first member must cooperate with the 480 GC to create the group key. There are several established software-based 481 key creation protocols, including Diffie-Hellman and RSA, that support two 482 group members cooperating to create a cryptographic key. However, for this 483 document, the following discussion presents single-point key generation. 484 Prior to the first member join, the GC will have created the GTEK and the 485 Rekey array. 487 4.1.3 Distribute Group Key 489 Potential GMs may join a group and receive the group key in two ways: by 490 invitation (push) or request (pull). The following message definition shows 491 a Request to Join message from a potential GM. The initial message from the 492 GM would contain the following: 494 1. GSA request and 496 2. GM Certificate (optional). 498 The components of a Request to Join message are are shown in Table 1: 500 Table 1: Request to Join Message Definition 502 Message Name : Request to Join 503 Dissection : {HDR, GrpID, Nonce_I, GSA RQ} SigM, [CertM] 504 Payload Types : T-GSAKMP Header, Nonce, Notification, Signature, 505 [Certificate], [Certificate Request], [Vendor 506 ID], [Identification], [Authorization] 508 SigM : Signature of Group Member 509 CertM : Certificate of Group Member 510 {}SigX :Indicates minimum fields used in Signature 511 [] : Indicate an optional data item 513 The following message definition shows an ``Invitation to Join'' message 514 from the GC to a potential GM. The initial message from the GC would contain 515 the following: 517 1. Signed group policy token, 519 2. GSA request, and 521 3. GC Certificate (optional). 523 The components of an Invitation to Join message are shown in Table 2: 525 Table 2: Invitation to Join Message Definition 527 Message Name : Invitation to Join 528 Dissection : {HDR, GrpID, Policy Token, (Nonce_R, Nonce_C) OR 529 Nonce_I, [Key Creation], GSA RQ}SigC, [CertC], 530 [SigSC], [CertSC] 531 Payload Types : T-GSAKMP Header, Policy Token, Nonce, 532 Notification, Signature, [Certificate], 533 [Signature], [Certificate], [Key Creation], 534 [Certificate Request], [Vendor ID], [Identification], 535 [Authorization] 537 SigC : Signature of Group Controller 538 SigSC : Signature of Subordinate Group Controller 539 CertC : Certificate of Group Controller 540 CertSC : Certificate of Subordinate Group Controller 541 {}SigX :Indicates minimum fields used in Signature 542 [] : Indicate an optional data item 544 For purposes of discussion, this section presents a ``Invitation to Join'' 545 as presented in Table 2. 547 The GM will receive this message and process it according to the provisions 548 of Processing the Invitation. The GSA RQ contains the identity of the 549 message source in enough detail to allow the potential member to verify 550 the signature. The GSA RQ also contains the ID of the invited member. In 551 ``Process Invitation'' the potential GM will initially verify that the 552 signature on the message is authentic. If the message signature does not 553 verify, the session is terminated. T-GSAKMP sends a properly authenticated 554 message with a Notification Payload of type NACK to indicate termination. 556 If the message signature is authentic, then the potential GM will look 557 at who signed the message, verify the signer's authorization, and make 558 a decision to proceed. If the potential GM decides not to proceed, the 559 session is terminated. T-GSAKMP sends a properly authenticated message with 560 a Notification Payload of type NACK to indicate termination. 562 If the GM initiated a pull by sending a Request to Join message, the 563 Invitation to Join message received must contain the Nonce_R and Nonce_C 564 payloads. If the GM is being invited to join the group via a push by 565 the GCKS, the Invitation to Join message received must contain a Nonce_I 566 payload. 568 NOTE: When not using an underlying Security Association (SA), or the SA is 569 not sufficient to protect the key data in the Key Download message, the 570 Key Creation payload is required in this message if using a pairwise key 571 determination system. 573 If the potential GM has decided to continue, they will examine the 574 information within the policy token to determine if this is a group they are 575 authorized and interested in joining. If the decision is not to join, the 576 session is terminated. T-GSAKMP sends a properly authenticated message with 577 a Notification Payload of type NACK to indicate termination. 579 If the potential GM is satisfied with the received information and decides 580 to join the group, he will pass back a message containing the following: 582 1. Signed GSA response, and 584 2. GM's certificate (optional). 586 The components of an Invitation Response message are shown in Table 3: 588 The GC receives this message and processes it according to the provisions of 589 Processing the Invitation Response. In this procedure, the GC will verify 590 the signature on the message to ensure its authenticity. If the message 591 signature does not verify, the session is terminated. T-GSAKMP sends a 592 properly authenticated message with a Notification Payload of type NACK to 593 indicate termination. 595 Table 3: Invitation Response Message Definition 597 Message Name : Invitation Response 598 Dissection : {HDR, GrpID, (Nonce_R, Nonce_C) OR Nonce_C, [ID_R], 599 [Key Creation], GSA RS}SigM, [CertM] 600 Payload Types : T-GSAKMP Header, Nonce, [Identification], 601 Notification, Signature, [Key Creation], 602 [Certificate], [Vendor ID], [Authorization] 604 SigM : Signature of Group Member 605 CertM : Certificate of Group Member 606 {}SigX :Indicates minimum fields used in Signature 607 [] : Indicate an optional data item 609 If this negotiation was initiated by the GC via a push, the Invitation 610 Response message received must contain the Nonce_R and Nonce_C payloads. If 611 this negotiation was initiated by the GM via a pull, the Invitation Response 612 message received must contain a Nonce_C payload. 614 NOTE: When not using an underlying Security Association (SA), or the SA is 615 not sufficient to protect the key data in the Key Download message, the 616 Key Creation payload is required in this message if using a pairwise key 617 determination system. 619 If the message signature is verified, and the GM passes the GC's access 620 control checks, the GC will create and send a signed message containing the 621 GTEK and the Rekey array to the GM. 623 The components of a Key Download message are shown in Table 4: 625 Table 4: Key Download Message Definition 627 Message Name : Key Download 628 Dissection : {HDR, GrpID, Nonce_C, ID_R, [(]Key Data[)*]}SigC, 629 [SigSC], [CertSC] 630 Payload Types : T-GSAKMP Header, Nonce, Identification, Key 631 Download, Signature, [Authorization], [Vendor ID] 632 SigC : Signature of Group Controller 633 SigSC : Signature of Subordinate Group Controller 634 CertC : Certificate of Group Controller 635 CertSC : Certificate of Subordinate Group Controller 636 {}SigX :Indicates minimum fields used in Signature 637 [] : Indicate an optional data item 638 (data)* : Indicates encrypted information 640 The GM receives this message and processes it according to the provisions 641 of Processing the Key Download. In this procedure, the GM will verify the 642 following information: signature on the message to ensure its authenticity, 643 the contents of the nonce payload, and the identity information contained in 644 the Identification payload is the GM identity information. If the message 645 signature, nonce, or identification information does not verify, the session 646 is terminated. T-GSAKMP sends a properly authenticated message with a 647 Notification Payload of type NACK to indicate termination. 649 NOTE: When not using an underlying Security Association (SA), or the SA 650 is not sufficient to protect the key data in the Key Download message, the 651 Key Data section of the Key Download message must be encrypted. An example 652 format for this message is shown in Table 5: 654 Table 5: Key Download Message with Insufficient SA Definition 656 Message Name : Key Download 657 Dissection : {HDR, GrpID, Nonce_C, ID_R, (Key Data)*}SigC, 658 [SigSC], [CertSC] 659 Payload Types : T-GSAKMP Header, Nonce, Identification, Key 660 Download, Signature, [Authorization], [Vendor ID] 662 SigC : Signature of Group Controller 663 SigSC : Signature of Subordinate Group Controller 664 CertC : Certificate of Group Controller 665 CertSC : Certificate of Subordinate Group Controller 666 {}SigX :Indicates minimum fields used in Signature 667 [] : Indicate an optional data item 668 (data)* : Indicates encrypted information 670 If the message signature, nonce, and identification are verified, the GM 671 will create a signed acknowledgment message to return to the GC. 673 The components of an Acknowledgment message are shown in Table 6: 675 Table 6: Acknowledgment Message Definition 677 Message Name : Acknowledgment 678 Dissection : {HDR, GrpID, Nonce_C, [ID_R], ACK}SigM, [CertM] 679 Payload Types : T-GSAKMP Header, Nonce, [Identification], 680 Notification, Signature, [Certificate], [Vendor 681 ID], [Identification], [Authorization] 683 SigM : Signature of Group Member 684 CertM : Certificate of Group Member 685 {}SigX :Indicates minimum fields used in Signature 686 [] : Indicate an optional data item 688 The GC receives the signed acknowledgment and processes it according to 689 the provision of Processing the Acknowledgement. In this procedure, the 690 GC will verify the signature on the message to ensure its authenticity and 691 the nonce value. If the message signature or nonce does not verify, the 692 session is terminated. T-GSAKMP sends a properly authenticated message with 693 a Notification Payload of type NACK to indicate termination. 695 If the message signature and nonce are verified, then the GC and GM have 696 established a Shared Keyed Group Session. 698 4.2 Group Maintenance 700 The Group Maintenance phase includes member joins and leaves, group rekey 701 activities, and the management of Rekey events. These activities are 702 presented in the following sections. 704 4.2.1 Member Joins/Leaves 706 The addition of group members to a previously established group will closely 707 follow the processing presented in Section 3.1 -- Group Establishment. With 708 the exception of the pure group establishment tasks (e.g., creation of 709 policy token, GTEK, and Rekey array), an entity becomes a GM using the same 710 message exchanges described in Section 3.1. 712 A member who elects to voluntarily leave the group will be responsible for 713 destroying his key. Any further action for a voluntary leave should be 714 specifically addressed in the group's security policy. 716 4.2.2 Rekey Events 718 A Rekey event is any action, including compromises, that involves the 719 creation and dissemination of a new group key and/or Rekey information. 721 Once it has been identified, using the group's security policy, that a Rekey 722 event has occurred, the GC must create and send a signed message containing 723 the GTEK and Rekey array to the group. 725 Each GM who receives this message must verify the signature on the message 726 to ensure its authenticity. If the message signature does not verify, the 727 session is terminated. T-GSAKMP sends a properly authenticated message 728 with a Notification Payload of type NACK to indicate termination. Upon 729 verification the GM will find the appropriate Rekey download packet and 730 decrypt the information with a stored Rekey key. 732 The components of a Rekey Event message are shown in Table 7: 734 4.3 Group Removal/Destruction 736 At this point in the group's life-cycle, there has been a decision to 737 destroy the group and the notification is broadcast on a key management 738 Table 7: Rekey Event Message Definition 740 Message Name : Rekey Event 741 Dissection : {HDR, GrpID, [Policy Token], Rekey Array}SigC, 742 [CertC] 743 Payload Types : T-GSAKMP Header, [Policy Token], Rekey Event, 744 Signature, [Certificate], [Vendor ID] 746 SigC : Signature of Group Controller 747 CertC : Certificate of Group Controller 748 {}SigX :Indicates minimum fields used in Signature 749 [] : Indicate an optional data item 751 channel or through a directory service. 753 The components of a Group Removal/Destruction message are shown in Table 8: 755 Table 8: Group Removal/Destruction Message Definition 757 Message Name : Group Removal/Destruction 758 Dissection : {HDR, GrpID, [Policy Token], Destruct}SigC, 759 [CertC] 760 Payload Types : T-GSAKMP Header, [Policy Token], Notification, 761 Signature, [Certificate], [Vendor ID] 763 SigC : Signature of Group Controller 764 CertC : Certificate of Group Controller 765 {}SigX :Indicates minimum fields used in Signature 766 [] : Indicate an optional data item 768 5 Message formats 770 5.1 T-GSAKMP Header 772 The T-GSAKMP Header fields are defined in Figure 2: 773 0 1 2 3 774 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 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 776 !Group ID Type ! Group ID Value ~ 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 778 ~ ~ 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 780 ~ ! Next Payload ! Version ! Exchange Type ! 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 782 ! Sequence ID ! 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 784 ! Length ! 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 787 Figure 2: T-GSAKMP Header Format 789 Group Identification Type (1 octet) - Table 9 presents the group 790 identification types. 792 Table 9: Group Identification Types 794 Grp ID Type Value 796 _____________________ 797 IPSec IPv4 0 798 IPSec IPv6 1 799 TLS 2 800 SMIME 3 801 Other 4-255 803 Group Identification Value (8 octets) - Indicates the name/title of the 804 group. 806 Next Payload (1 octet) - Indicates the type of the first payload in the 807 message. The format for each payload is defined in the following 808 sections. Table 10 presents the payload types. 810 Version (1 octet) - Indicates the version of the T-GSAKMP protocol in use. 812 Table 10: Payload Types 814 Next_Payload_Type Value 815 ___________________________________ 817 None 0 818 Policy Token 1 819 Key Download Packet 2 820 Rekey event 3 821 Identification 4 822 Authorization 5 823 Certificate 6 824 Certificate Request 7 825 Signature 9 826 Notification 10 827 Vendor ID 11 828 Key Creation 12 829 Nonce 13 830 Reserved 14 - 127 831 Private Use 128 -- 255 833 Exchange Type (1 octet) - Indicates the type of exchange (also known as 834 the message type). Table 11 presents the exchange type values. 836 Sequence ID (4 octets) - Group Management replay protection field. 837 Sequence ID for group management messages. If not a group management 838 message, this value is set to zero (0). 840 Length (4 octets) - Length of total message (header + payloads) in octets. 841 Encryption can expand the size of a T-GSAKMP message. 843 Table 11: Exchange Types 845 Exchange_Type Value 846 ____________________________________ 848 Request to Join 0 849 Invitation 1 850 Invitation Response 2 851 Key Download 3 852 Acknowledgement 4 853 Rekey Event 5 854 Group Removal/Destruction 6 855 No Message 7 856 Light Request to Join 8 857 Light Key Download 9 858 Other 10-255 860 5.2 Generic Payload Header 862 Each T-GSAKMP payload defined in the following sections begins with a 863 generic header, shown in Figure 3, which provides a payload ``chaining`` 864 capability and clearly defines the boundaries of a payload. The Generic 865 Payload Header fields are defined as follows: 867 0 1 2 3 868 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 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 870 ! Next Payload ! RESERVED ! Payload Length ! 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 873 Figure 3: Generic Payload Header 875 Next Payload (1 octet) - Identifier for the payload type of the next 876 payload in the message. If the current payload is the last in 877 the message, then this field will be 0. This field provides the 878 ``chaining`` capability. 880 RESERVED (1 octet) - Unused, set to 0. 882 Payload Length (2 octets) - Length in octets of the current payload, 883 including the generic payload header. 885 5.3 Data Attributes Payload 887 There are instances within T-GSAKMP where it is necessary to represent 888 Data Attributes. These Data Attributes are not a T-GSAKMP payload, but 889 are contained within T-GSAKMP payloads. The format of the Data Attributes 890 provides the flexibility for representation of many different types of 891 information. There can be multiple Data Attributes within a payload. 892 The length of the Data Attributes will either be 4 octets or defined by 893 the Attribute Length field. This is done using the Attribute Format bit 894 described in Figure 4. 896 The Data Attributes fields are defined as follows: 898 Attribute Type (2 octets) - Unique identifier for each type of attribute. 899 The most significant bit, or Attribute Format (AF), indicates whether 900 the data attributes follow the Type/Length/Value (TLV) format or a 901 shortened Type/Value (TV) format. If the AF bit is a zero (0), then the 902 Data Attributes are of the Type/Length/Value (TLV) form. If the AF bit 903 is a one (1), then the Data Attributes are of the Type/Value form. 905 0 1 2 3 906 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 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 908 ! Attribute Type ! AF=0 Attribute Length ! 909 ! ! AF=1 Attribute Value ! 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 911 ! AF=0 Attribute Value ~ 912 ! AF=1 Not Transmitted ~ 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 915 Figure 4: Data Attributes Payload 917 Attribute Length (2 octets) - Length in octets of the Attribute Value. 918 When the AF bit is a one (1), the Attribute Value is only 2 octets and 919 the Attribute Length field is not present. 921 Attribute Value (variable length) - Value of the attribute associated with 922 the T-GSAKMP-specific Attribute Type. If the AF bit is a zero (0), this 923 field has a variable length defined by the Attribute Length field. If 924 the AF bit is a one (1), the Attribute Value has a length of 2 octets. 926 5.4 Policy Token Payload 928 The Policy Token Payload contains group specific information that describes 929 the group security relevant behaviors, access control parameters, and 930 security mechanisms. This information may contain a digital signature(s) to 931 prove authority and integrity of the information. Figure 5 shows the format 932 of the payload. 934 0 1 2 3 935 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 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 937 ! Next Payload ! RESERVED ! Payload Length ! 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 939 ! ID Type ! Policy Token Data ~ 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 942 Figure 5: Policy Token Payload Format 944 The Policy Token Payload fields are defined as follows: 946 Next Payload (1 octet) - Identifier for the payload type of the next 947 payload in the message. If the current payload is the last in the 948 message, then this field will be 0. 950 0 1 2 3 951 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 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 953 ! Next Payload ! RESERVED ! Payload Length ! 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 955 ! Key Download Data ~ 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 958 Figure 6: Key Download Payload Format 960 RESERVED (1 octet) - Unused, set to 0. 962 Payload Length (2 octets) - Length in octets of the current payload, 963 including the generic payload header. 965 ID Type (1 octet) - Specifies the type of Policy Token being used. 966 Table 12 identifies the types of policy tokens. 968 Table 12: Policy Token Types 970 ID_Type Value 972 ______________________ 973 Group 0 974 Auxiliary 1 975 Reserved 2-63 976 Unassigned 64-255 978 Policy Token Data (variable length) - Contains Policy Token information. 979 The values for this field are group specific and the format is specified 980 by the ID Type field. 982 The payload type for the Policy Token Payload is one (1). 984 5.5 Key Download Payload 986 The Key Download Payload contains group keys. These key download payloads 987 can have several security attributes applied to them based upon the security 988 policy of the group. Figure 6 shows the format of the payload. 990 If the security policy of the group dictates, the key download payload may 991 be encrypted with a key exchange key (KEK). The type of encryption used is 992 specified in the Policy Token. The group members may create the KEK using 993 the key creation method identified in the Key Creation Payload. 995 The Key Download Payload fields are defined as follows: 997 Next Payload (1 octet) - Identifier for the payload type of the next 998 payload in the message. If the current payload is the last in the 999 message, then this field will be 0. 1001 RESERVED (1 octet) - Unused, set to 0. 1003 Payload Length (2 octets) - Length in octets of the current payload, 1004 including the generic payload header. 1006 Key Download Data (variable length) - Contains Key Download information. 1008 Number of Key Packets (2 octets) -- Contains the total number of both 1009 GTEK and Rekey arrays being passed in this data block. 1011 For each Key Packet, the data format is as follows: 1013 Key Download Data (KDD) Type (1 octet) -- Identifier for the Key 1014 Data field of this Key Packet. See Table 13 for the possible 1015 values of this field. 1017 Table 13: Key Download Data Types 1019 Key Download Data Type Value 1020 ________________________________ 1022 GTEK 0 1023 Rekey 1 1024 Unassigned 2-255 1026 Key Download Length (2 octets) -- Length in octets of the Key 1027 Packet data following this field. 1029 Key Packet Data (variable length) -- Contains Key information. 1030 The format of this field is specific depending on the value of 1031 the Key Download Data field. 1033 5.5.1 GTEK Key Packet 1035 For a Key Download Data value of GTEK, the Key Packet Data field is 1036 formatted as follows: 1038 Key Type (1 octet) -- This is the encryption algorithm for which this key 1039 data is to be used. This value is specified in the Policy Token. 1041 Key Creation Date (4 octets) -- This is the time value of when this key 1042 data was originally generated. 1044 Key Expiration Date (4 octets) -- This is the time value of when this key 1045 is no longer valid for use. 1047 Key Handle (4 octets) -- This is the randomly generated value to uniquely 1048 identify a key. 1050 Key Data (variable length) -- This is the actual encryption key data, 1051 which is dependent on the Key Type algorithm for its format. 1053 5.5.2 Rekey Key Packet 1055 T-GSAKMP currently uses the Logical Key Hierarchy (LKH) protocol for Rekey 1056 operations. This Key Packet Data is assumed to contain LKH Array data of 1057 the following format: 1059 LKH Version (1 octet) -- Contains the version of the LKH protocol which 1060 the data is formatted in. 1062 Leaf ID (2 octets) -- This is the Leaf Node ID of the LKH sequence 1063 contained in this Key Packet Data block. 1065 Number of LKH Keys (2 octets) -- This value is the number of distinct LKH 1066 keys in this sequence. 1068 For each LKH key in the sequence, the data format is as follows: 1070 LKH ID (2 octets) -- This is the position of this key in the binary 1071 tree structure used by LKH. 1073 Key Type (1 octet) -- This is the encryption algorithm for which this 1074 key data is to be used. This value is specified in the Policy 1075 Token. 1077 Key Creation Date (4 octets) -- This is the time value of when this 1078 key data was originally generated. 1080 Key Expiration Date (4 octets) -- This is the time value of when this 1081 key is no longer valid for use. 1083 Key Handle (4 octets) -- This is the randomly generated value to 1084 uniquely identify a key. 1086 Key Data (variable length) -- This is the actual encryption key data, 1087 which is dependent on the Key Type algorithm for its format. 1089 The payload type for the Key Download Packet is two (2). 1091 5.6 Rekey Event Payload 1093 The Rekey Event Payload contains multiple keys encrypted in Rekey keys. 1094 These Rekey Event payloads can have several security attributes applied to 1095 them based upon the security policy of the group. Figure 7 shows the format 1096 of the payload. 1097 0 1 2 3 1098 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 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1100 ! Next Payload ! RESERVED ! Payload Length ! 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1102 ! ID Type ! Rekey Event Data ~ 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1105 Figure 7: Rekey Event Payload Format 1107 The Rekey Event Payload fields are defined as follows: 1109 Next Payload (1 octet) - Identifier for the payload type of the next 1110 payload in the message. If the current payload is the last in the 1111 message, then this field will be 0. 1113 RESERVED (1 octet) - Unused, set to 0. 1115 Payload Length (2 octets) - Length in octets of the current payload, 1116 including the generic payload header. 1118 ID Type (1 octet) - Specifies the type of Rekey Event being used. 1119 Table 14 presents the types of Rekey events. 1121 Table 14: Rekey Event Types 1123 ID_Type Value 1124 ______________________________ 1126 None 0 1127 Group Recovery 1 1128 Individual Recovery 2 1129 Maintenance 3 1130 Delete Group Key 4 1131 Unassigned 5-255 1133 Rekey Event Data (variable length) - Contains Rekey Event information. 1135 The values for this field are group specific and the format is specified 1136 by the ID Type field. The format for the LKH type of Rekey Event Data 1137 is located in the appendix section. 1139 The Rekey Event payload type is three (3). 1141 5.7 Identification Payload 1143 The Identification Payload contains entity-specific data used to 1144 exchange identification information. This information is used for 1145 determining the identities of negotiating members and may be used for 1146 determining authenticity of information. Figure 8 shows the format of the 1147 Identification Payload. 1149 0 1 2 3 1150 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 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1152 ! Next Payload ! RESERVED ! Payload Length ! 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1154 ! ID Type ! Identification Data ~ 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1157 Figure 8: Identification Payload Format 1159 The Identification Payload fields are defined as follows: 1161 Next Payload (1 octet) - Identifier for the payload type of the next 1162 payload in the message. If the current payload is the last in the 1163 message, then this field will be 0. 1165 RESERVED (1 octet) - Unused, set to 0. 1167 Payload Length (2 octets) - Length in octets of the current payload, 1168 including the generic payload header. 1170 ID Type (1 octet) - Specifies the type of Identification being used. 1171 Table 15 identifies the types of identities. 1173 Identification Data (variable length) - Contains identity information. 1174 The values for this field are group-specific and the format is specified 1175 by the ID Type field. 1177 The payload type for the Identification Payload is four (4). 1179 Table 15: Identification Types 1181 ID_Type Value 1182 _____________________________________________ 1184 Sender Distinguished Name 0 1185 Receiver Distinguished Name 1 1186 Hash of Sender Distinguished Name 2 1187 Hash of Receiver Distinguished Name 3 1188 Unassigned 4-255 1190 5.8 Authorization Payload 1192 The Authorization Payload contains group-specific data used to exchange role 1193 authorization information. This information is used for determining the 1194 authorization of entities within a group. Figure 9 shows the format of the 1195 Authorization Payload. 1197 0 1 2 3 1198 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 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1200 ! Next Payload ! RESERVED ! Payload Length ! 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1202 ! Auth Type ! Authorization Data ~ 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1205 Figure 9: Authorization Payload Format 1207 The Authorization Payload fields are defined as follows: 1209 Next Payload (1 octet) - Identifier for the payload type of the next 1210 payload in the message. If the current payload is the last in the 1211 message, then this field will be 0. 1213 RESERVED (1 octet) - Unused, set to 0. 1215 Payload Length (2 octets) - Length in octets of the current payload, 1216 including the generic payload header. 1218 Authorization Type (1 octet) - Specifies the type of role authorization 1219 being used. Table 16 identifies the types of roles. 1221 Authorization Data (variable length) - Contains authorization information. 1222 The values for this field are group-specific and the format is specified 1223 by the Authorization Type field. 1225 Table 16: Authorization Types 1227 Auth_Type Value 1228 ________________________________________________ 1230 Group Controller 0 1231 Group and Rekey Controller 1 1232 Rekey Controller 2 1233 Subordinate Group Controller 3 1234 Subordinate Group and Rekey Controller 4 1235 Subordinate Rekey Controller 5 1236 Member ID 6 1237 Unassigned 7-255 1239 The payload type for the Authorization Payload is five (5). 1241 5.9 Certificate Payload 1243 The Certificate Payload provides a means to transport certificates or other 1244 certificate-related information via T-GSAKMP and can appear in any T-GSAKMP 1245 message. Certificate payloads SHOULD be included in an exchange whenever an 1246 appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available 1247 to distribute certificates. The Certificate payload MUST be accepted at 1248 any point during an exchange. Figure 10 shows the format of the Certificate 1249 Payload. 1251 0 1 2 3 1252 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 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1254 ! Next Payload ! RESERVED ! Payload Length ! 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1256 ! Cert Encoding ! Certificate Data ~ 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1259 Figure 10: Certificate Payload Format 1261 The Certificate Payload fields are defined as follows: 1263 Next Payload (1 octet) - Identifier for the payload type of the next 1264 payload in the message. If the current payload is the last in the 1265 message, then this field will be 0. 1267 RESERVED (1 octet) - Unused, set to 0. 1269 Payload Length (2 octets) - Length in octets of the current payload, 1270 including the generic payload header. 1272 Certificate Encoding (1 octet) - This field indicates the type of 1273 certificate or certificate-related information contained in the 1274 Certificate Data field. Table 17 presents the types of certificate 1275 payloads. 1277 Table 17: Certificate Payload Types 1279 Certificate_Type Value 1280 _______________________________________________ 1282 None 0 1283 PKCS #7 wrapped X.509 certificate 1 1284 PGP Certificate 2 1285 DNS Signed Key 3 1286 X.509 Certificate -- Signature 4 1287 X.509 Certificate - Key Exchange 5 1288 Kerberos Tokens 6 1289 Certificate Revocation List (CRL) 7 1290 Authority Revocation List (ARL) 8 1291 SPKI Certificate 9 1292 X.509 Certificate -- Attribute 10 1293 Reserved 11 -- 255 1295 Certificate Data (variable length) - Actual encoding of certificate data. 1296 The type of certificate is indicated by the Certificate Encoding field. 1298 The payload type for the Certificate Payload is six (6). 1300 5.10 Certificate Request Payload 1302 The Certificate Request Payload provides a means to request certificates 1303 via T-GSAKMP and can appear in any message. Certificate Request payloads 1304 SHOULD be included in an exchange whenever an appropriate directory service 1305 (e.g., Secure DNS [DNSSEC]) is not available to distribute certificates. 1306 The Certificate Request payload MUST be accepted at any point during the 1307 exchange. The responder to the Certificate Request payload MUST send its 1308 certificate, if certificates are supported, based on the values contained 1309 in the payload. If multiple certificates are required, then multiple 1310 Certificate Request payloads SHOULD be transmitted. Figure 11 shows the 1311 format of the Certificate Request Payload. 1313 The Certificate Payload fields are defined as follows: 1315 Next Payload (1 octet) - Identifier for the payload type of the next 1316 0 1 2 3 1317 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 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1319 ! Next Payload ! RESERVED ! Payload Length ! 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1321 ! Cert Type ! Certificate Authority ~ 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1324 Figure 11: Certificate Request Payload Format 1326 payload in the message. If the current payload is the last in the 1327 message, then this field will be 0. 1329 RESERVED (1 octet) - Unused, set to 0. 1331 Payload Length (2 octets) - Length in octets of the current payload, 1332 including the generic payload header. 1334 Certificate Type (1 octet) - Contains an encoding of the type of 1335 certificate requested. 1337 Certificate Authority (variable length) - Contains an encoding of an 1338 acceptable certificate authority for the type of certificate requested. 1339 As an example, for an X.509 certificate this field would contain the 1340 Distinguished Name encoding of the Issuer Name of an X.509 certificate 1341 authority acceptable to the sender of this payload. This would be 1342 included to assist the responder in determining how much of the 1343 certificate chain would need to be sent in response to this request. If 1344 there is no specific certificate authority requested, this field SHOULD 1345 NOT be included. 1347 The payload type for the Certificate Request Payload is seven (7). 1349 5.11 Signature Payload 1351 The Signature Payload contains data generated by the digital signature 1352 function. The digital signature covers the Signature Payload Span and the 1353 Signature Payload up to the Signature Data. The exception to this is if 1354 the signature algorithm used is DSS with ASN.1/DER encoding. Due to the 1355 variable length of a DER encoding, the signature span across the signature 1356 payload itself only extends up to the signature data length field, not the 1357 signature data. Figure 12 shows the format of the Signature Payload. 1359 The Signature Payload fields are defined as follows: 1361 0 1 2 3 1362 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 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1364 ! Next Payload ! RESERVED ! Payload Length ! 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1366 ! Sig Type ! Signature Payload Span ~ 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1368 ~ ! Sig ID Role ! Signature Timestamp ~ 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1370 ~ ! Signer ID Length ! 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1372 ~ Signer ID Data ~ 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1374 ! Signature Length ! Signature Data ~ 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1376 ~ ~ 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1379 Figure 12: Signature Payload Format 1381 Next Payload (1 octet) - Identifier for the payload type of the next 1382 payload in the message. If the current payload is the last in the 1383 message, then this field will be 0. 1385 RESERVED (1 octet) - Unused, set to 0. 1387 Payload Length (2 octets) - Length in octets of the current payload, 1388 including the generic payload header. 1390 Signature Type (1 octet) -- Indicates the type of signature. Table 18 1391 presents the Signature Types. 1393 Table 18: Signature Types 1395 Signature Type Value 1396 _____________________________________ 1398 DSS with ASN.1/DER encoding 0 1399 DSS without encoding 1 1400 Other 2-255 1402 Signature Payload Span (4 octets) - Identifies the information included in 1403 the signature. The first two octets define the first signature payload. 1404 The third and fourth octet define the last payload. The payloads in the 1405 message are an ordered sequence beginning at the header, with a value 1406 of 0. If the signature payload itself is not in the signature span, you 1407 must still sign over the signature payload up to the signature data. 1409 Signature ID Role (1 octet) -- Specifies the type of Authorization (Role) 1410 being used. Refer to Table 16 for the types of authorization (role). 1412 Signature Timestamp (4 octets) -- Date and time that the digital signature 1413 was applied. 1415 Signer ID Length (2 octets) - Length in octets of the Signer' ID. 1417 Signer ID (variable length) -- Data identifying the Signer's ID (e.g., 1418 DN). 1420 Signature Length (2 octets) -- Length in octets of the Signature Data. 1422 Signature Data (variable length) - Data that results from applying the 1423 digital signature function to the T-GSAKMP message and/or payload. 1425 The payload type for the Signature Payload is nine (9). 1427 5.12 Notification Payload 1429 The Notification Payload can contain both T-GSAKMP and group specific data 1430 and is used to transmit informational data, such as error conditions, to 1431 a T-GSAKMP peer. It is possible to send multiple Notification payloads in 1432 a single T-GSAKMP message. Figure 13 shows the format of the Notification 1433 Payload. 1435 0 1 2 3 1436 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 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1438 ! Next Payload ! RESERVED ! Payload Length ! 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1440 ! Notify Message Type ! STATUS TYPE ! ~ 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1442 ~ Notification Data ~ 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1445 Figure 13: Notification Payload Format 1447 The Notification Payload fields are defined as follows: 1449 Next Payload (1 octet) - Identifier for the payload type of the next 1450 payload in the message. If the current payload is the last in the 1451 message, then this field will be 0. 1453 RESERVED (1 octet) - Unused, set to 0. 1455 Payload Length (2 octets) - Length in octets of the current payload, 1456 including the generic payload header. 1458 Notify Message Type (2 octets) - Specifies the type of notification 1459 message. Table 19 presents the Notify Message Types. 1461 Table 19: Notify Messages Types 1463 Information Value 1464 _______________________________________________ 1466 None 0 1467 Invalid-Payload-Type 1 1468 Situation-Not-Supported 2 1469 Invalid-Major-Version 3 1470 Invalid-Version 4 1471 Invalid-Group-ID 5 1472 Invalid-Message-ID 6 1473 Payload-Malformed 7 1474 Invalid-Key-Information 8 1475 Invalid-ID-Information 9 1476 Invalid-Cert-Encoding 10 1477 Invalid-Certificate 11 1478 Cert-Type-Unsupported 12 1479 Invalid-Cert-Authority 13 1480 Authentication-Failed 14 1481 Invalid-Signature 15 1482 Notify-GSA-Lifetime 16 1483 Certificate-Unavailable 17 1484 Unequal-Payload-Lengths 18 1485 Unauthorized Request 19 1486 Unable To Take Requested Role 20 1487 Group Deleted 21 1488 Request To Join 22 1489 Acknowledgement 23 1490 Invitation 24 1491 Invitation-Response 25 1492 Nack 26 1493 Reserved (future use) 27 - 8191 1494 Private Use 8192 -- 16383 1496 Status Type (1 octet) - Specifies the status of group with respect to 1497 originator of notification. Notification information specifies status 1498 data and can be used by a process managing a SA database to communicate 1499 with a peer process. For example, a secure front end or security 1500 gateway may use the Notify message to synchronize SA communication. 1501 Table 20 presents the Notification Message Status Types. 1503 Notification Data (variable length) - Informational or error data 1504 transmitted in addition to the Notify Message Type. Values for this 1505 Table 20: Notify Messages -- Status Types 1507 Status Value 1508 ____________________________________ 1510 Not connected 0 1511 Establishing group 1 1512 Connected to group 2 1513 Previously member of group 3 1514 Reserved (future use) 4-255 1516 field are Domain of Interpretation (DOI)-specific. 1518 The payload type for the Notification Payload is ten (10). 1520 5.12.1 Notification Data - Acknowledgement (ACK) Message Type 1522 The data portion of the ACK payload serves either for confirmation of 1523 correct receipt of the Key Download message, or, when needed, can provide 1524 non-repudiation of receipt when included in a signed message. Figure 14 1525 shows the format of the Notification Data - Acknowledge Message Type. 1527 0 1 2 3 1528 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 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1530 ! Ack Type ! Acknowledgement Data ~ 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1533 Figure 14: Notification Data - Acknowledge Message Type Format 1535 The Notification Data - Acknowledgement Message Type data fields are defined 1536 as follows: 1538 Ack Type (1 octet) - Specifies the type of acknowledgement message. 1539 Table 21 presents the Notify Acknowledgement Message Types. 1541 Simple - Data portion null. 1543 MD5 MAC - Data portion contains output of MD5 HMAC function [RFC 1544 2104]. Input to HMAC function is the Nonce_C value appended to the 1545 decrypted portion, sans encryption padding, of the Key Download 1546 payload of the received Key Download Packet. 1548 Table 21: Acknowledgement Types 1550 ACK_Type Value 1551 ____________________ 1553 Simple 0 1554 MD5 MAC 1 1555 SHA-1 HMAC 2 1556 Unassigned 3-255 1558 SHA-1 HMAC - Data portion contains output of SHA-1 HMAC function [RFC 1559 2104]. Input to HMAC function is the Nonce_C value appended to the 1560 decrypted portion, sans encryption padding, of the Key Download 1561 payload of the received Key Download Packet. 1563 5.13 Vendor ID Payload 1565 The Vendor ID Payload contains a vendor defined constant. The constant 1566 is used by vendors to identify and recognize remote instances of their 1567 implementations. This mechanism allows a vendor to experiment with new 1568 features while maintaining backwards compatibility. This is not a general 1569 extension facility of T-GSAKMP. Figure 15 shows the format of the Vendor ID 1570 Payload. 1572 The Vendor ID payload is not an announcement from the sender that it 1573 will send private payload types. A vendor sending the Vendor ID MUST 1574 NOT make any assumptions about private payloads that it may send unless 1575 a Vendor ID is received as well. Multiple Vendor ID payloads MAY be 1576 sent. An implementation is NOT REQUIRED to understand any Vendor ID 1577 payloads. An implementation is NOT REQUIRED to send any Vendor ID payload 1578 at all. If a private payload was sent without prior agreement to send it, a 1579 compliant implementation may reject a proposal with a notify message of type 1580 INVALID-PAYLOAD-TYPE. 1582 The vendor defined constant MUST be unique. The choice of hash and text to 1583 hash is left to the vendor to decide. As an example, vendors could generate 1584 their vendor id by taking a plain (non-keyed) hash of a string containing 1585 the product name, and the version of the product. 1587 The Vendor ID Payload fields are defined as follows: 1589 Next Payload (1 octet) - Identifier for the payload type of the next 1590 payload in the message. If the current payload is the last in the 1591 message, then this field will be 0. 1593 RESERVED (1 octet) - Unused, set to 0. 1595 0 1 2 3 1596 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 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1598 ! Next Payload ! RESERVED ! Payload Length ! 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1600 ! Vendor ID (VID) ~ 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1603 Figure 15: Vendor ID Payload Format 1605 Payload Length (2 octets) - Length in octets of the current payload, 1606 including the generic payload header. 1608 Vendor ID (variable length) - Hash of the vendor string plus version (as 1609 described above). 1611 The payload type for the Vendor ID Payload is eleven (11). 1613 5.14 Key Creation Payload 1615 The Key Creation Payload contains information used to create key encryption 1616 keys. These key creation payloads can have security attributes applied 1617 to them based upon the security policy of the group. Figure 16 shows the 1618 format of the payload. 1620 0 1 2 3 1621 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 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1623 ! Next Payload ! RESERVED ! Payload Length ! 1624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1625 ! ID Type ! Key Creation Data ~ 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1628 Figure 16: Key Creation Payload Format 1630 The Key Creation Payload fields are defined as follows: 1632 Next Payload (1 octet) - Identifier for the payload type of the next 1633 payload in the message. If the current payload is the last in the 1634 message, then this field will be 0. 1636 RESERVED (1 octet) - Unused, set to 0. 1638 Payload Length (2 octets) - Length in octets of the current payload, 1639 including the generic payload header. 1641 ID Type (1 octet) - Specifies the type of Key Creation being used. 1642 Table 22 identifies the types of key download information. 1644 Table 22: Types Of Key Creation Information 1646 ID_Type Value 1647 ________________________ 1649 Reserved 0 1650 Diffie-Hellman 1 1651 other 2-255 1653 Key Creation Data (variable length) - Contains Key Creation information. 1654 The values for this field are group specific and the format is specified 1655 by the ID Type field. 1657 The payload type for the Key Creation Packet is twelve (12). 1659 5.15 Nonce Payload 1661 The Nonce Payload contains random data used to guarantee freshness during an 1662 exchange and protect against replay attacks. Figure 17 shows the format of 1663 the Nonce Payload. 1664 0 1 2 3 1665 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 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1667 ! Next Payload ! RESERVED ! Payload Length ! 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1669 ! Nonce Type ! Nonce Data ~ 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1672 Figure 17: Nonce Payload Format 1674 The Nonce Payload fields are defined as follows: 1676 Next Payload (1 octet) - Identifier for the payload type of the next 1677 payload in the message. If the current payload is the last in the 1678 message, then this field will be 0. 1680 RESERVED (1 octet) - Unused, set to 0. 1682 Payload Length (2 octets) - Length in octets of the current payload, 1683 including the generic payload header. 1685 Nonce Type (1 octet) - Specifies the type of Nonce being used. Table 23 1686 identifies the types of nonces. 1688 Table 23: Nonce Types 1690 Nonce_Type Value Definition 1691 __________________________________________________________________________ 1693 None 0 1694 Initiator 1 1695 Responder 2 1696 Combined 3 Hash ( Append (Initiator_Value, Responder_Value) ) 1697 Unassigned 4-255 1699 Nonce Data (variable length) - Contains the nonce information. The values 1700 for this field are group-specific and the format is specified by the 1701 Nonce Type field. If no group-specific information is provided, the 1702 minimum length for this field is 4 bytes. 1704 The payload type for the Nonce Payload is thirteen (13). 1706 6 T-GSAKMP State Diagram 1708 Figure 18 presents the states encountered in the use of this protocol. 1710 (1) 1711 ! -----------------------------------(17)---------------- 1712 ! ! ! 1713 V V ! 1714 ( )---------------------(4)---------------->( ) ! 1715 (idle) (queued) ! 1716 ( )<-------------------(5)-----------------( ) ! 1717 ! ^ ! 1718 ! ! ! 1719 (2) (3) ! 1720 V ! ! 1721 (Establishing Group) -(10)-> (GSA Established) -(16)->(Destroy GSA) 1722 ! ^ ^ ! ^ ^ 1723 ! ! ! ! ! !----(15)---- 1724 ! ! ! ! -----(13)- ! 1725 (6)! ------(9)----- --(12)-- ! ! 1726 !(7) ! ! ! ! 1727 V ! ! V ! ! 1728 (Establishing Group) (GSA Established) (Destroy GSA) (Destroy GSA) 1730 Figure 18: T-GSAKMP State Diagram 1732 Table 24 defines the transitions. 1734 Table 24: State Transition Events 1735 ____________________________________________________________________ 1736 Transition 1 : Request to Join is received from TCP/IP 1737 : GUI Input 1738 _______________:_Application_Input__________________________________ 1739 : 1740 _Transition_2__:_Group_SA_Required__________________________________ 1741 : 1742 Transition 3 : Failure of Peer SA service 1743 : Protocol Message failure 1744 : Incorrect format 1745 : Signature failed validation 1746 : Certificate on CRL 1747 : Access control invalid 1748 : Authorization invalid 1749 _______________:_Timeout____________________________________________ 1750 : 1751 Transition 4 : Session required, but tables full 1752 _______________:_Session_required,_but_processor_busy_______________ 1754 : 1755 _Transition_5__:_Timeout____________________________________________ 1756 : 1757 Transition 6 : Request Peer SA service 1758 _______________:_Create_Protocol_Messages___________________________ 1759 : 1760 _Transition_7__:_Peer_SA_established________________________________ 1761 : 1762 _Transition_8__:_N/A________________________________________________ 1763 : 1764 _Transition_9__:_Receipt_of_protocol_messages_______________________ 1765 : 1766 _Transition_10_:_Group_SA_establishment_complete____________________ 1767 : 1768 _Transition_11_:_N/A________________________________________________ 1769 : 1770 _Transition_12_:_LKH_event_message_completed________________________ 1771 : 1772 _Transition_13_:_Group_SA_send_failure_notification_________________ 1773 : 1774 _Transition_14_:_N/A________________________________________________ 1775 : 1776 _Transition_15_:_LKH_event_message__________________________________ 1777 : 1778 _Transition_16_:_Delete_Request_validated___________________________ 1779 : 1780 Transition 17 : Destruction complete 1781 ____________________________________________________________________ 1783 7 APPENDIX A -- Rekey Packet data format 1785 This appendix defines the format of the Rekey Event Data in the Rekey Event 1786 Payload, when using Logical Key Hierarchy (LKH) as the rekeying mechanism. 1788 The Rekey Event Data consists of Rekey Event Header and Rekey Event Packet 1789 Data(s). A Packet Data is a complete set of information that an end-user 1790 requires to be Rekeyed. Packet Datas are comprised of new Key Packs of 1791 types GTEK and Rekey. 1793 7.1 Rekey Event Header 1795 The Rekey Event Data Header contains information about the rekey data being 1796 transmitted to the group. Figure 19 shows the format for the header. 1797 0 1 2 3 1798 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 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1800 ! Group ID Value ~ 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1802 ~ Group ID Value ! 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1804 ! Time/Date Stamp ! 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1806 ! Rekey Type ! Algorithm Ver ! # of Rekey Packets ! 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1808 ! Rekey Event Packet Data(s) ~ 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1811 Figure 19: A.1: Rekey Event Header Format 1813 Group Identification Value (8 octets) - Indicates the name/title of 1814 the group to be rekeyed. This is the same format as the Group 1815 Identification Value in the T-GSAKMP Message Header. 1817 Time/Date Stamp (4 octets) - This is the time value of when the Rekey 1818 Event Data was generated. 1820 Rekey Type (1 octet) - This is the Rekey algorithm being used for this 1821 group. This value is token specific. For this appendix, this value is 1822 LKH, which has a value of one (1). 1824 Algorithm Version (1 octet) - Indicates the version of the Rekey Type 1825 being used. The value at this time is one (1). 1827 # of Rekey Packets (2 octets) - The number of Rekey Packets contained in 1828 the Rekey Data. 1830 Rekey Event Packet Data(s) (variable length) - Contains the packets of 1831 rekey event information being transmitted. 1833 7.2 Rekey Event Packet Data(s) 1835 As defined in the Rekey Event Header, # of Rekey Packets field, multiple 1836 pieces of information are sent in a Rekey Event Data. Each end user, will 1837 be interested in only one packet of the information sent. Each Packet, will 1838 contain all the Key Packs that a user requires. For each Packet, the data 1839 following the Security Header fields is encrypted with the key identified in 1840 the Security Header. Figure 20 shows the format of each Rekey Event Packet 1841 with respect to LKH. 1843 0 1 2 3 1844 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 1845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1846 ! Packet Length ! Security Header: LKH ID ! 1847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1848 ! Security Header: Key Handle ! 1849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1850 ! # of Key Packs ! Key Pack Data(s) ! 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1853 Figure 20: A.2: Rekey Event Packet Data Format 1855 Packet Length (2 octets) - Length in octets of the Rekey Packet, which 1856 consists of the # of Key Packs and the Key Pack Data(s). 1858 Security Header: LKH ID (2 octets) - This is the LKH ID of the Rekey Pack 1859 that is being used for encryption/decryption. 1861 Security Header: Key Handle (4 octets) - This is a randomly generated 1862 value to uniquely identify the key defined by the LKH ID. 1864 # of Key Packs (2 octets) - The number of key packs contained in this 1865 Packet Data. 1867 Key Pack Data(s) (variable length) - Contains all the key pack data for 1868 this packet. 1870 7.3 Key Pack Data 1872 Each Key Pack contains all the information about the key. 1873 Figure 21 shows the format for each type of key pack. 1875 0 1 2 3 1876 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 1877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1878 ! Pack Type ! Pack Length ! Pack Data ~ 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1881 Figure 21: A.3: Key Pack Data Format 1883 Pack Type (1 octet) - The type of key in this key pack. Legal values are 1884 GTEK (0) and LKH (1). 1886 Pack Length (2 octets) - The length of the Pack Data. 1888 Pack Data (variable length) - The actual data of the key, defined by the 1889 key type. 1891 7.4 Pack Data Formats 1893 There are 2 legal values for the Pack Type, GTEK and LKH. The formats for 1894 each Pack type are defined in this section. 1896 7.4.1 GTEK Pack Data 1898 This is data for the new GTEK being sent to the Rekeyed group. 1900 Key Type (1 octet) - This is the encryption algorithm for which this key 1901 data is to be used. This value is specified in the Policy Token. 1903 Key Creation Date (4 octets) - This is the time value of when this key 1904 data was originally generated. 1906 Key Expiration Date (4 octets) - This is the time value of when this key 1907 is no longer valid for use. 1909 Key Handle (4 octets) - This is the randomly generated value to uniquely 1910 identify a key. 1912 Key Data (variable length) - This is the actual encryption key data, which 1913 is dependent on the Key Type algorithm for its format. 1915 7.4.2 LKH Pack Data 1917 This is the data to fix an Group Member Rekey sequence to recover from a 1918 compromise. 1920 LKH ID (2 octets) -- This is the position of this key in the binary tree 1921 structure used by LKH. 1923 Key Type (1 octet) - This is the encryption algorithm for which this key 1924 data is to be used. This value is specified in the Policy Token. 1926 Key Creation Date (4 octets) - This is the time value of when this key 1927 data was originally generated. 1929 Key Expiration Date (4 octets) - This is the time value of when this key 1930 is no longer valid for use. 1932 Key Handle (4 octets) - This is the randomly generated value to uniquely 1933 identify a key. 1935 Key Data (variable length) - This is the actual encryption key data, which 1936 is dependent on the Key Type algorithm for its format. 1938 7.5 Example 1940 This section will give an example of the data. The data to be transmitted 1941 is: 1943 | GroupID | Date/Time | Rekey Type | Algorithm Ver | # of Packets| 1944 { (GTEK)A, (GTEK, B, E)6, (GTEK, B)F } 1946 This data shows that three packets are being transmitted. Read each 1947 packet as: 1948 a) GTEK wrapped in LKH key A 1949 b) GTEK, LKH keys B & E, all wrapped in LKH key 6 1950 c) GTEK and LKH key B, all wrapped in LKH key F 1952 We will show format for all header data, and packet (b). 1954 Definition of values: 1956 0xLLLL - length value 1957 0xHHHHHHH# - handle value 1958 0xTTTTTTTC - creation time 1959 0xTTTTTTTE - expiration time 1961 GroupID - 0xAABBCCDD 1962 0x12345678 1963 Date/Time - 0x34574509 1964 Rekey Type - 0x01 (LKH) 1965 Algorithm Vers - 0x01 1966 # of Packets - 0x0003 1967 For Packet (b): 1968 Packet Length - 0xLLLL 1969 Sec HDR:LKH ID - 0x0006 1970 Sec HDR:Key Handle - 0xHHHHHHH1 1971 # of Key Packs - 0x0003 1972 Key Pack 1: 1973 Pack Type - 0x00 (GTEK) 1974 Pack Length - 0xLLLL 1975 Key Type - 0x02 (DES3) 1976 Key Creation Date - 0xTTTTTTTC 1977 Key Expiration Date - 0xTTTTTTTE 1978 Key Handle - 0xHHHHHHH2 1979 Key Data - variable, based on key definition 1980 Key Pack 2: 1981 Pack Type - 0x01 (LKH) 1982 Pack Length - 0xLLLL 1983 LKH ID - 0x000B 1984 Key Type - 0x02 (DES3) 1985 Key Creation Date - 0xTTTTTTTC 1986 Key Expiration Date - 0xTTTTTTTE 1987 Key Handle - 0xHHHHHHH3 1988 Key Data - variable, based on key definition 1989 Key Pack 3: 1990 Pack Type - 0x01 (LKH) 1991 Pack Length - 0xLLLL 1992 LKH ID - 0x000E 1993 Key Type - 0x02 (DES3) 1994 Key Creation Date - 0xTTTTTTTC 1995 Key Expiration Date - 0xTTTTTTTE 1996 Key Handle - 0xHHHHHHH4 1997 Key Data - variable, based on key definition 1999 8 References and Authors Addresses 2001 8.1 References 2003 The following references were used in the preparation of this document: 2005 Wallner, D., Harder E., and Agee R., ``Key Management for Multicast: Issues 2006 and Architectures'', Internet Draft, Informational, September 1998. 2008 ``Multicast Security Management Protocol (MSMP) Requirements and Policy'', 2009 SPARTA, October, 1998. 2011 ``Logical Key Hierarchy (LKH) Protocol'', SPARTA, October, 1998. 2013 [RFC 2093] Harney H., Muckenhirn C., and Rivers T., ``Group Key, Management 2014 Protocol Specification'', RFC 2093, Experimental, July 1997. 2016 [RFC 2094] Harney H., Muckenhirn C., and Rivers T., ``Group Key Management 2017 Protocol Architecture'', RFC 2094, Experimental, July 1997. 2019 [RFC 2104] Krawczyk H., Bellare M., and Canetti R., ``HMAC: Keyed-Hashing 2020 for Message Authentication'', RFC 2104, Informational, February 1997. 2022 [RFC 2408] Maughan D., Schertler M., Schneider M., and Turner J., ``Internet 2023 Security Association and Key Management Protocol (ISAKMP)'', RFC 2408, 2024 Proposed Standard, November 1998. 2026 [RFC 2409] Harkins D. and Carrel D., ``The Internet Key Exchange (IKE)'', 2027 RFC 2409, Proposed Standard, November 1998. 2029 [RFC 2412] Orman H. K., ``The OAKLEY Key Determination Protocol'', RFC 2412, 2030 Informational, November 1998. 2032 The Secure Multicast Research Group (SMuG), An Internet Research Task Force 2033 Group formed to discuss issues related to multicast security. 2035 [RFC 2402] Kent S. and Atkinson, R., ``IP Authentication Header'', RFC 2402, 2036 November 1998, Proposed Standard. 2038 [RFC 2401] Kent S. and Atkinson, R., ``Security Architecture for the 2039 Internet Protocol'', RFC 2401, November 1998, Proposed Standard. 2041 [RFC 2406] Kent S. and Atkinson, R., ``IP Encapsulating Security Payload 2042 (ESP)'', RFC 2406, November 1998, Proposed Standard. 2044 Balenson D., McGrew D., Sherman A., ``Key Management for Large Dynamic 2045 Groups: One-Way Function Trees and Amortized Initialization'', Internet 2046 Draft, February 1999. 2048 Bhattacharya P. and Pereira R., ``IPSec Policy Data Model'', Internet Draft, 2049 February 1998. 2051 8.2 Authors Addresses 2053 Hugh Harney (point-of-contact) 2054 7075 Samuel Morse Drive 2055 Columbia, MD 21046 2056 (410) 872 - 1515 ext 203 2057 FAX (410) 872 - 8079 2058 hh@columbia.sparta.com 2060 Andrea Colegrove 2061 7075 Samuel Morse Drive 2062 Columbia, MD 21046 2063 (410) 872 - 1515 ext 232 2064 FAX (410) 872 - 8079 2065 acc@columbia.sparta.com 2067 Eric J. Harder 2068 R231 NSA 2069 9800 Savage Rd 2070 Suite 6534 2071 Fort Meade, MD 20755 2072 (301) 688-0847 2073 FAX (301) 688-0255 2074 ejharde@tycho.ncsc.mil 2076 Uri Meth 2077 7075 Samuel Morse Drive 2078 Columbia, MD 21046 2079 (410) 872 - 1515 ext 233 2080 FAX (410) 872 - 8079 2081 umeth@columbia.sparta.com 2083 Rod Fleischer 2084 7075 Samuel Morse Drive 2085 Columbia, MD 21046 2086 (410) 872 - 1515 ext 241 2087 FAX (410) 872 - 8079 2088 rodf@columbia.sparta.com 2090 Document expiration: October 31, 2003