SPARTA, Inc. Hugh Harney, Eric Harder INTERNET-DRAFT SPARTA, Inc., National Security Agency draft-harney-sparta-gsakmp-sec-00.txt April, 1999 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. This document is an Internet-Draft. 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. To view the entire list of current Internet-Drafts, please check the ``lid-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net(Northern Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Document expiration: November 30, 1999 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 facillitating delegation of process-intensive actions in a secure and controlled manner. INTERNET-DRAFT GSAKM Protocol April, 1999 Copyright Notice Copyright Oc The Internet Society (1999). All Rights Reserved. Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 2] INTERNET-DRAFT GSAKM Protocol April, 1999 Contents 1 Overview 6 1.1 GSAKMP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3 Document Organization . . . . . . . . . . . . . . . . . . . . . . . 7 1.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2 Terminology 8 2.1 GSAKMP Terminology . . . . . . . . . . . . . . . . . . . . . . . . 9 3 GROUP LIFE-CYCLE 12 3.1 Group Establishment . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.1Create Group Key . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.2Distribute Group Key . . . . . . . . . . . . . . . . . . . . . . 14 3.2 Group Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.1Member Joins/Leaves . . . . . . . . . . . . . . . . . . . . . . 16 3.2.2CR Events . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3 Group Removal/Destruction . . . . . . . . . . . . . . . . . . . . . 17 4 Message formats 17 4.1 GSAKMP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . . 19 4.3 Data Attributes Payload . . . . . . . . . . . . . . . . . . . . . . 20 4.4 Policy Token Payload . . . . . . . . . . . . . . . . . . . . . . . 20 4.5 Key Download Payload . . . . . . . . . . . . . . . . . . . . . . . 22 4.6 CR Event Payload . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.7 Identification/Role Payload . . . . . . . . . . . . . . . . . . . . 24 4.8 Certificate Payload . . . . . . . . . . . . . . . . . . . . . . . . 25 4.9 Certificate Request Payload . . . . . . . . . . . . . . . . . . . . 27 4.10Signature Payload . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.11Notification Payload . . . . . . . . . . . . . . . . . . . . . . . 29 4.12Notify Message Types . . . . . . . . . . . . . . . . . . . . . . . 30 4.13Vendor ID Payload . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.14Key Creation Payload . . . . . . . . . . . . . . . . . . . . . . . 32 5 State Diagram 33 Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 3] INTERNET-DRAFT GSAKM Protocol April, 1999 List of Figures 1 Group Establishment Ladder Diagram . . . . . . . . . . . . . . . . 13 2 GSAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . . 18 3 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . . 19 4 Data Attributes Payload . . . . . . . . . . . . . . . . . . . . . . 20 5 Policy Token Payload Format . . . . . . . . . . . . . . . . . . . . 21 6 Key Download Payload Format . . . . . . . . . . . . . . . . . . . . 22 7 Key Download Data Payload Format . . . . . . . . . . . . . . . . . 23 8 CR Event Payload Format . . . . . . . . . . . . . . . . . . . . . . 24 9 Identification/Role Payload Format . . . . . . . . . . . . . . . . 25 10 Certificate Payload Format . . . . . . . . . . . . . . . . . . . . 26 11 Certificate Request Payload Format . . . . . . . . . . . . . . . . 27 12 Signature Payload Format . . . . . . . . . . . . . . . . . . . . . 28 13 Notification Payload Format . . . . . . . . . . . . . . . . . . . . 29 14 Vendor ID Payload Format . . . . . . . . . . . . . . . . . . . . . 32 15 Key Creation Payload Format . . . . . . . . . . . . . . . . . . . . 32 16 GSAKMP State Diagram . . . . . . . . . . . . . . . . . . . . . . . 34 Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 4] INTERNET-DRAFT GSAKM Protocol April, 1999 List of Tables 1 Message Definitions: Group Establishment . . . . . . . . . . . . . 14 2 Legend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3 Message Definitions: Compromise Recovery Event . . . . . . . . . . 17 4 Message Definitions: Group Removal and Destruction . . . . . . . . 17 5 Group Identification Type Values . . . . . . . . . . . . . . . . . 17 6 Exchange Type Values . . . . . . . . . . . . . . . . . . . . . . . 18 7 Payload Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8 Policy Token Types . . . . . . . . . . . . . . . . . . . . . . . . 21 9 Key Download Information Types . . . . . . . . . . . . . . . . . . 22 10 Key Download Data Types . . . . . . . . . . . . . . . . . . . . . . 23 11 CR Event Types . . . . . . . . . . . . . . . . . . . . . . . . . . 24 12 Identity/Role Types . . . . . . . . . . . . . . . . . . . . . . . . 25 13 Certificate Payload Types . . . . . . . . . . . . . . . . . . . . . 26 14 Signature Types . . . . . . . . . . . . . . . . . . . . . . . . . . 29 15 Signature Context Types . . . . . . . . . . . . . . . . . . . . . . 29 16 Notify Messages -- Status Types . . . . . . . . . . . . . . . . . . 30 17 Notify Messages Types . . . . . . . . . . . . . . . . . . . . . . . 31 18 Types Of Key Creation Information . . . . . . . . . . . . . . . . . 33 19 State Transition Events . . . . . . . . . . . . . . . . . . . . . . 35 Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 5] INTERNET-DRAFT GSAKM Protocol April, 1999 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 key, 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 compromise recovery based on the Logical Key Hierarchy (LKH) compromise recovery methodology. 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 the 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: Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 6] INTERNET-DRAFT GSAKM Protocol April, 1999 1. Coherent permission topology, 2. Group policy, 3. Group policy dissemination, 4. Peer SA to protect data, and 5. Access control checking. 1.2 Assumptions 1. GSAKMP makes the following assumptions of the underlying host: 2. The operating system can provide the process and data separation services to support software encryption. 3. A separate SA mechanism is present that is sufficient to protect the distribution of the group key. 4. 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: Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 7] INTERNET-DRAFT GSAKM Protocol April, 1999 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 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 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. DCCM Architecture and System Design, June 1998, Mr David Balenson, Dr Dennis Branstad, TIS Labs at Network Associates, Inc., Technical report to DARPA Contract No. F30602-97-C-0277. [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. Bhattacharya P. and Pereira R., ``IPSec Policy Data Model``, Internet Draft, February 1998. 2 Terminology The following terminology is used throughout the GSAKMP paper. Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 8] INTERNET-DRAFT GSAKM Protocol April, 1999 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 CRL lists, 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, 2. Key creation method, 3. Key dissemination policy, 4. Access control policy, 5. Group architecture policy, and 6. Compromise recovery policy. Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 9] INTERNET-DRAFT GSAKM Protocol April, 1999 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 CR infrastructure (LKH), and 3. Build and maintain the LKH arrays. As the group evolves, it may become desirable to have multiple controllers perform these functions (e.g., LKH 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 to 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 draft document. 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 SSL/HS. 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 group 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 Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 10] INTERNET-DRAFT GSAKM Protocol April, 1999 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/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 11] INTERNET-DRAFT GSAKM Protocol April, 1999 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. Mode 1 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 Mode 1 indicate that the GC should reject the request, the session is terminated. If the results of Mode 1 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/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 12] INTERNET-DRAFT GSAKM Protocol April, 1999 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 specify the group's address, group permissions, group join policy, group controller identity, group management information, and digital signature of the controller. 3.1.1 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 LKH array. Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 13] INTERNET-DRAFT GSAKM Protocol April, 1999 Table 1: Message Definitions: Group Establishment ____________________________________________________________________ Message Name :Request to Join Dissection : {HDR, Grp ID, GSA RQ} SigM, [CertM] Payload Types : GSAKMP Header, Notification, Identification/Role, Signature, [Certificate], [Certificate Request], _________________[Vendor_ID]________________________________________ Message Name : Invitation Dissection : {HDR, Policy Token, GSA RQ}SigC, [CertC], [SigSC], [CertSC} Payload Types : GSAKMP Header, Policy Token, Notification, Signature, [Certificate], [Signature], [Certificate], [Key Creation], [Certificate _________________Request],_[Vendor_ID],_[Identification/Role]_______ Message Name : Invitation Response Dissection : {HDR, GSA RS}SigM, [CertM], [RuleM] Payload Types : GSAKMP Header, [Notification], Signature, [Key Creation], [Certificate], [Vendor ID], _________________[Identification/Role]______________________________ Message Name : Key Download Dissection : {HDR,(GTEK, LKH)SigC}, [SigSC], [CertSC] Payload Types : GSAKMP Header, Key Download, Signature, [Key _________________Creation],_[Identification/Role],_[Vendor_ID]______ Message Name : Acknowledgment Dissection : {HDR, ACK}SigM, [CertM] Payload Types : GSAKMP Header, Notification, Signature, _________________[Certificate],_[Vendor_ID]_________________________ 3.1.2 Distribute Group Key This function consists of four messages between the GC and the first member. The initial message from the GC contains the following: 1. Signed group policy token, 2. GSA request, and 3. GC Certificate (optional). The GM will receive this message and process it according to the provisions of Mode 2. 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 Mode 2, the potential GM will initially verify that the signature on the message to verify its authenticity. If the message signature does not verify, the session is terminated. Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 14] INTERNET-DRAFT GSAKM Protocol April, 1999 Table 2: Legend _______________________________________________________________ SigC :Signature of Group Controller SigSC : Signature of Subordinate Group Controller SigM : Signature of Group Member CertC : Certificate of Group Controller CertSC : Certificate of Subordinate Group Controller CertM : Certificate of Group Member {}SigX :Indicates minimum fields used in Signature [] Indicates an optional data item If the message signature is authentic, then the potential GM will look at who signed the message, verify the signer's authorities, and make a decision to proceed. If the potential GM decides not to proceed, the session is terminated. 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. 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 GC receives this message and processes it according to the provisions of Mode 3. In Mode 3, the GC will verify the signature on the message to ensure its authenticity. If the message signature does not verify, the session is terminated. If the message signature is verified, then the GC will then create and send a signed message containing the GTEK and the LKH array to the GM. The GM receives this message and processes it according to the provisions in Mode 4. In Mode 4, the GM will verify the signature on the message to ensure its authenticity. If the message signature does not verify, the session is terminated. If the message signature is verified, the GM will create a signed acknowledgment message to return to the GC. The GC receives the signed acknowledgment and processes it according to the provision in Mode 5. In Mode 5, the GC will verify the signature on the message to ensure its authenticity. If the message signature does not Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 15] INTERNET-DRAFT GSAKM Protocol April, 1999 verify, the session is terminated. If the message signature is 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 CR 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 LKH 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 CR Events A CR event is any action, including compromises, that involves the creation and dissemination of a new group key and/or LKH array. A complete presentation of LKH events can be found in the draft document Logical Key Hierarchy (LKH) Protocol. Once it has been identified, using the group's security policy, that a CR event has occurred, the GC must create and send a signed message containing the GTEK and LKH 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. Upon verification the GM will find the appropriate LKH key download packet and decrypt the information with a stored LKH key. The components of a CR event message are shown in Table 3. Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 16] INTERNET-DRAFT GSAKM Protocol April, 1999 Table 3: Message Definitions: Compromise Recovery Event ___________________________________________________________________ Message Name :CR Event Dissection : {HDR, Grp ID, Policy Token, CR Array}SigC, [CertC] Payload Types : GSAKMP Header, [Policy Token], CR Event, [Certificate], [Vendor ID], [Identification/Role], ___________________Signature_______________________________________ 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 channel or through a directory service. The components of a Group Removal/Destruction message are shown in Table 4. Table 4: Message Definitions: Group Removal and Destruction ___________________________________________________________________ Message Name :Group Removal/Destruction Dissection : {HDR, Grp ID, Policy Token, Destruct}SigC, [CertC] Payload Types : GSAKMP Header, Policy Token, Notification, ___________________[Certificate],_[Vendor_ID],_[Identification/Role]_ 4 Message formats 4.1 GSAKMP Header The GSAKMP Header fields are shown in Figure 2 and defined below in Tables 5- 7. Table 5: Group Identification Type Values _Grp_ID_Type__Value__ IPSec IPv4 0 IPSec IPv6 1 TLS 2 SMIME 3 Other 4-255 Exchange Type (2 octets) - Indicates the type of exchange. Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 17] INTERNET-DRAFT GSAKM Protocol April, 1999 0 1 2 3 4 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 ! Ver ! Message ID ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-++-+ ~ Msg ID ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-++-+ ! Length ! ! -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+ Figure 2: GSAKMP Header Format Table 6: Exchange Type Values _Exchange_Type_______________Value_ Request to Join 0 Invitation 1 Invitation Response 2 Key Download 3 Acknowledgement 4 CR Event 5 Group Removal/Destruction 6 Other 7-255 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 7 presents the payload types. Version (1 octet) - Indicates the version of the GSAKMP protocol in use. Message ID (4 octets) - Unique Message Identifier used to identify protocol state during negotiations. This value is randomly generated by the initiator of communications for each group join activity. In the event of simultaneous GSA establishments (i.e., collisions), the value of this field may be different because they are independently generated and, thus, two group security associations will progress toward establishment. However, it is unlikely there will be absolute simultaneous establishments. Length (4 octets) - Length of total message (header + payloads) in octets. Encryption can expand the size of an GSAKMP message. Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 18] INTERNET-DRAFT GSAKM Protocol April, 1999 Table 7: Payload Types _Group_Identification_Type_(1_octet)_____ Next_Payload_Type Value None 0 Policy Token/Certificate 1 Key Download Packet 2 CR even t 3 Identification/ Roles (ID) 4 Certificate (CERT) 5 Certificate Request (CR) 6 Hash (HASH) 7 Signature (SIG) 8 Notification (N) 9 Delete (D) 10 Vendor ID (VID) 11 Key Creation 12 Reserved 13 - 127 Private Use 128 -- 255 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 4 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 (4 octets) Length in octets of the current payload, including the generic payload header. Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 19] INTERNET-DRAFT GSAKM Protocol April, 1999 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. 0 1 2 3 4 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 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. 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 Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 20] INTERNET-DRAFT GSAKM Protocol April, 1999 authority and integrity of the information. Figure 5 shows the format of the payload. 0 1 2 3 4 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. 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 8 identifies the types of policy tokens. Table 8: Policy Token Types _ID_Type____________________________Value_ Establishment 0 Key Dissemination (Subordinate) 1 Access Control (change) 2 Rekey 3 Notification of GSAKMP resource 4 Compromise Recovery 5 Delete 6 Unassigned 7-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). Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 21] INTERNET-DRAFT GSAKM Protocol April, 1999 0 1 2 3 4 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 Download Data ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 6: Key Download Payload Format 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 identified in the ID Type field. 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: 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 Download being used. Figure 9 identifies the types of key download information. Table 9: Key Download Information Types _ID_Type______Value_ NONE 0 DES/ECB 1 3Des/ECB 2 Unassigned 3-255 Key Download Data (variable length) - Contains Key Download information. The values for this field are group specific and the format is specified by the ID Type field. Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 22] INTERNET-DRAFT GSAKM Protocol April, 1999 0 1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ! # Key Datas ! KDD Type ! Length Key Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ~ ! Key Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 7: Key Download Data Payload Format # Key Datas (1 octet) - Specifies the number of key data elements contained in the payload - from 1 to n. Key Download Data Type (1 octet) - Each key will have a type identifier associated with it. This specifies what the key will be used for in the protocol. Table 10: Key Download Data Types _Key_Download_Data_Type___Value_ GTEK 0 LKH Key/Data 1 Unassigned 2-255 Length of Key (3 octets) - Defines the number of bytes for the key data that follows. The payload type for the Key Download Packet is two (2). 4.6 CR Event Payload The CR Event Payload contains multiple keys encrypted in CR keys. These CR Event payloads can have several security attributes applied to them based upon the security policy of the group. Figure 8 shows the format of the payload. The CR 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. Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 23] INTERNET-DRAFT GSAKM Protocol April, 1999 0 1 2 3 4 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 ! CR Event Data ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 8: CR Event 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 CR Event being used. Figure 11 presents the types of CR events. Table 11: CR Event Types _ID_Type________________Value_ None 0 Group Recovery 1 Individual Recovery 2 Maintenance 3 Delete Group Key 4 Unassigned 5-255 CR Event Data (variable length) - Contains CR Event information. The values for this field are group specific and the format is specified by the ID Type field. The CR Event payload type is three (3). 4.7 Identification/Role Payload The Identification/Role Payload contains group-specific data used to exchange identification information. This information is used for determining the identities of subordinate controllers and may be used for determining authenticity of information. Figure 9 shows the format of the Identification Payload. The Identification/Role 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 Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 24] INTERNET-DRAFT GSAKM Protocol April, 1999 0 1 2 3 4 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/Role Data ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 9: Identification/Role Payload Format 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/Role being used. Table 12 identifies the types of identities/roles. Table 12: Identity/Role Types _ID_Type_______________________________Value_ Group Controller 0 Group and CR Controller 1 CR Controller 2 Subordinate Group Controller 3 Subordinate Group and CR Controller 4 Subordinate CR Controller 5 Member ID 6 Unassigned 7-255 Identification Data (variable length) - Contains identity information. The values for this field are group-specific and the format is specified by the ID Type field. The payload type for the Identification Payload is four (4). 4.8 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 Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 25] INTERNET-DRAFT GSAKM Protocol April, 1999 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 4 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, 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 13 presents the types of certificate payloads. Table 13: 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. Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 26] INTERNET-DRAFT GSAKM Protocol April, 1999 The payload type for the Certificate Payload is five (5). 4.9 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. 0 1 2 3 4 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 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, 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 Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 27] INTERNET-DRAFT GSAKM Protocol April, 1999 requested, this field SHOULD not be included. The payload type for the Certificate Request Payload is six (6). 4.10 Signature Payload The Signature Payload contains data generated by the digital signature function, over some part of the message. Figure 12 shows the format of the Signature Payload. 0 1 2 3 4 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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ! ! Signature Data ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ! ! Signer ID Type Length ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ! Signer ID Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 12: Signature Payload Format The Signature Payload fields are defined as follows: Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. Reserved (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. Sig Type (1 octet) - Indicates the type of signature. Table 14 presents the Signature Types. 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. Table 15 presents the Signature Payload Span types. Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 28] INTERNET-DRAFT GSAKM Protocol April, 1999 Table 14: Signature Types _Signature_Type___Value_ DSS 0 Other 1-255 Table 15: Signature Context Types _Signature_Payload_Span_Type_____Value_ No signature 0 Signature over generic header 1 Signature up to payload 2 Signature Data (variable length) - Data that results from applying the digital signature function to the GSAKMP message and/or payload. Signer ID Type Length (2 octets) - Length in octets of the Signer ID type. Signer ID Type (variable length) - Data identifying the Signer's ID Type. The payload type for the Signature Payload is eight (8). 4.11 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 an GSAKMP peer. It is possible to send multiple Notification payloads in a single GSAKMP message. Figure 13 shows the format of the Notification Payload. 0 1 2 3 4 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 13: Notification Payload Format The Notification Payload fields are defined as follows: Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 29] INTERNET-DRAFT GSAKM Protocol April, 1999 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. Notify Message Type (2 octets) - Specifies the type of notification message. Status Type (1 octet) - Specifies the status of group with respect to originator of notification. 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. The payload type for the Notification Payload is nine (9). 4.12 Notify Message Types Notification information can be messages specifying information. It can also be status data that a process managing an SA database wishes 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 16 and 17 list the Notification Messages and their corresponding values. Table 16: 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 4.13 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 14 shows the format of the Vendor ID Payload. Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 30] INTERNET-DRAFT GSAKM Protocol April, 1999 Table 17: Notify Messages Types _Information_________________________Value_____ Invalid-Payload-Type 1 Situation-Not-Supported 2 Invalid-Major-Version 3 Invalid-Version 4 Invalid-Group-ID 5 Invalid-Message-ID 6 Payload-Malformed 7 Invalid-key-Information 8 Invalid-ID-Information 9 Invalid-Cert-Encoding 10 Invalid-Certificate 11 Cert-Type-Unsupported 12 Invalid-Cert-Authority 13 Authentication-Failed 14 Invalid-Signature 15 Notify-GSA-Lifetime 16 Certificate-Unavailable 17 Unequal-Payload-Lengths 18 Unauthorized Request 19 Unable To Take Requested Role 20 Group Deleted 21 Request Addition To Group 22 Acknowledgement 23 Invitation 24 Invitation Response 25 Reserved (future use) 26 - 8191 Private Use 8192 -- 16383 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. The Vendor ID Payload fields are defined as follows: Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 31] INTERNET-DRAFT GSAKM Protocol April, 1999 0 1 2 3 4 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 14: Vendor ID 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. 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.14 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 15 shows the format of the payload. 0 1 2 3 4 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 15: Key Creation Payload Format The Key Creation Payload fields are defined as follows: Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 32] INTERNET-DRAFT GSAKM Protocol April, 1999 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 18 identifies the types of key download information. Table 18: 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). 5 State Diagram Figure 16 presents the states encountered in the use of this protocol. Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 33] INTERNET-DRAFT GSAKM Protocol April, 1999 (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 16: GSAKMP State Diagram Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 34] INTERNET-DRAFT GSAKM Protocol April, 1999 Table 19: 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:______________________NA____________________ _Transition_9:__________Receipt_of_protocol_messages______ _Transition_10:_______Group_SA_establishment_complete_____ _Transition_11:______________________NA___________________ _Transition_12:_________LKH_event_message_completed_______ _Transition_13:______Group_SA_send_failure_notification___ _Transition_14:______________________NA___________________ _Transition_15:______________LKH_event_message____________ _Transition_16:___________Delete_Request_validated________ _Transition 17: Destruction complete _________________________________________________________ Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 35]