Internet Engineering Task Force INTERNET-DRAFT H Harney, U Meth, A Colegrove (SPARTA) A Schuett (NSA) P McDaniel (AT&T) G Kenny (Logica) H Cruickshank, S Iyengar (UoS) G Gross (IdentAware) draft-ietf-msec-gsakmp-sec-04.txt SPARTA, Inc., National Security Agency AT&T Labs, LogicaCMG, University of Surrey IdentAware Security Expires: April 24, 2004 October 2003 GSAKMP Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress''. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies the Group Secure Association Key Management Protocol (GSAKMP). The GSAKMP provides a security framework for creating and managing cryptographic groups on a network. It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security INTERNET-DRAFT GSAKMP October 2003 functions, and capabilities to destroy the group. It also generates group keys. Copyright Notice Copyright (c) The Internet Society (2003). All Rights Reserved. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 2]
INTERNET-DRAFT GSAKMP October 2003 Contents 1 Overview 8 1.1 GSAKMP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2 Protocol Considerations . . . . . . . . . . . . . . . . . . . . . . 9 1.3 Document Organization . . . . . . . . . . . . . . . . . . . . . . . 9 2 Terminology 9 3 Security Considerations 11 3.1 Security Assumptions . . . . . . . . . . . . . . . . . . . . . . . 12 3.2 GSAKMP Use of Other Protocols . . . . . . . . . . . . . . . . . . . 12 3.2.1ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.2FIPS Pub 196 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.3LKH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.4Rekey Availability . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.5Diffie-Hellman . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3 Denial of Service (DoS) Attack . . . . . . . . . . . . . . . . . . 13 3.4 Proof of Trust Hierarchy . . . . . . . . . . . . . . . . . . . . . 14 4 Architecture 14 4.1 Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.1Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.2GO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.3GC/KS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.4Subordinate GC/KS . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.5GM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.6Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2 Rule-Based Security Policy . . . . . . . . . . . . . . . . . . . . 17 4.2.1Access Control . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.2Authorizations for security relevant actions . . . . . . . . . . 19 4.3 Distributed Operation . . . . . . . . . . . . . . . . . . . . . . . 19 4.4 Concept of Operation . . . . . . . . . . . . . . . . . . . . . . . 20 4.4.1Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.4.2Creation of a PT . . . . . . . . . . . . . . . . . . . . . . . . 21 4.4.3Creation of a Group . . . . . . . . . . . . . . . . . . . . . . 22 4.4.4Discovery of GC/KS . . . . . . . . . . . . . . . . . . . . . . . 22 4.4.5GC/KS registration policy enforcement . . . . . . . . . . . . . 22 4.4.6GM registration policy enforcement . . . . . . . . . . . . . . . 23 4.4.7S-GC/KS operations . . . . . . . . . . . . . . . . . . . . . . . 23 4.5 GSAKMP Interactions With NAT Traversal . . . . . . . . . . . . . . 24 4.5.1Non-Transparent Network Address Translation Behaviors . . . . . 24 4.5.2GSAKMP Avoidance of NAT Using an IP-v6 Over IP-v4 Network . . . 25 4.5.3GSAKMP Multicast IP-v4 NAT Architectural Assumptions . . . . . . 26 4.5.4Representative Example GSAKMP Multi-Realm Configuration . . . . 27 4.5.5GSAKMP Registration Security Association NAT Traversal . . . . . 30 4.5.6GSAKMP Re-key Security Association NAT Traversal . . . . . . . . 31 4.5.7Multicast Application Security Association NAT Traversal . . . . 31 5 Group Life Cycle 32 5.1 Group Definition . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.2 Group Establishment . . . . . . . . . . . . . . . . . . . . . . . . 33 5.2.1Standard Group Establishment . . . . . . . . . . . . . . . . . . 33 Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 3]
INTERNET-DRAFT GSAKMP October 2003 5.2.1.1Request to Join . . . . . . . . . . . . . . . . . . . . . . 34 5.2.1.2Key Download . . . . . . . . . . . . . . . . . . . . . . . 35 5.2.1.3Request to Join Error . . . . . . . . . . . . . . . . . . . 37 5.2.1.4Key Download - Ack/Failure . . . . . . . . . . . . . . . . 37 5.2.1.5Lack of Ack . . . . . . . . . . . . . . . . . . . . . . . . 38 5.2.2Cookies - Group Establishment with Denial of Service Protection 39 5.3 Group Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.3.1Rekey Events . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.3.2Leaving a Group . . . . . . . . . . . . . . . . . . . . . . . . 42 5.3.2.1Eviction . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.3.2.2Voluntary Departure without Notice . . . . . . . . . . . . 43 5.3.2.3De-Registration . . . . . . . . . . . . . . . . . . . . . . 43 5.3.2.3.1Request to Depart - . . . . . . . . . . . . . . . . . . 43 5.3.2.3.2Departure_Response - . . . . . . . . . . . . . . . . . 44 5.3.2.3.3Departure_ACK - . . . . . . . . . . . . . . . . . . . . 45 6 Security Suite 46 6.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 6.2 Definition Suite 1 . . . . . . . . . . . . . . . . . . . . . . . . 46 7 GSAKMP Payload Structure 47 7.1 GSAKMP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 7.1.1GSAKMP Header Structure . . . . . . . . . . . . . . . . . . . . 47 7.1.2GSAKMP Header Processing . . . . . . . . . . . . . . . . . . . . 50 7.2 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . . 51 7.2.1Generic Payload Header Structure . . . . . . . . . . . . . . . . 51 7.2.2Generic Payload Header Processing . . . . . . . . . . . . . . . 51 7.3 Policy Token Payload . . . . . . . . . . . . . . . . . . . . . . . 52 7.4 Key Download Payload . . . . . . . . . . . . . . . . . . . . . . . 53 7.5 Rekey Event Payload . . . . . . . . . . . . . . . . . . . . . . . . 54 7.6 Identification Payload . . . . . . . . . . . . . . . . . . . . . . 55 7.7 Certificate Payload . . . . . . . . . . . . . . . . . . . . . . . . 56 7.8 Signature Payload . . . . . . . . . . . . . . . . . . . . . . . . . 58 7.8.1Signature Payload Structure . . . . . . . . . . . . . . . . . . 58 7.8.2Signature Payload Processing . . . . . . . . . . . . . . . . . . 59 7.9 Notification Payload . . . . . . . . . . . . . . . . . . . . . . . 60 7.9.1Notification Data - Acknowledgement (ACK) Payload Type . . . . . 62 7.9.2Notification Data - Cookie_Required and Cookie Payload Type . . 62 7.9.3Notification Data - Mechanism Choices Payload Type . . . . . . . 63 7.10Key Creation Payload . . . . . . . . . . . . . . . . . . . . . . . 64 7.10.1Key Creation Payload Structure . . . . . . . . . . . . . . . . . 64 7.10.2Key Creation Payload Processing . . . . . . . . . . . . . . . . 65 7.11Nonce Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.11.1Nonce Payload Structure . . . . . . . . . . . . . . . . . . . . 66 7.11.2Nonce Payload Processing . . . . . . . . . . . . . . . . . . . . 67 8 GSAKMP State Diagram 68 A APPENDIX A -- Variable Length Payload Field Definitions 71 A.1 Key Download Payload Fields . . . . . . . . . . . . . . . . . . . . 71 A.1.1GTEK Key Packet Fields . . . . . . . . . . . . . . . . . . . . . 71 A.1.2Rekey Key Packet Fields . . . . . . . . . . . . . . . . . . . . 71 A.2 Signature Payload Fields . . . . . . . . . . . . . . . . . . . . . 72 Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 4]
INTERNET-DRAFT GSAKMP October 2003 A.2.1Signature ID Data Field Format . . . . . . . . . . . . . . . . . 72 B APPENDIX B -- LKH Variable Length Payload Field Definitions 72 B.1 LKH Rekey Key Packet Fields . . . . . . . . . . . . . . . . . . . . 72 B.2 LKH Rekey Packet Data Format Fields . . . . . . . . . . . . . . . . 73 B.2.1Rekey Event Header . . . . . . . . . . . . . . . . . . . . . . . 73 B.2.2Rekey Event Packet Data(s) . . . . . . . . . . . . . . . . . . . 74 B.2.3Key Pack Data . . . . . . . . . . . . . . . . . . . . . . . . . 75 B.2.4Pack Data Formats . . . . . . . . . . . . . . . . . . . . . . . 75 B.2.4.1GTEK Pack Data . . . . . . . . . . . . . . . . . . . . . . 76 B.2.4.2LKH Pack Data . . . . . . . . . . . . . . . . . . . . . . . 76 B.2.5Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 C APPENDIX C -- Change History 78 C.1 Changes from GSAKMP-00 to GSAKMP-01 February 2003 . . . . . . . . . 78 C.2 Changes from GSAKMP-01 to GSAKMP-02 June 2003 . . . . . . . . . . . 78 C.3 Changes from GSAKMP-02 to GSAKMP-03 August 2003 . . . . . . . . . . 79 C.4 Changes from GSAKMP-03 to GSAKMP-04 October 2003 . . . . . . . . . 79 D References, Authors Addesses, and Acknowledgements 83 D.1 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 D.2 Authors Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 84 D.3 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 86 Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 5]
INTERNET-DRAFT GSAKMP October 2003 List of Figures 1 GSAKMP NAT Example . . . . . . . . . . . . . . . . . . . . . . . . 29 2 GSAKMP Ladder Diagram . . . . . . . . . . . . . . . . . . . . . . . 34 3 GSAKMP Ladder Diagram with Cookies . . . . . . . . . . . . . . . . 40 4 GSAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . . 48 5 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . . 51 6 Policy Token Payload Format . . . . . . . . . . . . . . . . . . . . 52 7 Key Download Payload Format . . . . . . . . . . . . . . . . . . . . 53 8 Rekey Event Payload Format . . . . . . . . . . . . . . . . . . . . 55 9 Identification Payload Format . . . . . . . . . . . . . . . . . . . 56 10 Certificate Payload Format . . . . . . . . . . . . . . . . . . . . 57 11 Signature Payload Format . . . . . . . . . . . . . . . . . . . . . 58 12 Notification Payload Format . . . . . . . . . . . . . . . . . . . . 60 13 Notification Data - Acknowledge Payload Type Format . . . . . . . . 62 14 Notification Data - Mechanism Choices Payload Type Format . . . . . 63 15 Key Creation Payload Format . . . . . . . . . . . . . . . . . . . . 64 16 Nonce Payload Format . . . . . . . . . . . . . . . . . . . . . . . 66 17 GSAKMP State Diagram . . . . . . . . . . . . . . . . . . . . . . . 68 18 B. 1: Rekey Event Header Format . . . . . . . . . . . . . . . . . 74 19 B. 2: Rekey Event Packet Data Format . . . . . . . . . . . . . . 74 20 B. 3: Key Pack Data Format . . . . . . . . . . . . . . . . . . . 75 Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 6]
INTERNET-DRAFT GSAKMP October 2003 List of Tables 1 Request to Join (RTJ) Message Definition . . . . . . . . . . . . . 35 2 Key Download (KeyDL) Message Definition . . . . . . . . . . . . . . 36 3 Request to Join Error (RTJ-Err) Message Definition . . . . . . . . 37 4 Key Download - Ack/Failure (KeyDL-A/F) Message Definition . . . . . 38 5 Lack of Ack (LOA) Message Definition . . . . . . . . . . . . . . . 39 6 Cookie Download Message Definition . . . . . . . . . . . . . . . . 40 7 Rekey Event Message Definition . . . . . . . . . . . . . . . . . . 42 8 Request_to_Depart (RTD) Message Definition . . . . . . . . . . . . . 43 9 Departure_Response (DR) Message Definition . . . . . . . . . . . . 44 10 Departure_ACK (DA) Message Definition . . . . . . . . . . . . . . . 45 11 Group Identification Types . . . . . . . . . . . . . . . . . . . . 48 12 Payload Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 13 Exchange Types . . . . . . . . . . . . . . . . . . . . . . . . . . 49 14 Policy Token Types . . . . . . . . . . . . . . . . . . . . . . . . 52 15 Key Download Data Types . . . . . . . . . . . . . . . . . . . . . . 54 16 Rekey Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 55 17 Identification Types . . . . . . . . . . . . . . . . . . . . . . . 56 18 Certificate Payload Types . . . . . . . . . . . . . . . . . . . . . 57 19 Signature Types . . . . . . . . . . . . . . . . . . . . . . . . . . 59 20 Signature Types . . . . . . . . . . . . . . . . . . . . . . . . . . 59 21 Notify Payload Types . . . . . . . . . . . . . . . . . . . . . . . 61 22 Acknowledgement Types . . . . . . . . . . . . . . . . . . . . . . . 62 23 Mechanism Types . . . . . . . . . . . . . . . . . . . . . . . . . . 63 24 Encryption Types . . . . . . . . . . . . . . . . . . . . . . . . . 64 25 Nonce Hash Types . . . . . . . . . . . . . . . . . . . . . . . . . 64 26 Types Of Key Creation Information . . . . . . . . . . . . . . . . . 65 27 Nonce Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 28 GSAKMP States . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 29 State Transition Events . . . . . . . . . . . . . . . . . . . . . . 70 Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 7]
INTERNET-DRAFT GSAKMP October 2003 1 Overview 1.1 GSAKMP Overview Protecting group information requires the definition of a security policy and the enforcement of that policy by all participating parties. Controlling dissemination of cryptographic key is the primary mechanism to enforce the access control policy. It is the primary purpose of GSAKMP to generate and disseminate a group key in a secure fashion. GSAKMP separates group security management functions and responsibilities into three major roles: 1) Group Owner, 2) Group Controller Key Server, and 3) Group Member. The Group Owner is responsible for creating the security policy rules for a group and expressing these in the Policy Token. The Group Controller Key Server (GC/KS) is responsible for creating and maintaining the keys and enforcing the group policy by granting access to potential Group Members (GM) in accordance with the Policy Token. To enforce a group's policy the potential Group Members need to have knowledge of the access control policy for the group, an unambiguous identification of any party downloading keys to them, and verifiable chains of authority for key download. In other words, the Group Members need to know who potentially will be in the group and to verify that the key disseminator is authorized to act in that capacity. In order to establish a Group Secure Association (GSA) to support these activities, the identity of each party in the process MUST be unambiguously asserted and authenticated. It MUST also be verified that each party is authorized, as defined by the Policy Token, to function in his role in the protocol (e.g., GM or GC/KS). The security features of the establishment protocol for the SA include - Group policy identification - Group policy dissemination - GM to GC/KS SA establishment to protect data - Access control checking GSAKMP provides mechanisms for cryptographic group creation and management. Other protocols may be used in conjunction with GSAKMP to allow various applications to create functional groups according to their application-specific requirements. For example, in a small-scale video conference the organizer might use a session invitation protocol like SIP [RFC2543] to transmit information about the time of the conference, the address of the session, and the formats to be used. For a large-scale video Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 8]
INTERNET-DRAFT GSAKMP October 2003 transmission, the organizer might use a multicast announcement protocol like SAP [RFC2974]. This document describes a useful default set of security algorithms and configurations, Security Suite 1. This suite allows an entire set of algorithms and settings to be described to prospective group members in a concise manner. Other security suites MAY be defined as needed and MAY be disseminated during the out-of-band announcement of a group. Distributed architectures support large scale cryptographic groups. Secure distributed architectures require authorized delegation of GSA actions to network resources. The fully specified Policy Token is the mechanism to facilitate this authorization. Trasmission of this Policy Token to all joining GMs allows GSAKMP to securely support distributed architectures and multiple data sources. Many-to-many group communications require multiple data sources. Multiple data sources are supported because the inclusion of a policy token and policy payloads allow group members to review the group access control and authorization parameters. This member review process gives each member (each potential source of data), the ability to determine if the group provides adequate protection for member data. 1.2 Protocol Considerations IANA has provided GSAKMP port number 3761 in both the UDP and TCP spaces. All implementations MUST use this port assignment in the appropriate manner. 1.3 Document Organization The remainder of this document is organized as follows: Section 5.2.1.5 presents the terminology and concepts used to present the requirements of this protocol. Section 3 outlines the security considerations with respect to GSAKMP. Section 5 describes the group management life-cycle. Section 6 describes the Security Suite Definition. Section 7 presents the message types and formats used during each phase of the life-cycle. Section 8 defines the state diagram for the protocol. 2 Terminology The following terminology is used throughout the GSAKMP paper. Certificate: A data structure used to verifiably bind an identity to a Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 9]
INTERNET-DRAFT GSAKMP October 2003 cryptographic key (e.g., X.509v3). Compromise Recovery: The act of recovering a secure operating state after detecting that a group member cannot be trusted. This can be accomplished by rekey. Cryptographic Group: A set of entities sharing or desiring to share a GSA. Group Controller Key Server (GC/KS): A group member with authority to perform critical protocol actions including creating and distributing keys and building and maintaining the rekey structures. As the group evolves, it MAY become desirable to have multiple controllers perform these functions. Group Member (GM): A Group Member is any entity with access to the group keys. Regardless of how a member becomes a part of the group or how the group is structured, GMs will perform the following actions: - Authenticate and validate the identities and the authorizations of entities performing security relevant actions - Accept group keys from the GC/KS - Request group keys from the GC/KS - Enforce the cooperative group policies as stated in the group policy token - Perform peer review of key management actions - Manage local local key Group Owner (GO): A Group Owner is the entity authorized for generating and modifying an authenticatable policy token for the group, and notifying the GC/KS to start the group. Group Policy: The Group Policy completely describes the protection mechanisms and security relevant behaviors of the group. This policy MUST be commonly understood and enforced by the group for coherent secure operations. Group Secure Association (GSA): A GSA is a logical association of users or hosts that share cryptographic key(s). This group may be established to support associations between applications or communication protocols. Group Traffic Encryption Key (GTEK): The key or keys created for encrypting the group data. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 10]
INTERNET-DRAFT GSAKMP October 2003 Logical Key Hierarchy (LKH) Array: The group of keys created to facilitate the LKH compromise recovery methodology. Policy Token: The policy token is a data structure used to disseminate group policy and the mechanisms to enforce it. The policy token is issued and signed by an authorized source. Each member of the group MUST verify the token, meet the group join policy, and enforce the policy of the group, (e.g., encrypt application data with a specific algorithm). The group policy token will contain a variety of information including: - GSAKMP protocol version - Key creation method - Key dissemination policy - Access control policy - Group authorization policy - Compromise recovery policy - Data protection mechanisms An example of a policy token is specified in [HCLM00]. Rekey: The act of changing keys within a group as defined by policy. Subordinate Group Controller Key Server (S-GC/KS): Any group member having the appropriate processing and trust characteristics as defined in the group policy that has the potential to act as a S-GC/KS. This will allow the group processing and communication requirements to be distributed equitably throughout the network (e.g., distribute group key). The optional use of GSAKMP with Subordinate Group Controller Key Servers will be documented in a separate paper. 3 Security Considerations In addition to the specification of GSAKMP itself, the security of an implemented GSAKMP system is affected by supporting factors. These are discussed here. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 11]
INTERNET-DRAFT GSAKMP October 2003 3.1 Security Assumptions The following assumptions are made as the basis for the security discussion 1. GSAKMP assumes its supporting platform can provide the process and data separation services at the appropriate assurance level to support its groups. 2. The key generation function of the cryptographic engine will only generate strong keys. 3. The security of this protocol is critically dependent on the randomness of the randomly chosen parameters. These should be generated by a strong random or properly seeded pseudo-random source. 3.2 GSAKMP Use of Other Protocols GSAKMP is based upon two (2) existing protocols: ISAKMP [MSST98] and FIPS Pub 196 [FIPS 196]. GSAKMP MAY use Diffie-Hellman key exchange [DH77] for two party key creation and MAY use LKH for rekey capability. 3.2.1 ISAKMP ISAKMP provides a flexible structure of chained payloads in support of authenticated key exchange and security association management for pairwise communications. GSAKMP builds upon these features to provide policy enforcement features in support of diverse group communications. 3.2.2 FIPS Pub 196 FIPS Pub 196 provides a mutual authentication protocol. 3.2.3 LKH GSAKMP relies upon a rekey capability, i.e., LKH, to enable group recovery after a compromise. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 12]
INTERNET-DRAFT GSAKMP October 2003 3.2.4 Rekey Availability In addition to GSAKMP having the capability to do rekey operations, GSAKMP MUST aslo have the capability to make this rekey information available to GMs. The necessity of GMs receiving rekey messages, requires the use of methods to increase the likelyhood of receipt of Rekey Messages. These methods MAY include multiple transmissions of the rekey message, posting of the rekey message on a bulliten board, etc. 3.2.5 Diffie-Hellman GSAKMP MAY rely upon two party key creation mechanisms, i.e., Diffie-Hellman, to protect sensitive data during download. The information in this section is borrowed heavily from [IKEv2] as this protocol has already worked through this issue and GSAKMP is using the same security considerations for its purposes. This section will contain paraphrased sections of [IKEv2] modified for GSAKMP as appropriate. The strength of a key derived from a Diffie-Hellman exchange using specific p and g values depends on the inherent strength of the values, the size of the exponent used, and the entropy provided by the random number generator used. Security Suite 1 defined in section 6, based on [IKEv2] Group 2, with a strong random number generator and an exponent no less than 200 bits is sufficient to use for 3DES. An implementation should make note of this conservative estimate when establishing policy and negotiating security parameters. Note that these limitations are on the Diffie-Hellman values themselves. There is nothing in GSAKMP which prohibits using stronger values nor is there anything which will dilute the strength obtained from stronger values. In fact, the extensible framework of GSAKMP encourages the definition of more Security Suites. It is assumed that the Diffie-Hellman exponents in this exchange are erased from memory after use. In particular, these exponents MUST NOT be derived from long-lived secrets like the seed to a pseudo-random generator that is not erased after use. 3.3 Denial of Service (DoS) Attack This GSAKMP specification addresses the mitigation for a distributed IP spoofing attack (a subset of possible DoS attacks) in section 5.2.2, Cookies. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 13]
INTERNET-DRAFT GSAKMP October 2003 3.4 Proof of Trust Hierarchy As defined by [HCM], security group policy MUST be defined in a verifiable manner. GSAKMP anchors its trust in the creator of the group, the GO. The Policy Token explicitly defines all the parameters that create a secure verifiable infrastructure. The GSAKMP Policy Token is issued and signed by the GO. The GC/KS will verify it and grant access to GMs only if they meet the rules of the Policy Token. The new GMs will accept access only if 1) the token verifies, 2) the GC/KS is an authorized disseminator, and 3) the group mechanisms are acceptable for protecting the GMs data. 4 Architecture This architecture presents a trust model for GSAKMP and a concept of operations for establishing a trusted distributed infrastructure for group key and policy distribution. GSAKMP conforms to the IETF MSEC architectural concepts as specified in the MSEC Architecture document [RFC xxxx]. GSAKMP uses the MSEC components to create a trust model for operations that implement the security principles of mutual suspicion and trust anchors. 4.1 Trust Model 4.1.1 Components The trust model contains four key components: - Group Owners (GO), - Group Controllers / Key Servers (GC/KS), - Subordinate GC/KS (S-GC/KS), and - Group Members (GM). The goal of the GSAKMP trust model is to derive trust from a common trust anchor for a group. All security relevant decisions and actions implemented by GSAKMP are based on information that ultimately is traceable to and verified by a core trust anchor. There are two pieces of the trust anchors for GSAKMP, the GO (policy creation authority) and the PKI root that allows Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 14]
INTERNET-DRAFT GSAKMP October 2003 us to verify the GO. 4.1.2 GO The GO is the policy creation authority for the group. The GO has a well defined identity that is relevant to the group. That identity can be of a person or of a group trusted component. All potential entities in the group have to recognize the GO as the individual with authority to specify policy for the group. The policy reflects the protection requirements of the data in a group. Ultimately, the data and the application environment drives the security policy for the group. The GO has to determine the security rules and mechanisms that are appropriate for the data being protected by the group keys. All this information is captured in a policy token (PT). The GO creates the PT and signs it. 4.1.3 GC/KS The GC/KS is authorized to perform several functions: key creation, key distribution, rekey, and group membership management. As key creation authority, the GC/KS will create the set of keys for the group. These keys include the Traffic Protection Keys (TPK) and first tier rekey keys. There may be second tier rekey trees if a distributed rekey management structure is required for the group. As the key distribution (registration) authority, it has to notify the group of its location for registration services. The GS/KS will have to enforce key access control as part of the key distribution and registration processes. As the group rekey authority, it performs rekey in order to change the group's TPK. Change of the TPK limits the exposure of data encrypted with any single TPK. Finally, as group membership management authority, the GC/KS can manage the group membership (registration, eviction, de-registration, etc.). This may be done in part by using key tree approaches such as Logical Key Hierarchies (LKH). Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 15]
INTERNET-DRAFT GSAKMP October 2003 4.1.4 Subordinate GC/KS A subordinate GC/KS is used to distribute the GC/KS functionality across multiple entities. The S-GC/KS will have all the authorities of the GC/KS except one: it will not create the TPK. It is assumed here that the group will transmit data with a single TPK at any one time. This TPK comes from the GC/KS. Note that relative to the GC/KS, the S-GC/KS is responsible for an additional security check: the S-GC/KS must register as a member with the GCKS, and during that process it has to verify the authority of the GC/KS. 4.1.5 GM The GM has two jobs - make sure all security relevant actions are authorized and properly use the group keys. During the registration process, the GM will verify that the PT is signed by a recognized GO. In addition, it will verify that the GC/KS or S-GC/KS engaged in the registration process is authorized, as specified in the PT. If rekey and new PTs are distributed to the group, the GM will verify that they are proper and all actions are authorized. The GM is granted access to group data through receipt of the group keys This carries along with it a responsibility to protect the key from unauthorized disclosure. GSAKMP does not offer any enforcement mechanisms to control which GM are multicast speakers at a given moment. This policy and its enforcement depend on the multicast application and its protocols. However, GSAKMP does allow a group to have one of three Group Security Association multicast speaker configurations: - There is a single GM authorized to be the group's speaker. There is one multicast application SA allocated by the GO in support of that speaker. The PT initializes this multicast application SA and identifies the GM that has been authorized to be speaker. All GM share a single TPK with that GM speaker. Sequence number checking for anti-replay protection is feasible and enabled by default. This is the default group configuration. GSAKMP implementations MUST support this configuration. - The GO authorizes all of the GM to be a group speaker. The GO allocates one multicast application SA in support of these speakers. The PT initializes this multicast application SA and indicates that any GM can be a speaker. All of the GM share a single TPK and other SA state information. Consequently, some SA security features such as sequence number checking for anti-replay protection can not be supported by Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 16]
INTERNET-DRAFT GSAKMP October 2003 this configuration. GSAKMP implementations MUST support this group configuration. - The GO authorizes a subset of the GM to be a group speaker (which may be the subset comprised of all GM). The GO allocates a distinct multicast application SA for each of these speakers. The PT identifies the authorized speakers, and initializes each of their multicast application Security Associations. The speakers still share a common TPK across their SA, but each speaker has a separate SA state information instance at every peer GM. Consequently, this configuration supports SA security features such as sequence number checking for anti-replay protection or source authentication mechanisms that require per speaker state at the receiver. The drawback of this configuration is that it does not scale to a large numbers of speakers. GSAKMP implementations MAY support this group configuration. 4.1.6 Assumptions The assumptions for this trust model are: - the GCKS is assumed to be never compromised, - the GO is assumed to be never compromised, - the PKI, subject to certificate validation, is assumed to be trustworthy,, - The GO is capable of creating a security policy to meet the demands of the group, - the compromises of a group member will be detectable and reported to the GO in a trusted manner, - the subsequent recovery from a compromise will deny inappropriate access to protected data to the compromised member, - no security relevant actions depend on a precise network time, - that there is confidentiality, integrity, multicast source authentication and anti-replay protection mechanisms for all GSAKMP control messages, 4.2 Rule-Based Security Policy The trust model for GSAKMP revolves around the definition and enforcement of the security policy. In fact, the use of the key is only relevant, in Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 17]
INTERNET-DRAFT GSAKMP October 2003 a security sense, if it represents the successful enforcement of the group security policy. Group operations lend themselves to rule-based security policy. The need for distribution of data to many endpoints often leads to the defining of those authorized endpoints based on rules. For example, all IETF attendees at a given conference could be defined as a single group. If the security policy rules are to be relevant, they must be coupled with validation mechanisms. The core principle here is that the level of trust one can afford a security policy is exactly equal to the level of trust one has in the validation mechanism used to prove that policy. For example, if all IETF attendees are allowed in then they could register their identity from their certificate upon check in to the meetings. That certificate is issued by a trust anchor (PKI root) that is authorized to identify someone as being an IETF attendee. The GO could make admittance rules to the IETF group based on the identity certificates issued from trusted PKIs. In GSAKMP, every security policy rule is coupled with an explicit validation mechanism. For interoperability considerations, GSAKMP requires its supporting PKI implementations MUST be compliant to RFC 2459. If a GM public key certificate is revoked, then the entity that issues that revocation SHOULD signal the GO, so that the GO can expel that GM. The method that signals this event to the GO is not standardized by this specification. A direct mapping of rule to validation mechanism allows the use of multiple rules and PKIs to create groups. This allows a GO to define a group security policy that spans multiple PKI domains, each with their own Certificate Authority public key certificate. 4.2.1 Access Control The access control policy for the group keys is equivalent to the access control policy for the multicast application data the keys are protecting. In a group, each data source is responsible for ensuring that the access to the source's data is appropriate. This implies that every data source should have knowledge of the access control policy for the group keys. In the general case, GSAKMP offers a suite of security services to its applications, and does not prescribe how they use those services. GSAKMP supports the creation of GSAs with multiple data sources. It also supports architectures where the GC/KS is not itself a data source. In the multiple data source architectures GSAKMP requires that the access control policy is precisely defined and distributed to each data source. The reference for this data structure is the GSAKMP Policy Token [ref TBD]. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 18]
INTERNET-DRAFT GSAKMP October 2003 4.2.2 Authorizations for security relevant actions A critical aspect of the GSAKMP trust model is the authorization of security relevant actions. Security relevant actions include - download of group key, rekey, and PT creation and updates. These actions could be used to disrupt the secure group and all entities in the group must verify that they were instigated by authorized entities within the group. 4.3 Distributed Operation Scalability is a core feature of GSAKMP. GSAKMP's approach to scalable operations is the establishment of S-GC/KSs. This allows the GSAKMP systems to distribute the workload of setting up and managing very large groups. Another aspect of distributed S-GC/KS operations is the enabling of local management authorities. In very large groups, subordinate enclaves may be best suited to provide local management of the enclaves' group membership, due to a direct knowledge of the group members. One of the critical issues involved with distributed operation is the discovery of the security infrastructure location and security suite. Many group applications that have dynamic interactions must "find" each other to operate. The discovery of the security infrastructure is just another piece of information that has to be known by the group in order to operate securely. There are several methods for infrastructure discovery: - Announcements - Anycast - Rendezvous points / Registration One method for distributing the security infrastructure location is to use announcements. The SAP is commonly used to announce the existence of a new multicast application or service. If an application uses SAP[Ref RFC 2974] to announce the existence of a service on a multicast channel, that service could be extended to include the security infrastructure location for a particular group. Announcements can also be used by GSAKMP in one of two modes - Expanding Ring Searches (ERS) of security infrastructure and expanding ring searches for infrastructure discovery. In either case, the GSAKMP would use a multicast broadcast that would slowly increase in its range by incremental multicast hops. The multicast source controls the packet's multicast range Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 19]
INTERNET-DRAFT GSAKMP October 2003 by explicitly setting its Time To Live count. An expanding ring announcement operates by the GC/KS announcing its existence for a particular group. The number of hops this announcement would travel would be a locally configured number. The GMs would listen on a well know multicast address for GC/KSs that provide service for groups of interest. If multiple GC/KSs are found that provide service, then the GM would pick the closest one (in terms of multicast hops). The GM would then send a GSAKMP Request to Join message (RTJ) to the announced GC/KS. If the announcement is found to be spurious then that is reported to the appropriate management authorities. The ERA concept is slightly different from SAP in that it could occur over the data channel multicast address, instead of a special multicast address dedicated for the SAP service. An expanding ring search operates in the reverse order than the ERA. In this case, the GM is the announcing entity. The (S-)GC/KSs listen for the requests for service, specifically the RTJ. The (S-)GC/KS responds to the RTJ. . If the GM receives more than one response, it would either ignore the responses or send NACKs based on local configuration. Anycast is a service that is very similar to ERS. It also can be used to provide connection to the security infrastructure. In this case, the GM would send the RTJ to a well-known service request address. This anycast service would route the RTJ to an appropriate GC/KS. The anycast service would have security infrastructure and network connectivity knowledge to facilitate this connection. Registration points can be used to distribute many group relevant data, including security infrastructure. Many group applications rely on well known registration points to advertise the availability of groups. There is no reason that GSAKMP could not use the same approach for advertising the existence and location of the security infrastructure. This is a simple process if the application being supported already supports registration. The GSAKMP infrastructure can always provide a registration site if the existence of this security infrastructure discovery hub is needed. The registration of S-GC/KSs at this site could be an efficient way to allow GM registration. GSAKMP infrastructure discovery can use whatever mechanism suits a particular multicast application's requirements, including mechanisms that have not been discussed by this architecture. However, GSAKMP infrastructure discovery is not standardized by this version of the GSAKMP specification. 4.4 Concept of Operation This concept of operation shows how the different roles in GSAKMP interact to set up a secure group. This particular concept of operation focuses on a secure group that utilizes the distributed key dissemination services of the Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 20]
INTERNET-DRAFT GSAKMP October 2003 S-GC/KS. 4.4.1 Assumptions The most basic assumption here is one or more trustworthy PKI for the group. That trusted PKI will be used to create and verify security policy rules. There is a GO that all GMs recognize as having group policy creation authority. All GM must be securely pre-configured to know the GO public key. All GMs have access to the GO PKI information, both the trusted anchor public keys and the certificate path validation rules. There is sufficient connectivity between the GSAKMP entities. - The registration SA requires that GM can connect to the GC/KS or S-GC/KS using either TCP or UDP. - The rekey SA requires that the data layer multicast communication service be available. This can be multicast IP, overlay networks using TCP, or NAT tunnels. - GSAKMP can support many different data layer secure applications each with unique connectivity requirements. 4.4.2 Creation of a PT The GO creates and signs the Policy Token for a group. The policy token contains the rules for access control and authorizations for a particular group. The PT consists of the following information: - Identification - this allows an unambiguous identification of the PT and the group, - Access Control Rules - these rules specify who can have access to the group keys, - Authorization Rules - these rules specify who can be a S-GC/KS, - Mechanisms - these rules specify the security mechanisms that will be used by the group, this is necessary to ensure there is no weak link in the group security profile Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 21]
INTERNET-DRAFT GSAKMP October 2003 - Source authentication of the PT to the GO - the PT is a CMS signed object and this allows all GMs to verify the PT 4.4.3 Creation of a Group The PT is sent to a potential GC/KS. This can occur in several ways, and the method of transmittal is outside the scope of GSAKMP. The potential GC/KS will verify the GO signature on the PT to ensure that it comes from a trusted GO. Next, the GC/KS will verify that it is authorized to become the GC/KS, based on the authorization rules in the PT. Assuming that the GC/KS trusts the PT, is authorized to be a GC/KS, and is locally configured to become a GC/KS for a given group and the GO, then the GC/KS will create the keys necessary to start the group. The GC/KS will take whatever action is necessary (if any) to advertise its ability to distribute key for the group. The GC/KS will then listen for RTJs. The PT has a sequence number. Every time a PT is distributed to the group the group members verify that the sequence number on the PT is increasing. The PT lifetime is not limited to a particular time interval, other than by the lifetimes imposed by some of its attributes (e.g. signature key lifetime). The current PT sequence number is downloaded to the GM in the "Key Download" message. Also, to avoid replay attacks, you should indicate that this sequence number is never reset to a lower value (i.e. rollover to zero) as long as the group identifier remains valid and in use. The GO must preserve this sequence number across re-boots. 4.4.4 Discovery of GC/KS Potential GMs will receive notice of the new group via some mechanism: announcement, Anycast, registration look-up. The GM will send an RTJ to the GC/KS. 4.4.5 GC/KS registration policy enforcement The GC/KS may or may not require cookies, depending on Denial of Service environment and the local configuration. Once the RTJ has been received, the GC/KS will verify that the GM is allowed to have access to the group keys. The GC/KS will then verify the signature on the RTJ to ensure it was sent by the claimed identity. If the checks succeed, the GC/KS will ready a Key Download message for the GM. If not the GC/KS can notify the GM of a non-security relevant problem. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 22]
INTERNET-DRAFT GSAKMP October 2003 4.4.6 GM registration policy enforcement Upon receipt of the Key Download message, the GM will verify the signature on the message. Then the GM will retrieve the PT from the Key Download message and verify that the GO created and signed the PT. Once the PT is verified as valid, the GM will verify that the GC/KS is authorized to distribute key for this group. Then the GM will verify that the mechanisms used in the group are available and acceptable for protection of the GMs data (assuming the GM is a data source). The GM will then accept membership in this group. The GM will then check to see if it is allowed to be a S-GC/KS for this group. If the GM is allowed to be a S-GC/KS AND the local GM configuration allows the GM to act as a S-GC/KS for this group, then the GM changes its operating state to S-GC/KS. The GO needs to take care when assigning the authority to become an S-GC/KS. 4.4.7 S-GC/KS operations As a S-GC/KS, the host will now distribute keys and the PT. The first action is to notify the potential GMs of its ability to distribute key for the group. This can be accomplished in exactly the same manner as the GC/KS notifications. The S-GC/KS may be authorized to be a local management GC and as such, it can be authorized to create its own rekey trees. There are several ways to architect S-GC/KS operations that include rekey trees. Rekey operations with S-GC/KSs can use: - the S-GC/KS to distribute the rekey arrays generated at the GC/KS, - the S-GC/KS can create and distribute it's sub tree and report those keys back to the GC/KS, The GSAKMP message that sends those keys from the S-GC/KS to the GC/KS is not standardized in this version of the specification. or - the S-GC/KS can act as an independent rekey authority passing on the group keys to its subscribers. In the independent mode of operation, the S-GC/KS holds the rekey key it received upon group registration. It will then create rekey messages for its subscribers using the rekey key it creates. Once the notification mechanisms have been activated and key trees created, the S-GC/KS waits for RTJs. GMs will join the group via the S-GC/KS. The S-GC/KS will then manage its rekey group based on notification of local Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 23]
INTERNET-DRAFT GSAKMP October 2003 rekey needs. 4.5 GSAKMP Interactions With NAT Traversal GSAKMP security association endpoints services that may straddle any combination of IP-v4 public addresses and private addresses [RFC1918]. In such cases, GSAKMP endpoint identifiers may be embedded within the GSAKMP policy token's security association Security Policy Database (SPD) traffic selector rules. These GSAKMP endpoint identifiers when resolved to their equivalent private or public IP-v4 addresses entangle the GSAKMP protocol with Network Address Translation (NAT) [RFC2663] [RFC3022] gateway behaviors. In addition, the NAT translation of IP-v4 header addresses also impacts the GSAKMP registration SA, the GSAKMP re-key SA, and the multicast application SA. This section defines the GSAKMP mechanisms that partially mitigate the inherent complexity spawned by IP-v4 NAT and Network Address Port Translation (NAPT) traversal. However, given the large number of documented NAT problems and its erosion of end-to-end security, [reference okazaki-v6ops-natpt-security-00.txt] new GSAKMP applications and deployments SHOULD strongly prefer the use of IP-v6. This specification offers IP-v4 to IP-v6 transitional guidance in support of that objective. 4.5.1 Non-Transparent Network Address Translation Behaviors The following NAT side effects are known to interact with the GSAKMP protocol and its three security association types (Registration, Rekey, and Data Layer (specifically IPSec in this example): The following NAT behavior adversely impacts source-specific secure multicast IPSec groups. When a NAT gateway is on the path between a multicast source endpoint residing behind a NAT and a public IP-v4 multicast destination, the NAT alters the private source address to a public IP-v4 address. This translation must be coordinated with every GSAKMP IPSec receiver's inbound Security Policy Database (SPD) multicast entries that uses that source address as a traffic selector [RFC2401bis]. In addition to its impact on the inbound SPD, this NAT behavior also impacts the source-specific multicast routing. The GCKS must set up the GSAKMP receiver with a SPD entry that anticipates the value(s) that the NAT translates the packet's source address. However, there are known cases where this address translation can change without warning: NAT gateways may re-boot and lose their address translation state information. The NAT gateway may de-allocate its address translation state after an inactivity timer expires. The address translation used by the NAT gateway Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 24]
INTERNET-DRAFT GSAKMP October 2003 after the resumption of data flow may differ than that known to the SPD selectors at the GSAKMP endpoints. The GCKS may not have global consistent knowledge of a GSAKMP endpoint's current public and private address mappings due to network errors or race conditions. For example, an endpoint's address may change due to a DHCP assigned address lease expiration. Alternate paths may exist between a given pair of GSAKMP endpoints. If there are parallel NAT gateways along those paths, then the address translation state information at each NAT gateway may produce different translations on a per packet basis. When multiple multicast source endpoints reside behind a NAT with a single public IP-v4 address, the NAT gateway can not do UDP or TCP port translation (i.e. NAPT) because the ESP encryption conceals the transport layer protocol headers. The use of UDP encapsulated ESP [ref XXXXX] avoids this problem. However, this capability must be configured at the GCKS as a group policy, and it must be supported in unison by all of the GSAKMP endpoints within the group, even those that reside in the public Internet. Note that at the time of this writing this solution has IPR. In a transport mode multicast application SA, the UDP checksum operation may require the origin endpoint's IP address to complete successfully. In IKE-v2 [IKE-v2], this information is exchanged between the endpoints by a NAT-OA payload (NAT original address). See section X.Y of reference [ipsec-nat-t-v03.txt]. A comparable facility must exist in a GSAKMP PT payload that defines the multicast application SA attributes for each multicast source endpoint. The GSAKMP receiver endpoints must authenticate the source of all key management packets and they must not trust a packet's IP addresses or port numbers. The presence of a NAT gateway makes it impossible to use an Authentication Header, keyed by a group-wide key, to protect the integrity of the IP header, from individuals within the cryptographic group. 4.5.2 GSAKMP Avoidance of NAT Using an IP-v6 Over IP-v4 Network A straight forward and standards-based architecture that effectively avoids the GSAKMP use of NAT gateways is the IP-v6 over IP-v4 transition mechanism [RFC2529]. In IP-v6 over IP-v4 (a.k.a. "6over4"), the underlying IP-v4 network is treated as a virtual multicast-capable Local Area Network. The IP-v6 traffic tunnels over that IP-v4 virtual link layer. Applying GSAKMP in a 6over4 architecture leverages the fact that an administrative domain deploying GSAKMP would already be planning to deploy IP-v4 multicast router(s). The GSAKMP group's IP-v6 multicast routing can execute in parallel to IP-v4 multicast routing on that same physical Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 25]
INTERNET-DRAFT GSAKMP October 2003 router infrastructure. In particular, the NAT gateways at administrative domain public/private boundaries are replaced by IP-v6 multicast routers operating with 6over4 mode enabled on their network interfaces. This yields a substantial reduction in complexity and error cases over the NAT-based approaches. This reduction in complexity can translate into better security. The following factors may effect the decision to deploy GSAKMP 6over4 rather than GSAKMP with IP-v4 NAT: When traversing NAT, application layer protocols that contain IP-v4 addresses in their payload need the intervention of an Application Layer Gateway (ALG) that understands that application layer protocol [RFC3027] [RFC3235]. The ALG massages the payload's private IP-v4 addresses into equivalent public IP-v4 addresses. However, when encrypted by end-to-end ESP such payloads are opaque to application layer gateways. The primary drawback of the GSAKMP 6over4 approach is that the secure multicast application must be (re-)written to an IP-v6 multicast socket API or equivalent, and it must interact with the Multicast Listener Discovery (MLD) API [reference vida-mld-v2-07.txt] [reference magma-msf-api-05.txt] rather than IGMP. For new applications, this may not be of consequence; it usually only becomes an issue if the application has an embedded base. An embedded base of GSAKMP multicast IP-v4 applications that are only available in binary form will not be able to migrate to these transitional IP-v6 mechanisms. The secondary drawbacks of GSAKMP 6over4 are that the IP hosts must be upgraded to dual-stack, the attendant overlay IP-v6 multicast network operational costs, and the difficulty of finding commercial wide-area IP-v6 multicast services. Reliable scalable GSAKMP 6over4 deployment is far more practical than GSAKMP/NAT. In particular, new GSAKMP multicast applications should prefer GSAKMP 6over4. However, GSAKMP supports either choice. 4.5.3 GSAKMP Multicast IP-v4 NAT Architectural Assumptions To make the GSAKMP NAT interaction problem tractable to a solution, this specification makes the following simplifying assumptions: The secure multicast group destination address is a statically allocated public IP-v4 multicast address known to all GSAKMP endpoints. Wherever they are present in the GSAKMP policy token, GSAKMP IPSec endpoint identifiers are expressed as permanent IP-v6 "6to4" addresses [RFC3056] to assure that the GSAKMP endpoints that refer to hosts assigned private IP-v4 addresses are globally unique. The GCKS resides within one of the private networks, but it also has a permanent public IP-v4 address on at least one of its network interfaces. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 26]
INTERNET-DRAFT GSAKMP October 2003 The GCKS domain name RR record should point to that public IP-v4 address, and it should be protected by DNS-SEC. Each private address space has one or more NAT gateways directly connected to the IP-v4 public Internet, and a packet does not have to traverse multiple private networks to reach the public Internet. This can be thought of as a "spoke and hub" configuration wherein the public Internet is the hub. Each of an administrative domain's NAT gateways are explicitly configured with static private/public address translation mappings for the GCKS's GSAKMP re-key multicast UDP packets inbound from the public Internet [RFC2588]. The NAT gateways/firewalls are explicitly configured with stateless filter rules that simply pass through without any address translation the group's inbound multicast application packets arriving from the public Internet. The NAT gateway does not translate the multicast application packet's public multicast IP destination address into a private IP multicast address. In the outbound direction, NAT gateways generally translate the multicast application packet's private source IP address into a dynamically selected public IP address. Exceptions to this policy for source specific multicast are noted in subsequent sections. Within each administrative domain, a multicast routing protocol domain routes packets based on the group's destination multicast public IP-v4 address. The multicast routers will distribute the group's packets to all of the group's GSAKMP endpoints residing in that administrative domain. The border routers of each of the administrative domains spanned by the group do cross-realm multicast routing and distribution on behalf of the group. The IP-v4 multicast routers that exchange reachability information regarding the group across trust boundaries authenticate that information. GSAKMP IPSec group security associations are end-to-end transport mode, rather than tunnels terminated at a combined NAT/security gateway [RFC2709]. 4.5.4 Representative Example GSAKMP Multi-Realm Configuration Figure 1 illustrates a representative group "Z" wherein a GSAKMP group security association spans two private IP-v4 networks and the public IP-v4 Internet. The Group "Z" GCKS has two network interfaces, one attached to the public Internet and the other interface attached to the administrative domain "B" private network. The group members GM1 and GM2 reside within the administrative domain "A" private network. They communicate with the GCKS and the group Z multicast source endpoint(s) through the administrative domain "A" NAT gateway. When GM1 or GM2 send multicast application SA traffic to the group Z public Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 27]
INTERNET-DRAFT GSAKMP October 2003 multicast address, the Group Z peer members (i.e. GM3, GM4, GM5, and GM6) receive that multicast with the source address translated by NAT gateway "A" processing. In the inverse direction, the administrative domain "A" NAT gateway/firewall must be configured to allow Group Z multicast application SA and re-key SA traffic to enter the private network "A" from the public Internet (e.g. a multicast originating from GM6). The group members GM5 and GM6 reside within the administrative domain "B" private network. Their interactions with Group Z are very similar to those discussed for members GM1 and GM2. The only difference is that they use private addresses when communicating with the GCKS, as they are both in private network "B". The group members GM3 and GM4 are in a public Internet administrative domain operated by an ISP. They communicate with the GCKS using public IP-v4 addresses without passage through a NAT gateway. When GM3 or GM4 send multicast application SA traffic to the group Z public multicast address, the Group Z peer members behind NAT gateways receive that multicast with the source address unchanged by NAT processing. Each administrative domain operates an IP-v4 multicast routing domain instance. The multicast routers distribute both GSAKMP re-key event messages and multicast application SA data traffic. The multicast routing for group "Z" peers between these three multicast routing domains. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 28]
INTERNET-DRAFT GSAKMP October 2003 . . "A" Admin Domain . ISP Admin Domain . "B" Administrative domain +-------------------.---------------------.-----------------------------+ ! . . ! ! P U B L.I C I P - v 4 . I N T E R N E T ! ! . . ! +-------/\\----------.-----A-------A----A--.---------/\\--------------/\\--+ !! public . ! ! ! . !! public !! !! IP-v4 . ! ! ! . !! IP-v4 !! +-------\\/--------+ . ! ! ! . +-------\\/--------+ +---\\/--+ ! NAT gateway ! . ! ! ! . ! Group "Z" ! !NAT "B"! ! domain A ! . ! ! ! . ! GSAKMP GCKS ! !gateway! +---A------A----A-+ . ! ! ! . +-A------A------A-+ +---A---+ ! ! ! . ! ! ! . ! ! ! ! registration SA! . registration SA ! . registration SA ! ! ! ! ! . ! ! ! . ! ! ! ! +-V-+ +-V-+ ! . +-V-+ +-V-+ ! . +-V-+ +-V-+ ! ! !GM1! !GM2! ! . !GM3! !GM4! ! . !GM5! !GM6! ! ! +-A-+ +-A-+ ! . +-A-+ +-A-+ ! . +-A-+ +-A-+ ! ! ! ! ! . ! ! ! . ! ! ! ! Group data/rekey SA . Group data/rekey SA . Group data/rekey Sec. Assoc. ! ! ! . ! ! ! . ! ! ! ! +-V------V----V-+ . +---V-------V----V+ . +-V------V------V-------V--+ ! Group "Z" ! . ! Group "Z" ! . ! Group "Z" ! ! multicast ! . ! multicast ! . ! multicast ! !routing domain ! . ! routing domain ! . ! routing domain ! +---------------+ . +-----------------+ . +--------------------------+ . . . . Figure 1: GSAKMP NAT Example Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 29]
INTERNET-DRAFT GSAKMP October 2003 4.5.5 GSAKMP Registration Security Association NAT Traversal This class of GSAKMP unicast messages are exchanged between a GCKS in the public IP-v4 Internet and a group member that may be in a private network. The following GSAKMP message types are sent and received over the registration security association as UDP packets with an authenticated payload: - Request-To-Join - Key Download - This message contains a Policy Token that includes a multicast application SA initialization payload, including IPSec SPD traffic selector rules that refer to GSAKMP endpoint identifiers. It also contains the re-key SA initialization payload, which also refers to GSAKMP IPSec endpoint identifiers. - Notification - Request To Join Acknowledge/Negative Acknowledge - Request-To-Depart - Departure-Response - Notification - Departure Acknowledgement A group member sends a registration SA GSAKMP message to the GCKS public IP-v4 address and the GSAKMP reserved port number. The group member assigns a unique GSAKMP UDP source port number for each GSAKMP registration SA that it participates in. The group member MUST send the GSAKMP UDP packet without a checksum to avoid NAT alterations to that field. The UDP packet's transmission error detection depends on the GSAKMP signature payload. A NAT gateway on the path leading to the GCKS translates the private source IP address and source UDP port number into a public address and a temporary UDP port number (assuming NAPT), then forwards the packet to the GCKS. The NAT gateway creates state information for that public/private address mapping so it can do the inverse translation on the GSAKMP messages sent from the GCKS to that group member. The GCKS must process the GSAKMP messages that it receives from group members originating from any source IP address or source port number, even if those two values have changed since the last time that the GCKS had interacted with a given group member. This could cause problems if the GC/KS is operating in the mandatory cookie exchange mode. To identify the group member, the GCKS MUST use the GSAKMP signature payload's identifying information and validate the message's digital signature. After processing a message from a group member that requires a GCKS response, the GCKS creates the GSAKMP UDP message destined for the same IP-v4 address and UDP port that the GCKS found in the group member message's Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 30]
INTERNET-DRAFT GSAKMP October 2003 source IP address and UDP source port. 4.5.6 GSAKMP Re-key Security Association NAT Traversal The GCKS multicasts the GSAKMP Re-key Event message to the re-key SA in a UDP packet addressed to group's destination public IP-v4 multicast address. Both the UDP source port and the UDP destination port are set to the GSAKMP reserved port number. The UDP checksum is optional. The GCKS sends two copies of the GSAKMP Re-key Event message, one originating from its public Internet interface, and the other copy originating from one of its private network interfaces. Group members behind a NAT gateway will receive the Re-key Event message unchanged provided that the intervening NAT gateway has been configured correctly to allow the packet through without translation. 4.5.7 Multicast Application Security Association NAT Traversal Each such SA has a group-wide unique SPI, its own sequence number, and associated group keying material. Unlike the Re-key Event message multicast to the re-key SA, a multicast application message sent to the group may originate from a GSAKMP endpoint located behind a NAT gateway. Since the application's message is encrypted within an ESP payload, the transport layer protocol header port fields are concealed from NAT gateways and they can not participate in NAPT. The multicast application IPSec SA must be handled differently depending on whether the application requires source-specific multicast. If the application requires IPSec source-specific multicast routing, then there must be a separate public IP-v4 address statically reserved at the NAT gateway for each multicast source endpoint private/public address mapping. This constraint allows the GCKS to specify at every group member the inbound SPD traffic selector with a pre-determined public source address for each multicast source GSAKMP endpoint in the group. The traffic selector's public source address in combination with the group's destination multicast address and SPI selects the inbound SA. Keeping the NAT gateway's source address mapping static rather than dynamic also allows the multicast routers along the packet's path to apply source-specific routing policies. Note that the use of a static source address mapping NAT avoids the need for the group policy token to specify UDP encapsulated ESP. The GCKS SPD configuration database must be kept synchronized with the group's NAT gateway address mapping configurations. If source-specific multicast routing is not required by the application, then the NAT gateway's source address translation can use dynamically allocated public IP-v4 addresses rather than statically allocated IP-v4 addresses. However, unless the group uses UDP encapsulated ESP, then the NAT gateway must have a pool of public IP-v4 addresses reserved that is at least as large as the number of multicast source GSAKMP endpoints Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 31]
INTERNET-DRAFT GSAKMP October 2003 within its private network. This allows the NAT gateway to do a one-to-one mapping from every GSAKMP endpoint's private source address to a dynamically allocated public source address. The GCKS specifies the SPD inbound traffic selector as the combination of the group's destination multicast address and the SPI. In some deployments, the number of public IP-v4 addresses assigned to a NAT gateway is very limited (e.g. only one public address). Also, it may be difficult to predict how many multicast source endpoints will reside within the private network before the group begins its operation. For these cases, the group MAY use UDP encapsulated ESP. The NAT gateway applies NAPT to the UDP header's source port field, sidestepping the constraint of its limited public address pool. The GCKS modifies the group policy token to specify that the outbound SPD processing must pre-append a UDP header in front of the ESP header. When a GSAKMP endpoint originates a multicast application packet, it inserts a UDP header in front of the ESP header, as per reference [XXXXX]. 5 Group Life Cycle The management of a cryptographic group follows a life-cycle: group definition, group establishment, and security relevant group maintenance. Group definition involves defining the parameters necessary to support a secure group, including its policy token. Group establishment is the process of granting access to new members. Security relevant group maintenance messages include rekey, policy changes and member deletion. Each of these life-cycle phases is discussed in the following sections. 5.1 Group Definition A cryptographic group is established to support secure communications among a group of individuals. The activities necessary to create a Policy Token in support of a cryptographic group include - Determine Access Policy - identify the entities that are authorized to receive the group key. - Determine Authorization Policy - identify which entities are authorized to perform security relevant actions, including key dissemination, policy creation, and initiation of security management actions. - Determine Mechanisms - define the algorithms and protocols used by GSAKMP to secure the group. - Create Group Policy Token - format the policies and mechanisms into a Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 32]
INTERNET-DRAFT GSAKMP October 2003 Policy Token and apply the GO signature. 5.2 Group Establishment GSAKMP Group Establishment consists of three mandatory-to-implement messages, the Request to Join, the Key Download, and the Key Download Ack/Failure. The exchange may also include two OPTIONAL error messages, the Request to Join Error and the Lack_of_Ack messages. Operation using the mandatory messages only is referred to as "Terse Mode", while inclusion of the error messaging is referred to as "Verbose Mode". GSAKMP implementations MUST support Terse Mode and MAY support Versbose Mode. Group Establishment is discussed in Section 5.2.1. For Denial of Service protection, a Cookie Exchange MAY precede the Group Establishment exchange. The Cookie Exchange is described in Section 5.2.2. 5.2.1 Standard Group Establishment After the out-of-band receipt of a Policy Token, a potential Group Controller Key Server (GC/KS) verifies the token and its eligibility to perform GC/KS functionality. It is then permitted to create any needed group keys and begin to establish the group. The GSAKMP Ladder Diagram, Figure 2, is presented to illustrate the process of establishing a cryptographic group. The left side of the diagram represents the actions of the GC/KS. The right side of the diagram represents the actions of the GMs. The components of each message shown in the diagram are presented in sections 5.2.1.1 - 5.2.1.5. The Request to Join message is sent from a potential GM to the GC/KS to request admission to the cryptographic group. The message contains key creation material, freshness data, an optional selection of mechanisms, and the signature of the GM. The Key Download message is sent from the GC/KS to the GM in response to an accepted Request to Join. This GC/KS-signed message contains the identifier of the GM, freshness data, key creation material, encrypted keys, and the encrypted Policy Token. The Policy Token is used to facilitate well-ordered group creation and MUST include the group's identification, group permissions, group join policy, group controller key server identity, group management information, and digital signature of the GO. This will allow the GM to determine whether group policy is compatible with local policy. The Request to Join Error message is sent from the GC/KS to the GM in response to an unaccepted Request to Join. This message is not signed by the GC/KS for two reasons: 1) The GM, at this point, has no knowledge Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 33]
INTERNET-DRAFT GSAKMP October 2003 CONTROLLER Mandatory/ MESSAGE MEMBER Optional !<-M----------Request to Join-------------! <Process RTJ> ! ! !--M----------Key Download--------------->! ! ! <Process KeyDL> !--O-------Request to Join Error--------->! or ! ! <Proc RTJ-Err> !<-M----Key Download - Ack/Failure--------! <Process KeyDL-A/F>! ! !--O------Lack of Ackknowledgement------->! ! ! <Proc LOA> !<=======SHARED KEYED GROUP SESSION======>! Figure 2: GSAKMP Ladder Diagram of who is authorized to act as a GC/KS and so the signature would thus be meaningless to the GM, and 2) Signing responses to denied join requests would provide a denial of service potential. The message contains an indication of the error condition. The Key Download Ack/Failure message indicates Key Download receipt status at the GM. It is a GM-signed message containing freshness data and status. The Lack_of_Ack message is sent from the GC/KS to the GM in response to an invalid or absent Key Download Ack/Failure message. The signed message contains freshness and status data and is used to warn the GM of impending eviction from the group if a valid Key Download Ack/Failure is not sent. For the following message structure sections, details about payload format and processing can be found in Section 7. 5.2.1.1 Request to Join The components of a Request to Join Message are shown in Table 1. As shown by Figure 2, a potential GM MUST generate and send an RTJ message to request permission to join the group. As defined in the disection of the RTJ message, this message MUST contain payloads to hold the following information: Key Creation payload for KEK generation and Nonce payload for freshness. The Nonce_I value MUST be saved for later use. An OPTIONAL Notification payload of type Mechanism Choices MAY be included to identify the mechanisms the GM wants to use. Absence of this payload will cause the GC/KS to select appropriate mechanisms for the Key Download. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 34]
INTERNET-DRAFT GSAKMP October 2003 Table 1: Request to Join (RTJ) Message Definition Message Name : Request to Join (RTJ) Dissection : {HDR-GrpID, Key Creation, Nonce_I, [Notif_Mechanism_Choices], [Notif_Cookie]} SigM, [Cert] Payload Types : GSAKMP Header, Key Creation, Nonce, Signature, [Certificate], [Notifications] SigM : Signature of Group Member Cert : Necessary Certificates, zero or more {}SigX :Indicates minimum fields used in Signature [] : Indicate an optional data item In response, the GC/KS accepts or denies the request based on local configuration. <Process RTJ> indicates the GC/KS actions that will determine if the RTJ will be acted upon. The following checks SHOULD be performed in the order presented. In this procedure, the GC/KS MUST verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If the header checks pass, then the identity of the sender is extracted from the Signature payload. This identity MUST be used to perform access control checks, find the GMs credentials (e.g. certificate) for message verification, and MUST also be used in the Key Download message. Then the GC/KS will verify the signature on the message to ensure its authenticity. The GC/KS MUST use verified and trusted authentication material from a known root. If the message signature verifies, the GC/KS then confirms that all required payloads are present and properly formatted based upon the mechanisms announced and/or requested. If all checks pass, the GC/KS will create and send the Key Download message as described in section 5.2.1.2. NOTE: At any one time, a GC/KS MUST process no more that one (1) valid RTJ message from a single GM per group. If the GM receives no response to the RTJ within the GM's locally configured timeout value, the GM SHOULD resend the RTJ message up to three (3) times. If any error occurs during RTJ message processing, and the GC/KS is running in Terse mode, the session MUST be terminated and all saved state information MUST be cleared. The OPTIONAL Notification payload of type Cookie is discussed in section 5.2.2. 5.2.1.2 Key Download The components of a Key Download Message are shown in Table 2: Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 35]
INTERNET-DRAFT GSAKMP October 2003 Table 2: Key Download (KeyDL) Message Definition Message Name : Key Download (KeyDL) Dissection : {HDR-GrpID, Member ID, Nonce_R, Nonce_C, Key Creation, (Policy Token)*, (Key Download)*} SigC, [Cert] Payload Types : GSAKMP Header, Identification, Nonce, Key Creation, Policy Token, Key Download, Signature, [Certificate] SigC : Signature of Group Controller Key Server Cert : Necessary Certificates, zero or more {}SigX :Indicates minimum fields used in Signature [] : Indicate an optional data item (data)* : Indicates encrypted information In response to a properly formed and verfied RTJ message, the GC/KS creates and sends the KeyDL message. As defined in the dissection of the message, this message MUST contain payloads to hold the following information: GM identification, Nonce payloads for freshness, Key Creation material, encrypted Policy Token, enctyped key information, and signature information. The nonce values transmitted MUST be the GC/KSs generated Nonce_R value and the conbined Nonce_C value which was generated by using the GS/KSs Nonce_R value and the Nonce_I value received from the GM in the RTJ. The key creation material supplied by the GM and/or the GC/KS will be used to generate the KEK. Generation of this KEK is defined by policy. The Policy Token and Key material are encrypted in the generated KEK. The GM MUST be able to process the Key Download message. <Process KeyDL> indicates the GM actions that will determine how the Key Download message will be acted upon. The following checks SHOULD be performed in the order presented. In this procedure, the GM will verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If the header checks pass, the GM MUST confirm that this message was intended for itself by comparing the Member ID in the Identification payload to its identity. After identification confirmation, the freshness values are checked. The GM MUST use its save Nonve_I value, extract the received GC/KS Nonce_R value, compute the combined Nonce_C value, and compare it to the received Nonce_C value. After freshness is confirmed, the signature MUST be verified to ensure its authenticity, The GM MUST use verified and trusted authentication material from a known root. If the message signature verifies, the key creation material is extracted from the Key Creation payload to generate the KEK. This KEK is then used to decrypt the Policy Token data. The signature on the policy token MUST be verified. Access control checks MUST be performed on both the GO and the GC/KS to determine both their authorities within this group. After all these checks pass, the KEK can then be used to decrypt and process the key material from Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 36]
INTERNET-DRAFT GSAKMP October 2003 the Key Download payload. If all is successful, the GM will create and send the Key Download - Ack/Failure message as described in section 5.2.1.4. The Policy Token and Key Download payloads are sent encrypted in the KEK generated by the Key Creation payload information using the mechanisms defined in the group announcment. This guarantees that the sensitive policy and key data for the group and potential rekey data for this individual cannot be read by anyone but the intended recipient. If any error occurs during KeyDL message processing, and the GM is running in Terse mode, the session MUST be terminated, the GM MUST send a Key Download - Ack/Failure message with a Notification Payload of type NACK to indicate termination, and all saved state information MUST be cleared. 5.2.1.3 Request to Join Error The components of the Request to Join Error Message are shown in Table 3: Table 3: Request to Join Error (RTJ-Err) Message Definition Message Name : Request to Join Error (RTJ-Err) Dissection : {HDR-GrpID, Nonce_I, Notification} Payload Types : GSAKMP Header, Nonce, Notification In response to an unacceptable RTJ, the GC/KS MAY send a Request to Join Error (RTJ-Err) message containing an appropriate Notification payload. Note that the RTJ-Err message is not a signed for the following reasons: the lack of awareness on the GM's perspective of who is a valid GC/KS as well as the need to protect the GC/KS from signing messages and using valuable resources. Following the sending of an RTJ-Err, the GC/KS MUST terminated the session and all saved state information MUST be cleared. Upon receipt of an RTJ-Err message, the GM will validate the following: the GroupID in the header belongs to a group to which the GM has sent an RTJ, and the Nonce_I matches a Nonce_I sent in an RTJ to that group. If the above checks are successful, the GM MAY terminate the state associated with that GroupID and Nonce. The GM SHOULD be capable of receiving a valid KeyDownload message for that GroupID and Nonce after receiving an RTJ-Err for a locally-configured amount of time. 5.2.1.4 Key Download - Ack/Failure The components of the Key Download - Ack/Failure Message are shown in Table 4: In response to a properly processed KeyDL message, the GM creates and sends Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 37]
INTERNET-DRAFT GSAKMP October 2003 Table 4: Key Download - Ack/Failure (KeyDL-A/F) Message Definition Message Name : Key Download - Ack/Failure (KeyDL-A/F) Dissection : {HDR-GrpID, Nonce_C, Notif_Ack}SigM Payload Types : GSAKMP Header, Nonce, Notification, Signature SigM : Signature of Group Member {}SigX :Indicates minimum fields used in Signature the KeyDL-A/F message. As defined in the dissection of the message, this message MUST contain payloads to hold the following information: Nonce payload for freshness, Notification payload of type Acknowledgment (ACK). and signature information. The nonce value transmitted MUST be the GMs generated Nonce_C value. The GC/KS MUST be able to process the KeyDL-A/F message. <Process KeyDL-A/F> indicates the GC/KS actions that will determine how the KeyDL-A/F message will be acted upon. The following checks SHOULD be performed in the order presented. In this procedure, the GC/KS will verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If the header checks pass, the GC/KS MUST check the message for freshness. The GC/KS MUST use its saved Nonve_C value, and compare it to the received Nonce_C value. After freshness is confirmed, the signature MUST be verified to ensure its authenticity, The GC/KS MUST use verified and trusted authentication material from a known root. If the message signature verifies, the GC/KS processes the Notification payload. If the notification type is of type ACK, then the GC/KS and GM have established a GSA. If the GC/KS does not receive a KeyDL-A/F message of proper form, is unable to correctly process the KeyDL-A/F message, the Notification payload type is any value excpet ACK, or if no KeyDL-A/F message is received within the locally configured timeout, the GC/KS MUST remove this GM from the group and handle according to policy. The GC/KS MAY send the OPTIONAL Lack_of_Ack message if running in Verbose Mode as defined in section 5.2.1.5. 5.2.1.5 Lack of Ack The components of a Lack of Ack Message are shown in Table 5: If the GC/KSs local timeout value expires prior to receiving a KeyDL-A/F from the GM, the GC/KS MAY create and send a LOA message to the GM. As defined in the dissection of the message, this message MUST contain payloads to hold the following information: GM identification, Nonce payloads for freshness, Notification of error, and signature information. The nonce values transmitted MUST be the GC/KSs generated Nonce_R value and Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 38]
INTERNET-DRAFT GSAKMP October 2003 Table 5: Lack of Ack (LOA) Message Definition Message Name : Lack of Ack (LOA) Dissection : {HDR-GrpID, Member ID, Nonce_R, Nonce_C, Notification} SigC, [Cert] Payload Types : GSAKMP Header, Identification, Nonce, Notification, Signature, [Certificate] SigC : Signature of Group Controller Key Server Cert : Necessary Certificates, zero or more {}SigX :Indicates minimum fields used in Signature [] : Indicate an optional data item the conbined Nonce_C value which was generated by using the GS/KSs Nonce_R value and the Nonce_I value received from the GM in the RTJ. These values were already generated during the Key Download message phase. The GM MAY be able to process the LOA message based upon local configuration. <Process LOA> indicates the GM actions that will determine how the LOA message will be acted upon. The following checks SHOULD be performed in the order presented. In this procedure, the GM MUST verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If the header checks pass, the GM MUST confirm that this message was intended for itself by comparing the Member ID in the Identification payload to its identity. After identification confirmation, the freshness values are checked. The GM MUST use its save Nonve_I value, extract the received GC/KS Nonce_R value, compute the combined Nonce_C value, and compare it to the received Nonce_C value. After freshness is confirmed, access control checks MUST be performed on the GC/KS to determine its authority within this group. Then signature MUST be verified to ensure its authenticity, The GM MUST use verified and trusted authentication material from a known root. If the checks succeed, the GM SHOULD resend a KeyDL-A/F for that session. 5.2.2 Cookies - Group Establishment with Denial of Service Protection This section defines an OPTIONAL capability that MAY be implemented into GSAKMP when using IP based groups. The information in this section is borrowed heavily from [IKEv2] as this protocol has already worked through this issue and GSAKMP is copying this concept. This section will contain paraphrased sections of [IKEv2] modified for GSAKMP to define the purpose of Cookies. An optional Cookie mode is being defined for the GSAKMP to help against DoS attacks. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 39]
INTERNET-DRAFT GSAKMP October 2003 The term "cookies" originates with Karn and Simpson [RFC 2522] in Photuris, an early proposal for key management with IPsec. The ISAKMP fixed message header includes two eight octet fields titled "cookies". Instead of placing this cookie data in the header, this data is moved into a Notification payload. An expected attack against GSAKMP is state and CPU exhaustion, where the target GC/KS is flooded with Request to Join requests from forged IP addresses. This attack can be made less effective if a GC/KS implementation uses minimal CPU and commits no state to the communication until it knows the initiator potential GM can receive packets at the address from which it claims to be sending them. To accomplish this, the GC/KS when operating in Cookie mode, SHOULD reject initial Request to Join messages unless they contain a Notification payload of type "cookie". It SHOULD instead send a Cookie Download message as a response to the RTJ and include a cookie in a notify payload of type Cookie_Required. Potential GMs who receive such responses MUST retry the Request to Join message with the responder GC/KS supplied cookie in its notification payload of type Cookie, as defined by the optional Notification payload of the Request to Join Msg as defined in section 5.2.1.1. This initial exchange will then be as shown in Figure 3 with the components of the new message Cookie Download shown in Table 6. CONTROLLER MESSAGE MEMBER in Cookie Mode !<--Request to Join without Cookie Info---! <Gen Cookie Rsp> ! ! !----------Cookie Download--------------->! ! ! <Process CD> !<----Request to Join with Cookie Info----! <Process RTJ> ! ! !-------------Key Download--------------->! ! ! <Process KeyDL> !<-----Key Download - Ack/Failure--------! <Proc KeyDL-A/F> ! ! !<=======SHARED KEYED GROUP SESSION======>! Figure 3: GSAKMP Ladder Diagram with Cookies Table 6: Cookie Download Message Definition Message Name : Cookie Download Dissection : {HDR-GrpID, COOKIE_REQUIRED} Payload Types : GSAKMP Header, Notification The first two messages do not affect any GM or GC/KS state except for communicating the cookie. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 40]
INTERNET-DRAFT GSAKMP October 2003 A GSAKMP implementation SHOULD implement its GC/KS cookie generation in such a way as to not require any saved state to recognize its valid cookie when the second Request to Join message arrives. The exact algorithms and syntax they use to generate cookies does not affect interoperability and hence is not specified here. The following is an example of how an endpoint could use cookies to implement limited DoS protection. A good way to do this is to set the cookie to be: Cookie = <SecretVersionNumber> ! Hash(Ni ! IPi ! <secret>) where <secret> is a randomly generated secret known only to the responder GC/KS and periodically changed, Ni is the Nonce value taken from the initiator potential GM, IPi is the supposed IP of the initiator potential GM. <SecretVersionNumber> should be changed whenever <secret> is regenerated. The cookie can be recomputed when the "Request to Join with Cookie Info" arrives and compared to the cookie in the received message. If it matches, the responder GC/KS knows that all values have been computed since the last change to <secret> and that IPi MUST be the same as the source address it saw the first time. Incorporating Ni into the hash assures that an attacker who sees only the Cookie_Download message cannot successfully forge a "Request to Join with Cookie Info" message. This Ni value MUST be the same Ni value from the original "Request to Join" message for the calculation to be successful. If a new value for <secret> is chosen while there are connections in the process of being initialized, a "Request to Join with Cookie Info" might be returned with other than the current <SecretVersionNumber>. The responder GC/KS in that case MAY reject the message by sending another response with a new cookie or it MAY keep the old value of <secret> around for a short time and accept cookies computed from either one. The responder GC/KS SHOULD NOT accept cookies indefinitely after <secret> is changed, since that would defeat part of the denial of service protection. The responder GC/KS SHOULD change the value of <secret> frequently, especially if under attack. 5.3 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. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 41]
INTERNET-DRAFT GSAKMP October 2003 5.3.1 Rekey Events A Rekey Event is any action, including compromise report or key expiration, that requires the creation of a new group key and/or Rekey information. Once an event has been identified (as defined in the group security policy token), the GC/KS MUST create and provide a signed message containing the GTEK and Rekey information to the group. Each GM who receives this message MUST verify the signature on the message to ensure its authenticity. If the message signature does not verify, the message MUST be discarded. Upon verification the GM will find the appropriate Rekey download packet and decrypt the information with a stored Rekey key(s). If a new Policy Token is distributed with the message, it MUST be encrypted in the old GTEK. The components of a Rekey Event message are shown in Table 7: Table 7: Rekey Event Message Definition Message Name : Rekey Event Dissection : {HDR-GrpID, ([Policy Token])*, Rekey Array}SigC, [Cert] Payload Types : GSAKMP Header, [Policy Token], Rekey Event, Signature, [Certificate], SigC : Signature of Group Controller Key Server Cert : Necessary Certificates, zero or more {}SigX :Indicates minimum fields used in Signature (data)* : Indicates encrypted information [] : Indicate an optional data item 5.3.2 Leaving a Group There are several conditions under which a member will leave a group: eviction, voluntary departure without notice, and voluntary departure with notice -- or De-Registration. Each of these is discussed in this section. 5.3.2.1 Eviction At some point in the group's lifetime, it may be desireable to evict one or more members from a group. From a key management viewpoint, this involves revoking access to the group's protected data by "disabling" the departing members' keys. This is accomplished with a Rekey Event, which is discussed in more detail in section 5.3.1. If future access to the group is also to be denied, the members MUST be added to a denied access control list, and Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 42]
INTERNET-DRAFT GSAKMP October 2003 the tokens authorization rules MUST be appropriately updated so that they will exclude the expelled GM(s). After receipt of a new PT, GMs SHOULD evaluate the trustworthiness of any recent application data originating from the expelled GM(s). 5.3.2.2 Voluntary Departure without Notice If a member wishes to leave a group for which membership imposes no cost or responsibility to that member, then the member MAY merely delete local copies of group keys and cease group activities. 5.3.2.3 De-Registration If the membership in the group does impose cost or responsibility to the departing member, then the member SHOULD de-register from the group that the member wishes to leave. De-Registration consists of a three-message exchange between the GM and the member's GCKS: the Request_to_Depart, Departure_Reponse, and the Departure_Ack. These messages SHOULD be done under the protection of the GSA. 5.3.2.3.1 Request to Depart - The components of a Request_to_Depart Message are shown in Table 8. Table 8: Request_to_Depart (RTD) Message Definition Message Name : Request_to_Depart (RTD) Dissection : {HDR-GrpID, GS/KS_ID, Nonce_I, Notif_Leave_Group} SigM, [Cert] Payload Types : GSAKMP Header, Identification, Nonce, Notification, Signature, [Certificate] SigM : Signature of Group Member Cert : Necessary Certificates, zero or more {}SigX :Indicates minimum fields used in Signature [] : Indicate an optional data item Any GM desiring to initiate the De-Registration process MUST generate and send an RTD message to notify the GC/KS of its intent. As defined in the disection of the RTD message, this message MUST contain payloads to hold the following information: the GC/KS identification, Nonce payload for freshness, and Notification of the desire to leave the group. The Nonce_I value MUST be saved for later use. This message MUST then by signed by the GM. Upon receipt of the RTD message, the GC/KS MUST verify that the message header is properly formed and confirm that this message is for this group Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 43]
INTERNET-DRAFT GSAKMP October 2003 by checking the value of the GroupID. If the header checks pass, then the identifier value in Identification payload is compared to its own, the GC/KSs identity, to confirm that the GM intended to converse with this GC/KS, the GC/KS who registered this member into the group. Then the identity of the sender is extracted from the Signature payload. This identity MUST be used to confirm that this GM is a member of the group serviced by this GC/KS. Then the GC/KS will confirm from the Notification payload that the GM is requesting to leave the group. Then the GC/KS will verify the signature on the message to ensure its authenticity. The GC/KS MUST use verified and trusted authentication material from a known root. If all checks pass and the message is successfully processed, and/or the GC/KS is in Verbose Mode, then the GCKS MUST form a Departure_Response message as defined in section 5.3.2.3.2. If the processing of the message fails and/or the GC/KS is in Terse Mode, then the session MUST be terminated and all state associated with this session is removed. 5.3.2.3.2 Departure_Response - The components of a Departure_Response Message are shown in Table 9. Table 9: Departure_Response (DR) Message Definition Message Name : Departure_Response (DR) Dissection : {HDR-GrpID, Member_ID, Nonce_R, Nonce_C, Notification} SigC, [Cert] Payload Types : GSAKMP Header, Identification, Nonce, Notification, Signature, [Certificate] SigC : Signature of Group Member Cert : Necessary Certificates, zero or more {}SigX :Indicates minimum fields used in Signature [] : Indicate an optional data item In response to a properly formed and verfied RTD message, the GC/KS MUST create and send the DR message. As defined in the dissection of the message, this message MUST contain payloads to hold the following information: GM identification, Nonce payloads for freshness, Notification for acceptance of departure, and signature information. The nonce values transmitted MUST be the GC/KSs generated Nonce_R value and the conbined Nonce_C value which was generated by using the GS/KSs Nonce_R value and the Nonce_I value received from the GM in the RTD. This Nonce_C value MUST be saved relative to this departing GMs ID. The GM MUST be able to process the Departure_Response message. The following checks SHOULD be performed in the order presented. The GM MUST verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 44]
INTERNET-DRAFT GSAKMP October 2003 the header checks pass, the GM MUST confirm that this message was intended for itself by comparing the Member ID in the Identification payload to its identity. After identification confirmation, the freshness values are checked. The GM MUST use its saved Nonve_I value, extract the received GC/KS Nonce_R value, compute the combined Nonce_C value, and compare it to the received Nonce_C value. After freshness is confirmed, confirmation of the identity of the signer of the DR message is the GMs authorized GC/KS is performed. Then the signature MUST be verified to ensure its authenticity, The GM MUST use verified and trusted authentication material from a known root. If the message signature verifies, then the GM MUST verify that the Notification is of Type Departure_Accepted or Request_to_Depart_Error. If the processing is successful, and the Notification payload is of type Departure_Accepted, the member MUST form the Departure_ACK message as defined in section 5.3.2.3.3. If the processing is successful, and the Notification payload is of type Request_to_Depart_Error, the member MUST remove all state associated with the action. If the member still desires to De-Register from the group, the member MUST restart the De-Registration process. 5.3.2.3.3 Departure_ACK - The components of the Departure_ACK Message are shown in Table 10: Table 10: Departure_ACK (DA) Message Definition Message Name : Departure_ACK (DA) Dissection : {HDR-GrpID, Nonce_C, Notif_Ack}SigM Payload Types : GSAKMP Header, Nonce, Notification, Signature SigM : Signature of Group Member {}SigX :Indicates minimum fields used in Signature In response to a properly processed Departure_Response message, the GM MUST create and send the Departure_ACK message. As defined in the dissection of the message, this message MUST contain payloads to hold the following information: Nonce payload for freshness, Notification payload of type Acknowledgment (ACK), and signature information. The nonce value transmitted MUST be the GMs generated Nonce_C value. Upon receipt of the Departure_ACK, the GCKS MUST perform the following checks. These checks SHOULD be performed in the order presented. In this procedure, the GC/KS will verify that the message header is properly formed and confirm that this message is for this group by checking the value of the GroupID. If the header checks pass, the GC/KS MUST check the message for freshness. The GC/KS MUST use its saved Nonve_C value, and compare it to the received Nonce_C value. After freshness is confirmed, the signature MUST be verified to ensure its authenticity, The GC/KS MUST use verified and trusted authentication material from a known root. If the message signature verifies, the GC/KS processes the Notification payload. If the notification type is of type ACK, this is considered a successful processing of this Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 45]
INTERNET-DRAFT GSAKMP October 2003 message. If the processing of the message is successful, the GC/KS MUST remove the member from the group. This MAY involve initiating a Rekey Event for the group. If the processing of the message fails or if no Departure_Ack is received, the GC/KS MAY issue a LOA message. 6 Security Suite The Security Definition Suite 1 MUST be supported. Other security suite definitions MAY be defined in other internet specifications. 6.1 Assumptions All potential GMs will have enough information available to them to use the correct Security Suite to join the group. This can be accomplished by a well known default suite 'Security Suite 1' or by announcing/posting another suite. 6.2 Definition Suite 1 GSAKMP implementations MUST support the following suite of algorithms and configurations. The following definition of Suite 1 borrows heavily from IKE's Oakley group 2 definition and Oakley itself. The GSAKMP Suite 1 definition defines all the algorithm and cryptographic definitions required to process group establishment messages. It is important to note that GSAKMP does not negotiate these cryptographic mechanisms. This definition is set by the Group Owner via the Policy Token (passed during the GSAKMP exchange for member verification purposes). The GSAKMP Suite 1 definition is Key download and Policy Token encryption algorithm definition: Algorithm: 3DES Mode: CBC64 Key Length: 192 bits Policy Token digital signature algorithm is: DSS-ASN1-DER Hash algorithm is: Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 46]
INTERNET-DRAFT GSAKMP October 2003 SHA-1 Nonce Hash algorithm is: SHA-1 The Key Creation definition is: Algorithm type is Diffie Hellman MODP group definition g: 2 p: "FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1" "29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD" "EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245" "E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED" "EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381" "FFFFFFFF FFFFFFFF" NOTE: The p and g values comes from IKE [RFC 2409], section 6.2 Second Oakley Group, and p is 1024 bits long. The digital signature algorithm is: DSS-ASN1-DER Hash algorithm is: SHA-1 The digital signature ID type is: U-NAME 7 GSAKMP Payload Structure A GSAKMP Message is composed of a GSAKMP Header (Section 7.1) followed by at least one GSAKMP Payload. All GSAKMP Payloads are composed of the Generic Payload Header (Section 7.2) followed by the specific payload data. The message is chained by a preceeding payload defining its succeeding payload. The final payload in a message will point to no succeeding payload. All fields of type integer in the Header and Payload structure that are larger than one octet, MUST be converted into Network Byte Order prior to data transmission. 7.1 GSAKMP Header 7.1.1 GSAKMP Header Structure The GSAKMP Header fields are defined in Figure 4: Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 47]
INTERNET-DRAFT GSAKMP October 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! GroupID Type ! GroupID Length! Group ID Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ ! Next Payload ! Version ! Exchange Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Sequence ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 4: GSAKMP Header Format Group Identification Type (1 octet) - Table 11 presents the group identification types. Table 11: Group Identification Types Grp ID Type Value ______________________________________ Network Byte Ordered Integer 0 Ascii 1 Other 2-255 Group Identification Length (1 octet) - Length of Group ID field in octets. Group Identification Value (variable length) - 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 12 presents the payload types. Version (1 octet) - Indicates the version of the GSAKMP protocol in use. The current value is one (1). Exchange Type (1 octet) - Indicates the type of exchange (also known as the message type). Table 13 presents the exchange type values. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 48]
INTERNET-DRAFT GSAKMP October 2003 Table 12: Payload Types Next_Payload_Type Value ___________________________________ None 0 Policy Token 1 Key Download Packet 2 Rekey event 3 Identification 4 Reserved 5 Certificate 6 Reserved 7 Signature 8 Notification 9 Reserved 10 Key Creation 11 Nonce 12 Reserved 13 - 127 Private Use 128 -- 255 Table 13: Exchange Types Exchange_Type Value ___________________________________ Reserved 0 - 3 Key Download Ack/Failure 4 Rekey Event 5 Reserved 6 No Message 7 Request to Join 8 Key Download 9 Cookie Download 10 Request to Join Error 11 Ack Error 12 Other 13-255 Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 49]
INTERNET-DRAFT GSAKMP October 2003 Sequence ID (4 octets) - Group Management replay protection field. Sequence ID for group management messages. If not a group management message, this value MUST be set to zero (0). When a (S-)GC/KS is initiated, it MUST set its initial sequence ID value to one (1). For each distinct group management message that this (S-)GC/KS transmits, this value MUST be incremented by one (1). Receivers of this group management message MUST confirm that the value received is greater that the value of the sequence ID received with the last group management message from this (S-)GC/KS. GMs MUST also recognize receipt of a Group Management messages that suffer from rolloever and handle accordingly. Length (4 octets) - Length of total message (header + payloads) in octets. 7.1.2 GSAKMP Header Processing When processing the GSASKMP Header, the following fields MUST be checked for correct values: 1. GroupID - The GroupID of the received message MUST match the GroupID of the processing member. 2. Next Payload - The Next Payload value MUST be a valid payload type as defined by Table 12. 3. Version - The GSAKMP version numbers MUST match. 4. Exchange Type - The Exchange Type MUST be a valid exchange type as defined by Table 13 and MUST be of the type expected to receive. 5. Sequence ID - The Sequence ID value MUST be of the correct value. For negotiation messages this value MUST be zero (0). For group management messages, this value MUST be greater than the last sequence ID received from this (S-)GC/KS. The length fields in the GSAKMP Header are used to help process the message. If any field is found to be incorrect, then termination processing MUST be initiated. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 50]
INTERNET-DRAFT GSAKMP October 2003 7.2 Generic Payload Header 7.2.1 Generic Payload Header Structure Each GSAKMP payload defined in the following sections begins with a generic header, shown in Figure 5, which provides a payload ``chaining`` capability and clearly defines the boundaries of a payload. The Generic Payload Header fields are defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 5: Generic Payload Header Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the ``chaining`` capability. Table 12 identifies the payload types. RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. 7.2.2 Generic Payload Header Processing When processing the Generic Payload Header, the following fields MUST be checked for correct values: 1. Next Payload - The Next Payload value MUST be a valid payload type as defined by Table 12. 2. RESERVED - This field MUST contain the value zero (0). The length field in the Generic Payload Header is used to process the remainder of the payload. If any field is found to be incorrect, then termination processing MUST be initiated. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 51]
INTERNET-DRAFT GSAKMP October 2003 7.3 Policy Token Payload The Policy Token Payload contains authenticatable group specific information that describes the group security relevant behaviors, access control parameters, and security mechanisms. Figure 6 shows the format of the payload. 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 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! PT Type ! Policy Token Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 6: 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. Policy Token (PT) Type (2 octets) - Specifies the type of Policy Token being used. Table 14 identifies the types of policy tokens. Table 14: Policy Token Types PT_Type Value Definition ____________________________________________________________________________ GSAKMP_V1_PT 0 The format for this Policy Token is specified in [HCLM00]. GSAKMP_ASN.1_PT 1 All implementations of GSAKMP MUST support this Policy Token format. This format is specified in TBD. Reserved 2-65535 Policy Token Data (variable length) - Contains Policy Token information. The values for this field are token specific and the format is specified by the PT Type field. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 52]
INTERNET-DRAFT GSAKMP October 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Key Download Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 7: Key Download Payload Format If this payload is encrypted, only the Policy Token Data field is encrypted. The payload type for the Policy Token Payload is one (1). 7.4 Key Download Payload The Key Download Payload contains group keys (eg., group keys, initial rekey keys, etc.). These key download payloads can have several security attributes applied to them based upon the security policy of the group. Figure 7 shows the format of the payload. The security policy of the group dictates that the key download payload MUST be encrypted with a key encryption key (KEK). The type of encryption used is specified in the Policy Token. The group members MUST create the KEK using the key creation method identified in the Key Creation Payload. The Key Download 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. 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: Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 53]
INTERNET-DRAFT GSAKMP October 2003 Key Download Data (KDD) Type (1 octet) -- Identifier for the Key Data field of this Key Packet. See Table 15 for the possible values of this field. Table 15: Key Download Data Types Key Download Data Type Value ________________________________ GTEK 0 Rekey - LKH 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. If this payload is encrypted, only the Key Download Data field is encrypted. For a Key Download Data value of GTEK, the Key Packet Data field format is defined in Section A.1.1. For a Key Download Data value of Rekey, the Key Packet Data field format is defined in Section A.1.2. The payload type for the Key Download Packet is two (2). 7.5 Rekey Event Payload The Rekey Event Payload MAY contain 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 8 shows the format of the payload. 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, Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 54]
INTERNET-DRAFT GSAKMP October 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Rekey Type ! Rekey Event Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 8: Rekey Event Payload Format including the generic payload header. Rekey Type (1 octet) - Specifies the type of Rekey Event being used. Table 16 presents the types of Rekey events. Table 16: Rekey Event Types Rekey_Type Value Definition ______________________________________________________________________________ None 0 This type MUST be implemented. In this case, the size of the Rekey Event Data field will be zero byes long. The purpose of a Rekey Event Payload with type None is when it is necessary to send out a new token with no rekey information. GSAKMPekey Msg requires a Rekey Event PL, and in this instance it would have rekey data of type None. GSAKMP_LKH 1 The rekey data will by of type LKH formatted according to GSAKMP. The format for this field is defined in Section B.2. Unassigned 2-255 Rekey Event Data (variable length) - Contains Rekey Event information. The values for this field are group specific and the format is specified by the Rekey Type field. The Rekey Event payload type is three (3). 7.6 Identification Payload The Identification Payload contains entity-specific data used to exchange identification information. This information is used to verify the identities of members. Figure 9 shows the format of the Identification Payload. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 55]
INTERNET-DRAFT GSAKMP October 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! ID Type ! Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 9: 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. Identification (ID) Type (1 octet) - Specifies the type of Identification being used. Table 17 identifies possible values for this type. Table 17: Identification Types ID_Type Value ____________________________________________ Sender Unencoded Name (S-U-NAME) 0 Receiver Unencoded Name (R-U-NAME) 1 Unassigned 2-255 Identification 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 format for this field is defined in Section A.2.1 The payload type for the Identification Payload is four (4). 7.7 Certificate Payload The Certificate Payload provides a means to transport certificates or other certificate-related information via GSAKMP and can appear in any GSAKMP Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 56]
INTERNET-DRAFT GSAKMP October 2003 message. Certificate payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available to distribute certificates. Figure 10 shows the format of the Certificate Payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Cert Type ! 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 Type (2 octets) - This field indicates the type of certificate or certificate-related information contained in the Certificate Data field. Table 18 presents the types of certificate payloads. Table 18: Certificate Payload Types Certificate_Type Value ____________________________________________________________ None 0 Reserved 1 - 3 X.509 Certificate -- Signature - DER Encoding 4 Reserved 5 -- 65534 Certificate Data (variable length) - Actual encoding of certificate data. The type of certificate is indicated by the Certificate Type/Encoding field. The payload type for the Certificate Payload is six (6). Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 57]
INTERNET-DRAFT GSAKMP October 2003 7.8 Signature Payload 7.8.1 Signature Payload Structure 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 but not including the Signature Data Length. Figure 11 shows the format of the Signature Payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Signature Type! Sig ID Type ! Signature Payload Span ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ ! Signature Timestamp ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ ! Signer ID Lenth ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Signer ID Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Signature Length ! Signature Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 11: 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. Signature Type (1 octet) -- Indicates the type of signature. Table 19 presents the allowable signature types. Signature ID Type (1 octet) -- Indicates the format for the Signature ID Data. Table 20 presents the allowable signature ID types. The formats for these types are defined in Section A.2.1 Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 58]
INTERNET-DRAFT GSAKMP October 2003 Table 19: Signature Types Signature Type Value ____________________________________________________ DSS with ASN.1/DER encoding (DSS-ASN1-DER) 0 Other 1-255 Table 20: Signature Types Signature ID Type Value _________________________________ Unencoded Name (U-NAME) 0 Other 1-255 Signature Payload Span (4 octets) - Identifies the information included in the signature. The first two octets define the first signature payload. The third and fourth octet define the last payload. The payloads in the message are an ordered sequence beginning at the header, with a value of zero (0). If the signature payload itself is not in the signature span, you MUST still sign over the signature payload up to the signature data. Signature Timestamp (4 octets) -- Date and time that the digital signature was applied. This field contains the time in seconds from the epoch 00:00 GMT 1 January 1970. Signer ID Length (2 octets) - Length in octets of the Signer' ID. Signer ID Data (variable length) -- Data identifying the Signer's ID (e.g., DN). The format for this field is based on the Signature ID Type field and is shown where that type is defined. The contents of this field MUST be checked against the Policy Token to determine the authority and access of the Signer within the context of the group. Signature Length (2 octets) -- Length in octets of the Signature Data. Signature Data (variable length) - Data that results from applying the digital signature function to the GSAKMP message and/or payload. The payload type for the Signature Payload is eight (8). 7.8.2 Signature Payload Processing When processing the Signature Payload, the following fields MUST be checked for correct values: Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 59]
INTERNET-DRAFT GSAKMP October 2003 1. Signature Type - The Signature Type value MUST be a valid signature type as defined by Table 19. 2. Signature ID Type - The Signature ID Type value MUST be a valid signature ID type as defined by Table 20. 3. Signature Span - The signature span values MUST encompass the payloads as defined by the message disection for this message type. 4. Signature ID Data - This field will be used to identify the sending party. This information MUST then be used, when applicable, to confirm that the correct party sent us this information. 5. Signature Data - This value MUST be compared to the recomputed signature to verify the message. The length fields in the Signature Payload are used to process the remainder of the payload. If any field is found to be incorrect, then termination processing MUST be initiated. 7.9 Notification Payload The Notification Payload can contain both GSAKMP and group specific data and is used to transmit informational data, such as error conditions, to a GSAKMP peer. It is possible to send multiple independant Notification payloads in a single GSAKMP message. Figure 12 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 Payload Type ! Notification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 12: 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. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 60]
INTERNET-DRAFT GSAKMP October 2003 Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. Notify Payload Type (2 octets) - Specifies the type of notification message. Table 21 presents the Notify Payload Types. Table 21: Notify Payload Types Notification Type Value _______________________________________________ None 0 Invalid-Payload-Type 1 Situation-Not-Supported 2 Invalid-Major-Version 3 Invalid-Version 4 Invalid-Group-ID 5 Invalid-Sequence-ID 6 Payload-Malformed 7 Invalid-Key-Information 8 Invalid-ID-Information 9 Invalid-Cert-Encoding 10 Invalid-Certificate 11 Cert-Type-Unsupported 12 Invalid-Cert-Authority 13 Authentication-Failed 14 Invalid-Signature 15 Notify-GSA-Lifetime 16 Certificate-Unavailable 17 Unequal-Payload-Lengths 18 Unauthorized-Request 19 Unable-To-Take-Requested-Role 20 Reserved 21 - 22 Acknowledgement 23 Reserved 24 - 25 Nack 26 Cookie-Required 27 Cookie 28 Mechanism Choices 29 Leave Group 30 Departure Accepted 31 Request to Depart Error 32 Reserved (future use) 33 - 8191 Private Use 8192 -- 16383 Notification Data (variable length) - Informational or error data transmitted in addition to the Notify Payload Type. Values for this field are Domain of Interpretation (DOI)-specific. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 61]
INTERNET-DRAFT GSAKMP October 2003 The payload type for the Notification Payload is nine (9). 7.9.1 Notification Data - Acknowledgement (ACK) Payload Type The data portion of the Notification payload of type ACK serves either for confirmation of correct receipt of the Key Download message, or, when needed, can provide other receipt information when included in a signed message. Figure 13 shows the format of the Notification Data - Acknowledge Payload Type. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Ack Type ! Acknowledgement Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 13: Notification Data - Acknowledge Payload Type Format The Notification Data - Acknowledgement Payload Type data fields are defined as follows: Ack Type (1 octet) - Specifies the type of acknowledgement. Table 22 presents the Notify Acknowledgement Payload Types. Table 22: Acknowledgement Types ACK_Type Value Definition ___________________________________________ Simple 0 Data portion null. Unassigned 1-255 7.9.2 Notification Data - Cookie_Required and Cookie Payload Type The data portion of the Notification payload of types Cookie_Required and Cookie contain the Cookie value. The value for this field will have been computed by the responder GC/KS and sent to the GM. The GM will take the value received and copy it into the Notification payload Notification Data field of type Cookie that is transmitted in the "Request to Join with Cookie Info" back to the GC/KS. The cookie value MUST NOT be modified. The format for this is already described in the discussion on cookies in section 5.2.2. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 62]
INTERNET-DRAFT GSAKMP October 2003 7.9.3 Notification Data - Mechanism Choices Payload Type The data portion of the Notification payload of types Mechanism Choices contains the mechanisms the GM is requesting to use for the negotiation with the GC/KS. This information will be supplied by the GM in a RTJ message. Figure 14 shows the format of the Notification Data - Mechanism Choices Payload Type. Multiple type!length!data choices are strung togther in one notification payload to allow a user to transmit all relevant information within one Notification Payload. The length of the payload will contol the parsing of the Notification Data Mechanism Choices field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Mech Type ! Length ! Mechanism Choice Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ... Figure 14: Notification Data - Mechanism Choices Payload Type Format The Notification Data - Mechanism Choices Payload Type data fields are defined as follows: Mechanism Type (1 octet) - Specifies the type of mechanism. Table 23 presents the Notify Mechanism Choices Mechanism Types. Table 23: Mechanism Types Mechanism_Type Value Mechanism Choice Data Value Table Reference ________________________________________________________________________________ Key Creation Algorithm 0 Table 26 Encryption Algorithm 1 Table 24 Nonce Hash Algorithm 2 Table 25 Unassigned 1-255 Length (1 octet) -- Length in octets of the Mechanism Choice Data. Mechanism Choice Data (variable length) - The data value for the mechanism type being selected. The values are specific to each Mechanism Type defined. All tables necessary to define the values that are not defined elsewhere (in this specification or others) are defined here. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 63]
INTERNET-DRAFT GSAKMP October 2003 Table 24: Encryption Types Encryption_Types Value ____________________________ Reserved 0 - 2 3DES_CBC64_192 3 Unassigned 4 - 16k Table 25: Nonce Hash Types Nonce_Hash_Type Value __________________________ Reserved 0 SHA-1 1 Unassigned 2 - 16k 7.10 Key Creation Payload 7.10.1 Key Creation Payload Structure The Key Creation Payload contains information used to create key encryption keys. The security attributes for this payload are provided in the Policy Token. Figure 15 shows the format of the payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Key Crtn Type ! Key Creation Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 15: Key Creation Payload Format The Key Creation Payload fields are defined as follows: Next Payload (1 octet) - Identifier for the payload type 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. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 64]
INTERNET-DRAFT GSAKMP October 2003 Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. Key Creation (Crtn) Type (1 octet) - Specifies the type of Key Creation being used. Table 26 identifies the types of key download information. Table 26: Types Of Key Creation Information Key Creation Type Value Definition ____________________________________________________________ Reserved 0 Diffie-Hellman 1 This type MUST be supported. other 2-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 eleven (11). 7.10.2 Key Creation Payload Processing The specifics of the Key Creation Payload are defined in section 7.10. When processing the Key Creation Payload, the following fields MUST be checked for correct values: 1. Key Creation Type - The Key Creation Type value MUST be a valid key creation type as defined by Table 26. 2. Key Creation Data - This data will be used to compute the key encryption key (KEK). If any field is found to be incorrect, then termination processing MUST be initiated. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 65]
INTERNET-DRAFT GSAKMP October 2003 7.11 Nonce Payload 7.11.1 Nonce Payload Structure The Nonce Payload contains random data used to guarantee freshness during an exchange and protect against replay attacks. Figure 16 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 16: 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 27 identifies the types of nonces. Table 27: Nonce Types Nonce_Type Value Definition ______________________________________________________________________________ None 0 Initiator (Nonce_I) 1 Responder (Nonce_R) 2 Combined (Nonce_C) 3 Hash (Append(Initiator_Value,Responder_Value)) The hash type comes from the Security Suite Definition. Unassigned 4-255 Nonce Data (variable length) - Contains the nonce information. The values Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 66]
INTERNET-DRAFT GSAKMP October 2003 for this field are group-specific and the format is specified by the Nonce Type field. If no group-specific information is provided, the minimum length for this field is 4 bytes. The payload type for the Nonce Payload is twelve (12). 7.11.2 Nonce Payload Processing The specifics of the Nonce Payload are defined in section 7.11. When processing the Nonce Payload, the following fields MUST be checked for correct values: 1. Nonce Type - The Nonce Type value MUST be a valid key creation type as defined by Table 27. 2. Nonce Data - This is the nonce data and it must be checked according to its type. The size of this field is defined in Nonce Payload section 7.11. It any value is found to be incorrect, then termination processing MUST be initiated. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 67]
INTERNET-DRAFT GSAKMP October 2003 8 GSAKMP State Diagram Figure 17 presents the states encountered in the use of this protocol. Table 28 defines the states. Table 29 defines the transitions. !-----------------> ( ) ! !-------------> ( Idle ) <------------------! ! ! ( ) ! ! ! ! ! ! ! ! ! ! ! ! ! (1a) (1) ! ! ! ! ! ! ! ! ! ! ! ! ! V V ! ! !---(5a)--- (Wait for ) (Wait for ) ----(5)-----! ! (Group ) (GC/KS Event) <--- ! (Membership) ^ ! \ \ ! ! ! ! \ \ ! ! ! ! \--(2)---\ ! (2a) (4)(3) ! ! ! ! ! ! ! ! ! V ! V !-------(4a)--- (Wait for ) (Wait for ) (Group ) (Response ) (Membership) (from Key ) /--> (Event ) (Download ) / / / / /--(3a)---/ Figure 17: GSAKMP State Diagram Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 68]
INTERNET-DRAFT GSAKMP October 2003 Table 28: GSAKMP States ___________________________________________________________________________ Idle : GSAKMP Application waiting for input _____________________:_____________________________________________________ : Wait for GC/KS Event : GC/KS up and running, waiting for events _____________________:_____________________________________________________ : Wait for Response : GC/KS has sent Key Download, from Key Download : waiting for response from GM _____________________:_____________________________________________________ : Wait for Group : GM in process of joining group Membership : _____________________:_____________________________________________________ : Wait for Group : GM has group key, waiting for Membership Event : group management messages. : ___________________________________________________________________________ Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 69]
INTERNET-DRAFT GSAKMP October 2003 Table 29: State Transition Events ____________________________________________________________________ Transition 1 : Create group command _______________:____________________________________________________ : Transition 2 : Receive bad RTJ : Receive valid command to change group membership : Send Compromise message x times _______________:____________________________________________________ : Transition 3 : Receive valid RTJ _______________:____________________________________________________ : Transition 4 : Timeout : Receive Ack : Receive Nack _______________:____________________________________________________ : Transition 5 : Delete group command _______________:____________________________________________________ : Transition 1a : Join group command _______________:____________________________________________________ : Transition 2a : Send Ack _______________:____________________________________________________ : Transition 3a : Receipt of group management messages _______________:____________________________________________________ : Transition 4a : Delete group command _______________:____________________________________________________ : Transition 5a : Time out : Msg failure : errors : ____________________________________________________________________ Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 70]
INTERNET-DRAFT GSAKMP October 2003 A APPENDIX A -- Variable Length Payload Field Definitions This appendix defines the format of all variable length fields that contain multiple items of information. A.1 Key Download Payload Fields A.1.1 GTEK Key Packet Fields 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 data was originally generated. This field contains the time in seconds from the epoch 00:00 GMT 1 January 1970. Key Expiration Date (4 octets) -- This is the time value of when this key is no longer valid for use. This field contains the time in seconds from the epoch 00:00 GMT 1 January 1970. 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. A.1.2 Rekey Key Packet Fields This field is defined within the specific type of rekey scheme used by the group. For LKH, the format of the this field is defined in Section B.1. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 71]
INTERNET-DRAFT GSAKMP October 2003 A.2 Signature Payload Fields A.2.1 Signature ID Data Field Format Identification Data - For type Unencoded Name (U-NAME) the format is: Serial Number (4 octets) -- The certificate serial number in network byte order. Length (4 octets) -- Length in octets of the DN Data field. DN Data (variable length) -- The actual ascii DN value using the slash (/) character for field delimiters. (e.g. "/C=US/ST=MD/ L=Somewhere/O=ACME, Inc./OU=DIV1/CN=user1/Email=user1@acme.com" without the surrounding quotes) B APPENDIX B -- LKH Variable Length Payload Field Definitions This appendix defines the format of all LKH specific variable length fields that contain multiple items of information. B.1 LKH Rekey Key Packet Fields When using the Logical Key Hierarchy (LKH) protocol for Rekey operations, the 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 in which the data is formatted. The current value for this field is one (1). Leaf ID (2 octets) -- This is the Leaf Node ID of the LKH sequence contained in this Key Packet Data block. The leftmost leaf node ID value is one (1). 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. The base node of the binary tree has a Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 72]
INTERNET-DRAFT GSAKMP October 2003 value of one (1). 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. This field contains the time in seconds from the epoch 00:00 GMT 1 January 1970. Key Expiration Date (4 octets) -- This is the time value of when this key is no longer valid for use. This field contains the time in seconds from the epoch 00:00 GMT 1 January 1970. 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. B.2 LKH Rekey Packet Data Format Fields This section 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. B.2.1 Rekey Event Header The Rekey Event Data Header contains information about the rekey data being transmitted to the group. Figure 18 shows the format for the header. Group Identification Value (variable length) - Indicates the name/title of the group to be rekeyed. This is the same format as the Group Identification Value in Section 7.1 GSAKMP Message Header. Time/Date Stamp (4 octets) - This is the time stamp when the Rekey Event Data was generated. This field contains the time in seconds from the epoch 00:00 GMT 1 January 1970. 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). Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 73]
INTERNET-DRAFT GSAKMP October 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Group ID Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ~ Group ID Value ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Time/Date Stamp ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Rekey Type ! Algorithm Ver ! # of Rekey Packets ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! ! Rekey Event Packet Data(s) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! Figure 18: B. 1: Rekey Event Header Format 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 the Rekey Data. Rekey Event Packet Data(s) (variable length) - Contains the packets of rekey event information being transmitted. B.2.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 19 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 19: B. 2: Rekey Event Packet Data Format Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 74]
INTERNET-DRAFT GSAKMP October 2003 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. Refer to Section B.1 for the values of this field. 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. B.2.3 Key Pack Data Each Key Pack contains all the information about the key. Figure 20 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 20: B. 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. B.2.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. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 75]
INTERNET-DRAFT GSAKMP October 2003 B.2.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. This field contains the time in seconds from the epoch 00:00 GMT 1 January 1970. Key Expiration Date (4 octets) - This is the time value of when this key is no longer valid for use. This field contains the time in seconds from the epoch 00:00 GMT 1 January 1970. 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. B.2.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. Refer to Section B.1 for the values of this field. 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. This field contains the time in seconds from the epoch 00:00 GMT 1 January 1970. Key Expiration Date (4 octets) - This is the time value of when this key is no longer valid for use. This field contains the time in seconds from the epoch 00:00 GMT 1 January 1970. 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, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 76]
INTERNET-DRAFT GSAKMP October 2003 B.2.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: 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 Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 77]
INTERNET-DRAFT GSAKMP October 2003 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 C APPENDIX C -- Change History C.1 Changes from GSAKMP-00 to GSAKMP-01 February 2003 This specification was based on two earlier versions of GSAKMP drafts, referred to to GSAKMP and GSAKMP-Light. These two specifications were merged to incorporate all information necessary to allow the original GSAKMP-Light specification to stand on its own. The original GSAKMP protocol no longer exists as a standard, it has been subsumed by GSAKMP-Light. GSAKMP-Light is now called GSAKMP. Major modifications to the specification are Removed Payloads: Authorization, Certificate Request, Vendor ID, and Hash. Removed Messages: Group Removal/Destruction. Signature Processing: The signature processing has been modified. C.2 Changes from GSAKMP-01 to GSAKMP-02 June 2003 1. The specification was modified to confirm that key words are used as defined by RFC2119. 2. The Protocol Considerations section for IANA port number was added. 3. The Cookie section for mitigation of DoS attacks was added. 4. The Protocol State Diagram was added. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 78]
INTERNET-DRAFT GSAKMP October 2003 C.3 Changes from GSAKMP-02 to GSAKMP-03 August 2003 1. Clarrified Nonce value in Request to Join With Cookie msg. 2. Added Signature ID Type to Security Suite 1 definition. 3. Clarrified format of Identification information used in Signature and Identification Payloads. 4. Split Signature Type field into it's two appropriate fields. This was not a change in the payload, just cleaning up the definition. C.4 Changes from GSAKMP-03 to GSAKMP-04 October 2003 1. Terminology Section (a) Rekey definition was made more verbose. 2. Securiry Considerations Section (a) ISAKMP Section i. Corrected GSAKMPs relationship definition to ISAKMP. (b) Rekey Availability Section i. Added this new section. 3. Architecture Section (a) This section in its entirety was added for this revision of the specification. 4. Group Life Cycle Section (a) Group Establishment Section Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 79]
INTERNET-DRAFT GSAKMP October 2003 i. Introduced Verbose and Terse concept. (b) Standard Group Establishment Section i. Added messages Request to Join Error and Lack_of_Ack to ladder diagram to show verbose error messaging. ii. Modified definition of Ack message on ladder diagram to be consistant with new naming convention. iii. Reworked all section wording to convey the new message trasmissions. (c) Request to Join Section i. Completly reworked to better define the process of building and processing the RTJ message by the GM and GC/KS. (d) Key Download Section i. Completly reworked to better define the process of building and processing the KeyDL message by the GC/KS and GM. (e) Request to Join Error Section i. New section added for this new verbose message. (f) Key Download = Ack/Failure Section i. Completly reworked to better define the process of building and processing the KeyDL-A/F message by the GM and GC/KS. (g) Lack_of_Ack Section i. New section added for this new verbose message. (h) Added the following new Sub-sections to this section. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 80]
INTERNET-DRAFT GSAKMP October 2003 i. Leaving Group ii. Eviction iii. Voluntary Departure without Notice iv. Deregistration v. Request to Depart Message vi. Departure Response Message vii. Departure Ack Message 5. GSAKMP Payload Structure Section (a) Added note that all all integer fields larger than one octet MUST be converted to Network Byte Order prior to trnasmission. (b) GSAKMP Header Section i. Existing section became the Structure subsection. ii. Added the Processgin subsection. iii. GroupID Type was modified to GroupID Length with the appropriate definitions. iv. New Exchange Types added for verbose mode. v. Sequence ID definition was modified for: A. New initial value. B. Rollover handling responsibility. (c) GSAKMP Payload Header Section i. Existing section became the Structure subsection. ii. Added the Processgin subsection. (d) Policy Token Payload Section Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 81]
INTERNET-DRAFT GSAKMP October 2003 i. The header paragraph was corrected to not levy any requirements from GSAKMP on the Policy Token. ii. The PT Type field was expaned from one (1) to two (2) octets. iii. The values of the PT Types were modified and defined to reflect the true purpose. (e) Rekey Event Payload Section i. Renamed Type field to be unique within specification. ii. The values of the Rekey Type field were modified and defined to reflect thier true purpose. (f) Signature Payload Section i. Existing section became the Structure subsection. ii. Added the Processgin subsection. iii. Removed the one (1) octet field Signature ID Role from the payload, it contained irrelevant data. iv. Expnaded the definition of Singer ID Data to inform the user how to intepret this field. (g) Notification Payload Section i. Removed the one (1) octet Status Type field from the payload. It was irrelevant information. Additionally, all refereneces to Status Type were removed from the payload definition. ii. Added new Notification Payload Type "Mechanism Choices". iii. Added section "Notification Data - Mechanism Choices Payload Type" to define the format of a Notification Payload of type Mechanism Choices. (h) Key Creation Payload Section i. Existing section became the Structure subsection. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 82]
INTERNET-DRAFT GSAKMP October 2003 ii. Added the Processgin subsection. iii. Renamed Type field to be unique within specification. (i) Nonce Payload Section i. Existing section became the Structure subsection. ii. Added the Processgin subsection. D References, Authors Addesses, and Acknowledgements The following references were used in the preparation of this document. D.1 References [HHMCD01] , Thomas Hardjono, Hugh Harney, Pat McDaniel, Andrea Colgrove, Pete Dinsmore, Group Security Policy Token: Definition and Payloads', draft-ietf-msec-gspt-00.txt, Work in progress. [MSST98] Maughan, D., Schertler, M., Schneider, M., and J. Turner, ``Internet Security Association and Key Management Protocol (ISAKMP)'', RFC 2408, November 1998. [FIPS 196], ``Entity Authentication Using Public Key Cryptography,'' Federal Information Processing Standards Publication 196, NIST, February 1997. [DH77], Diffie, W., and M. Hellman, ``New Directions in Cryptography'', IEEE Transactions on Information Theory, June 1977. [DSS] NIST, "Digital Signature Standard", FIPS 186, National Institute of Standards and Technology, U.S. Department of Commerce, May, 1994. [WHA98], Wallner, D., Harder E., and Agee R., ``Key Management for Multicast: Issues and Architectures'', Internet Draft, Informational, September 1998. [BMS], Balenson D., McGrew D., Sherman A., ``Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization'', Internet Draft, February 1999. [RFC 2093] Harney H., Muckenhirn C., and Rivers T., ``Group Key, Management Protocol Specification'', RFC 2093, Experimental, July 1997. Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 83]
INTERNET-DRAFT GSAKMP October 2003 [RFC 2094] Harney H., Muckenhirn C., and Rivers T., ``Group Key Management Protocol Architecture'', RFC 2094, Experimental, July 1997. [RFC 2104] Krawczyk H., Bellare M., and Canetti R., ``HMAC: Keyed-Hashing for Message Authentication'', RFC 2104, Informational, February [RFC 2401] Kent S. and Atkinson, R., ``Security Architecture for the Internet Protocol'', RFC 2401, November 1998, Proposed Standard. [RFC 2402] Kent S. and Atkinson, R., ``IP Authentication Header'', RFC 2402, November 1998, Proposed Standard.1997. [RFC 2406] Kent S. and Atkinson, R., ``IP Encapsulating Security Payload (ESP)'', RFC 2406, November 1998, Proposed Standard. [RFC 2408] Maughan D., Schertler M., Schneider M., and Turner J., ``Internet Security Association and Key Management Protocol (ISAKMP)'', RFC 2408, Proposed Standard, November 1998. [RFC 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. [RFC2543], M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, SIP: Session Initiation Protocol, March 99 [RFC2627] D. Wallner, E. Harder, R. Agee, Kay Management for Multicast: Issues and Architectures, June 1999 [RFC2974], M. Handley, C. Perkins, E. Whelan, Session Announcement Protocol, Oct 2000. [IKEv2], C. Kaufman, ``Internet Key Exchange (IKEv2) Protocol'', draft-ietf-ipsec-ikev2-o6.txt, March 2003 [HCM] H. Harney, A. Colegrove, P. McDaniel, "Principles of Policy in Secure Groups", Proceedings of Network and Distributed Systems Security 2001 Internet Society, San Diego, CA, February 2001 [HCLM00] H. Harney, A. Colegrove, P. Lough, U. Meth, ``GSAKMP Token Specification'', draft-ietf-msec-tokenspec-sec-00.txt D.2 Authors Addresses Hugh Harney (point-of-contact) SPARTA, Inc. 7075 Samuel Morse Drive Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 84]
INTERNET-DRAFT GSAKMP October 2003 Columbia, MD 21046 (410) 872-1515 ext 203 FAX (410) 872-8079 hh@sparta.com Uri Meth SPARTA, Inc. 7075 Samuel Morse Drive Columbia, MD 21046 (410) 872-1515 ext 233 FAX (410) 872-8079 umeth@sparta.com Andrea Colegrove SPARTA, Inc. 7075 Samuel Morse Drive Columbia, MD 21046 (410) 872-1515 ext 232 FAX (410) 872-8079 acc@sparta.com Angela Schuett R231 NSA 9800 Savage Rd Suite 6534 Fort Meade, MD 20755 (301) 688-0850 FAX (301) 688-0255 amschue@tycho.ncsc.mil Patrick McDaniel AT&T Labs - Research A203, Bldg. 103 180 Park Ave. Florham Park, NJ 07932 Office (973) 360-5721 pdmcdan@research.att.com Gavin Kenny LogicaCMG Keats House The Office Park Springfield Drive Leatherhead, Surrey KT22 7LP, UK +44 1372 838043 FAX +44 1372 759196 Gavin.IA.Kenny@LogicaCMG.com Haitham S. Cruickshan Centre for Communication Systems Research (CCSR) Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 85]
INTERNET-DRAFT GSAKMP October 2003 University of Surrey Guildford, Surrey GU2 7XH, UK +44 1483 686007 (indirect 689844) FAX +44 1483 686011 H.Cruickshank@surrey.ac.uk Sunil Iyengar Centre For Communication And Systems Research(CCSR) School of Electronics, Computing and Mathematics University Of Surrey, Guildford GU2 7XH Surrey, England, United Kingdom +44 (0)1483 876008 s.iyengar@eim.surrey.ac.uk George Gross IdentAware Security 82 Old Mountain Road Lebanon, NJ 08833 (908) 268 - 1629 gmgross@nac.net D.3 Acknowledgements The following individuals deserve recognition and thanks for their contributions which have greatly improved this protocol: Eric Harder is an author to the Tunneled-GSAKMP, whose concepts are found in GSAKMP as well. Rod Fleischer, also a Tunneled-GSAKMP author, and Peter Lough were both instrumental in coding a prototype of the GSAKMP software and helped define many areas of the protocol that were vague at best. Andrew McFarland and Gregory Bergren provided critical analysis of early versions of the specification. Ran Canetti analyzed the security of the protocol and provided denial of service suggestions leading to optional "cookie protection". Document expiration: April 24, 2004 Harney, etal. draft-ietf-msec-gsakmp-sec-04.txt [Page 86]