SPARTA, Inc. H Harney (SPARTA) A Colegrove (SPARTA) E Harder (NSA) U Meth (SPARTA) R Fleischer (SPARTA) INTERNET-DRAFT SPARTA, Inc., National Security Agency draft-harney-sparta-gsakmp-sec-02.txt June 2000 Group Secure Association Key Management Protocol Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress''. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Document expiration: November 30, 2000 Abstract The Group Secure Association Key Management Protocol (GSAKMP) provides a security framework for creating cryptographic groups on a network. It provides mechanisms to disseminate group security policy, perform access control based upon PKI certificates, generate group keys, and recover from compromise. This framework addresses group scalability issues by facilitating delegation of process-intensive actions in a secure and controlled manner. INTERNET-DRAFT GSAKM Protocol June 2000 Copyright Notice Copyright (c) The Internet Society (2000). All Rights Reserved. Harney/Colegrove/Harder/Meth/Fleischer [Page 2] INTERNET-DRAFT GSAKM Protocol June 2000 Contents 1 Overview 6 1.1 GSAKMP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3 Document Organization . . . . . . . . . . . . . . . . . . . . . . . 7 1.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2 Terminology 9 2.1 GSAKMP Terminology . . . . . . . . . . . . . . . . . . . . . . . . 9 3 GROUP LIFE-CYCLE 12 3.1 Group Establishment . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.1Group Establishment without the Use of an Underlying SA . . . . 14 3.1.2Create Group Key . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.3Distribute Group Key . . . . . . . . . . . . . . . . . . . . . . 14 3.2 Group Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.1Member Joins/Leaves . . . . . . . . . . . . . . . . . . . . . . 19 3.2.2Rekey Events . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3 Group Removal/Destruction . . . . . . . . . . . . . . . . . . . . . 19 4 Message formats 21 4.1 GSAKMP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . . 23 4.3 Data Attributes Payload . . . . . . . . . . . . . . . . . . . . . . 23 4.4 Policy Token Payload . . . . . . . . . . . . . . . . . . . . . . . 24 4.5 Key Download Payload . . . . . . . . . . . . . . . . . . . . . . . 25 4.5.1GTEK Key Packet . . . . . . . . . . . . . . . . . . . . . . . . 26 4.5.2Rekey Key Packet . . . . . . . . . . . . . . . . . . . . . . . . 27 4.6 Rekey Event Payload . . . . . . . . . . . . . . . . . . . . . . . . 28 4.7 Identification Payload . . . . . . . . . . . . . . . . . . . . . . 29 4.8 Authorization Payload . . . . . . . . . . . . . . . . . . . . . . . 30 4.9 Certificate Payload . . . . . . . . . . . . . . . . . . . . . . . . 31 4.10Certificate Request Payload . . . . . . . . . . . . . . . . . . . . 32 4.11Hash Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.12Signature Payload . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.13Notification Payload . . . . . . . . . . . . . . . . . . . . . . . 36 4.13.1Notification Data - Acknowledgement (ACK) Message Type . . . . . 38 4.14Vendor ID Payload . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.15Key Creation Payload . . . . . . . . . . . . . . . . . . . . . . . 40 4.16Nonce Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5 GSAKMP State Diagram 43 6 APPENDIX A -- Rekey Packet data format 45 6.1 Rekey Event Header . . . . . . . . . . . . . . . . . . . . . . . . 45 6.2 Rekey Event Packet Data(s) . . . . . . . . . . . . . . . . . . . . 46 6.3 Key Pack Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.4 Pack Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.4.1GTEK Pack Data . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.4.2LKH Pack Data . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 7 Authors Addresses 50 Harney/Colegrove/Harder/Meth/Fleischer [Page 3] INTERNET-DRAFT GSAKM Protocol June 2000 List of Figures 1 Group Establishment Ladder Diagram . . . . . . . . . . . . . . . . 13 2 GSAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . . 21 3 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . . 23 4 Data Attributes Payload . . . . . . . . . . . . . . . . . . . . . . 24 5 Policy Token Payload Format . . . . . . . . . . . . . . . . . . . . 24 6 Key Download Payload Format . . . . . . . . . . . . . . . . . . . . 25 7 Rekey Event Payload Format . . . . . . . . . . . . . . . . . . . . 28 8 Identification Payload Format . . . . . . . . . . . . . . . . . . . 29 9 Authorization Payload Format . . . . . . . . . . . . . . . . . . . 30 10 Certificate Payload Format . . . . . . . . . . . . . . . . . . . . 31 11 Certificate Request Payload Format . . . . . . . . . . . . . . . . 33 12 Hash Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 34 13 Signature Payload Format . . . . . . . . . . . . . . . . . . . . . 35 14 Notification Payload Format . . . . . . . . . . . . . . . . . . . . 36 15 Notification Data - Acknowledge Message Type Format . . . . . . . . 38 16 Vendor ID Payload Format . . . . . . . . . . . . . . . . . . . . . 39 17 Key Creation Payload Format . . . . . . . . . . . . . . . . . . . . 40 18 Nonce Payload Format . . . . . . . . . . . . . . . . . . . . . . . 41 19 GSAKMP State Diagram . . . . . . . . . . . . . . . . . . . . . . . 43 20 A.1: Rekey Event Header Format . . . . . . . . . . . . . . . . . . 45 21 A.2: Rekey Event Packet Data Format . . . . . . . . . . . . . . . 46 22 A.3: Key Pack Data Format . . . . . . . . . . . . . . . . . . . . 47 Harney/Colegrove/Harder/Meth/Fleischer [Page 4] INTERNET-DRAFT GSAKM Protocol June 2000 List of Tables 1 Request to Join Message Definition . . . . . . . . . . . . . . . . 15 2 Invitation to Join Message Definition . . . . . . . . . . . . . . . 15 3 Invitation Response Message Definition . . . . . . . . . . . . . . 17 4 Key Download Message Definition . . . . . . . . . . . . . . . . . . 17 5 Key Download Message with Insufficient SA Definition . . . . . . . 18 6 Acknowledgment Message Definition . . . . . . . . . . . . . . . . . 18 7 Rekey Event Message Definition . . . . . . . . . . . . . . . . . . 20 8 Group Removal/Destruction Message Definition . . . . . . . . . . . 20 9 Group Identification Types . . . . . . . . . . . . . . . . . . . . 21 10 Payload Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11 Exchange Types . . . . . . . . . . . . . . . . . . . . . . . . . . 22 12 Policy Token Types . . . . . . . . . . . . . . . . . . . . . . . . 25 13 Key Download Data Types . . . . . . . . . . . . . . . . . . . . . . 26 14 Rekey Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 28 15 Identification Types . . . . . . . . . . . . . . . . . . . . . . . 30 16 Authorization Types . . . . . . . . . . . . . . . . . . . . . . . . 31 17 Certificate Payload Types . . . . . . . . . . . . . . . . . . . . . 32 18 Hash Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 19 Signature Types . . . . . . . . . . . . . . . . . . . . . . . . . . 35 20 Notify Messages Types . . . . . . . . . . . . . . . . . . . . . . . 37 21 Notify Messages -- Status Types . . . . . . . . . . . . . . . . . . 38 22 Acknowledgement Types . . . . . . . . . . . . . . . . . . . . . . . 38 23 Types Of Key Creation Information . . . . . . . . . . . . . . . . . 41 24 Nonce Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 25 State Transition Events . . . . . . . . . . . . . . . . . . . . . . 44 Harney/Colegrove/Harder/Meth/Fleischer [Page 5] INTERNET-DRAFT GSAKM Protocol June 2000 1 Overview The Group Secure Association Key Management Protocol (GSAKMP) provides symmetric key to groups of users on a network. It provides mechanisms to disseminate group policy, perform access control decisions during group establishment, generate group keys, recover from the compromise of group members, delegate group security functions and destroy the group. The goals of the GSAKMP are to create a protocol that: 1. Distributes group policy, 2. Provides mechanisms for distributing the group key, and 3. Provides mechanisms for a Rekey of the group. 1.1 GSAKMP Overview Protecting information requires the definition of a security policy and the enforcement of that policy by capable parties. Control and access to the cryptographic key is the primary mechanism to enforce the access control policy. The GSAKMP provides these mechanisms to control access to the group key. This document identifies the GSAKMP Message Passing Requirements. The group key(s) are created by the group controller. The group controller must start the group access control, policy enforcement process. The group controller needs to have the access rules defined for joining the group and should be able to identify and verify the permissions of the members to which they will distribute keys. The potential group members need to have ``knowledge'' of the access control policy for the group, an unambiguous identification of any party downloading keys to them, and verifiable chain of authority for key download. The group members also need to verify that the key creator is authorized to act in that capacity. In order to establish a group Secure Association (SA) to support these activities, the identity of each party in the security/access control process must be unambiguously stated/asserted and authenticated to ensure that they are authorized to be a member of the group as defined by the group's security policy. The security characteristics of the establishment protocol for the SA should include: 1. Coherent permission topology, Harney/Colegrove/Harder/Meth/Fleischer [Page 6] INTERNET-DRAFT GSAKM Protocol June 2000 2. Group policy, 3. Group policy dissemination, 4. Peer SA to protect data, and 5. Access control checking. 1.2 Assumptions GSAKMP makes the following assumptions of the underlying host: 1. The operating system can provide the process and data separation services to support software encryption. 2. A separate SA mechanism is present that is sufficient to protect the distribution of the group key. 3. The host and all the applications on that host share the same certificate identities (at least initially). 1.3 Document Organization Section 1 presents an overview of secure group communications and identifies additional reference documents. Section 2 presents the terminology and concepts used to present the requirements of this protocol. Section 3 describes the group management life-cycle and Section 4 presents the message types and formats used during each phase of the life-cycle. Section 5 presents a discussion of the states encountered in the protocol. 1.4 References The following references were used in the preparation of this document: Wallner, D., Harder E., and Agee R., ``Key Management for Multicast: Issues and Architectures'', Internet Draft, Informational, September 1998. ``Multicast Security Management Protocol (MSMP) Requirements and Policy'', SPARTA, October, 1998. ``Logical Key Hierarchy (LKH) Protocol'', SPARTA, October, 1998. [RFC 2093] Harney H., Muckenhirn C., and Rivers T., ``Group Key, Management Harney/Colegrove/Harder/Meth/Fleischer [Page 7] INTERNET-DRAFT GSAKM Protocol June 2000 Protocol Specification'', RFC 2093, Experimental, July 1997. [RFC 2094] Harney H., Muckenhirn C., and Rivers T., ``Group Key Management Protocol Architecture'', RFC 2094, Experimental, July 1997. [RFC 2104] Krawczyk H., Bellare M., and Canetti R., ``HMAC: Keyed-Hashing for Message Authentication'', RFC 2104, Informational, February 1997. [RFC 2408] Maughan D., Schertler M., Schneider M., and Turner J., ``Internet Security Association and Key Management Protocol (ISAKMP)'', RFC 2408, Proposed Standard, November 1998. [RFC 2409] Harkins D. and Carrel D., ``The Internet Key Exchange (IKE)'', RFC 2409, Proposed Standard, November 1998. [RFC 2412] Orman H. K., ``The OAKLEY Key Determination Protocol'', RFC 2412, Informational, November 1998. The Secure Multicast Research Group (SMuG), An Internet Research Task Force Group formed to discuss issues related to multicast security. [RFC 2402] Kent S. and Atkinson, R., ``IP Authentication Header'', RFC 2402, November 1998, Proposed Standard. [RFC 2401] Kent S. and Atkinson, R., ``Security Architecture for the Internet Protocol'', RFC 2401, November 1998, Proposed Standard. [RFC 2406] Kent S. and Atkinson, R., ``IP Encapsulating Security Payload (ESP)'', RFC 2406, November 1998, Proposed Standard. Balenson D., McGrew D., Sherman A., ``Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization'', Internet Draft, February 1999. Bhattacharya P. and Pereira R., ``IPSec Policy Data Model'', Internet Draft, February 1998. Harney/Colegrove/Harder/Meth/Fleischer [Page 8] INTERNET-DRAFT GSAKM Protocol June 2000 2 Terminology The following terminology is used throughout the GSAKMP paper. 2.1 GSAKMP Terminology Group Member: A group member (GM) is any entity with access to the group keys. Regardless of how a member becomes a part of the group or how the group is structured, GMs will perform the following actions: 1. Validate the GC's authorization to perform actions; 2. Accept group keys from the GC; 3. Request group keys from the GC; 4. Maintain local Certificate Revocation Lists (CRLs); 5. Enforce the cooperative group policies as stated in the group policy token; 6. Perform peer review of key management actions; and 7. Manage their local key. Group Secure Association (GSA): A cryptographic group is a logical association of users or hosts that share cryptographic key(s). This group may be established to support associations between applications or communication protocols. Group Policy: 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. Policy Token/Certificate: The policy token is a mechanism used to disseminate the group policy. 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. The group policy data element will contain a variety of information including: 1. GSAKMP protocol format, Harney/Colegrove/Harder/Meth/Fleischer [Page 9] INTERNET-DRAFT GSAKM Protocol June 2000 2. Key creation method, 3. Key dissemination policy, 4. Access control policy, 5. Group architecture policy, and 6. Compromise recovery policy. The policy token layout will be fully presented in the Group Policy Token Specification document. Group Controller: The Group Controller (GC) is a group member with authority to perform any critical protocol actions including: 1. Creating and distributing keys; 2. Maintain the Rekey infrastructure; and 3. Building and maintaining the Rekey arrays. As the group evolves, it may become desirable to have multiple controllers perform these functions (e.g., Rekey Controller and Group Key Controller). Subordinate Controller: Any group member, as defined in the group policy, has the capability to act as a Subordinate Controller (SC) thus allowing the group processing and communication requirements to be distributed equitably throughout the network. If the group is structured in such a way, the delegated group members would be identified via the policy token. The SCs may perform actions delegated to them by the GC including: 1. Dissemination of the group key and 2. Management of the status of the local group. The ease of managing a very large group may also be improved by delegating the creation of subordinate LKH arrays to the SCs. The SCs would have the authority and mechanisms necessary to create and disseminate the LKH arrays for the members under their control. A more detailed discussion of LKH arrays may be found in the Logical Key Hierarchy (LKH) Protocol document. Harney/Colegrove/Harder/Meth/Fleischer [Page 10] INTERNET-DRAFT GSAKM Protocol June 2000 Peer-to-Peer SA: Peer-to-Peer SA keys can be created by using any number of key generation protocols including the Internet Secure Association Key Management Protocol (ISAKMP)/IPSec and HS/SSL. These protocols rely on cooperative key generation algorithms and on peer review of permissions. Modern SA protocols are specifically developed to support this task. Once the peer-to-peer SA is established, the group protocol can use that SA mechanism for secure confidential peer communications throughout the life of the group. GSA Keys: GSA keys can be created using strong randomization key generation protocols. These protocols rely on a cooperatively conferred policy. Once the group keys are created and disseminated to the group members, the group protocol can use that SA mechanism for secure confidential group communications throughout the life of the group. Group Traffic Encryption Key (GTEK): The key or keys created for encrypting the group data. Logical Key Hierarchy (LKH) array: The group of keys created to facilitate the LKH compromise recovery methodology. Compromise Recovery: The act of recovering a secure operating state after detecting that a group member cannot be trusted. Harney/Colegrove/Harder/Meth/Fleischer [Page 11] INTERNET-DRAFT GSAKM Protocol June 2000 3 GROUP LIFE-CYCLE The management of a cryptographic group follows a life-cycle: group definition, group establishment, group maintenance, and group removal. Each of these life-cycle phases is discussed in the following sections. A cryptographic group is established based on some need for secure communications among a group of individuals. The activities involved in creating a cryptographic group include: 1. Determine Access Policy: Group Join 2. Determine Authorization Policy: Key Dissemination, Computer Trust, and Architecture Authorization 3. Determine Mechanisms: Algorithms and Infrastructure 4. Determine Architecture: Key Dissemination and Compromise Recovery 5. Create Group Policy Token For the purposes of this document, it is assumed that the group definition activity has occurred and the group information has been broadcast on a key management channel or through a directory service. 3.1 Group Establishment The Group Establishment Ladder diagram, Figure 1, is presented to illustrate the process of establishing a cryptographic group. The left side of the diagram represents the actions of the GC. The right side of the diagram represents the actions of the GMs. The components of each message shown in the diagram are presented in the Message Definitions sections following the diagram. Potential GMs may join a group in two ways: by invitation (push) or request (pull). For purposes of illustration, the diagram presents a ``Request to Join Group'', a ``pull'', message sent from a potential GM. At this point, the GC must accept or deny the request. ``Process RTJ`` indicates a provision for refusing the connection due to some specified reason (e.g., no group, group full, repetitive attempts to join). If the results of ``Process RTJ`` indicate that the GC should reject the request, the session is terminated. If the results of Processing the Request to Join indicate that the GC should accept the request, the session continues. The message traffic to an invited potential member also begins at this point on the diagram. Harney/Colegrove/Harder/Meth/Fleischer [Page 12] INTERNET-DRAFT GSAKM Protocol June 2000 CONTROLLER MESSAGE MEMBER !<------------Request to Join-------------! ! ! !<============SA ESTABLISHMENT===========>!(Outside GSAKMP) ! ! !-------------Invitation----------------->! ! ! !<------------Invitation Response-------->! ! ! !-------------Key Download--------------->! ! ! !<------------Acknowledgment--------------! ! ! !<=======SHARED KEYED GROUP SESSION======>! Figure 1: Group Establishment Ladder Diagram The area of the diagram specified as ``Outside GSAKMP'' is merely illustrative to show the confidentiality between the GC and GM. It is assumed, for the purposes of this document, that the GC and GM are able to establish a SA using protocols like ISAKMP and IPSec. The GC will specify the security characteristics of the SA to the outside application. The level of protection shall be as good or stronger than the SA characteristics specified in the group policy token. A suggested minimal SA security level is confidentiality with integrity. To facilitate a well ordered group creation, security policy information must be passed between the GC and the GMs using a group policy token. The group policy token must include the group's address, group permissions, group join policy, group controller identity, group management information, and digital signature of the policy creation authority. Standard design principles for secure protocols mandate the use of explicit identification of senders and recipients of messages. The signature payload of each message identifies the signer of the message and therefore satisfies the sender requirement. Within the GSAKMP header is a group ID. Because the member may be served by any Key Server within a group, this ID provides sufficient granularity for the recipient ID for the Request to Join message. Other messages sent by the potential member will contain the recipient ID for the GCKS serving that member. The Invitation message provides no authority to join the group (authorization information is contained in the signed token), but merely provides information to a potential member. Because of this, unintended receipt of this message by someone would not cause harm. The recipient ID for this message is therefore optional. The Key Download message also contains a required explicit ID. Harney/Colegrove/Harder/Meth/Fleischer [Page 13] INTERNET-DRAFT GSAKM Protocol June 2000 3.1.1 Group Establishment without the Use of an Underlying SA Group Establishment, as specified in Section 3.1, uses an underlying Security Association to protect the contents of the Token and subsequent key download. In the cases where token contents are not sensitive, GSAKMP can provide secure member joins and associated secure policy and key downloads without any reliance on an underlying secure protocol subsystem. In both of these cases, it is assumed that the data portion of the Key Download payload is encrypted. The details of the encryption of this data is provided in the Key Download payload itself. The key determination for this encryption may be done through a two-party contributory system (a la Diffie-Hellman) using the Key Creation Payloads to carry the contributions of the participants to this key, or may be transferred with the encrypted contents using public key encryption and an enveloping scheme (e.g., RFC 2630 Enveloped Data with Key Transport.) 3.1.2 Create Group Key There are two options: key generation at a single point and shared generation. In shared generation, the first member must cooperate with the GC to create the group key. There are several established software-based key creation protocols, including Diffie-Hellman and RSA, that support two group members cooperating to create a cryptographic key. However, for this document, the following discussion presents single-point key generation. Prior to the first member join, the GC will have created the GTEK and the Rekey array. 3.1.3 Distribute Group Key Potential GMs may join a group and receive the group key in two ways: by invitation (push) or request (pull). The following message definition shows a Request to Join message from a potential GM. The initial message from the GM would contain the following: 1. GSA request and 2. GM Certificate (optional). The components of a Request to Join message are are shown in Table 1: Harney/Colegrove/Harder/Meth/Fleischer [Page 14] INTERNET-DRAFT GSAKM Protocol June 2000 Table 1: Request to Join Message Definition Message Name : Request to Join Dissection : {HDR, GrpID, Nonce_I, GSA RQ} SigM, [CertM] Payload Types : GSAKMP Header, Nonce, Notification, Signature, [Certificate], [Certificate Request], [Vendor ID], [Identification], [Authorization] SigM : Signature of Group Member CertM : Certificate of Group Member {}SigX :Indicates minimum fields used in Signature [] : Indicate an optional data item The following message definition shows an ``Invitation to Join'' message from the GC to a potential GM. The initial message from the GC would contain the following: 1. Signed group policy token, 2. GSA request, and 3. GC Certificate (optional). The components of an Invitation to Join message are shown in Table 2: Table 2: Invitation to Join Message Definition Message Name : Invitation to Join Dissection : {HDR, GrpID, Policy Token, (Nonce_R, Nonce_C) OR Nonce_I, [Key Creation], GSA RQ}SigC, [CertC], [SigSC], [CertSC] Payload Types : GSAKMP Header, Policy Token, Nonce, Notification, Signature, [Certificate], [Signature], [Certificate], [Key Creation], [Certificate Request], [Vendor ID], [Identification], [Authorization] SigC : Signature of Group Controller SigSC : Signature of Subordinate Group Controller CertC : Certificate of Group Controller CertSC : Certificate of Subordinate Group Controller {}SigX :Indicates minimum fields used in Signature [] : Indicate an optional data item For purposes of discussion, this section presents a ``Invitation to Join'' as presented in Table 2. Harney/Colegrove/Harder/Meth/Fleischer [Page 15] INTERNET-DRAFT GSAKM Protocol June 2000 The GM will receive this message and process it according to the provisions of Processing the Invitation. The GSA RQ contains the identity of the message source in enough detail to allow the potential member to verify the signature. The GSA RQ also contains the ID of the invited member. In ``Process Invitation'' the potential GM will initially verify that the signature on the message is authentic. If the message signature does not verify, the session is terminated. GSAKMP sends a properly authenticated message with a Notification Payload of type NACK to indicate termination. If the message signature is authentic, then the potential GM will look at who signed the message, verify the signer's authorization, and make a decision to proceed. If the potential GM decides not to proceed, the session is terminated. GSAKMP sends a properly authenticated message with a Notification Payload of type NACK to indicate termination. If the GM initiated a pull by sending a Request to Join message, the Invitation to Join message received must contain the Nonce_R and Nonce_C payloads. If the GM is being invited to join the group via a push by the GCKS, the Invitation to Join message received must contain a Nonce_I payload. NOTE: When not using an underlying Security Association (SA), or the SA is not sufficient to protect the key data in the Key Download message, the Key Creation payload is required in this message if using a pairwise key determination system. If the potential GM has decided to continue, they will examine the information within the policy token to determine if this is a group they are authorized and interested in joining. If the decision is not to join, the session is terminated. GSAKMP sends a properly authenticated message with a Notification Payload of type NACK to indicate termination. If the potential GM is satisfied with the received information and decides to join the group, he will pass back a message containing the following: 1. Signed GSA response, and 2. GM's certificate (optional). The components of an Invitation Response message are shown in Table 3: The GC receives this message and processes it according to the provisions of Processing the Invitation Response. In this procedure, the GC will verify the signature on the message to ensure its authenticity. If the message signature does not verify, the session is terminated. GSAKMP sends a properly authenticated message with a Notification Payload of type NACK to indicate termination. Harney/Colegrove/Harder/Meth/Fleischer [Page 16] INTERNET-DRAFT GSAKM Protocol June 2000 Table 3: Invitation Response Message Definition Message Name : Invitation Response Dissection : {HDR, GrpID, (Nonce_R, Nonce_C) OR Nonce_C, [ID_R], [Key Creation], GSA RS}SigM, [CertM] Payload Types : GSAKMP Header, Nonce, [Identification], Notification, Signature, [Key Creation], [Certificate], [Vendor ID], [Authorization] SigM : Signature of Group Member CertM : Certificate of Group Member {}SigX :Indicates minimum fields used in Signature [] : Indicate an optional data item If this negotiation was initiated by the GC via a push, the Invitation Response message received must contain the Nonce_R and Nonce_C payloads. If this negotiation was initiated by the GM via a pull, the Invitation Response message received must contain a Nonce_C payload. NOTE: When not using an underlying Security Association (SA), or the SA is not sufficient to protect the key data in the Key Download message, the Key Creation payload is required in this message if using a pairwise key determination system. If the message signature is verified, and the GM passes the GC's access control checks, the GC will create and send a signed message containing the GTEK and the Rekey array to the GM. The components of a Key Download message are shown in Table 4: Table 4: Key Download Message Definition Message Name : Key Download Dissection : {HDR, GrpID, Nonce_C, ID_R, [(]Key Data[)*]}SigC, [SigSC], [CertSC] Payload Types : GSAKMP Header, Nonce, Identification, Key Download, Signature, [Authorization], [Vendor ID] SigC : Signature of Group Controller SigSC : Signature of Subordinate Group Controller CertC : Certificate of Group Controller CertSC : Certificate of Subordinate Group Controller {}SigX :Indicates minimum fields used in Signature [] : Indicate an optional data item (data)* : Indicates encrypted information The GM receives this message and processes it according to the provisions of Processing the Key Download. In this procedure, the GM will verify the following information: signature on the message to ensure its authenticity, the contents of the nonce payload, and the identity information contained Harney/Colegrove/Harder/Meth/Fleischer [Page 17] INTERNET-DRAFT GSAKM Protocol June 2000 in the Identification payload is the GM identity information. If the message signature, nonce, or identification information does not verify, the session is terminated. GSAKMP sends a properly authenticated message with a Notification Payload of type NACK to indicate termination. NOTE: When not using an underlying Security Association (SA), or the SA is not sufficient to protect the key data in the Key Download message, the Key Data section of the Key Download message must be encrypted. An example format for this message is shown in Table 5: Table 5: Key Download Message with Insufficient SA Definition Message Name : Key Download Dissection : {HDR, GrpID, Nonce_C, ID_R, (Key Data)*}SigC, [SigSC], [CertSC] Payload Types : GSAKMP Header, Nonce, Identification, Key Download, Signature, [Authorization], [Vendor ID] SigC : Signature of Group Controller SigSC : Signature of Subordinate Group Controller CertC : Certificate of Group Controller CertSC : Certificate of Subordinate Group Controller {}SigX :Indicates minimum fields used in Signature [] : Indicate an optional data item (data)* : Indicates encrypted information If the message signature, nonce, and identification are verified, the GM will create a signed acknowledgment message to return to the GC. The components of an Acknowledgment message are shown in Table 6: Table 6: Acknowledgment Message Definition Message Name : Acknowledgment Dissection : {HDR, GrpID, Nonce_C, [ID_R], ACK}SigM, [CertM] Payload Types : GSAKMP Header, Nonce, [Identification], Notification, Signature, [Certificate], [Vendor ID], [Identification], [Authorization] SigM : Signature of Group Member CertM : Certificate of Group Member {}SigX :Indicates minimum fields used in Signature [] : Indicate an optional data item The GC receives the signed acknowledgment and processes it according to the provision of Processing the Acknowledgement. In this procedure, the GC will verify the signature on the message to ensure its authenticity and the nonce value. If the message signature or nonce does not verify, the session is terminated. GSAKMP sends a properly authenticated message with a Notification Payload of type NACK to indicate termination. Harney/Colegrove/Harder/Meth/Fleischer [Page 18] INTERNET-DRAFT GSAKM Protocol June 2000 If the message signature and nonce are verified, then the GC and GM have established a Shared Keyed Group Session. 3.2 Group Maintenance The Group Maintenance phase includes member joins and leaves, group rekey activities, and the management of Rekey events. These activities are presented in the following sections. 3.2.1 Member Joins/Leaves The addition of group members to a previously established group will closely follow the processing presented in Section 3.1 -- Group Establishment. With the exception of the pure group establishment tasks (e.g., creation of policy token, GTEK, and Rekey array), an entity becomes a GM using the same message exchanges described in Section 3.1. A member who elects to voluntarily leave the group will be responsible for destroying his key. Any further action for a voluntary leave should be specifically addressed in the group's security policy. 3.2.2 Rekey Events A Rekey event is any action, including compromises, that involves the creation and dissemination of a new group key and/or Rekey information. Once it has been identified, using the group's security policy, that a Rekey event has occurred, the GC must create and send a signed message containing the GTEK and Rekey array to the group. Each GM who receives this message must verify the signature on the message to ensure its authenticity. If the message signature does not verify, the session is terminated. GSAKMP sends a properly authenticated message with a Notification Payload of type NACK to indicate termination. Upon verification the GM will find the appropriate Rekey download packet and decrypt the information with a stored Rekey key. The components of a Rekey Event message are shown in Table 7: 3.3 Group Removal/Destruction At this point in the group's life-cycle, there has been a decision to destroy the group and the notification is broadcast on a key management Harney/Colegrove/Harder/Meth/Fleischer [Page 19] INTERNET-DRAFT GSAKM Protocol June 2000 Table 7: Rekey Event Message Definition Message Name : Rekey Event Dissection : {HDR, GrpID, [Policy Token], Rekey Array}SigC, [CertC] Payload Types : GSAKMP Header, [Policy Token], Rekey Event, Signature, [Certificate], [Vendor ID] SigC : Signature of Group Controller CertC : Certificate of Group Controller {}SigX :Indicates minimum fields used in Signature [] : Indicate an optional data item channel or through a directory service. The components of a Group Removal/Destruction message are shown in Table 8: Table 8: Group Removal/Destruction Message Definition Message Name : Group Removal/Destruction Dissection : {HDR, GrpID, [Policy Token], Destruct}SigC, [CertC] Payload Types : GSAKMP Header, [Policy Token], Notification, Signature, [Certificate], [Vendor ID] SigC : Signature of Group Controller CertC : Certificate of Group Controller {}SigX :Indicates minimum fields used in Signature [] : Indicate an optional data item Harney/Colegrove/Harder/Meth/Fleischer [Page 20] INTERNET-DRAFT GSAKM Protocol June 2000 4 Message formats 4.1 GSAKMP Header The GSAKMP Header fields are defined in Figure 2: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! !Group ID Type ! Group ID Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ ! Next Payload ! Version ! Exchange Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Message ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 2: GSAKMP Header Format Group Identification Type (1 octet) - Table 9 presents the group identification types. Table 9: Group Identification Types Grp ID Type Value _____________________ IPSec IPv4 0 IPSec IPv6 1 TLS 2 SMIME 3 Other 4-255 Group Identification Value (8 octets) - Indicates the name/title of the group. Next Payload (1 octet) - Indicates the type of the first payload in the message. The format for each payload is defined in the following sections. Table 10 presents the payload types. Version (1 octet) - Indicates the version of the GSAKMP protocol in use. Harney/Colegrove/Harder/Meth/Fleischer [Page 21] INTERNET-DRAFT GSAKM Protocol June 2000 Table 10: Payload Types Next_Payload_Type Value ___________________________________ None 0 Policy Token 1 Key Download Packet 2 Rekey event 3 Identification 4 Authorization 5 Certificate 6 Certificate Request 7 Hash 8 Signature 9 Notification 10 Vendor ID 11 Key Creation 12 Nonce 13 Reserved 14 - 127 Private Use 128 -- 255 Exchange Type (1 octet) - Indicates the type of exchange (also known as the message type). Table 11 presents the exchange type values. Table 11: Exchange Types Exchange_Type Value ___________________________________ Request to Join 0 Invitation 1 Invitation Response 2 Key Download 3 Acknowledgement 4 Rekey Event 5 Group Removal/Destruction 6 Other 7-255 Message ID (4 octets) - This field is included to keep symmetry with ISAKMP. Currently, this value is set to zero (0). Length (4 octets) - Length of total message (header + payloads) in octets. Encryption can expand the size of a GSAKMP message. Harney/Colegrove/Harder/Meth/Fleischer [Page 22] INTERNET-DRAFT GSAKM Protocol June 2000 4.2 Generic Payload Header Each GSAKMP payload defined in the following sections begins with a generic header, shown in Figure 3, which provides a payload ``chaining`` capability and clearly defines the boundaries of a payload. The Generic Payload Header fields are defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 3: Generic Payload Header Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the ``chaining`` capability. RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. 4.3 Data Attributes Payload There are instances within GSAKMP where it is necessary to represent Data Attributes. These Data Attributes are not a GSAKMP payload, but are contained within GSAKMP payloads. The format of the Data Attributes provides the flexibility for representation of many different types of information. There can be multiple Data Attributes within a payload. The length of the Data Attributes will either be 4 octets or defined by the Attribute Length field. This is done using the Attribute Format bit described in Figure 4. The Data Attributes fields are defined as follows: Attribute Type (2 octets) - Unique identifier for each type of attribute. The most significant bit, or Attribute Format (AF), indicates whether the data attributes follow the Type/Length/Value (TLV) format or a shortened Type/Value (TV) format. If the AF bit is a zero (0), then the Data Attributes are of the Type/Length/Value (TLV) form. If the AF bit is a one (1), then the Data Attributes are of the Type/Value form. Harney/Colegrove/Harder/Meth/Fleischer [Page 23] INTERNET-DRAFT GSAKM Protocol June 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Attribute Type ! AF=0 Attribute Length ! ! ! AF=1 Attribute Value ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! AF=0 Attribute Value ~ ! AF=1 Not Transmitted ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 4: Data Attributes Payload Attribute Length (2 octets) - Length in octets of the Attribute Value. When the AF bit is a one (1), the Attribute Value is only 2 octets and the Attribute Length field is not present. Attribute Value (variable length) - Value of the attribute associated with the GSAKMP-specific Attribute Type. If the AF bit is a zero (0), this field has a variable length defined by the Attribute Length field. If the AF bit is a one (1), the Attribute Value has a length of 2 octets. 4.4 Policy Token Payload The Policy Token Payload contains group specific information that describes the group security relevant behaviors, access control parameters, and security mechanisms. This information may contain a digital signature(s) to prove authority and integrity of the information. Figure 5 shows the format of the payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! ID Type ! Policy Token Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 5: Policy Token Payload Format The Policy Token Payload fields are defined as follows: Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. Harney/Colegrove/Harder/Meth/Fleischer [Page 24] INTERNET-DRAFT GSAKM Protocol June 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Key Download Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 6: Key Download Payload Format RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. ID Type (1 octet) - Specifies the type of Policy Token being used. Table 12 identifies the types of policy tokens. Table 12: Policy Token Types ID_Type Value ______________________ Group 0 Auxiliary 1 Reserved 2-63 Unassigned 64-255 Policy Token Data (variable length) - Contains Policy Token information. The values for this field are group specific and the format is specified by the ID Type field. The payload type for the Policy Token Payload is one (1). 4.5 Key Download Payload The Key Download Payload contains group keys. These key download payloads can have several security attributes applied to them based upon the security policy of the group. Figure 6 shows the format of the payload. If the security policy of the group dictates, the key download payload may be encrypted with a key exchange key (KEK). The type of encryption used is specified in the Policy Token. The group members may create the KEK using the key creation method identified in the Key Creation Payload. The Key Download Payload fields are defined as follows: Harney/Colegrove/Harder/Meth/Fleischer [Page 25] INTERNET-DRAFT GSAKM Protocol June 2000 Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. Key Download Data (variable length) - Contains Key Download information. Number of Key Packets (2 octets) -- Contains the total number of both GTEK and Rekey arrays being passed in this data block. For each Key Packet, the data format is as follows: Key Download Data (KDD) Type (1 octet) -- Identifier for the Key Data field of this Key Packet. See Table 13 for the possible values of this field. Table 13: Key Download Data Types Key Download Data Type Value ________________________________ GTEK 0 Rekey 1 Unassigned 2-255 Key Download Length (2 octets) -- Length in octets of the Key Packet data following this field. Key Packet Data (variable length) -- Contains Key information. The format of this field is specific depending on the value of the Key Download Data field. 4.5.1 GTEK Key Packet For a Key Download Data value of GTEK, the Key Packet Data field is formatted as follows: Key Type (1 octet) -- This is the encryption algorithm for which this key data is to be used. This value is specified in the Policy Token. Key Creation Date (4 octets) -- This is the time value of when this key Harney/Colegrove/Harder/Meth/Fleischer [Page 26] INTERNET-DRAFT GSAKM Protocol June 2000 data was originally generated. Key Expiration Date (4 octets) -- This is the time value of when this key is no longer valid for use. Key Handle (4 octets) -- This is the randomly generated value to uniquely identify a key. Key Data (variable length) -- This is the actual encryption key data, which is dependent on the Key Type algorithm for its format. 4.5.2 Rekey Key Packet GSAKMP currently uses the Logical Key Hierarchy (LKH) protocol for Rekey operations. This Key Packet Data is assumed to contain LKH Array data of the following format: LKH Version (1 octet) -- Contains the version of the LKH protocol which the data is formatted in. Leaf ID (2 octets) -- This is the Leaf Node ID of the LKH sequence contained in this Key Packet Data block. Number of LKH Keys (2 octets) -- This value is the number of distinct LKH keys in this sequence. For each LKH key in the sequence, the data format is as follows: LKH ID (2 octets) -- This is the position of this key in the binary tree structure used by LKH. Key Type (1 octet) -- This is the encryption algorithm for which this key data is to be used. This value is specified in the Policy Token. Key Creation Date (4 octets) -- This is the time value of when this key data was originally generated. Key Expiration Date (4 octets) -- This is the time value of when this key is no longer valid for use. Key Handle (4 octets) -- This is the randomly generated value to uniquely identify a key. Key Data (variable length) -- This is the actual encryption key data, which is dependent on the Key Type algorithm for its format. Harney/Colegrove/Harder/Meth/Fleischer [Page 27] INTERNET-DRAFT GSAKM Protocol June 2000 The payload type for the Key Download Packet is two (2). 4.6 Rekey Event Payload The Rekey Event Payload contains multiple keys encrypted in Rekey keys. These Rekey Event payloads can have several security attributes applied to them based upon the security policy of the group. Figure 7 shows the format of the payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! ID Type ! Rekey Event Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 7: Rekey Event Payload Format The Rekey Event Payload fields are defined as follows: Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. ID Type (1 octet) - Specifies the type of Rekey Event being used. Table 14 presents the types of Rekey events. Table 14: Rekey Event Types ID_Type Value ______________________________ None 0 Group Recovery 1 Individual Recovery 2 Maintenance 3 Delete Group Key 4 Unassigned 5-255 Rekey Event Data (variable length) - Contains Rekey Event information. Harney/Colegrove/Harder/Meth/Fleischer [Page 28] INTERNET-DRAFT GSAKM Protocol June 2000 The values for this field are group specific and the format is specified by the ID Type field. The format for the LKH type of Rekey Event Data is located in the appendix section. The Rekey Event payload type is three (3). 4.7 Identification Payload The Identification Payload contains entity-specific data used to exchange identification information. This information is used for determining the identities of negotiating members and may be used for determining authenticity of information. Figure 8 shows the format of the Identification Payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! ID Type ! Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 8: Identification Payload Format The Identification Payload fields are defined as follows: Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. ID Type (1 octet) - Specifies the type of Identification being used. Table 15 identifies the types of identities. Identification Data (variable length) - Contains identity information. The values for this field are group-specific and the format is specified by the ID Type field. The payload type for the Identification Payload is four (4). Harney/Colegrove/Harder/Meth/Fleischer [Page 29] INTERNET-DRAFT GSAKM Protocol June 2000 Table 15: Identification Types ID_Type Value _____________________________________________ Sender Distinguished Name 0 Receiver Distinguished Name 1 Hash of Sender Distinguished Name 2 Hash of Receiver Distinguished Name 3 Unassigned 4-255 4.8 Authorization Payload The Authorization Payload contains group-specific data used to exchange role authorization information. This information is used for determining the authorization of entities within a group. Figure 9 shows the format of the Authorization 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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Auth Type ! Authorization Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 9: Authorization Payload Format The Authorization Payload fields are defined as follows: Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. Authorization Type (1 octet) - Specifies the type of role authorization being used. Table 16 identifies the types of roles. Authorization Data (variable length) - Contains authorization information. The values for this field are group-specific and the format is specified by the Authorization Type field. Harney/Colegrove/Harder/Meth/Fleischer [Page 30] INTERNET-DRAFT GSAKM Protocol June 2000 Table 16: Authorization Types Auth_Type Value ________________________________________________ Group Controller 0 Group and Rekey Controller 1 Rekey Controller 2 Subordinate Group Controller 3 Subordinate Group and Rekey Controller 4 Subordinate Rekey Controller 5 Member ID 6 Unassigned 7-255 The payload type for the Authorization Payload is five (5). 4.9 Certificate Payload The Certificate Payload provides a means to transport certificates or other certificate-related information via GSAKMP and can appear in any GSAKMP message. Certificate payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available to distribute certificates. The Certificate payload MUST be accepted at any point during an exchange. Figure 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 Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Cert Encoding ! Certificate Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 10: Certificate Payload Format The Certificate Payload fields are defined as follows: Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, Harney/Colegrove/Harder/Meth/Fleischer [Page 31] INTERNET-DRAFT GSAKM Protocol June 2000 including the generic payload header. Certificate Encoding (1 octet) - This field indicates the type of certificate or certificate-related information contained in the Certificate Data field. Table 17 presents the types of certificate payloads. Table 17: Certificate Payload Types Certificate_Type Value _______________________________________________ None 0 PKCS #7 wrapped X.509 certificate 1 PGP Certificate 2 DNS Signed Key 3 X.509 Certificate -- Signature 4 X.509 Certificate - Key Exchange 5 Kerberos Tokens 6 Certificate Revocation List (CRL) 7 Authority Revocation List (ARL) 8 SPKI Certificate 9 X.509 Certificate -- Attribute 10 Reserved 11 -- 255 Certificate Data (variable length) - Actual encoding of certificate data. The type of certificate is indicated by the Certificate Encoding field. The payload type for the Certificate Payload is six (6). 4.10 Certificate Request Payload The Certificate Request Payload provides a means to request certificates via GSAKMP and can appear in any message. Certificate Request payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g., Secure DNS [DNSSEC]) is not available to distribute certificates. The Certificate Request payload MUST be accepted at any point during the exchange. The responder to the Certificate Request payload MUST send its certificate, if certificates are supported, based on the values contained in the payload. If multiple certificates are required, then multiple Certificate Request payloads SHOULD be transmitted. Figure 11 shows the format of the Certificate Request Payload. The Certificate Payload fields are defined as follows: Next Payload (1 octet) - Identifier for the payload type of the next Harney/Colegrove/Harder/Meth/Fleischer [Page 32] INTERNET-DRAFT GSAKM Protocol June 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Cert Type ! Certificate Authority ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 11: Certificate Request Payload Format payload in the message. If the current payload is the last in the message, then this field will be 0. RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. Certificate Type (1 octet) - Contains an encoding of the type of certificate requested. Certificate Authority (variable length) - Contains an encoding of an acceptable certificate authority for the type of certificate requested. As an example, for an X.509 certificate this field would contain the Distinguished Name encoding of the Issuer Name of an X.509 certificate authority acceptable to the sender of this payload. This would be included to assist the responder in determining how much of the certificate chain would need to be sent in response to this request. If there is no specific certificate authority requested, this field SHOULD NOT be included. The payload type for the Certificate Request Payload is seven (7). 4.11 Hash Payload The Hash Payload contains data generated by the hash function over some part of the message and/or GSAKMP state. This payload may be used to verify the integrity of the data in a GSAKMP message or for authentication of the negotiating entities. Figure 12 shows the format of the Hash Payload. The Hash Payload fields are defined as follows: Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the Harney/Colegrove/Harder/Meth/Fleischer [Page 33] INTERNET-DRAFT GSAKM Protocol June 2000 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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Hash Domain ! Hash Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 12: Hash Payload Format message, then this field will be 0. RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. Hash Domain (1 octet) - Specifies the domain of the hash. Table 18 identifies the hash domains. Table 18: Hash Domains Hash Domain Value _____________________ None 0 Unassigned 1-255 Hash Data (variable length) - Contains the hash information. The payload type for the Hash Payload is eight (8). 4.12 Signature Payload The Signature Payload contains data generated by the digital signature function. The digital signature covers the Signature Payload Span and the Signature Payload up to the Signature Data. The exception to this is if the signature algorithm used is DSS with ASN.1/DER encoding. Due to the variable length of a DER encoding, the signature span across the signature payload itself only extends up to the signature data length field, not the signature data. Figure 13 shows the format of the Signature Payload. The Signature Payload fields are defined as follows: Harney/Colegrove/Harder/Meth/Fleischer [Page 34] INTERNET-DRAFT GSAKM Protocol June 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Sig Type ! Signature Payload Span ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ ! Sig ID Role ! Signature Timestamp ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ ! Signer ID Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ Signer ID Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Signature Length ! Signature Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 13: Signature Payload Format Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. Signature Type (1 octet) -- Indicates the type of signature. Table 19 presents the Signature Types. Table 19: Signature Types Signature Type Value _____________________________________ DSS with ASN.1/DER encoding 0 DSS without encoding 1 Other 2-255 Signature Payload Span (4 octets) - Identifies the information included in the signature. The first two octets define the first signature payload. The third and fourth octet define the last payload. The payloads in the message are an ordered sequence beginning at the header, with a value of 0. If the signature payload itself is not in the signature span, you must still sign over the signature payload up to the signature data. Harney/Colegrove/Harder/Meth/Fleischer [Page 35] INTERNET-DRAFT GSAKM Protocol June 2000 Signature ID Role (1 octet) -- Specifies the type of Authorization (Role) being used. Refer to Table 16 for the types of authorization (role). Signature Timestamp (4 octets) -- Date and time that the digital signature was applied. Signer ID Length (2 octets) - Length in octets of the Signer' ID. Signer ID (variable length) -- Data identifying the Signer's ID (e.g., DN). Signature Data (variable length) - Data that results from applying the digital signature function to the GSAKMP message and/or payload. The payload type for the Signature Payload is nine (9). 4.13 Notification Payload The Notification Payload can contain both GSAKMP and group specific data and is used to transmit informational data, such as error conditions, to a GSAKMP peer. It is possible to send multiple Notification payloads in a single GSAKMP message. Figure 14 shows the format of the Notification Payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Notify Message Type ! STATUS TYPE ! ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ Notification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 14: Notification Payload Format The Notification Payload fields are defined as follows: Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, Harney/Colegrove/Harder/Meth/Fleischer [Page 36] INTERNET-DRAFT GSAKM Protocol June 2000 including the generic payload header. Notify Message Type (2 octets) - Specifies the type of notification message. Table 20 presents the Notify Message Types. Table 20: Notify Messages Types Information Value _______________________________________________ Invalid-Payload-Type 0 Situation-Not-Supported 1 Invalid-Major-Version 2 Invalid-Version 3 Invalid-Group-ID 4 Invalid-Message-ID 5 Payload-Malformed 6 Invalid-Key-Information 7 Invalid-ID-Information 8 Invalid-Cert-Encoding 9 Invalid-Certificate 10 Cert-Type-Unsupported 11 Invalid-Cert-Authority 12 Authentication-Failed 13 Invalid-Signature 14 Notify-GSA-Lifetime 15 Certificate-Unavailable 16 Unequal-Payload-Lengths 17 Unauthorized Request 18 Unable To Take Requested Role 19 Group Deleted 20 Request To Join 21 Acknowledgement 22 Invitation 23 Invitation-Response 24 Nack 25 Reserved (future use) 26 - 8191 Private Use 8192 -- 16383 Status Type (1 octet) - Specifies the status of group with respect to originator of notification. Notification information specifies status data and can be used by a process managing a SA database to communicate with a peer process. For example, a secure front end or security gateway may use the Notify message to synchronize SA communication. Table 21 presents the Notification Message Status Types. Notification Data (variable length) - Informational or error data transmitted in addition to the Notify Message Type. Values for this field are Domain of Interpretation (DOI)-specific. Harney/Colegrove/Harder/Meth/Fleischer [Page 37] INTERNET-DRAFT GSAKM Protocol June 2000 Table 21: Notify Messages -- Status Types Status Value ____________________________________ Not connected 0 Establishing group 1 Connected to group 2 Previously member of group 3 Reserved (future use) 4-255 The payload type for the Notification Payload is ten (10). 4.13.1 Notification Data - Acknowledgement (ACK) Message Type The data portion of the ACK payload serves either for confirmation of correct receipt of the Key Download message, or, when needed, can provide non-repudiation of receipt when included in a signed message. Figure 15 shows the format of the Notification Data - Acknowledge Message Type. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Ack Type ! Acknowledgement Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 15: Notification Data - Acknowledge Message Type Format The Notification Data - Acknowledgement Message Type data fields are defined as follows: Ack Type (1 octet) - Specifies the type of acknowledgement message. Table 22 presents the Notify Acknowledgement Message Types. Table 22: Acknowledgement Types ACK_Type Value ____________________ Simple 0 MD5 MAC 1 SHA-1 HMAC 2 Unassigned 3-255 Harney/Colegrove/Harder/Meth/Fleischer [Page 38] INTERNET-DRAFT GSAKM Protocol June 2000 Simple - Data portion null. MD5 MAC - Data portion contains output of MD5 HMAC function [RFC 2104]. Input to HMAC function is the Nonce_C value appended to the decrypted portion, sans encryption padding, of the Key Download payload of the received Key Download Packet. SHA-1 HMAC - Data portion contains output of SHA-1 HMAC function [RFC 2104]. Input to HMAC function is the Nonce_C value appended to the decrypted portion, sans encryption padding, of the Key Download payload of the received Key Download Packet. 4.14 Vendor ID Payload The Vendor ID Payload contains a vendor defined constant. The constant is used by vendors to identify and recognize remote instances of their implementations. This mechanism allows a vendor to experiment with new features while maintaining backwards compatibility. This is not a general extension facility of GSAKMP. Figure 16 shows the format of the Vendor ID Payload. The Vendor ID payload is not an announcement from the sender that it will send private payload types. A vendor sending the Vendor ID MUST NOT make any assumptions about private payloads that it may send unless a Vendor ID is received as well. Multiple Vendor ID payloads MAY be sent. An implementation is NOT REQUIRED to understand any Vendor ID payloads. An implementation is NOT REQUIRED to send any Vendor ID payload at all. If a private payload was sent without prior agreement to send it, a compliant implementation may reject a proposal with a notify message of type INVALID-PAYLOAD-TYPE. The vendor defined constant MUST be unique. The choice of hash and text to hash is left to the vendor to decide. As an example, vendors could generate their vendor id by taking a plain (non-keyed) hash of a string containing the product name, and the version of the product. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Vendor ID (VID) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 16: Vendor ID Payload Format The Vendor ID Payload fields are defined as follows: Harney/Colegrove/Harder/Meth/Fleischer [Page 39] INTERNET-DRAFT GSAKM Protocol June 2000 Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. Vendor ID (variable length) - Hash of the vendor string plus version (as described above). The payload type for the Vendor ID Payload is eleven (11). 4.15 Key Creation Payload The Key Creation Payload contains information used to create key encryption keys for the key download payload. These key creation payloads can have security attributes applied to them based upon the security policy of the group. Figure 17 shows the format of the payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! ID Type ! Key Creation Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 17: Key Creation Payload Format The Key Creation Payload fields are defined as follows: Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. ID Type (1 octet) - Specifies the type of Key Creation being used. Table 23 identifies the types of key download information. Harney/Colegrove/Harder/Meth/Fleischer [Page 40] INTERNET-DRAFT GSAKM Protocol June 2000 Table 23: Types Of Key Creation Information ID_Type Value ________________________ Diffie-Hellman 0 other 1-255 Key Creation Data (variable length) - Contains Key Creation information. The values for this field are group specific and the format is specified by the ID Type field. The payload type for the Key Creation Packet is twelve (12). 4.16 Nonce Payload The Nonce Payload contains random data used to guarantee freshness during an exchange and protect against replay attacks. Figure 18 shows the format of the Nonce Payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Nonce Type ! Nonce Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 18: Nonce Payload Format The Nonce Payload fields are defined as follows: Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. Nonce Type (1 octet) - Specifies the type of Nonce being used. Table 24 identifies the types of nonces. Harney/Colegrove/Harder/Meth/Fleischer [Page 41] INTERNET-DRAFT GSAKM Protocol June 2000 Table 24: Nonce Types Nonce_Type Value Definition __________________________________________________________________________ None 0 Initiator 1 Responder 2 Combined 3 Hash ( Append (Initiator_Value, Responder_Value) ) Unassigned 4-255 Nonce 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 payload type for the Identification Payload is thirteen (13). Harney/Colegrove/Harder/Meth/Fleischer [Page 42] INTERNET-DRAFT GSAKM Protocol June 2000 5 GSAKMP State Diagram Figure 19 presents the states encountered in the use of this protocol. (1) ! -----------------------------------(17)---------------- ! ! ! V V ! ( )---------------------(4)---------------->( ) ! (idle) (queued) ! ( )<-------------------(5)-----------------( ) ! ! ^ ! ! ! ! (2) (3) ! V ! ! (Establishing Group) -(10)-> (GSA Established) -(16)->(Destroy GSA) ! ^ ^ ! ^ ^ ! ! ! ! ! !----(15)---- ! ! ! ! -----(13)- ! (6)! ------(9)----- --(12)-- ! ! !(7) ! ! ! ! V ! ! V ! ! (Establishing Group) (GSA Established) (Destroy GSA) (Destroy GSA) Figure 19: GSAKMP State Diagram Table 25 defines the transitions. Harney/Colegrove/Harder/Meth/Fleischer [Page 43] INTERNET-DRAFT GSAKM Protocol June 2000 Table 25: State Transition Events ____________________________________________________________________ Transition 1 : Request to Join is received from TCP/IP : GUI Input _______________:_Application_Input__________________________________ : _Transition_2__:_Group_SA_Required__________________________________ : Transition 3 : Failure of Peer SA service : Protocol Message failure : Incorrect format : Signature failed validation : Certificate on CRL : Access control invalid : Authorization invalid _______________:_Timeout____________________________________________ : Transition 4 : Session required, but tables full _______________:_Session_required,_but_processor_busy_______________ : _Transition_5__:_Timeout____________________________________________ : Transition 6 : Request Peer SA service _______________:_Create_Protocol_Messages___________________________ : _Transition_7__:_Peer_SA_established________________________________ : _Transition_8__:_N/A________________________________________________ : _Transition_9__:_Receipt_of_protocol_messages_______________________ : _Transition_10_:_Group_SA_establishment_complete____________________ : _Transition_11_:_N/A________________________________________________ : _Transition_12_:_LKH_event_message_completed________________________ : _Transition_13_:_Group_SA_send_failure_notification_________________ : _Transition_14_:_N/A________________________________________________ : _Transition_15_:_LKH_event_message__________________________________ : _Transition_16_:_Delete_Request_validated___________________________ : Transition 17 : Destruction complete ____________________________________________________________________ Harney/Colegrove/Harder/Meth/Fleischer [Page 44] INTERNET-DRAFT GSAKM Protocol June 2000 6 APPENDIX A -- Rekey Packet data format This appendix defines the format of the Rekey Event Data in the Rekey Event Payload, when using Logical Key Hierarchy (LKH) as the rekeying mechanism. The Rekey Event Data consists of Rekey Event Header and Rekey Event Packet Data(s). A Packet Data is a complete set of information that an end-user requires to be Rekeyed. Packet Datas are comprised of new Key Packs of types GTEK and Rekey. 6.1 Rekey Event Header The Rekey Event Data Header contains information about the rekey data being transmitted to the group. Figure 20 shows the format for the header. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Group ID Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ Group ID Value ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Time/Date Stamp ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Rekey Type ! Algorithm Ver ! # of Rekey Packets ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Rekey Event Packet Data(s) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 20: A.1: Rekey Event Header Format Group Identification Value (8 octets) - Indicates the name/title of the group to be rekeyed. This is the same format as the Group Identification Value in the GSAKMP Message Header. Time/Date Stamp (4 octets) - This is the time value of when the Rekey Event Data was generated. Rekey Type (1 octet) - This is the Rekey algorithm being used for this group. This value is token specific. For this appendix, this value is LKH, which has a value of one (1). Algorithm Version (1 octet) - Indicates the version of the Rekey Type being used. The value at this time is one (1). # of Rekey Packets (2 octets) - The number of Rekey Packets contained in Harney/Colegrove/Harder/Meth/Fleischer [Page 45] INTERNET-DRAFT GSAKM Protocol June 2000 the Rekey Data. Rekey Event Packet Data(s) (variable length) - Contains the packets of rekey event information being transmitted. 6.2 Rekey Event Packet Data(s) As defined in the Rekey Event Header, # of Rekey Packets field, multiple pieces of information are sent in a Rekey Event Data. Each end user, will be interested in only one packet of the information sent. Each Packet, will contain all the Key Packs that a user requires. For each Packet, the data following the Security Header fields is encrypted with the key identified in the Security Header. Figure 21 shows the format of each Rekey Event Packet with respect to LKH. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Packet Length ! Security Header: LKH ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Security Header: Key Handle ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! # of Key Packs ! Key Pack Data(s) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 21: A.2: Rekey Event Packet Data Format Packet Length (2 octets) - Length in octets of the Rekey Packet, which consists of the # of Key Packs and the Key Pack Data(s). Security Header: LKH ID (2 octets) - This is the LKH ID of the Rekey Pack that is being used for encryption/decryption. Security Header: Key Handle (4 octets) - This is a randomly generated value to uniquely identify the key defined by the LKH ID. # of Key Packs (2 octets) - The number of key packs contained in this Packet Data. Key Pack Data(s) (variable length) - Contains all the key pack data for this packet. Harney/Colegrove/Harder/Meth/Fleischer [Page 46] INTERNET-DRAFT GSAKM Protocol June 2000 6.3 Key Pack Data Each Key Pack contains all the information about the key. Figure 22 shows the format for each type of key pack. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Pack Type ! Pack Length ! Pack Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 22: A.3: Key Pack Data Format Pack Type (1 octet) - The type of key in this key pack. Legal values are GTEK (0) and LKH (1). Pack Length (2 octets) - The length of the Pack Data. Pack Data (variable length) - The actual data of the key, defined by the key type. 6.4 Pack Data Formats There are 2 legal values for the Pack Type, GTEK and LKH. The formats for each Pack type are defined in this section. 6.4.1 GTEK Pack Data This is data for the new GTEK being sent to the Rekeyed group. Key Type (1 octet) - This is the encryption algorithm for which this key data is to be used. This value is specified in the Policy Token. Key Creation Date (4 octets) - This is the time value of when this key data was originally generated. Key Expiration Date (4 octets) - This is the time value of when this key is no longer valid for use. Key Handle (4 octets) - This is the randomly generated value to uniquely identify a key. Key Data (variable length) - This is the actual encryption key data, which Harney/Colegrove/Harder/Meth/Fleischer [Page 47] INTERNET-DRAFT GSAKM Protocol June 2000 is dependent on the Key Type algorithm for its format. 6.4.2 LKH Pack Data This is the data to fix an Group Member Rekey sequence to recover from a compromise. LKH ID (2 octets) -- This is the position of this key in the binary tree structure used by LKH. Key Type (1 octet) - This is the encryption algorithm for which this key data is to be used. This value is specified in the Policy Token. Key Creation Date (4 octets) - This is the time value of when this key data was originally generated. Key Expiration Date (4 octets) - This is the time value of when this key is no longer valid for use. Key Handle (4 octets) - This is the randomly generated value to uniquely identify a key. Key Data (variable length) - This is the actual encryption key data, which is dependent on the Key Type algorithm for its format. 6.5 Example This section will give an example of the data. The data to be transmitted is: | GroupID | Date/Time | Rekey Type | Algorithm Ver | # of Packets| { (GTEK)A, (GTEK, B, E)6, (GTEK, B)F } This data shows that three packets are being transmitted. Read each packet as: a) GTEK wrapped in LKH key A b) GTEK, LKH keys B & E, all wrapped in LKH key 6 c) GTEK and LKH key B, all wrapped in LKH key F We will show format for all header data, and packet (b). Definition of values: Harney/Colegrove/Harder/Meth/Fleischer [Page 48] INTERNET-DRAFT GSAKM Protocol June 2000 0xLLLL - length value 0xHHHHHHH# - handle value 0xTTTTTTTC - creation time 0xTTTTTTTE - expiration time GroupID - 0xAABBCCDD 0x12345678 Date/Time - 0x34574509 Rekey Type - 0x01 (LKH) Algorithm Vers - 0x01 # of Packets - 0x0003 For Packet (b): Packet Length - 0xLLLL Sec HDR:LKH ID - 0x0006 Sec HDR:Key Handle - 0xHHHHHHH1 # of Key Packs - 0x0003 Key Pack 1: Pack Type - 0x00 (GTEK) Pack Length - 0xLLLL Key Type - 0x02 (DES3) Key Creation Date - 0xTTTTTTTC Key Expiration Date - 0xTTTTTTTE Key Handle - 0xHHHHHHH2 Key Data - variable, based on key definition Key Pack 2: Pack Type - 0x01 (LKH) Pack Length - 0xLLLL LKH ID - 0x000B Key Type - 0x02 (DES3) Key Creation Date - 0xTTTTTTTC Key Expiration Date - 0xTTTTTTTE Key Handle - 0xHHHHHHH3 Key Data - variable, based on key definition Key Pack 3: Pack Type - 0x01 (LKH) Pack Length - 0xLLLL LKH ID - 0x000E Key Type - 0x02 (DES3) Key Creation Date - 0xTTTTTTTC Key Expiration Date - 0xTTTTTTTE Key Handle - 0xHHHHHHH4 Key Data - variable, based on key definition Harney/Colegrove/Harder/Meth/Fleischer [Page 49] INTERNET-DRAFT GSAKM Protocol June 2000 7 Authors Addresses Hugh Harney (point-of-contact) 9861 Broken Land Parkway Suite 300 Columbia, MD 21046 (410) 381-9400 ext 203 FAX (410) 381-5559 hh@columbia.sparta.com Andrea Colegrove 9861 Broken Land Parkway Suite 300 Columbia, MD 21046 (410) 381-9400 ext 232 FAX (410) 381-5559 acc@columbia.sparta.com Eric J. Harder R231 NSA 9800 Savage Rd Suite 6534 Fort Meade, MD 20755 (301) 688-0847 FAX (301) 688-0255 ejharde@tycho.ncsc.mil Uri Meth 9861 Broken Land Parkway Suite 300 Columbia, MD 21046 (410) 381-9400 ext 233 FAX (410) 381-5559 umeth@columbia.sparta.com Rod Fleischer 9861 Broken Land Parkway Suite 300 Columbia, MD 21046 (410) 381-9400 ext 237 FAX (410) 381-5559 rodf@columbia.sparta.com Document expiration: November 30, 2000 Harney/Colegrove/Harder/Meth/Fleischer [Page 50]