idnits 2.17.1 draft-ietf-msec-gsakmp-sec-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 5303. -- Found old boilerplate from RFC 3978, Section 5.5 on line 5296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5325. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 5288), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 49. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** An RFC 3978, Section 5.1 paragraph was found, but not on the first page, as required. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 117 longer pages, the longest (page 2) being 77 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 124 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 24 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2005) is 6921 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'VendorID' is mentioned on line 1946, but not defined == Missing Reference: 'Cert' is mentioned on line 1946, but not defined == Missing Reference: 'Nonce' is mentioned on line 2008, but not defined == Missing Reference: 'Certificate' is mentioned on line 1949, but not defined == Missing Reference: 'Notifications' is mentioned on line 1341, but not defined == Missing Reference: 'Vendor ID' is mentioned on line 1948, but not defined == Missing Reference: 'RFC 2522' is mentioned on line 1644, but not defined == Missing Reference: 'DNSSEC' is mentioned on line 3339, but not defined == Missing Reference: 'HCLM00' is mentioned on line 5168, but not defined == Unused Reference: 'RFC 2412' is defined on line 4273, but no explicit reference was found in the text == Unused Reference: 'BMS' is defined on line 4288, but no explicit reference was found in the text == Unused Reference: 'HHMCD01' is defined on line 4296, but no explicit reference was found in the text == Unused Reference: 'RFC 2093' is defined on line 4308, but no explicit reference was found in the text == Unused Reference: 'RFC 2094' is defined on line 4312, but no explicit reference was found in the text == Unused Reference: 'RFC 2104' is defined on line 4315, but no explicit reference was found in the text == Unused Reference: 'RFC 2401' is defined on line 4319, but no explicit reference was found in the text == Unused Reference: 'RFC 2402' is defined on line 4322, but no explicit reference was found in the text == Unused Reference: 'RFC 2406' is defined on line 4325, but no explicit reference was found in the text == Unused Reference: 'RFC 2408' is defined on line 4328, but no explicit reference was found in the text == Unused Reference: 'RFC 2974' is defined on line 4335, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-msec-policy-token-sec-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'DH77' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 186-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 196' == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-12 ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2412 ** Downref: Normative reference to an Informational RFC: RFC 2627 ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) == Outdated reference: A later version (-02) exists of draft-ietf-msec-gspt-00 -- Obsolete informational reference (is this intentional?): RFC 2408 (ref. 'MSST98') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Duplicate reference: RFC2408, mentioned in 'RFC 2408', was also mentioned in 'MSST98'. -- Obsolete informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) Summary: 10 errors (**), 0 flaws (~~), 29 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 INTERNET-DRAFT H Harney (SPARTA) 4 U Meth (SPARTA) 5 A Colegrove (SPARTA) 6 G Gross (IdentAware) 7 draft-ietf-msec-gsakmp-sec-10.txt SPARTA, Inc., IdentAware Security 8 Expires: November 16, 2005 May 2005 10 GSAKMP: Group Secure Association Group Management Protocol 12 Status of this memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note 21 that other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than a "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Abstract 37 This document specifies the Group Secure Association 38 Key Management Protocol (GSAKMP). The GSAKMP provides a 39 security framework for creating and managing cryptographic 40 groups on a network. It provides mechanisms to disseminate 41 group policy and authenticate users, rules to perform 42 access control decisions during group establishment and 43 recovery, capabilities to recover from the compromise of 44 group members, delegation of group security functions, and 45 capabilities to destroy the group. It also generates group 46 keys. 48 Copyright Notice Copyright (c) The Internet Society (2005). All 49 Rights Reserved. 51 Contents 52 1 Overview 9 53 1.1 GSAKMP Overview . . . . . . . . . . . . . . . . . . . . . . 9 54 1.2 Document Organization . . . . . . . . . . . . . . . . . . . 10 55 2 Terminology 11 56 3 Security Considerations 13 57 3.1 Security Assumptions . . . . . . . . . . . . . . . . . . . 13 58 3.2 Related Protocols . . . . . . . . . . . . . . . . . . . . . 15 59 3.2.1 ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . 15 60 3.2.2 FIPS Pub 196 . . . . . . . . . . . . . . . . . . . . . 15 61 3.2.3 LKH . . . . . . . . . . . . . . . . . . . . . . . . . . 15 62 3.2.4 Diffie-Hellman . . . . . . . . . . . . . . . . . . . . 15 63 3.3 Denial of Service (DoS) Attack . . . . . . . . . . . . . . 16 64 3.4 Rekey Availability . . . . . . . . . . . . . . . . . . . . 16 65 3.5 Proof of Trust Hierarchy . . . . . . . . . . . . . . . . . 16 66 4 Architecture 17 67 4.1 Trust Model . . . . . . . . . . . . . . . . . . . . . . . . 17 68 4.1.1 Components . . . . . . . . . . . . . . . . . . . . . . 17 69 4.1.2 GO . . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 4.1.3 GC/KS . . . . . . . . . . . . . . . . . . . . . . . . . 18 71 4.1.4 Subordinate GC/KS . . . . . . . . . . . . . . . . . . . 18 72 4.1.5 GM . . . . . . . . . . . . . . . . . . . . . . . . . . 19 73 4.1.6 Assumptions . . . . . . . . . . . . . . . . . . . . . . 20 74 4.2 Rule-Based Security Policy . . . . . . . . . . . . . . . . 20 75 4.2.1 Access Control . . . . . . . . . . . . . . . . . . . . 21 76 4.2.2 Authorizations for security relevant actions . . . . . 22 77 4.3 Distributed Operation . . . . . . . . . . . . . . . . . . . 22 78 4.4 Concept of Operation . . . . . . . . . . . . . . . . . . . 24 79 4.4.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . 24 80 4.4.2 Creation of a Policy Token . . . . . . . . . . . . . . 24 81 4.4.3 Creation of a Group . . . . . . . . . . . . . . . . . . 25 82 4.4.4 Discovery of GC/KS . . . . . . . . . . . . . . . . . . 26 83 4.4.5 GC/KS registration policy enforcement . . . . . . . . . 26 84 4.4.6 GM registration policy enforcement . . . . . . . . . . 26 85 4.4.7 Autonomous Distributed GSAKMP Operations . . . . . . . 26 86 5 Group Life Cycle 29 87 5.1 Group Definition . . . . . . . . . . . . . . . . . . . . . 29 88 5.2 Group Establishment . . . . . . . . . . . . . . . . . . . . 29 89 5.2.1 Standard Group Establishment . . . . . . . . . . . . . 30 90 5.2.1.1 Request to Join . . . . . . . . . . . . . . . . . 32 91 5.2.1.2 Key Download . . . . . . . . . . . . . . . . . . 33 92 5.2.1.3 Request to Join Error . . . . . . . . . . . . . . 35 93 5.2.1.4 Key Download - Ack/Failure . . . . . . . . . . . 36 94 5.2.1.5 Lack of Ack . . . . . . . . . . . . . . . . . . . 37 95 5.2.2 Cookies - Group Establishment with Denial of Service 96 Protection . . . . . . . . . . . . . . . . . . . . . . . . 38 97 5.2.3 Group Establishment for Receive-Only Members . . . . . 40 98 5.3 Group Maintenance . . . . . . . . . . . . . . . . . . . . . 41 99 5.3.1 Group Management . . . . . . . . . . . . . . . . . . . 41 100 5.3.1.1 Rekey Events . . . . . . . . . . . . . . . . . . 41 101 5.3.1.2 Policy Updates . . . . . . . . . . . . . . . . . 42 102 5.3.1.3 Group Destruction . . . . . . . . . . . . . . . . 42 103 5.3.2Leaving a Group . . . . . . . . . . . . . . . . . . . . 42 104 5.3.2.1 Eviction . . . . . . . . . . . . . . . . . . . . 43 105 5.3.2.2 Voluntary Departure without Notice . . . . . . . 43 106 5.3.2.3 De-Registration . . . . . . . . . . . . . . . . . 43 107 5.3.2.3.1 Request to Depart . . . . . . . . . . . . . 43 108 5.3.2.3.2 Departure_Response . . . . . . . . . . . . . 44 109 5.3.2.3.3 Departure_ACK . . . . . . . . . . . . . . . 46 110 6 Security Suite 47 111 6.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 47 112 6.2 Definition Suite 1 . . . . . . . . . . . . . . . . . . . . 47 113 7 GSAKMP Payload Structure 48 114 7.1 GSAKMP Header . . . . . . . . . . . . . . . . . . . . . . . 49 115 7.1.1 GSAKMP Header Structure . . . . . . . . . . . . . . . . 49 116 7.1.1.1 GroupID Structure . . . . . . . . . . . . . . . . 52 117 7.1.1.1.1 UTF-8 . . . . . . . . . . . . . . . . . . . 52 118 7.1.1.1.2 Octet String . . . . . . . . . . . . . . . . 52 119 7.1.1.1.3 IPv4 Group Identifier . . . . . . . . . . . 53 120 7.1.1.1.4 IPv6 Group Identifier . . . . . . . . . . . 53 121 7.1.2 GSAKMP Header Processing . . . . . . . . . . . . . . . 54 122 7.2 Generic Payload Header . . . . . . . . . . . . . . . . . . 56 123 7.2.1 Generic Payload Header Structure . . . . . . . . . . . 56 124 7.2.2 Generic Payload Header Processing . . . . . . . . . . . 57 125 7.3 Policy Token Payload . . . . . . . . . . . . . . . . . . . 57 126 7.3.1 Policy Token Payload Structure . . . . . . . . . . . . 57 127 7.3.2 Policy Token Payload Processing . . . . . . . . . . . . 58 128 7.4 Key Download Payload . . . . . . . . . . . . . . . . . . . 59 129 7.4.1 Key Download Payload Structure . . . . . . . . . . . . 59 130 7.4.1.1 Key Datum Structure . . . . . . . . . . . . . . . 61 131 7.4.1.2 Rekey Array Structure . . . . . . . . . . . . . . 63 132 7.4.2 Key Download Payload Processing . . . . . . . . . . . . 64 133 7.5 Rekey Event Payload . . . . . . . . . . . . . . . . . . . . 65 134 7.5.1 Rekey Event Payload Structure . . . . . . . . . . . . . 65 135 7.5.1.1 Rekey Event Header Structure . . . . . . . . . . 67 136 7.5.1.2 Rekey Event Data Structure . . . . . . . . . . . 68 137 7.5.1.2.1 Key Package Structure . . . . . . . . . . . 69 138 7.5.2 Rekey Event Payload Processing . . . . . . . . . . . . 69 139 7.6 Identification Payload . . . . . . . . . . . . . . . . . . 72 140 7.6.1 Identification Payload Structure . . . . . . . . . . . 72 141 7.6.1.1 ID_U_NAME Structure . . . . . . . . . . . . . . . 75 142 7.6.2 Identification Payload Processing . . . . . . . . . . . 75 143 7.6.2.1 ID_U_NAME Processing . . . . . . . . . . . . . . 76 144 7.7 Certificate Payload . . . . . . . . . . . . . . . . . . . . 77 145 7.7.1 Certificate Payload Structure . . . . . . . . . . . . . 77 146 7.7.2 Certificate Payload Processing . . . . . . . . . . . . 78 147 7.8 Signature Payload . . . . . . . . . . . . . . . . . . . . . 79 148 7.8.1 Signature Payload Structure . . . . . . . . . . . . . . 79 149 7.8.2 Signature Payload Processing . . . . . . . . . . . . . 81 150 7.9 Notification Payload . . . . . . . . . . . . . . . . . . . 82 151 7.9.1 Notification Payload Structure . . . . . . . . . . . . 82 152 7.9.1.1 Notification Data - Acknowledgment (ACK) Payld Typ 85 153 7.9.1.2 Notification Data - Cookie_Required and Cookie 154 Payload Type. . . . . . . . . . . . . . . . . . . . . 85 155 7.9.1.3 Notification Data - Mechanism Choices Payload Type 86 156 7.9.1.4 Notification Data - IPv4 and IPv6 Value Payld Types87 157 7.9.2 Notification Payload Processing . . . . . . . . . . . . 87 158 7.10 Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 88 159 7.10.1 Vendor ID Payload Structure . . . . . . . . . . . . . 88 160 7.10.2 Vendor ID Payload Processing . . . . . . . . . . . . . 89 161 7.11 Key Creation Payload . . . . . . . . . . . . . . . . . . . 90 162 7.11.1 Key Creation Payload Structure . . . . . . . . . . . . 90 163 7.11.2 Key Creation Payload Processing . . . . . . . . . . . 91 164 7.12 Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 92 165 7.12.1 Nonce Payload Structure . . . . . . . . . . . . . . . 92 166 7.12.2 Nonce Payload Processing . . . . . . . . . . . . . . . 93 167 8 GSAKMP State Diagram 94 168 9 IANA Considerations 97 169 9.1 IANA Port Number Assignment . . . . . . . . . . . . . . . . 97 170 9.2 Initial IANA Registry Contents . . . . . . . . . . . . . . 97 171 10 Acknowledgments 98 172 11 References 98 173 11.1 Normative References . . . . . . . . . . . . . . . . . . . 98 174 11.2 Informative References . . . . . . . . . . . . . . . . . . 99 175 A APPENDIX A -- LKH Information 101 176 A.1 LKH Overview . . . . . . . . . . . . . . . . . . . . . . . 101 177 A.2 LKH and GSAKMP . . . . . . . . . . . . . . . . . . . . . . 102 178 A.3 LKH Examples . . . . . . . . . . . . . . . . . . . . . . . 103 179 A.3.1 LKH Key Download Example . . . . . . . . . . . . . . . 103 180 A.3.2 LKH Rekey Event Example . . . . . . . . . . . . . . . 104 181 B APPENDIX B -- Change History (To Be Removed from RFC) 105 182 B.1 Changes from GSAKMP-00 to GSAKMP-01 February 2003 . . . . 105 183 B.2 Changes from GSAKMP-01 to GSAKMP-02 June 2003 . . . . . . 106 184 B.3 Changes from GSAKMP-02 to GSAKMP-03 August 2003 . . . . . 106 185 B.4 Changes from GSAKMP-03 to GSAKMP-04 October 2003 . . . . . 106 186 B.5 Changes from GSAKMP-04 to GSAKMP-05 February 2004 . . . . 111 187 B.5.1Major Modification/Reorganization of Specification . . 111 188 B.5.1.1Key Terms and Payloads Modified . . . . . . . . . 111 189 B.5.2Modification By Section . . . . . . . . . . . . . . . . 112 190 B.6 Changes from GSAKMP-05 to GSAKMP-06 May 2004 . . . . . . . 115 191 B.7 Changes from GSAKMP-06 to GSAKMP-07 December 2004 . . . . 120 192 B.8 Changes from GSAKMP-07 to GSAKMP-08 March 2005 . . . . . . 121 193 B.9 Changes from GSAKMP-08 to GSAKMP-09 April 2005 . . . . . . 121 194 B.10Changes from GSAKMP-09 to GSAKMP-10 May 2005 . . . . . . . 122 195 Authors' Addresses 122 196 Full Copyright Statement 123 197 IPR Considerations 123 198 List of Figures 199 1 GSAKMP Ladder Diagram . . . . . . . . . . . . . . . . . . . 31 200 2 GSAKMP Ladder Diagram with Cookies . . . . . . . . . . . . 39 201 3 GSAKMP Header Format . . . . . . . . . . . . . . . . . . . 49 202 4 GroupID UTF-8 Format . . . . . . . . . . . . . . . . . . . 52 203 5 GroupID Octet String Format . . . . . . . . . . . . . . . . 53 204 6 GroupID IPv4 Format . . . . . . . . . . . . . . . . . . . . 53 205 7 GroupID IPv6 Format . . . . . . . . . . . . . . . . . . . . 54 206 8 Generic Payload Header . . . . . . . . . . . . . . . . . . 56 207 9 Policy Token Payload Format . . . . . . . . . . . . . . . . 57 208 10 Key Download Payload Format . . . . . . . . . . . . . . . . 59 209 11 Key Download Data Item Format . . . . . . . . . . . . . . . 60 210 12 Key Datum Format . . . . . . . . . . . . . . . . . . . . . 62 211 13 Rekey Array Structure Format . . . . . . . . . . . . . . . 64 212 14 Rekey Event Payload Format . . . . . . . . . . . . . . . . 66 213 15 Rekey Event Header Format . . . . . . . . . . . . . . . . . 67 214 16 Rekey Event Data Format . . . . . . . . . . . . . . . . . . 68 215 17 Key Package Format . . . . . . . . . . . . . . . . . . . . 69 216 18 Identification Payload Format . . . . . . . . . . . . . . . 72 217 19 Unencoded Name (ID-U-NAME) Format . . . . . . . . . . . . . 75 218 20 Certificate Payload Format . . . . . . . . . . . . . . . . 77 219 21 Signature Payload Format . . . . . . . . . . . . . . . . . 79 220 22 Notification Payload Format . . . . . . . . . . . . . . . . 82 221 23 Notification Data - Acknowledge Payload Type Format . . . . 85 222 24 Notification Data - Mechanism Choices Payload Type Format . 86 223 25 Vendor ID Payload Format . . . . . . . . . . . . . . . . . 88 224 26 Key Creation Payload Format . . . . . . . . . . . . . . . . 90 225 27 Nonce Payload Format . . . . . . . . . . . . . . . . . . . 92 226 28 GSAKMP State Diagram . . . . . . . . . . . . . . . . . . . 94 227 29 A. 1: LKH Tree . . . . . . . . . . . . . . . . . . . . . 101 228 30 A. 2: GSAKMP LKH Tree . . . . . . . . . . . . . . . . . . 102 230 List of Tables 231 1 Request to Join (RTJ) Message Definition . . . . . . . . . 32 232 2 Key Download (KeyDL) Message Definition . . . . . . . . . . 33 233 3 Request to Join Error (RTJ-Err) Message Definition . . . . 35 234 4 Key Download - Ack/Failure (KeyDL-A/F) Message Definition . 36 235 5 Lack of Ack (LOA) Message Definition . . . . . . . . . . . 37 236 6 Cookie Download Message Definition . . . . . . . . . . . . 39 237 7 Rekey Event Message Definition . . . . . . . . . . . . . . 42 238 8 Request_to_Depart (RTD) Message Definition . . . . . . . . 44 239 9 Departure_Response (DR) Message Definition . . . . . . . . 45 240 10 Departure_ACK (DA) Message Definition . . . . . . . . . . . 46 241 11 Group Identification Types . . . . . . . . . . . . . . . . 49 242 12 Payload Types . . . . . . . . . . . . . . . . . . . . . . . 50 243 13 Exchange Types . . . . . . . . . . . . . . . . . . . . . . 51 244 14 Policy Token Types . . . . . . . . . . . . . . . . . . . . 58 245 15 Key Download Data Item Types . . . . . . . . . . . . . . . 61 246 16 Cryptographic Key Types . . . . . . . . . . . . . . . . . . 63 247 17 Rekey Event Types . . . . . . . . . . . . . . . . . . . . . 66 248 18 Identification Classification . . . . . . . . . . . . . . . 73 249 19 Identification Types . . . . . . . . . . . . . . . . . . . 74 250 20 Certificate Payload Types . . . . . . . . . . . . . . . . . 78 251 21 Signature Types . . . . . . . . . . . . . . . . . . . . . . 80 252 22 Notification Types . . . . . . . . . . . . . . . . . . . . 84 253 23 Acknowledgment Types . . . . . . . . . . . . . . . . . . . 85 254 24 Mechanism Types . . . . . . . . . . . . . . . . . . . . . . 86 255 25 Nonce Hash Types . . . . . . . . . . . . . . . . . . . . . 87 256 26 Types Of Key Creation Information . . . . . . . . . . . . . 91 257 27 Nonce Types . . . . . . . . . . . . . . . . . . . . . . . . 93 258 28 GSAKMP States . . . . . . . . . . . . . . . . . . . . . . . 95 259 29 State Transition Events . . . . . . . . . . . . . . . . . . 96 261 1 Overview 263 This protocol provides policy distribution, policy enforcement, 264 key distribution, and key management for cryptographic groups. 265 Cryptographic groups all share a common (set of) key(s) for data 266 processing. These keys all support a system level security policy 267 so that the cryptographic group can be trusted to perform security 268 relevant services. 270 The ability of a group of entities to perform security services 271 requires that a Group Secure Association (GSA) be established. A 272 GSA ensures that there is a common "group level" definition of 273 security policy and enforcement of that policy. The distribution of 274 cryptographic keys is a mechanism utilizing the group level policy 275 enforcements. 277 1.1 GSAKMP Overview 279 Protecting group information requires the definition of a security 280 policy and the enforcement of that policy by all participating 281 parties. Controlling dissemination of cryptographic key is the 282 primary mechanism to enforce the access control policy. It is the 283 primary purpose of GSAKMP to generate and disseminate a group key in 284 a secure fashion. 286 GSAKMP separates group security management functions and 287 responsibilities into three major roles: 1) Group Owner, 2) Group 288 Controller Key Server, and 3) Group Member. The Group Owner is 289 responsible for creating the security policy rules for a group 290 and expressing these in the Policy Token. The Group Controller 291 Key Server (GC/KS) is responsible for creating and maintaining 292 the keys and enforcing the group policy by granting access to 293 potential Group Members (GM) in accordance with the Policy Token. 294 To enforce a group's policy the potential Group Members need to have 295 knowledge of the access control policy for the group, an unambiguous 296 identification of any party downloading keys to them, and verifiable 297 chains of authority for key download. In other words, the Group 298 Members need to know who potentially will be in the group and to 299 verify that the key disseminator is authorized to act in that 300 capacity. 302 In order to establish a Group Secure Association (GSA) to support 303 these activities, the identity of each party in the process MUST be 304 unambiguously asserted and authenticated. It MUST also be verified 305 that each party is authorized, as defined by the Policy Token, to 306 function in his role in the protocol (e.g., GM or GC/KS). 308 The security features of the establishment protocol for the GSA 309 include 311 - Group policy identification 313 - Group policy dissemination 315 - GM to GC/KS SA establishment to protect data 317 - Access control checking 319 GSAKMP provides mechanisms for cryptographic group creation and 320 management. Other protocols may be used in conjunction with GSAKMP 321 to allow various applications to create functional groups according 322 to their application-specific requirements. For example, in a 323 small-scale video conference the organizer might use a session 324 invitation protocol like SIP [RFC 3261] to transmit information 325 about the time of the conference, the address of the session, and 326 the formats to be used. For a large-scale video transmission, the 327 organizer might use a multicast announcement protocol like SAP [RFC 328 2974]. 330 This document describes a useful default set of security algorithms 331 and configurations, Security Suite 1. This suite allows an entire 332 set of algorithms and settings to be described to prospective group 333 members in a concise manner. Other security suites MAY be defined as 334 needed and MAY be disseminated during the out-of-band announcement of 335 a group. 337 Distributed architectures support large scale cryptographic groups. 338 Secure distributed architectures require authorized delegation of GSA 339 actions to network resources. The fully specified Policy Token is 340 the mechanism to facilitate this authorization. Transmission of this 341 Policy Token to all joining GMs allows GSAKMP to securely support 342 distributed architectures and multiple data sources. 344 Many-to-many group communications require multiple data sources. 345 Multiple data sources are supported because the inclusion of a policy 346 token and policy payloads allow group members to review the group 347 access control and authorization parameters. This member review 348 process gives each member (each potential source of data), the 349 ability to determine if the group provides adequate protection for 350 member data. 352 1.2 Document Organization 354 The remainder of this document is organized as follows: Section 2 355 presents the terminology and concepts used to present the 356 requirements of this protocol. Section 3 outlines the security 357 considerations with respect to GSAKMP. Section 4 defines the 358 architecture of GSAKMP. Section 5 describes the group management 359 life-cycle. Section 6 describes the Security Suite Definition. 360 Section 7 presents the message types and formats used during each 361 phase of the life-cycle. Section 8 defines the state diagram for the 362 protocol. 364 2 Terminology 366 The following terminology is used throughout the GSAKMP paper. 368 Requirements Terminology: Keywords "MUST", "MUST NOT", "REQUIRED", 369 "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are 370 to be interpreted as described in [RFC 2119]. 372 Certificate: A data structure used to verifiably bind an identity 373 to a cryptographic key (e.g., X.509v3). 375 Compromise Recovery: The act of recovering a secure operating 376 state after detecting that a group member cannot be trusted. 377 This can be accomplished by rekey. 379 Cryptographic Group: A set of entities sharing or desiring to 380 share a GSA. 382 Group Controller Key Server (GC/KS): A group member with authority 383 to perform critical protocol actions including creating and 384 distributing keys and building and maintaining the rekey 385 structures. As the group evolves, it MAY become desirable to 386 have multiple controllers perform these functions. 388 Group Member (GM): A Group Member is any entity with access to 389 the group keys. Regardless of how a member becomes a part of 390 the group or how the group is structured, GMs will perform the 391 following actions: 393 - Authenticate and validate the identities and the 394 authorizations of entities performing security relevant 395 actions 397 - Accept group keys from the GC/KS 399 - Request group keys from the GC/KS 401 - Enforce the cooperative group policies as stated in the 402 group policy token 404 - Perform peer review of key management actions 406 - Manage local key 408 Group Owner (GO): A Group Owner is the entity authorized for 409 generating and modifying an authenticatable policy token for the 410 group, and notifying the GC/KS to start the group. 412 Group Policy: The Group Policy completely describes the protection 413 mechanisms and security relevant behaviors of the group. This 414 policy MUST be commonly understood and enforced by the group for 415 coherent secure operations. 417 Group Secure Association (GSA): A GSA is a logical association of 418 users or hosts that share cryptographic key(s). This group may 419 be established to support associations between applications or 420 communication protocols. 422 Group Traffic Protection Key (GTPK): The key or keys created for 423 protecting the group data. 425 Key Datum: A single key and its associated attributes for its 426 usage. 428 Key Encryption Key (KEK): Key used in an encryption mechanism for 429 wrapping another key. 431 Key Handle: The identifier of a particular instance or version of 432 a key. 434 Key ID: The identifier for a key that MUST stay static throughout 435 the life-cycle of this key. 437 Key Package: Type/Length/Data format containing a Key Datum. 439 Logical Key Hierarchy (LKH) Array: The group of keys created to 440 facilitate the LKH compromise recovery methodology. 442 Policy Token (PT): The policy token is a data structure used to 443 disseminate group policy and the mechanisms to enforce it. The 444 policy token is issued and signed by an authorized Group Owner. 445 Each member of the group MUST verify the token, meet the group 446 join policy, and enforce the policy of the group, (e.g., encrypt 447 application data with a specific algorithm). The group policy 448 token will contain a variety of information including: 450 - GSAKMP protocol version 451 - Key creation method 453 - Key dissemination policy 455 - Access control policy 457 - Group authorization policy 459 - Compromise recovery policy 461 - Data protection mechanisms 463 Rekey: The act of changing keys within a group as defined by 464 policy. 466 Rekey Array: The construct that contains all the rekey information 467 for a particular member. 469 Rekey Key: The KEK used to encrypt keys for a subset of the group. 471 Subordinate Group Controller Key Server (S-GC/KS): Any group member 472 having the appropriate processing and trust characteristics as 473 defined in the group policy that has the potential to act as a 474 S-GC/KS. This will allow the group processing and communication 475 requirements to be distributed equitably throughout the network 476 (e.g., distribute group key). The optional use of GSAKMP with 477 Subordinate Group Controller Key Servers will be documented in a 478 separate paper. 480 Wrapping KeyID: - The Key ID of the key used to wrap a Key Package. 482 Wrapping Key Handle: The key handle of the Key used to wrap the 483 Key Package. 485 3 Security Considerations 487 In addition to the specification of GSAKMP itself, the security of an 488 implemented GSAKMP system is affected by supporting factors. These 489 are discussed here. 491 3.1 Security Assumptions 493 The following assumptions are made as the basis for the security 494 discussion 495 1. GSAKMP assumes its supporting platform can provide the process 496 and data separation services at the appropriate assurance level 497 to support its groups. 499 2. The key generation function of the cryptographic engine will only 500 generate strong keys. 502 3. The security of this protocol is critically dependent on the 503 randomness of the randomly chosen parameters. These should be 504 generated by a strong random or properly seeded pseudo-random 505 source [RFC 1750]. 507 4. The security of a group can be affected by the accuracy of the 508 system clock. Therefore, GSAKMP assumes that the system clock 509 is close to correct time. If a GSAKMP host relies on a network 510 time service to set its local clock, then that protocol must 511 be secure against attackers. The maximum allowable clock skew 512 across the group membership: policy configurable, with a default 513 of 5 minutes. 515 5. As described in the message processing section, the use of the 516 Nonce value used for freshness along with a signature is the 517 mechanism used to foil replay attacks. In any use of Nonces 518 a core requirement is unpredictability of the nonce, from an 519 attackers viewpoint. The utility of the Nonce relies on the 520 inability of an attacker to either reuse old Nonces or predict 521 the Nonce value. 523 6. GSAKMP does not provide identity protection. 525 7. The group's multicast routing infrastructure is not secured 526 by GSAKMP, and therefore it may be possible to create a 527 multicast flooding denial of service attack using the multicast 528 application's data stream. Either an insider (i.e. a rogue GM) 529 or a non-member could direct the multicast routers to spray data 530 at a victim system. 532 8. The compromise of a S-GC/KS forces the re-registration of all GMs 533 under its control. The GM recognizes this situation by finding 534 the S-GC/KSs certificate on a CRL as supplied by a service such 535 as LDAP. 537 9. The compromise of the GO forces termination of the group. The 538 GM recognizes this situation by finding the GOs certificate on a 539 Certificate Revocation List (CRL) as supplied by a service such 540 as LDAP. 542 3.2 Related Protocols 544 GSAKMP derives from two (2) existing protocols: ISAKMP [MSST98] and 545 FIPS Pub 196 [FIPS 196]. In accordance with Security Suite 1, GSAKMP 546 implementations MUST support the use of Diffie-Hellman key exchange 547 [DH77] for two party key creation and MAY use Logical Key Hierarchy 548 (LKH) [RFC 2627] for rekey capability. 550 3.2.1 ISAKMP 552 ISAKMP provides a flexible structure of chained payloads in support 553 of authenticated key exchange and security association management 554 for pairwise communications. GSAKMP builds upon these features 555 to provide policy enforcement features in support of diverse group 556 communications. 558 3.2.2 FIPS Pub 196 560 FIPS Pub 196 provides a mutual authentication protocol. 562 3.2.3 LKH 564 When group policy dictates that a recovery of the group security 565 is necessary after the discovery of the compromise of a GM, then 566 GSAKMP relies upon a rekey capability, i.e., LKH, to enable group 567 recovery after a compromise [RFC 2627]. This is optional since in 568 many instances it may be better to destroy the compromised group and 569 rebuild a secure group. 571 3.2.4 Diffie-Hellman 573 A Group may rely upon two party key creation mechanisms, i.e., 574 Diffie-Hellman, to protect sensitive data during download. 576 The information in this section is borrowed heavily from [IKEv2] as 577 this protocol has already worked through similar issues and GSAKMP 578 is using the same security considerations for its purposes. This 579 section will contain paraphrased sections of [IKEv2] modified for 580 GSAKMP as appropriate. 582 The strength of a key derived from a Diffie-Hellman exchange using 583 specific p and g values depends on the inherent strength of the 584 values, the size of the exponent used, and the entropy provided by 585 the random number generator used. A strong random number generator 586 combined with the recommendations from [RFC 3526] on Diffie-Hellman 587 exponent size is recommended as sufficient. An implementation should 588 make note of this conservative estimate when establishing policy and 589 negotiating security parameters. 591 Note that these limitations are on the Diffie-Hellman values 592 themselves. There is nothing in GSAKMP which prohibits using 593 stronger values nor is there anything which will dilute the strength 594 obtained from stronger values. In fact, the extensible framework of 595 GSAKMP encourages the definition of more Security Suites. 597 It is assumed that the Diffie-Hellman exponents in this exchange 598 are erased from memory after use. In particular, these exponents 599 MUST NOT be derived from long-lived secrets such as the seed to a 600 pseudo-random generator that is not erased after use. 602 3.3 Denial of Service (DoS) Attack 604 This GSAKMP specification addresses the mitigation for a distributed 605 IP spoofing attack (a subset of possible DoS attacks) in section 606 5.2.2, Cookies. 608 3.4 Rekey Availability 610 In addition to GSAKMP having the capability to do rekey operations, 611 GSAKMP MUST also have the capability to make this rekey information 612 highly available to GMs. The necessity of GMs receiving rekey 613 messages, requires the use of methods to increase the likelihood 614 of receipt of Rekey Messages. These methods MAY include multiple 615 transmissions of the rekey message, posting of the rekey message on 616 a bulletin board, etc. Compliant GSAKMP implementations supporting 617 the optional rekey capability MUST support retransmission of rekey 618 messages. 620 3.5 Proof of Trust Hierarchy 622 As defined by [HCM], security group policy MUST be defined in a 623 verifiable manner. GSAKMP anchors its trust in the creator of the 624 group, the GO. 626 The Policy Token explicitly defines all the parameters that create a 627 secure verifiable infrastructure. The GSAKMP Policy Token is issued 628 and signed by the GO. The GC/KS will verify it and grant access to 629 GMs only if they meet the rules of the Policy Token. The new GMs 630 will accept access only if 1) the token verifies, 2) the GC/KS is an 631 authorized disseminator, and 3) the group mechanisms are acceptable 632 for protecting the GMs data. 634 4 Architecture 636 This architecture presents a trust model for GSAKMP and a concept of 637 operations for establishing a trusted distributed infrastructure for 638 group key and policy distribution. 640 GSAKMP conforms to the IETF MSEC architectural concepts as specified 641 in the MSEC Architecture document [RFC 3740]. GSAKMP uses the MSEC 642 components to create a trust model for operations that implement the 643 security principles of mutual suspicion and trusted policy creation 644 authorities. 646 4.1 Trust Model 648 4.1.1 Components 650 The trust model contains four key components: 652 - Group Owners (GO), 654 - Group Controllers / Key Servers (GC/KS), 656 - Subordinate GC/KS (S-GC/KS), and 658 - Group Members (GM). 660 The goal of the GSAKMP trust model is to derive trust from a common 661 trusted policy creation authority for a group. All security 662 relevant decisions and actions implemented by GSAKMP are based on 663 information that ultimately is traceable to and verified by the 664 trusted policy creation authority. There are two trusted policy 665 creation authorities for GSAKMP, the GO (policy creation authority) 666 and the PKI root that allows us to verify the GO. 668 4.1.2 GO 670 The GO is the policy creation authority for the group. The GO has a 671 well defined identity that is relevant to the group. That identity 672 can be of a person or of a group trusted component. All potential 673 entities in the group have to recognize the GO as the individual with 674 authority to specify policy for the group. 676 The policy reflects the protection requirements of the data in a 677 group. Ultimately, the data and the application environment drives 678 the security policy for the group. 680 The GO has to determine the security rules and mechanisms that are 681 appropriate for the data being protected by the group keys. All this 682 information is captured in a policy token (PT). The GO creates the PT 683 and signs it. 685 4.1.3 GC/KS 687 The GC/KS is authorized to perform several functions: key creation, 688 key distribution, rekey, and group membership management. 690 As key creation authority, the GC/KS will create the set of keys for 691 the group. These keys include the Group Traffic Protection Keys 692 (GTPK) and first tier rekey keys. There may be second tier rekey 693 trees if a distributed rekey management structure is required for the 694 group. 696 As the key distribution (registration) authority, it has to notify 697 the group of its location for registration services. The GC/KS will 698 have to enforce key access control as part of the key distribution 699 and registration processes. 701 As the group rekey authority, it performs rekey in order to change 702 the group's GTPK. Change of the GTPK limits the exposure of data 703 encrypted with any single GTPK. 705 Finally, as group membership management authority, the GC/KS can 706 manage the group membership (registration, eviction, de-registration, 707 etc.). This may be done in part by using key tree approaches such as 708 Logical Key Hierarchies (LKH), as an optional approach. 710 4.1.4 Subordinate GC/KS 712 A subordinate GC/KS is used to distribute the GC/KS functionality 713 across multiple entities. The S-GC/KS will have all the authorities 714 of the GC/KS except one: it will not create the GTPK. It is assumed 715 here that the group will transmit data with a single GTPK at any one 716 time. This GTPK comes from the GC/KS. 718 Note that relative to the GC/KS, the S-GC/KS is responsible for 719 an additional security check: the S-GC/KS must register as a 720 member with the GC/KS, and during that process it has to verify the 721 authority of the GC/KS. 723 4.1.5 GM 725 The GM has two jobs - make sure all security relevant actions are 726 authorized and properly use the group keys. During the registration 727 process, the GM will verify that the PT is signed by a recognized GO. 728 In addition, it will verify that the GC/KS or S-GC/KS engaged in the 729 registration process is authorized, as specified in the PT. If rekey 730 and new PTs are distributed to the group, the GM will verify that 731 they are proper and all actions are authorized. 733 The GM is granted access to group data through receipt of the group 734 keys This carries along with it a responsibility to protect the key 735 from unauthorized disclosure. 737 GSAKMP does not offer any enforcement mechanisms to control which 738 GM are multicast speakers at a given moment. This policy and its 739 enforcement depend on the multicast application and its protocols. 740 However, GSAKMP does allow a group to have one of three Group 741 Security Association multicast speaker configurations: 743 - There is a single GM authorized to be the group's speaker. There 744 is one multicast application SA allocated by the GO in support 745 of that speaker. The PT initializes this multicast application 746 SA and identifies the GM that has been authorized to be speaker. 747 All GM share a single TPK with that GM speaker. Sequence number 748 checking for anti-replay protection is feasible and enabled 749 by default. This is the default group configuration. GSAKMP 750 implementations MUST support this configuration. 752 - The GO authorizes all of the GM to be a group speaker. The 753 GO allocates one multicast application SA in support of these 754 speakers. The PT initializes this multicast application SA and 755 indicates that any GM can be a speaker. All of the GM share 756 a single TPK and other SA state information. Consequently, 757 some SA security features such as sequence number checking 758 for anti-replay protection can not be supported by this 759 configuration. GSAKMP implementations MUST support this group 760 configuration. 762 - The GO authorizes a subset of the GM to be a group speaker 763 (which may be the subset comprised of all GM). The GO allocates 764 a distinct multicast application SA for each of these speakers. 765 The PT identifies the authorized speakers, and initializes 766 each of their multicast application Security Associations. 767 The speakers still share a common TPK across their SA, but 768 each speaker has a separate SA state information instance 769 at every peer GM. Consequently, this configuration supports 770 SA security features such as sequence number checking for 771 anti-replay protection or source authentication mechanisms that 772 require per speaker state at the receiver. The drawback of 773 this configuration is that it does not scale to a large numbers 774 of speakers. GSAKMP implementations MAY support this group 775 configuration. 777 4.1.6 Assumptions 779 The assumptions for this trust model are: 781 - the GCKS is assumed to be never compromised, 783 - the GO is assumed to be never compromised, 785 - the PKI, subject to certificate validation, is assumed to be 786 trustworthy, 788 - The GO is capable of creating a security policy to meet the 789 demands of the group, 791 - the compromises of a group member will be detectable and reported 792 to the GO in a trusted manner, 794 - the subsequent recovery from a compromise will deny inappropriate 795 access to protected data to the compromised member, 797 - no security relevant actions depend on a precise network time, 799 - that there is confidentiality, integrity, multicast source 800 authentication and anti-replay protection mechanisms for all 801 GSAKMP control messages. 803 4.2 Rule-Based Security Policy 805 The trust model for GSAKMP revolves around the definition and 806 enforcement of the security policy. In fact, the use of the key is 807 only relevant, in a security sense, if it represents the successful 808 enforcement of the group security policy. 810 Group operations lend themselves to rule-based security policy. The 811 need for distribution of data to many endpoints often leads to the 812 defining of those authorized endpoints based on rules. For example, 813 all IETF attendees at a given conference could be defined as a single 814 group. 816 If the security policy rules are to be relevant, they must be coupled 817 with validation mechanisms. The core principle here is that the 818 level of trust one can afford a security policy is exactly equal to 819 the level of trust one has in the validation mechanism used to prove 820 that policy. For example, if all IETF attendees are allowed in then 821 they could register their identity from their certificate upon check 822 in to the meetings. That certificate is issued by a trusted policy 823 creation authority (PKI root) that is authorized to identify someone 824 as being an IETF attendee. The GO could make admittance rules to 825 the IETF group based on the identity certificates issued from trusted 826 PKIs. 828 In GSAKMP, every security policy rule is coupled with an explicit 829 validation mechanism. For interoperability considerations, GSAKMP 830 requires its supporting PKI implementations MUST be compliant to RFC 831 3280. 833 If a GM public key certificate is revoked, then the entity that 834 issues that revocation SHOULD signal the GO, so that the GO can 835 expel that GM. The method that signals this event to the GO is not 836 standardized by this specification. 838 A direct mapping of rule to validation mechanism allows the use of 839 multiple rules and PKIs to create groups. This allows a GO to define 840 a group security policy that spans multiple PKI domains, each with 841 their own Certificate Authority public key certificate. 843 4.2.1 Access Control 845 The access control policy for the group keys is equivalent to the 846 access control policy for the multicast application data the keys are 847 protecting. 849 In a group, each data source is responsible for ensuring that the 850 access to the source's data is appropriate. This implies that every 851 data source should have knowledge of the access control policy for 852 the group keys. 854 In the general case, GSAKMP offers a suite of security services to 855 its applications, and does not prescribe how they use those services. 857 GSAKMP supports the creation of GSAs with multiple data sources. It 858 also supports architectures where the GC/KS is not itself a data 859 source. In the multiple data source architectures GSAKMP requires 860 that the access control policy is precisely defined and distributed 861 to each data source. The reference for this data structure is the 862 GSAKMP Policy Token [ref CH02]. 864 4.2.2 Authorizations for security relevant actions 866 A critical aspect of the GSAKMP trust model is the authorization 867 of security relevant actions. Security relevant actions include - 868 download of group key, rekey, and PT creation and updates. These 869 actions could be used to disrupt the secure group and all entities 870 in the group must verify that they were instigated by authorized 871 entities within the group. 873 4.3 Distributed Operation 875 Scalability is a core feature of GSAKMP. GSAKMP's approach to 876 scalable operations is the establishment of S-GC/KSs. This allows 877 the GSAKMP systems to distribute the workload of setting up and 878 managing very large groups. 880 Another aspect of distributed S-GC/KS operations is the enabling of 881 local management authorities. In very large groups, subordinate 882 enclaves may be best suited to provide local management of the 883 enclaves' group membership, due to a direct knowledge of the group 884 members. 886 One of the critical issues involved with distributed operation is the 887 discovery of the security infrastructure location and security suite. 888 Many group applications that have dynamic interactions must "find" 889 each other to operate. The discovery of the security infrastructure 890 is just another piece of information that has to be known by the 891 group in order to operate securely. 893 There are several methods for infrastructure discovery: 895 - Announcements 897 - Anycast 899 - Rendezvous points / Registration 901 One method for distributing the security infrastructure location 902 is to use announcements. The SAP is commonly used to announce 903 the existence of a new multicast application or service. If an 904 application uses SAP[Ref RFC 2974] to announce the existence of a 905 service on a multicast channel, that service could be extended to 906 include the security infrastructure location for a particular group. 908 Announcements can also be used by GSAKMP in one of two modes - 909 Expanding Ring Searches (ERS) of security infrastructure and 910 expanding ring searches for infrastructure discovery. In either 911 case, the GSAKMP would use a multicast broadcast that would slowly 912 increase in its range by incremental multicast hops. The multicast 913 source controls the packet's multicast range by explicitly setting 914 its Time To Live count. 916 An expanding ring announcement operates by the GC/KS announcing 917 its existence for a particular group. The number of hops this 918 announcement would travel would be a locally configured number. The 919 GMs would listen on a well know multicast address for GC/KSs that 920 provide service for groups of interest. If multiple GC/KSs are found 921 that provide service, then the GM would pick the closest one (in 922 terms of multicast hops). The GM would then send a GSAKMP Request 923 to Join message (RTJ) to the announced GC/KS. If the announcement 924 is found to be spurious then that is reported to the appropriate 925 management authorities. The ERA concept is slightly different from 926 SAP in that it could occur over the data channel multicast address, 927 instead of a special multicast address dedicated for the SAP service. 929 An expanding ring search operates in the reverse order than the ERA. 930 In this case, the GM is the announcing entity. The (S-)GC/KSs listen 931 for the requests for service, specifically the RTJ. The (S-)GC/KS 932 responds to the RTJ. . If the GM receives more than one response, 933 it would either ignore the responses or send NACKs based on local 934 configuration. 936 Anycast is a service that is very similar to ERS. It also can be used 937 to provide connection to the security infrastructure. In this case, 938 the GM would send the RTJ to a well-known service request address. 939 This anycast service would route the RTJ to an appropriate GC/KS. 940 The anycast service would have security infrastructure and network 941 connectivity knowledge to facilitate this connection. 943 Registration points can be used to distribute many group relevant 944 data, including security infrastructure. Many group applications 945 rely on well known registration points to advertise the availability 946 of groups. There is no reason that GSAKMP could not use the same 947 approach for advertising the existence and location of the security 948 infrastructure. This is a simple process if the application being 949 supported already supports registration. The GSAKMP infrastructure 950 can always provide a registration site if the existence of this 951 security infrastructure discovery hub is needed. The registration 952 of S-GC/KSs at this site could be an efficient way to allow GM 953 registration. 955 GSAKMP infrastructure discovery can use whatever mechanism suits a 956 particular multicast application's requirements, including mechanisms 957 that have not been discussed by this architecture. However, GSAKMP 958 infrastructure discovery is not standardized by this version of the 959 GSAKMP specification. 961 4.4 Concept of Operation 963 This concept of operation shows how the different roles in GSAKMP 964 interact to set up a secure group. This particular concept of 965 operation focuses on a secure group that utilizes the distributed key 966 dissemination services of the S-GC/KS. 968 4.4.1 Assumptions 970 The most basic assumption here is one or more trustworthy PKI for the 971 group. That trusted PKI will be used to create and verify security 972 policy rules. 974 There is a GO that all GMs recognize as having group policy creation 975 authority. All GM must be securely pre-configured to know the GO 976 public key. 978 All GMs have access to the GO PKI information, both the trusted 979 anchor public keys and the certificate path validation rules. 981 There is sufficient connectivity between the GSAKMP entities. 983 - The registration SA requires that GM can connect to the GC/KS or 984 S-GC/KS using either TCP or UDP. 986 - The rekey SA requires that the data layer multicast communication 987 service be available. This can be multicast IP, overlay networks 988 using TCP, or NAT tunnels. 990 - GSAKMP can support many different data layer secure applications 991 each with unique connectivity requirements. 993 4.4.2 Creation of a Policy Token 995 The GO creates and signs the Policy Token for a group. The policy 996 token contains the rules for access control and authorizations for a 997 particular group. 999 The PT consists of the following information: 1001 - Identification - this allows an unambiguous identification of the 1002 PT and the group, 1004 - Access Control Rules - these rules specify who can have access to 1005 the group keys, 1007 - Authorization Rules - these rules specify who can be a S-GC/KS, 1009 - Mechanisms - these rules specify the security mechanisms that 1010 will be used by the group, this is necessary to ensure there 1011 is no weak link in the group security profile, for example, for 1012 IPsec, this could include SPD/SAD configuration data, 1014 - Source authentication of the PT to the GO - the PT is a CMS 1015 signed object and this allows all GMs to verify the PT. 1017 4.4.3 Creation of a Group 1019 The PT is sent to a potential GC/KS. This can occur in several ways, 1020 and the method of transmittal is outside the scope of GSAKMP. The 1021 potential GC/KS will verify the GO signature on the PT to ensure that 1022 it comes from a trusted GO. Next, the GC/KS will verify that it is 1023 authorized to become the GC/KS, based on the authorization rules in 1024 the PT. Assuming that the GC/KS trusts the PT, is authorized to be a 1025 GC/KS, and is locally configured to become a GC/KS for a given group 1026 and the GO, then the GC/KS will create the keys necessary to start 1027 the group. The GC/KS will take whatever action is necessary (if any) 1028 to advertise its ability to distribute key for the group. The GC/KS 1029 will then listen for RTJs. 1031 The PT has a sequence number. Every time a PT is distributed to 1032 the group the group members verify that the sequence number on the 1033 PT is increasing. The PT lifetime is not limited to a particular 1034 time interval, other than by the lifetimes imposed by some of its 1035 attributes (e.g. signature key lifetime). The current PT sequence 1036 number is downloaded to the GM in the "Key Download" message. Also, 1037 to avoid replay attacks, this sequence number is never reset to a 1038 lower value (i.e. rollover to zero) as long as the group identifier 1039 remains valid and in use. The GO MUST preserve this sequence number 1040 across re-boots. 1042 4.4.4 Discovery of GC/KS 1044 Potential GMs will receive notice of the new group via some 1045 mechanism: announcement, Anycast, registration look-up. The GM will 1046 send an RTJ to the GC/KS. 1048 4.4.5 GC/KS registration policy enforcement 1050 The GC/KS may or may not require cookies, depending on Denial of 1051 Service environment and the local configuration. 1053 Once the RTJ has been received, the GC/KS will verify that the 1054 GM is allowed to have access to the group keys. The GC/KS will 1055 then verify the signature on the RTJ to ensure it was sent by the 1056 claimed identity. If the checks succeed, the GC/KS will ready a Key 1057 Download message for the GM. If not the GC/KS can notify the GM of a 1058 non-security relevant problem. 1060 4.4.6 GM registration policy enforcement 1062 Upon receipt of the Key Download message, the GM will verify the 1063 signature on the message. Then the GM will retrieve the PT from the 1064 Key Download message and verify that the GO created and signed the 1065 PT. Once the PT is verified as valid, the GM will verify that the 1066 GC/KS is authorized to distribute key for this group. Then the GM 1067 will verify that the mechanisms used in the group are available and 1068 acceptable for protection of the GMs data (assuming the GM is a data 1069 source). The GM will then accept membership in this group. 1071 The GM will then check to see if it is allowed to be a S-GC/KS for 1072 this group. If the GM is allowed to be a S-GC/KS AND the local 1073 GM configuration allows the GM to act as a S-GC/KS for this group, 1074 then the GM changes its operating state to S-GC/KS. The GO needs to 1075 assign the authority to become a S-GC/KS in a manner that supports 1076 the overall group integrity and operations. 1078 4.4.7 Autonomous Distributed GSAKMP Operations 1080 In autonomous mode, each S-GC/KS operates a largely self-contained 1081 sub-group for which the Primary-GC/KS delegates the sub-group's 1082 membership management responsibility to the S-GC/KS. In general, 1083 the S-GC/KS locally handles each Group Member's registration and 1084 de- registration without any interaction with the Primary-GC/KS. 1085 Periodically, the Primary-GC/KS multicasts a Re-Key Event message 1086 addressed only to its one or more S-GC/KS. 1088 After a S-GC/KS successfully processes a Rekey Event message from the 1089 Primary-GC/KS, the S-GC/KS transmits to its sub-group its own Rekey 1090 Event message containing a copy of the group's new GTPK and policy 1091 token. The S-GC/KS encrypts its Rekey Event message's sub-group key 1092 management information using Logical Key Hierarchy or a comparable 1093 re-key protocol. The S-GC/KS uses the re-key protocol to realize 1094 forward and backward secrecy, such that only the authorized sub-group 1095 members can decrypt and acquire access to the new GTPK and policy 1096 token. The frequency at which the Primary-GC/KS transmits a Re-Key 1097 Event message is a policy token parameter. 1099 For the special case of a S-GC/KS detecting an expelled or 1100 compromised group member, there is a mechanism defined to trigger 1101 an immediate group re-key rather than waiting for the group's re-key 1102 period to elapse. See below for details. 1104 Each S-GC/KS will be registered by the GC/KS as a management node 1105 with responsibility for GTPK distribution, access control policy 1106 enforcement, LKH tree creation and distribution of LKH key arrays. 1107 The S-GC/KS will be registered into the primary LKH tree as an 1108 endpoint. Each S-GC/KS will hold an entire LKH key array for the 1109 GC's LKH key tree. 1111 For the purpose of clarity the process of creating a distributed 1112 GSAKMP group will be explained in chronological order. 1114 First, the Group Owner will create a policy token that authorizes a 1115 subset of the group's membership to assume the role of S-GC/KS. 1117 The GO needs to ensure that the S-GC/KS rules in the policy token 1118 will be stringent enough to ensure trust in the S-GC/KSs. This 1119 policy token is handed off to the primary GC. 1121 The GC will create the GTPK and initial LKH key tree. The GC will 1122 then wait for a potential S-GC/KS to send a Request to Join (RTJ) 1123 message. 1125 A potential S-GC/KS will eventually send an RTJ. The GC will enforce 1126 the access control policy as defined in the policy token. The 1127 S-GC/KS will accept the role of S-GC/KS and create its own LKH key 1128 tree for its sub-group membership. 1130 The S-GC/KS will then offer registration services for the group. 1131 There are local management decisions that are optional to control 1132 the scope of group members that can be served by a S-GC/KS. These 1133 are truly local management issues that allow the administrators of an 1134 S-GC/KS to restrict service to potential GMs. These local controls 1135 do not effect the overall group security policy, as defined in the 1136 Policy Token. 1138 A potential Group Member will send an RTJ to the S-GC/KS. The S- 1139 GC/KS will enforce the entire access control policy as defined in 1140 the PT. The GM will receive an LKH key array that corresponds to the 1141 LKH tree of the S-GC/KS. The key tree generated by the S-GC/KS is 1142 independent of the key tree generated by the GC/KS., they share no 1143 common keys. 1145 The GM then has the keys it needs to receive group traffic and be 1146 subject to rekey from the S-GC/KS. For the sake of this discussion 1147 let's assume the GM is to be expelled from the group membership. 1149 The S-GC/KS will receive notification that the GM is to be expelled. 1150 This mechanism is outside the scope of this protocol. 1152 Upon notification that a GM that holds a key array within its 1153 LKH tree is to be expelled the S-GC/KS does two things. First 1154 the S-GC/KS initiates a de-registration exchange with the GC/KS 1155 identifying the member to be expelled. (The S-GC/KS proxies a Group 1156 Member's de- registration informing the GC/KS that the Group Member 1157 has been expelled from the group.) Second, the S-GC/KS will wait for 1158 a rekey action by the GC/KS. The immediacy of the rekey action by the 1159 GC/KS is a management decision at the GC/KS. Security is served best 1160 by quick expulsion of untrusted members. 1162 Upon receipt of the de-registration notification from the S-GC/KS the 1163 GC/KS will register the member to be expelled. The GC/KS will then 1164 follow group procedure for initiating a rekey action (outside the 1165 scope of this protocol). The GC/KS will communicate to the GO the 1166 expelled members information (outside the scope of this protocol). 1167 With this information, the GO will create a new PT for the group with 1168 the expelled GM identity added to the excluded list in the groups 1169 access control rules. The GO provides this new PT to the GC/KS for 1170 distribution with the Rekey Event Message. 1172 The GC/KS will send out a rekey operation with a new PT. The S- GC/KS 1173 will receive the rekey and process it. At the same time, all other 1174 S-GC/KSs will receive the rekey and note the excluded GM identity. 1175 All S-GC/KSs will review local identities to ensure that the excluded 1176 GM is not a local member. If it is, then the S-GC/KS will create 1177 a rekey message. The S-GC/KSs must always create a rekey message, 1178 whether the expelled Group Member is a member of their subtrees or 1179 not. 1181 The S-GC/KS will then create a local rekey message. The S-GC/KS 1182 will send the wrapped Group TPK to all members of its local LKH tree, 1183 except the excluded member(s). 1185 5 Group Life Cycle 1187 The management of a cryptographic group follows a life-cycle: 1188 group definition, group establishment, and security relevant group 1189 maintenance. Group definition involves defining the parameters 1190 necessary to support a secure group, including its policy token. 1191 Group establishment is the process of granting access to new members. 1192 Security relevant group maintenance messages include rekey, policy 1193 changes member deletions, and group destruction. Each of these 1194 life-cycle phases is discussed in the following sections. 1196 The use and processing of the optional Vendor ID payload for all 1197 messages can be found in Section 7.10. 1199 5.1 Group Definition 1201 A cryptographic group is established to support secure communications 1202 among a group of individuals. The activities necessary to create a 1203 Policy Token in support of a cryptographic group include 1205 - Determine Access Policy - identify the entities that are 1206 authorized to receive the group key. 1208 - Determine Authorization Policy - identify which entities are 1209 authorized to perform security relevant actions, including key 1210 dissemination, policy creation, and initiation of security 1211 management actions. 1213 - Determine Mechanisms - define the algorithms and protocols used 1214 by GSAKMP to secure the group. 1216 - Create Group Policy Token - format the policies and mechanisms 1217 into a Policy Token and apply the GO signature. 1219 5.2 Group Establishment 1221 GSAKMP Group Establishment consists of three mandatory-to-implement 1222 messages, the Request to Join, the Key Download, and the Key Download 1223 Ack/Failure. The exchange may also include two OPTIONAL error 1224 messages, the Request to Join Error and the Lack_of_Ack messages. 1225 Operation using the mandatory messages only is referred to as "Terse 1226 Mode", while inclusion of the error messaging is referred to as 1227 "Verbose Mode". GSAKMP implementations MUST support Terse Mode 1228 and MAY support Verbose Mode. Group Establishment is discussed in 1229 Section 5.2.1. 1231 A group is set in Terse or Verbose mode by a policy token parameter. 1232 All (S-)GC/KSs in a Verbose mode group MUST support Verbose mode. 1233 GSAKMP allows Verbose mode groups to have GMs that do not support 1234 Verbose mode. Candidate GMs that do not support Verbose mode and 1235 receive a RTJ-Error or Lack-of-Ack message must handle these messages 1236 gracefully. Additionally, a GM will not know a prior that it is 1237 interacting with the (S)-GC/KS in Verbose or Terse mode until the 1238 Policy Token is received. 1240 For Denial of Service protection, a Cookie Exchange MAY precede the 1241 Group Establishment exchange. The Cookie Exchange is described in 1242 Section 5.2.2. 1244 Regardless of mode, any error message sent between component members 1245 indicates the first error encountered while processing the message. 1247 5.2.1 Standard Group Establishment 1249 After the out-of-band receipt of a Policy Token, a potential Group 1250 Controller Key Server (GC/KS) verifies the token and its eligibility 1251 to perform GC/KS functionality. It is then permitted to create any 1252 needed group keys and begin to establish the group. 1254 The GSAKMP Ladder Diagram, Figure 1, is presented to illustrate the 1255 process of establishing a cryptographic group. The left side of the 1256 diagram represents the actions of the GC/KS. The right side of the 1257 diagram represents the actions of the GMs. The components of each 1258 message shown in the diagram are presented in sections 5.2.1.1 - 1259 5.2.1.5. 1261 The Request to Join message is sent from a potential GM to the 1262 GC/KS to request admission to the cryptographic group. The message 1263 contains key creation material, freshness data, an optional selection 1264 of mechanisms, and the signature of the GM. 1266 The Key Download message is sent from the GC/KS to the GM in response 1267 to an accepted Request to Join. This GC/KS-signed message contains 1268 the identifier of the GM, freshness data, key creation material, 1269 encrypted keys, and the encrypted Policy Token. The Policy Token 1270 is used to facilitate well-ordered group creation and MUST include 1271 the group's identification, group permissions, group join policy, 1272 group controller key server identity, group management information, 1273 and digital signature of the GO. This will allow the GM to determine 1274 whether group policy is compatible with local policy. 1276 The Request to Join Error message is sent from the GC/KS to the 1277 GM in response to an unaccepted Request to Join. This message 1278 CONTROLLER Mandatory/ MESSAGE MEMBER 1279 Optional 1280 !<-M----------Request to Join-------------! 1281 ! ! 1282 ! ! 1283 !--M----------Key Download--------------->! 1284 ! ! 1285 !--O-------Request to Join Error--------->! or 1286 ! ! 1287 !<-M----Key Download - Ack/Failure--------! 1288 ! ! 1289 ! ! 1290 !--O------Lack of Acknowledgment--------->! 1291 ! ! 1292 !<=======SHARED KEYED GROUP SESSION======>! 1294 Figure 1: GSAKMP Ladder Diagram 1296 is not signed by the GC/KS for two reasons: 1) The GM, at this 1297 point, has no knowledge of who is authorized to act as a GC/KS 1298 and so the signature would thus be meaningless to the GM, and 2) 1299 Signing responses to denied join requests would provide a denial 1300 of service potential. The message contains an indication of the 1301 error condition. The possible values for this error condition 1302 are: Invalid-Payload-Type, Invalid-Version, Invalid-Group-ID, 1303 Invalid-Sequence-ID, Payload-Malformed, Invalid-ID-Information, 1304 Invalid-Certificate, Cert-Type-Unsupported, Invalid-Cert-Authority, 1305 Authentication-Failed, Certificate-Unavailable, 1306 Unauthorized-Request, Prohibited-by-Group-Policy, and 1307 Prohibited-by-Locally-Configured-Policy. 1309 The Key Download Ack/Failure message indicates Key Download receipt 1310 status at the GM. It is a GM-signed message containing freshness data 1311 and status. 1313 The Lack_of_Ack message is sent from the GC/KS to the GM in response 1314 to an invalid or absent Key Download Ack/Failure message. The signed 1315 message contains freshness and status data and is used to warn the 1316 GM of impending eviction from the group if a valid Key Download 1317 Ack/Failure is not sent. Eviction means that the member will be 1318 excluded from the group after the next Rekey Event. The policy of 1319 when a particular group needs to rekey itself is stated in the Policy 1320 Token. Eviction is discussed further in Section 5.3.2.1. 1322 For the following message structure sections, details about payload 1323 format and processing can be found in Section 7. Each message is 1324 identified by its exchange type in the header of the message. Nonces 1325 MUST be present in the messages unless synchronization time is 1326 available to the system. 1328 5.2.1.1 Request to Join 1330 The exchange type for Request to Join is eight (8). 1332 The components of a Request to Join Message are shown in Table 1. 1334 Table 1: Request to Join (RTJ) Message Definition 1336 Message Name : Request to Join (RTJ) 1337 Dissection : {HDR-GrpID, Key Creation, Nonce_I, [VendorID], 1338 : [Notif_Mechanism_Choices], [Notif_Cookie], 1339 : [Notif_IPValue]} SigM, [Cert] 1340 Payload Types : GSAKMP Header, Key Creation, [Nonce], [Vendor 1341 ID], Signature, [Certificate], [Notifications] 1343 SigM : Signature of Group Member 1344 Cert : Necessary Certificates, zero or more 1345 {}SigX : Indicates fields used in Signature 1346 [] : Indicate an optional data item 1348 As shown by Figure 1, a potential GM MUST generate and send an RTJ 1349 message to request permission to join the group. At a minimum, 1350 the GM MUST be able to manually configure the destination for the 1351 RTJ. As defined in the dissection of the RTJ message, this message 1352 MUST contain a Key Creation payload for KEK determination. A Nonce 1353 payload MUST be included for freshness and the Nonce_I value MUST be 1354 saved for potential later use. Only if the Policy Token for this 1355 group defines the use of nonces versus synchronization time, will 1356 the GC/KS use this supplied nonce. An OPTIONAL Notification payload 1357 of type Mechanism Choices MAY be included to identify the mechanisms 1358 the GM wants to use. Absence of this payload will cause the GC/KS to 1359 select appropriate default Policy Token specified mechanisms for the 1360 Key Download. 1362 In response, the GC/KS accepts or denies the request based on local 1363 configuration. indicates the GC/KS actions that will 1364 determine if the RTJ will be acted upon. The following checks SHOULD 1365 be performed in the order presented. 1367 In this procedure, the GC/KS MUST verify that the message header is 1368 properly formed and confirm that this message is for this group by 1369 checking the value of the GroupID. If the header checks pass, then 1370 the identity of the sender is extracted from the Signature payload. 1371 This identity MUST be used to perform access control checks, find 1372 the GMs credentials (e.g. certificate) for message verification, 1373 and MUST also be used in the Key Download message. Then the GC/KS 1374 will verify the signature on the message to ensure its authenticity. 1375 The GC/KS MUST use verified and trusted authentication material 1376 from a known root. If the message signature verifies, the GC/KS 1377 then confirms that all required payloads are present and properly 1378 formatted based upon the mechanisms announced and/or requested. If 1379 all checks pass, the GC/KS will create and send the Key Download 1380 message as described in section 5.2.1.2. 1382 If the GM receives no response to the RTJ within the GM's locally 1383 configured timeout value, the GM SHOULD resend the RTJ message up to 1384 three (3) times. 1386 NOTE: At any one time, a GC/KS MUST process no more that one (1) 1387 valid RTJ message from a given GM per group until its pending 1388 registration protocol exchange concludes. 1390 If any error occurs during RTJ message processing, and the GC/KS is 1391 running in Terse mode, the registration session MUST be terminated 1392 and all saved state information MUST be cleared. 1394 The OPTIONAL Notification payload of type Cookie is discussed in 1395 section 5.2.2. 1397 The OPTIONAL Notification payload of type IPValue may be used for the 1398 GM to convey a specific IP value to the GC/KS. 1400 5.2.1.2 Key Download 1402 The exchange type for Key Download is nine (9). 1404 The components of a Key Download Message are shown in Table 2: 1406 Table 2: Key Download (KeyDL) Message Definition 1408 Message Name : Key Download (KeyDL) 1409 Dissection : {HDR-GrpID, Member ID, [Nonce_R, Nonce_C], Key 1410 Creation, (Policy Token)*, (Key Download)*, 1411 [VendorID]} SigC, [Cert] 1412 Payload Types : GSAKMP Header, Identification, [Nonce], Key 1413 Creation, Policy Token, Key Download, [Vendor 1414 ID], Signature, [Certificate] 1416 SigC : Signature of Group Controller Key Server 1417 Cert : Necessary Certificates, zero or more 1418 {}SigX : Indicates fields used in Signature 1419 [] : Indicate an optional data item 1420 (data)* : Indicates encrypted information 1422 In response to a properly formed and verified RTJ message, the GC/KS 1423 creates and sends the KeyDL message. As defined in the dissection of 1424 the message, this message MUST contain payloads to hold the following 1425 information: GM identification, Key Creation material, encrypted 1426 Policy Token, encrypted key information, and signature information. 1427 If synchronized time is not available, the Nonce payloads MUST be 1428 included in the message for freshness. 1430 If present, the nonce values transmitted MUST be the GC/KSs generated 1431 Nonce_R value and the combined Nonce_C value which was generated by 1432 using the GC/KSs Nonce_R value and the Nonce_I value received from the 1433 GM in the RTJ. 1435 If two party key determination is used, the key creation material 1436 supplied by the GM and/or the GC/KS will be used to generate the key. 1437 Generation of this key is dependant on the key exchange, as defined 1438 in Section 7.11, Key Creation Payload. The Policy Token and key 1439 material are encrypted in the generated key. 1441 The GM MUST be able to process the Key Download message. indicates the GM actions that will determine how the Key 1443 Download message will be acted upon. The following checks SHOULD be 1444 performed in the order presented. 1446 In this procedure, the GM will verify that the message header is 1447 properly formed and confirm that this message is for this group by 1448 checking the value of the GroupID. If the header checks pass, the GM 1449 MUST confirm that this message was intended for itself by comparing 1450 the Member ID in the Identification payload to its identity. 1452 After identification confirmation, the freshness values are checked. 1453 If using Nonces, the GM MUST use its saved Nonce_I value, extract the 1454 received GC/KS Nonce_R value, compute the combined Nonce_C value, and 1455 compare it to the received Nonce_C value. If not using Nonces, the 1456 GM MUST check the timestamp in the Signature payload to determine if 1457 the message is new. 1459 After freshness is confirmed, the signature MUST be verified to 1460 ensure its authenticity, The GM MUST use verified and trusted 1461 authentication material from a known root. If the message signature 1462 verifies, the key creation material is extracted from the Key 1463 Creation payload to generate the KEK. This KEK is then used to 1464 decrypt the Policy Token data. The signature on the policy token 1465 MUST be verified. Access control checks MUST be performed on both 1466 the GO and the GC/KS to determine both their authorities within this 1467 group. After all these checks pass, the KEK can then be used to 1468 decrypt and process the key material from the Key Download payload. 1469 If all is successful, the GM will create and send the Key Download - 1470 Ack/Failure message as described in section 5.2.1.4. 1472 The Policy Token and Key Download payloads are sent encrypted in 1473 the KEK generated by the Key Creation payload information using the 1474 mechanisms defined in the group announcement. This guarantees that 1475 the sensitive policy and key data for the group and potential rekey 1476 data for this individual cannot be read by anyone but the intended 1477 recipient. 1479 If any error occurs during KeyDL message processing, regardless of 1480 whether the GM is in Terse or Verbose mode, the registration session 1481 MUST be terminated, the GM MUST send a Key Download - Ack/Failure 1482 message, nd all saved state information MUST be cleared. If in 1483 Terse mode, the Notification Payload will be of type NACK to indicate 1484 termination. If in Verbose mode, the Notification Payload will 1485 contain the type of error encountered. 1487 5.2.1.3 Request to Join Error 1489 The exchange type for Request to Join Error is eleven (11). 1491 The components of the Request to Join Error Message are shown in 1492 Table 3: 1494 Table 3: Request to Join Error (RTJ-Err) Message Definition 1496 Message Name : Request to Join Error (RTJ-Err) 1497 Dissection : {HDR-GrpID, [Nonce_I], Notification, [VendorID]} 1498 Payload Types : GSAKMP Header, [Nonce] Notification, [Vendor ID] 1500 In response to an unacceptable RTJ, the GC/KS MAY send a Request to 1501 Join Error (RTJ-Err) message containing an appropriate Notification 1502 payload. Note that the RTJ-Err message is not a signed message for 1503 the following reasons: the lack of awareness on the GM's perspective 1504 of who is a valid GC/KS as well as the need to protect the GC/KS from 1505 signing messages and using valuable resources. Following the sending 1506 of an RTJ-Err, the GC/KS MUST terminated the session and all saved 1507 state information MUST be cleared. 1509 Upon receipt of an RTJ-Err message, the GM will validate the 1510 following: the GroupID in the header belongs to a group to which 1511 the GM has sent an RTJ, and, if present, the Nonce_I matches a Nonce_I 1512 sent in an RTJ to that group. If the above checks are successful, 1513 the GM MAY terminate the state associated with that GroupID and 1514 Nonce. The GM SHOULD be capable of receiving a valid KeyDownload 1515 message for that GroupID and Nonce after receiving an RTJ-Err for a 1516 locally-configured amount of time. 1518 5.2.1.4 Key Download - Ack/Failure 1520 The exchange type for Key Download - Ack/Failure is four (4). 1522 The components of the Key Download - Ack/Failure Message are shown in 1523 Table 4: 1525 Table 4: Key Download - Ack/Failure (KeyDL-A/F) Message Definition 1527 Message Name : Key Download - Ack/Failure (KeyDL-A/F) 1528 Dissection : {HDR-GrpID, [Nonce_C], Notif_Ack, [VendorID]}SigM 1529 Payload Types : GSAKMP Header, [Nonce], Notification, [Vendor 1530 ID], Signature 1531 SigM : Signature of Group Member 1532 {}SigX : Indicates fields used in Signature 1534 In response to a properly processed KeyDL message, the GM creates and 1535 sends the KeyDL-A/F message. As defined in the dissection of the 1536 message, this message MUST contain payloads to hold the following 1537 information: Notification payload of type Acknowledgment (ACK) and 1538 signature information. If synchronized time is not available, the 1539 Nonce payload MUST be present for freshness, and the nonce value 1540 transmitted MUST be the GMs generated Nonce_C value. If the GM does 1541 not receive a KeyDL message within a locally configured amount of 1542 time, the GM MAY send a new RTJ. If the GM receives a valid LOA (see 1543 section 5.2.1.5) message from the GC/KS before receipt of a KeyDL 1544 message, the GM SHOULD send a KeyDL-A/F message of type NACK followed 1545 by a new RTJ. 1547 The GC/KS MUST be able to process the KeyDL-A/F message. indicates the GC/KS actions that will determine how the 1549 KeyDL-A/F message will be acted upon. The following checks SHOULD be 1550 performed in the order presented. 1552 In this procedure, the GC/KS will verify that the message header 1553 is properly formed and confirm that this message is for this group 1554 by checking the value of the GroupID. If the header checks pass, 1555 the GC/KS MUST check the message for freshness. If using Nonces, 1556 the GC/KS MUST use its saved Nonce_C value, and compare it to the 1557 received Nonce_C value. If not using Nonces, the GC/KS MUST check 1558 the timestamp in the Signature payload to determine if the message 1559 is new. After freshness is confirmed, the signature MUST be verified 1560 to ensure its authenticity, The GC/KS MUST use verified and trusted 1561 authentication material from a known root. If the message signature 1562 verifies, the GC/KS processes the Notification payload. If the 1563 notification type is of type ACK, then the registration has completed 1564 successfully and both parties SHOULD remove state information 1565 associated with this GM's registration. 1567 If the GC/KS does not receive a KeyDL-A/F message of proper form, is 1568 unable to correctly process the KeyDL-A/F message, the Notification 1569 payload type is any value except ACK, or if no KeyDL-A/F message is 1570 received within the locally configured timeout, the GC/KS MUST evict 1571 this GM from the group in the next policy-defined Rekey Event. The 1572 GC/KS MAY send the OPTIONAL Lack_of_Ack message if running in Verbose 1573 Mode as defined in section 5.2.1.5. 1575 5.2.1.5 Lack of Ack 1577 The exchange type for Lack of Ack is twelve (12). 1579 The components of a Lack of Ack Message are shown in Table 5: 1581 Table 5: Lack of Ack (LOA) Message Definition 1583 Message Name : Lack of Ack (LOA) 1584 Dissection : {HDR-GrpID, Member ID, [Nonce_R, Nonce_C], 1585 Notification, [VendorID]} SigC, [Cert] 1586 Payload Types : GSAKMP Header, Identification, [Nonce], 1587 Notification, [Vendor ID], Signature, 1588 [Certificate] 1590 SigC : Signature of Group Controller Key Server 1591 Cert : Necessary Certificates, zero or more 1592 {}SigX : Indicates fields used in Signature 1593 [] : Indicate an optional data item 1595 If the GC/KSs local timeout value expires prior to receiving a 1596 KeyDL-A/F from the GM, the GC/KS MAY create and send a LOA message 1597 to the GM. As defined in the dissection of the message, this 1598 message MUST contain payloads to hold the following information: GM 1599 identification, Notification of error, and signature information. 1601 If synchronized time is not available, the Nonce payloads MUST be 1602 present for freshness, and the nonce values transmitted MUST be the 1603 GC/KSs generated Nonce_R value and the combined Nonce_C value which 1604 was generated by using the GC/KSs Nonce_R value and the Nonce_I value 1605 received from the GM in the RTJ. These values were already generated 1606 during the Key Download message phase. 1608 The GM MAY be able to process the LOA message based upon local 1609 configuration. indicates the GM actions that will 1610 determine how the LOA message will be acted upon. The following 1611 checks SHOULD be performed in the order presented. 1613 In this procedure, the GM MUST verify that the message header is 1614 properly formed and confirm that this message is for this group by 1615 checking the value of the GroupID. If the header checks pass, the GM 1616 MUST confirm that this message was intended for itself by comparing 1617 the Member ID in the Identification payload to its identity. After 1618 identification confirmation, the freshness values are checked. If 1619 using Nonces, the GM MUST use its save Nonce_I value, extract the 1620 received GC/KS Nonce_R value, compute the combined Nonce_C value, and 1621 compare it to the received Nonce_C value. If not using Nonces, the 1622 GM MUST check the timestamp in the Signature payload to determine if 1623 the message is new. After freshness is confirmed, access control 1624 checks MUST be performed on the GC/KS to determine its authority 1625 within this group. Then signature MUST be verified to ensure its 1626 authenticity, The GM MUST use verified and trusted authentication 1627 material from a known root. 1629 If the checks succeed, the GM SHOULD resend a KeyDL-A/F for that 1630 session. 1632 5.2.2 Cookies - Group Establishment with Denial of Service Protection 1634 This section defines an OPTIONAL capability that MAY be implemented 1635 into GSAKMP when using IP based groups. The information in this 1636 section is borrowed heavily from [IKEv2] as this protocol has already 1637 worked through this issue and GSAKMP is copying this concept. This 1638 section will contain paraphrased sections of [IKEv2] modified for 1639 GSAKMP to define the purpose of Cookies. 1641 An optional Cookie mode is being defined for the GSAKMP to help 1642 against DoS attacks. 1644 The term "cookies" originates with Karn and Simpson [RFC 2522] in 1645 Photuris, an early proposal for key management with IPSec. The 1646 ISAKMP fixed message header includes two eight octet fields titled 1647 "cookies". Instead of placing this cookie data in the header, in 1648 GSAKMP this data is moved into a Notification payload. 1650 An expected attack against GSAKMP is state and CPU exhaustion, 1651 where the target GC/KS is flooded with Request to Join requests 1652 from forged IP addresses. This attack can be made less effective 1653 if a GC/KS implementation uses minimal CPU and commits no state 1654 to the communication until it knows the initiator potential GM can 1655 receive packets at the address from which it claims to be sending 1656 them. To accomplish this, the GC/KS when operating in Cookie mode, 1657 SHOULD reject initial Request to Join messages unless they contain 1658 a Notification payload of type "cookie". It SHOULD instead send 1659 a Cookie Download message as a response to the RTJ and include a 1660 cookie in a notify payload of type Cookie_Required. Potential GMs 1661 who receive such responses MUST retry the Request to Join message 1662 with the responder GC/KS supplied cookie in its notification payload 1663 of type Cookie, as defined by the optional Notification payload of 1664 the Request to Join Msg as defined in section 5.2.1.1. This initial 1665 exchange will then be as shown in Figure 2 with the components of the 1666 new message Cookie Download shown in Table 6. The exchange type for 1667 Cookie Download is ten (10). 1669 CONTROLLER MESSAGE MEMBER 1670 in Cookie Mode 1671 !<--Request to Join without Cookie Info---! 1672 ! ! 1673 ! ! 1674 !----------Cookie Download--------------->! 1675 ! ! 1676 !<----Request to Join with Cookie Info----! 1677 ! ! 1678 ! ! 1679 !-------------Key Download--------------->! 1680 ! ! 1681 !<-----Key Download - Ack/Failure--------! 1682 ! ! 1683 ! ! 1684 !<=======SHARED KEYED GROUP SESSION======>! 1686 Figure 2: GSAKMP Ladder Diagram with Cookies 1688 Table 6: Cookie Download Message Definition 1690 Message Name : Cookie Download 1691 Dissection : {HDR-GrpID, Notif_COOKIE_REQUIRED, [VendorID]} 1692 Payload Types : GSAKMP Header, Notification, [Vendor ID] 1694 The first two messages do not affect any GM or GC/KS state except for 1695 communicating the cookie. 1697 A GSAKMP implementation SHOULD implement its GC/KS cookie generation 1698 in such a way as to not require any saved state to recognize its 1699 valid cookie when the second Request to Join message arrives. The 1700 exact algorithms and syntax they use to generate cookies does not 1701 affect interoperability and hence is not specified here. 1703 The following is an example of how an endpoint could use cookies to 1704 implement limited DoS protection. 1706 A good way to do this is to set the cookie to be: 1708 Cookie = | Hash(Ni | IPi | ) 1710 where is a randomly generated secret known only to the 1711 responder GC/KS and periodically changed, Ni is the Nonce value taken 1712 from the initiator potential GM, IPi is the asserted IP address of 1713 the candidate GM. The IP address is either the IP header's source IP 1714 address, or else if it is present then the IP address contained in 1715 the optional Notification "IPvalue" payload. 1716 should be changed whenever is regenerated. The cookie can 1717 be recomputed when the "Request to Join with Cookie Info" arrives 1718 and compared to the cookie in the received message. If it matches, 1719 the responder GC/KS knows that all values have been computed since 1720 the last change to and that IPi MUST be the same as the 1721 source address it saw the first time. Incorporating Ni into the hash 1722 assures that an attacker who sees only the Cookie_Download message 1723 cannot successfully forge a "Request to Join with Cookie Info" 1724 message. This Ni value MUST be the same Ni value from the original 1725 "Request to Join" message for the calculation to be successful. 1727 If a new value for is chosen while there are connections 1728 in the process of being initialized, a "Request to Join with 1729 Cookie Info" might be returned with other than the current 1730 . The responder GC/KS in that case MAY reject 1731 the message by sending another response with a new cookie or it MAY 1732 keep the old value of around for a short time and accept 1733 cookies computed from either one. The responder GC/KS SHOULD NOT 1734 accept cookies indefinitely after is changed, since that 1735 would defeat part of the denial of service protection. The responder 1736 GC/KS SHOULD change the value of frequently, especially if 1737 under attack. 1739 An alternative example for Cookie value generation in a NAT 1740 environment is to substitute the IPi value with the IPValue received 1741 in the Notification payload in the RTJ message. This scenario 1742 is indicated by the presence of the Notification payload of type 1743 IPValue. With this substitution, a similar calculation as described 1744 above can be used. 1746 5.2.3 Group Establishment for Receive-Only Members 1748 This section describes an OPTIONAL capability that may be implemented 1749 in a structured system where the authorized (S-)GC/KS is known in 1750 advance through out-of-band means and where synchronized time is 1751 available. 1753 Unlike Standard Group Establishment, in the Receive-Only system, the 1754 GMs and (S-)GC/KSs operate in terse mode and exchange one message 1755 only: the Key Download. Potential new GMs do not send an RTJ. 1756 (S)-GC/KSs do not expect Key Download - ACK/Failure messages and do 1757 not remove GMs for lack or receipt of the message. 1759 Operation is as follows: upon notification via an authorized 1760 out-of-band event, the (S)-GC/KS forms and sends a Key Download 1761 message to the new member with the Nonce payloads ABSENT. The GM 1762 verifies 1764 - the ID payload identifies that GM 1766 - the timestamp in the message is fresh 1768 - the message is signed by an authorized (S)-GC/KS 1770 - the signature on the message verifies 1772 When using a Diffie-Hellman Key Creation Type for receive-only 1773 members, a static-ephemeral model is assumed: the Key Creation 1774 payload in the Key Download message contains the (S-)GC/KS's public 1775 component. The member's public component is assumed to be obtained 1776 through secure out-of-band means. 1778 5.3 Group Maintenance 1780 The Group Maintenance phase includes member joins and leaves, group 1781 rekey activities, policy updates, and group destruction. These 1782 activities are presented in the following sections. 1784 5.3.1 Group Management 1786 5.3.1.1 Rekey Events 1788 A Rekey Event is any action, including compromise report or key 1789 expiration, that requires the creation of a new group key and/or 1790 Rekey information. 1792 Once an event has been identified (as defined in the group security 1793 policy token), the GC/KS MUST create and provide a signed message 1794 containing the GTPK and Rekey information to the group. 1796 Each GM who receives this message MUST verify the signature on the 1797 message to ensure its authenticity. If the message signature does 1798 not verify, the message MUST be discarded. Upon verification the 1799 GM will find the appropriate Rekey download packet and decrypt the 1800 information with a stored Rekey key(s). If a new Policy Token is 1801 distributed with the message, it MUST be encrypted in the old GTPK. 1803 The exchange type for Rekey Event is five (5). 1805 The components of a Rekey Event message are shown in Table 7: 1807 Table 7: Rekey Event Message Definition 1809 Message Name : Rekey Event 1810 Dissection : {HDR-GrpID, ([Policy Token])*, Rekey Array, 1811 [VendorID]}SigC, [Cert] 1812 Payload Types : GSAKMP Header, [Policy Token], Rekey Event, 1813 [Vendor ID], Signature, [Certificate], 1815 SigC : Signature of Group Controller Key Server 1816 Cert : Necessary Certificates, zero or more 1817 {}SigX : Indicates fields used in Signature 1818 (data)* : Indicates encrypted information 1819 [] : Indicate an optional data item 1821 5.3.1.2 Policy Updates 1823 New policy tokens are sent via the Rekey Event message. These policy 1824 updates may be coupled with an existing rekey event or may be sent in 1825 a message with the Rekey Event Type of the Rekey Event Payload set to 1826 None(0) (see section 7.5.1. 1828 A policy token MUST NOT be processed if the processing of the Rekey 1829 Event message carrying it fails. Policy token processing is type 1830 dependent and is beyond the scope of this document. 1832 5.3.1.3 Group Destruction 1834 Group destruction is also accomplished via the Rekey Event message. 1835 In a Rekey Event message for group destruction, the Sequence ID is 1836 set to 0xFFFFFFFF. Upon receipt of this authenticated Rekey Event 1837 message, group components MUST terminate processing of information 1838 associated with the indicated group. 1840 5.3.2 Leaving a Group 1842 There are several conditions under which a member will leave a group: 1843 eviction, voluntary departure without notice, and voluntary departure 1844 with notice -- or De-Registration. Each of these is discussed in 1845 this section. 1847 5.3.2.1 Eviction 1849 At some point in the group's lifetime, it may be desirable to evict 1850 one or more members from a group. From a key management viewpoint, 1851 this involves revoking access to the group's protected data by 1852 "disabling" the departing members' keys. This is accomplished with 1853 a Rekey Event, which is discussed in more detail in section 5.3.1.1. 1854 If future access to the group is also to be denied, the members MUST 1855 be added to a denied access control list, and the policy token's 1856 authorization rules MUST be appropriately updated so that they 1857 will exclude the expelled GM(s). After receipt of a new PT, GMs 1858 SHOULD evaluate the trustworthiness of any recent application data 1859 originating from the expelled GM(s). 1861 5.3.2.2 Voluntary Departure without Notice 1863 If a member wishes to leave a group for which membership imposes no 1864 cost or responsibility to that member, then the member MAY merely 1865 delete local copies of group keys and cease group activities. 1867 5.3.2.3 De-Registration 1869 If the membership in the group does impose cost or responsibility to 1870 the departing member, then the member SHOULD de-register from the 1871 group when that member wishes to leave. De-Registration consists 1872 of a three-message exchange between the GM and the member's GC/KS: 1873 the Request_to_Depart, Departure_Response, and the Departure_Ack. 1874 Compliant GSAKMP implementations for GMs SHOULD support the 1875 De-Registration messages. Compliant GSAKMP implementations for 1876 GC/KSs MUST support the De-Registration messages. 1878 5.3.2.3.1 Request to Depart - The Exchange Type for a 1879 Request_to_Depart Message is thirteen (13). The components of a 1880 Request_to_Depart Message are shown in Table 8. 1882 Any GM desiring to initiate the De-Registration process MUST generate 1883 and send an RTD message to notify the GC/KS of its intent. As 1884 defined in the dissection of the RTD message, this message MUST 1885 contain payloads to hold the following information: the GC/KS 1886 identification and Notification of the desire to leave the group. 1887 When synchronization time is not available to the system as defined 1888 by the Policy Token, a Nonce payload MUST be included for freshness, 1889 and the Nonce_I value MUST be saved for later use. This message MUST 1890 then by signed by the GM. 1892 Table 8: Request_to_Depart (RTD) Message Definition 1894 Message Name : Request_to_Depart (RTD) 1895 Dissection : {HDR-GrpID, GC/KS_ID, [Nonce_I], Notif_Leave_Group, 1896 [VendorID]} SigM, [Cert] 1897 Payload Types : GSAKMP Header, Identification, [Nonce], 1898 Notification, [Vendor ID], Signature, 1899 [Certificate] 1901 SigM : Signature of Group Member 1902 Cert : Necessary Certificates, zero or more 1903 {}SigX : Indicates fields used in Signature 1904 [] : Indicate an optional data item 1906 Upon receipt of the RTD message, the GC/KS MUST verify that the 1907 message header is properly formed and confirm that this message is 1908 for this group by checking the value of the GroupID. If the header 1909 checks pass, then the identifier value in Identification payload 1910 is compared to its own, the GC/KSs identity, to confirm that the GM 1911 intended to converse with this GC/KS, the GC/KS who registered this 1912 member into the group. Then the identity of the sender is extracted 1913 from the Signature payload. This identity MUST be used to confirm 1914 that this GM is a member of the group serviced by this GC/KS. Then 1915 the GC/KS will confirm from the Notification payload that the GM 1916 is requesting to leave the group. Then the GC/KS will verify the 1917 signature on the message to ensure its authenticity. The GC/KS 1918 MUST use verified and trusted authentication material from a known 1919 root. If all checks pass and the message is successfully processed, 1920 then the GC/KS MUST form a Departure_Response message as defined in 1921 section 5.3.2.3.2. 1923 If the processing of the message fails the de-registration session 1924 MUST be terminated and all state associated with this session is 1925 removed. If the GC/KS is operating in Terse Mode, then no error 1926 message is sent to the GM. If the GC/KS is operating in Verbose Mode, 1927 then the GC/KS sends a Departure_Response Message with a Notification 1928 Payload of type Request_to_Depart_Error. 1930 5.3.2.3.2 Departure_Response - The Exchange Type for a 1931 Departure_Response Message is fourteen (14). The components of a 1932 Departure_Response Message are shown in Table 9. 1934 In response to a properly formed and verified RTD message, the GC/KS 1935 MUST create and send the DR message. As defined in the dissection of 1936 the message, this message MUST contain payloads to hold the following 1937 information: GM identification, Notification for acceptance of 1938 departure, and signature information. If synchronization time is 1939 not available, the Nonce payloads MUST be included in the message for 1940 freshness. 1942 Table 9: Departure_Response (DR) Message Definition 1944 Message Name : Departure_Response (DR) 1945 Dissection : {HDR-GrpID, Member_ID, [Nonce_R, Nonce_C], 1946 Notification, [VendorID]} SigC, [Cert] 1947 Payload Types : GSAKMP Header, Identification, [Nonce], 1948 Notification, [Vendor ID], Signature, 1949 [Certificate] 1951 SigC : Signature of Group Member 1952 Cert : Necessary Certificates, zero or more 1953 {}SigX : Indicates fields used in Signature 1954 [] : Indicate an optional data item 1956 If present, the nonce values transmitted MUST be the GC/KSs generated 1957 Nonce_R value and the combined Nonce_C value which was generated by 1958 using the GC/KSs Nonce_R value and the Nonce_I value received from 1959 the GM in the RTD. This Nonce_C value MUST be saved relative to this 1960 departing GMs ID. 1962 The GM MUST be able to process the Departure_Response message. The 1963 following checks SHOULD be performed in the order presented. 1965 The GM MUST verify that the message header is properly formed 1966 and confirm that this message is for this group by checking the 1967 value of the GroupID. If the header checks pass, the GM MUST 1968 confirm that this message was intended for itself by comparing the 1969 Member ID in the Identification payload to its identity. After 1970 identification confirmation, the freshness values are checked. 1971 If using Nonces, the GM MUST use its saved Nonce_I value, extract 1972 the received GC/KS Nonce_R value, compute the combined Nonce_C 1973 value, and compare it to the received Nonce_C value. If not using 1974 Nonces, the GM MUST check the timestamp in the signature payload 1975 to determine if the message is new. After freshness is confirmed, 1976 confirmation of the identity of the signer of the DR message is 1977 the GMs authorized GC/KS is performed. Then the signature MUST be 1978 verified to ensure its authenticity, The GM MUST use verified and 1979 trusted authentication material from a known root. If the message 1980 signature verifies, then the GM MUST verify that the Notification is 1981 of Type Departure_Accepted or Request_to_Depart_Error. 1983 If the processing is successful, and the Notification payload 1984 is of type Departure_Accepted, the member MUST form the 1985 Departure_ACK message as defined in section 5.3.2.3.3. If the 1986 processing is successful, and the Notification payload is of 1987 type Request_to_Depart_Error, the member MUST remove all state 1988 associated with the de-registration session. If the member still 1989 desires to De-Register from the group, the member MUST restart the 1990 De-Registration process. 1992 If the processing of the message fails the de-registration session 1993 MUST be terminated and all state associated with this session is 1994 removed. If the GM is operating in Terse Mode, then a Departure_Ack 1995 Message with Notification Payload of type NACK is sent to the 1996 GC/KS. If the GM is operating in Verbose Mode, then the GM sends a 1997 Departure_Ack Message with a Notification Payload of the appropriate 1998 failure type. 2000 5.3.2.3.3 Departure_ACK - The Exchange Type for a Departure_ACK 2001 Message is fifteen (15). The components of the Departure_ACK Message 2002 are shown in Table 10: 2004 Table 10: Departure_ACK (DA) Message Definition 2006 Message Name : Departure_ACK (DA) 2007 Dissection : {HDR-GrpID, [Nonce_C], Notif_Ack, [VendorID]}SigM 2008 Payload Types : GSAKMP Header, [Nonce], Notification, [Vendor 2009 ID], Signature 2010 SigM : Signature of Group Member 2011 {}SigX : Indicates fields used in Signature 2013 In response to a properly processed Departure_Response message, the 2014 GM MUST create and send the Departure_ACK message. As defined in 2015 the dissection of the message, this message MUST contain payloads 2016 to hold the following information: Notification payload of type 2017 Acknowledgment (ACK) and signature information. If synchronization 2018 time is not available, the Nonce payload MUST be present for 2019 freshness, and the nonce value transmitted MUST be the GMs generated 2020 Nonce_C value. 2022 Upon receipt of the Departure_ACK, the GC/KS MUST perform the 2023 following checks. These checks SHOULD be performed in the order 2024 presented. 2026 In this procedure, the GC/KS MUST verify that the message header 2027 is properly formed and confirm that this message is for this group 2028 by checking the value of the GroupID. If the header checks pass, 2029 the GC/KS MUST check the message for freshness. If using Nonces, 2030 the GC/KS MUST use its saved Nonce_C value, and compare it to the 2031 received Nonce_C value. If not using Nonces, the GC/KS MUST check 2032 the timestamp in the signature payload to determine if the message 2033 is new. After freshness is confirmed, the signature MUST be verified 2034 to ensure its authenticity, The GC/KS MUST use verified and trusted 2035 authentication material from a known root. If the message signature 2036 verifies, the GC/KS processes the Notification payload. If the 2037 notification type is of type ACK, this is considered a successful 2038 processing of this message. 2040 If the processing of the message is successful, the GC/KS MUST remove 2041 the member from the group. This MAY involve initiating a Rekey Event 2042 for the group. 2044 If the processing of the message fails or if no Departure_Ack is 2045 received, the GC/KS MAY issue a LOA message. 2047 6 Security Suite 2049 The Security Definition Suite 1 MUST be supported. Other security 2050 suite definitions MAY be defined in other Internet specifications. 2052 6.1 Assumptions 2054 All potential GMs will have enough information available to them 2055 to use the correct Security Suite to join the group. This can be 2056 accomplished by a well known default suite 'Security Suite 1' or by 2057 announcing/posting another suite. 2059 6.2 Definition Suite 1 2061 GSAKMP implementations MUST support the following suite of algorithms 2062 and configurations. The following definition of Suite 1 borrows 2063 heavily from IKE's Oakley group 2 definition and Oakley itself. 2065 The GSAKMP Suite 1 definition defines all the algorithm and 2066 cryptographic definitions required to process group establishment 2067 messages. It is important to note that GSAKMP does not negotiate 2068 these cryptographic mechanisms. This definition is set by the Group 2069 Owner via the Policy Token (passed during the GSAKMP exchange for 2070 member verification purposes). 2072 The GSAKMP Suite 1 definition is 2074 Key download and Policy Token encryption algorithm definition: 2075 Algorithm: AES 2076 Mode: CBC 2077 Key Length: 128 bits 2079 Policy Token digital signature algorithm is: 2080 DSS-ASN1-DER 2081 Hash algorithm is: 2082 SHA-1 2084 Nonce Hash algorithm is: 2085 SHA-1 2087 The Key Creation definition is: 2088 Algorithm type is Diffie Hellman 2089 MODP group definition 2090 g: 2 2091 p: "FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1" 2092 "29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD" 2093 "EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245" 2094 "E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED" 2095 "EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381" 2096 "FFFFFFFF FFFFFFFF" 2098 NOTE: The p and g values comes from IKE [RFC 2409], section 6.2 2099 Second Oakley Group, and p is 1024 bits long. 2101 The digital signature algorithm is: 2102 DSS-SHA1-ASN1-DER 2103 The digital signature ID type is: 2104 ID-DN-STRING 2106 7 GSAKMP Payload Structure 2108 A GSAKMP Message is composed of a GSAKMP Header (Section 7.1) 2109 followed by at least one GSAKMP Payload. All GSAKMP Payloads are 2110 composed of the Generic Payload Header (Section 7.2) followed by 2111 the specific payload data. The message is chained by a preceeding 2112 payload defining its succeeding payload. Payloads are not required 2113 to be in the exact order shown in the message dissection in 2114 Sections 5 provided that all required payloads are present. Unless 2115 it is explicitly stated in a dissection that multiple payloads of 2116 a single type may be present, no more than one payload of each type 2117 allowed by the message may appear. The final payload in a message 2118 will point to no succeeding payload. 2120 All fields of type integer in the Header and Payload structure that 2121 are larger than one octet, MUST be converted into Network Byte Order 2122 prior to data transmission. 2124 Padding of fields MUST NOT be done as this leads to processing 2125 errors. 2127 When a message contains a Vendor ID payload, the processing of the 2128 payloads of that message are modified as defined in Section 7.10. 2130 7.1 GSAKMP Header 2132 7.1.1 GSAKMP Header Structure 2134 The GSAKMP Header fields are shown in Figure 3 and defined as: 2136 0 1 2 3 2137 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 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2139 ! GroupID Type ! GroupID Length! Group ID Value ~ 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 ~ ~ 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 ~ ! Next Payload ! Version ! Exchange Type ! 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 ! Sequence ID ! 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 ! Length ! 2148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 Figure 3: GSAKMP Header Format 2152 Group Identification Type (1 octet) - Table 11 presents the group 2153 identification types. This field is treated as an unsigned 2154 value. 2156 Table 11: Group Identification Types 2158 Grp ID Type Value Description 2160 ______________________________________________________________________ 2162 Reserved 0 2163 UTF-8 1 Format defined in Section 7.1.1.1.1. 2164 Octet String 2 This type MUST be implemented. 2165 Format defined in Section 7.1.1.1.2. 2166 IPv4 3 Format defined in Section 7.1.1.1.3. 2167 IPv6 4 Format defined in Section 7.1.1.1.4. 2168 Reserved to IANA 5 - 192 2169 Private Use 193 - 255 2171 Group Identification Length (1 octet) - Length of the Group ID 2172 field in octets. This value MUST NOT be zero (0). This field is 2173 treated as an unsigned value. 2175 Group Identification Value (variable length) - Indicates the 2176 name/title of the group. All GroupID types should provide 2177 unique naming across groups. GroupID types SHOULD provide this 2178 capability by including a random element generated by the creator 2179 (owner) of the group of at least eight (8) octets, providing 2180 extremely low probability of collision in group names. The 2181 GroupID value is static throughout the life of the group. 2183 Next Payload (1 octet) - Indicates the type of the next payload 2184 in the message. The format for each payload is defined in the 2185 following sections. Table 12 presents the payload types. This 2186 field is treated as an unsigned value. 2188 Table 12: Payload Types 2190 Next_Payload_Type Value 2191 ___________________________________ 2193 None 0 2194 Policy Token 1 2195 Key Download Packet 2 2196 Rekey event 3 2197 Identification 4 2198 Reserved 5 2199 Certificate 6 2200 Reserved 7 2201 Signature 8 2202 Notification 9 2203 Vendor ID 10 2204 Key Creation 11 2205 Nonce 12 2206 Reserved to IANA 13 - 192 2207 Private Use 193 -- 255 2209 Version (1 octet) - Indicates the version of the GSAKMP protocol in 2210 use. The current value is one (1). This field is treated as an 2211 unsigned value. 2213 Exchange Type (1 octet) - Indicates the type of exchange (also 2214 known as the message type). Table 13 presents the exchange type 2215 values. This field is treated as an unsigned value. 2217 Sequence ID (4 octets) - The Sequence ID is used for replay 2218 protection of group management messages. If the message is not 2219 a group management message, this value MUST be set to zero (0). 2220 The first value used by a (S-)GC/KS MUST be one (1). For each 2221 distinct group management message that this (S-)GC/KS transmits, 2222 this value MUST be incremented by one (1). Receivers of this 2223 group management message MUST confirm that the value received is 2224 greater that the value of the sequence ID received with the last 2225 Table 13: Exchange Types 2227 Exchange_Type Value 2228 ________________________________________ 2230 Reserved 0 - 3 2231 Key Download Ack/Failure 4 2232 Rekey Event 5 2233 Reserved 6 - 7 2234 Request to Join 8 2235 Key Download 9 2236 Cookie Download 10 2237 Request to Join Error 11 2238 Lack of Ack 12 2239 Request to Depart 13 2240 Departure Response 14 2241 Departure Ack 15 2242 Reserved to IANA 16 - 192 2243 Private Use 193 -- 255 2245 group management message from this (S-)GC/KS. Group Components 2246 (e.g., GMs, S-GC/KSs) MUST terminate processing upon receipt of 2247 an authenticated group management message containing a Sequence 2248 ID of 0xFFFFFFFF. This field is treated as an unsigned integer in 2249 network byte order. 2251 Length (4 octets) - Length of total message (header + payloads) in 2252 octets. This field is treated as an unsigned integer in network 2253 byte order. 2255 7.1.1.1 GroupID Structure 2257 This section defines the formats for the defined GroupID types. 2259 7.1.1.1.1 UTF-8 - The format for type UTF-8 [RFC 3629] is shown in 2260 Figure 4. 2262 0 1 2 3 2263 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 2264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 ! Random Value ~ 2266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2267 ~ ~ 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2269 ~ ~ 2270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2271 ~ ! 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2273 ! UTF-8 String ~ 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 Figure 4: GroupID UTF-8 Format 2278 Random Value (16 octets) - For the UTF-8 GroupID type, the Random 2279 Value is represented as a string of exactly 16 hexadecimal digits 2280 converted from its octet values in network-byte order. The 2281 leading zero hexadecimal digits and the trailing zero hexadecimal 2282 digits are always included in the string, rather than being 2283 truncated. 2285 UTF-8 String (variable length) - This field contains the human 2286 readable portion of the GroupID in UTF-8 format. Its length 2287 is calculated as the (GroupID Length - 16) for the Random Value 2288 field. The minimum length for this field is one (1) octet. 2290 7.1.1.1.2 Octet String 2292 The format for type Octet String is shown in Figure 5. 2294 Random Value (8 octets) - The 8 octet unsigned random value in 2295 network byte order format. 2297 Octet String (variable length) - This field contains the Octet 2298 0 1 2 3 2299 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 2300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2301 ! Random Value ~ 2302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2303 ~ ! 2304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2305 ! Octet String ~ 2306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2308 Figure 5: GroupID Octet String Format 2310 String portion of the GroupID. Its length is calculated as the 2311 (GroupID Length - 8) for the Random Value field. The minimum 2312 length for this field is one (1) octet. 2314 7.1.1.1.3 IPv4 Group Identifier 2316 The format for type IPv4 Group Identifier is shown in Figure 6. 2318 0 1 2 3 2319 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 2320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2321 ! Random Value ~ 2322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2323 ~ ! 2324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2325 ! IPv4 Value ! 2326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2328 Figure 6: GroupID IPv4 Format 2330 Random Value (8 octets) - The 8 octet unsigned random value in 2331 network byte order format. 2333 IPv4 Value (4 octets) - The IPv4 value in network byte order 2334 format. This value MAY contain the multicast address of the 2335 group. 2337 7.1.1.1.4 IPv6 Group Identifier 2339 The format for type IPv6 Group Identifier is shown in Figure 7. 2341 0 1 2 3 2342 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 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 ! Random Value ~ 2345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2346 ~ ! 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 ! IPv6 Value ~ 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 ~ ~ 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2352 ~ ~ 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 ~ ! 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2357 Figure 7: GroupID IPv6 Format 2359 Random Value (8 octets) - The 8 octet unsigned random value in 2360 network byte order format. 2362 IPv6 Value (16 octets) - The IPv6 value in network byte order 2363 format. This value MAY contain the multicast address of the 2364 group. 2366 7.1.2 GSAKMP Header Processing 2368 When processing the GSAKMP Header, the following fields MUST be 2369 checked for correct values: 2371 1. Group ID Type - The Group ID Type value MUST be checked to be a 2372 valid group identification payload type as defined by Table 11. 2373 If the value is not valid, then an error is logged and if in 2374 Verbose mode an appropriate message containing notification value 2375 Payload-Malformed will be sent. 2377 2. GroupID - The GroupID of the received message MUST be checked 2378 against the valid GroupIDs of the Group Component. If no 2379 match is found, then an error is logged and if in Verbose 2380 mode an appropriate message containing notification value 2381 Invalid-Group-ID will be sent. 2383 3. Next Payload - The Next Payload value MUST be checked to be 2384 a valid payload type as defined by Table 12. If the value 2385 is not valid, then an error is logged and if in Verbose 2386 mode an appropriate message containing notification value 2387 Invalid-Payload-Type will be sent. 2389 4. Version - The GSAKMP version number MUST be checked that its 2390 value is one (1). For other values, see below for processing. 2391 The GSAKMP version number MUST be checked that it is consistent 2392 with the group's policy as specified in its Policy Token. If 2393 the version is not supported or authorized, then an error is 2394 logged and if in Verbose mode an appropriate message containing 2395 notification value Invalid-Version will be sent. 2397 5. Exchange Type - The Exchange Type MUST be checked to be a valid 2398 exchange type as defined by Table 13 and MUST be of the type 2399 expected to be received by the GSAKMP state machine. If the 2400 exchange type is not valid, then an error is logged and if in 2401 Verbose mode an appropriate message containing notification value 2402 Invalid-Exchange-Type will be sent. 2404 6. Sequence ID - The Sequence ID value MUST be checked for 2405 correctness. For negotiation messages this value MUST be zero 2406 (0). For group management messages, this value MUST be greater 2407 than the last sequence ID received from this (S-)GC/KS. Receipt 2408 of incorrect Sequence ID on group management messages MUST NOT 2409 cause a reply message to be generated. Receipt of incorrect 2410 Sequence ID on non-group management messages, then an error is 2411 logged and if in Verbose mode an appropriate message containing 2412 notification value Invalid-Sequence-ID to be sent. 2414 The length fields in the GSAKMP Header (Group ID Length and Length) 2415 are used to help process the message. If any field is found to 2416 be incorrect, then an error is logged and if in Verbose mode an 2417 appropriate message containing notification value Payload-Malformed 2418 will be sent. 2420 In order to allow a GSAKMP version one (1) (v1) implementation to 2421 interoperate with future versions of the protocol, some ideas will 2422 be discussed here to this affect. 2424 A (S)-GC/KS that is operating in a multi-versioned group as defined 2425 by the Policy Token can take many approaches on how to interact with 2426 the GMs in this group for a Rekey Message. 2428 One possible solution is for the (S)-GC/KS to send out multiple 2429 Rekey Messages, one per version level that it supports. Then each 2430 GM would only process the message that has the version at which it is 2431 operating. 2433 An alternative approach which all GM v1 implementations MUST support 2434 is the embedding of a v1 message inside a version two (2) (v2) 2435 message. If a GM running at v1 receives a GSAKMP message that has 2436 a version value greater than one (1), the GM will attempt to process 2437 the information immediately after the Group Header as a Group Header 2438 for v1 of the protocol. If this is in fact a v1 Group Header, 2439 then the remainder of this v1 message will be processed in place. 2440 After processing this v1 embedded message, the data following the 2441 v1 message should be the payload as identified by the Next Payload 2442 field in the original header of the message and will be ignored by 2443 the v1 member. However, if the payload following the initial header 2444 is not a v1 Group Header, then the GM will gracefully handle the 2445 unrecognized message. 2447 7.2 Generic Payload Header 2449 7.2.1 Generic Payload Header Structure 2451 Each GSAKMP payload defined in the following sections begins with 2452 a generic header, shown in Figure 8, which provides a payload 2453 ``chaining`` capability and clearly defines the boundaries of a 2454 payload. The Generic Payload Header fields are defined as follows: 2455 0 1 2 3 2456 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 2457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2458 ! Next Payload ! RESERVED ! Payload Length ! 2459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2461 Figure 8: Generic Payload Header 2463 Next Payload (1 octet) - Identifier for the payload type of the 2464 next payload in the message. If the current payload is the last 2465 in the message, then this field will be 0. This field provides 2466 the ``chaining`` capability. Table 12 identifies the payload 2467 types. This field is treated as an unsigned value. 2469 RESERVED (1 octet) - Unused, set to 0. 2471 Payload Length (2 octets) - Length in octets of the current 2472 payload, including the generic payload header. This field is 2473 treated as an unsigned integer in network byte order format. 2475 7.2.2 Generic Payload Header Processing 2477 When processing the Generic Payload Header, the following fields MUST 2478 be checked for correct values: 2480 1. Next Payload - The Next Payload value MUST be checked to be 2481 a valid payload type as defined by Table 12. If the payload 2482 type is not valid, then an error is logged and if in Verbose 2483 mode an appropriate message containing notification value 2484 Invalid-Payload-Type will be sent. 2486 2. RESERVED - This field MUST contain the value zero (0). If the 2487 value of this field is not zero (0), then an error is logged and 2488 if in Verbose mode an appropriate message containing notification 2489 value Payload-Malformed will be sent. 2491 The length field in the Generic Payload Header is used to process the 2492 remainder of the payload. If this field is found to be incorrect, 2493 then an error is logged and if in Verbose mode an appropriate message 2494 containing notification value Payload-Malformed will be sent. 2496 7.3 Policy Token Payload 2498 7.3.1 Policy Token Payload Structure 2500 The Policy Token Payload contains authenticatable group specific 2501 information that describes the group security relevant behaviors, 2502 access control parameters, and security mechanisms. Figure 9 shows 2503 the format of the payload. 2505 0 1 2 3 2506 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 2507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2508 ! Next Payload ! RESERVED ! Payload Length ! 2509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 ! Policy Token Type ! Policy Token Data ~ 2511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2513 Figure 9: Policy Token Payload Format 2515 The Policy Token Payload fields are defined as follows: 2517 Next Payload (1 octet) - Identifier for the payload type of the 2518 next payload in the message. If the current payload is the last 2519 in the message, then this field will be 0. This field provides 2520 the ``chaining`` capability. Table 12 identifies the payload 2521 types. This field is treated as an unsigned value. 2523 RESERVED (1 octet) - Unused, set to 0. 2525 Payload Length (2 octets) - Length in octets of the current 2526 payload, including the generic payload header. This field is 2527 treated as an unsigned integer in network byte order format. 2529 Policy Token Type (2 octets) - Specifies the type of Policy Token 2530 being used. Table 14 identifies the types of policy tokens. 2531 This field is treated as an unsigned integer in network byte 2532 order format. 2534 Table 14: Policy Token Types 2536 Policy_Token_Type Value Definition/Defined In 2537 ____________________________________________________________________ 2539 Reserved 0 2540 GSAKMP_ASN.1_PT_V1 1 All implementations of GSAKMP 2541 MUST support this PT format. 2542 Format specified in [CH02]. 2543 Reserved to IANA 2 - 49152 2544 Private Use 49153 - 65535 2546 Policy Token Data (variable length) - Contains Policy Token 2547 information. The values for this field are token specific and 2548 the format is specified by the PT Type field. 2550 If this payload is encrypted, only the Policy Token Data field is 2551 encrypted. 2553 The payload type for the Policy Token Payload is one (1). 2555 7.3.2 Policy Token Payload Processing 2557 When processing the Policy Token Payload, the following fields MUST 2558 be checked for correct values: 2560 1. Next Payload, RESERVED, Payload Length - These fields are 2561 processed as defined in Section 7.2.2, Generic Payload Header 2562 Processing. 2564 0 1 2 3 2565 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 2566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2567 ! Next Payload ! RESERVED ! Payload Length ! 2568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2569 ! Number of Items ! Key Download Data Items ~ 2570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2572 Figure 10: Key Download Payload Format 2574 2. Policy Token Type - The Policy Token Type value MUST be checked 2575 to be a valid policy token type as defined by Table 14. If the 2576 value is not valid, then an error is logged and if in Verbose 2577 mode an appropriate message containing notification value 2578 Payload-Malformed will be sent. 2580 3. Policy Token Data - This Policy Token Data MUST be processed 2581 according to the Policy Token Type specified. The type will 2582 define the format of the data. 2584 7.4 Key Download Payload 2586 Refer to the terminology section for the different terms relating to 2587 keys used within this section. 2589 7.4.1 Key Download Payload Structure 2591 The Key Download Payload contains group keys (e.g., group keys, 2592 initial rekey keys, etc.). These key download payloads can have 2593 several security attributes applied to them based upon the security 2594 policy of the group. Figure 10 shows the format of the payload. 2596 The security policy of the group dictates that the key download 2597 payload MUST be encrypted with a key encryption key (KEK). The 2598 encryption mechanism used is specified in the Policy Token. The 2599 group members MUST create the KEK using the key creation method 2600 identified in the Key Creation Payload. 2602 The Key Download Payload fields are defined as follows: 2604 Next Payload (1 octet) - Identifier for the payload type of the 2605 next payload in the message. If the current payload is the last 2606 in the message, then this field will be 0. This field provides 2607 0 1 2 3 2608 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 2609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 ! KDD Item Type ! Key Download Data Item Length! ~ 2611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2612 ~ Data for Key Download Data Item (Key Datum/Rekey Array) ~ 2613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2615 Figure 11: Key Download Data Item Format 2617 the ``chaining`` capability. Table 12 identifies the payload 2618 types. This field is treated as an unsigned value. 2620 RESERVED (1 octet) - Unused, set to 0. 2622 Payload Length (2 octets) - Length in octets of the current 2623 payload, including the generic payload header. This field is 2624 treated as an unsigned integer in network byte order format. 2626 Number of Items (2 octets) -- Contains the total number of traffic 2627 protection keys and Rekey Arrays being passed in this data block. 2628 This field is treated as an unsigned integer in network byte 2629 order format. 2631 Key Download Data Items (variable length) - Contains Key 2632 Download information. The Key Download Data is a sequence of 2633 Type/Length/Data of the Number of Items. The format for each 2634 item is defined in figure 11. 2636 For each Key Download Data Item, the data format is as follows: 2638 Key Download Data (KDD) Item Type (1 octet) -- Identifier for 2639 the type of data contained in this Key Download Data Item. 2640 See Table 15 for the possible values of this field. This 2641 field is treated as an unsigned value. 2643 Key Download Data Item Length (2 octets) -- Length in octets 2644 of the Data for the Key Download Data Item following this 2645 field. This field is treated as an unsigned integer in 2646 network byte order format. 2648 Data for Key Download Data Item (variable length) -- Contains 2649 Keys and related information. The format of this field is 2650 specific depending on the value of the Key Download Data 2651 Item Type field. For KDD Item Type of GTPK, this field will 2652 contain a Key Datum as defined in Section 7.4.1.1 . For KDD 2653 Item Type Rekey - LKH, this field will contain a Rekey Array 2654 Table 15: Key Download Data Item Types 2656 Key Download Data Value Definition 2657 Item Type 2658 __________________________________________________________________ 2660 GTPK 0 This type MUST be implemented. 2661 This type identifies that the 2662 data contains group traffic 2663 protection key information. 2664 Rekey - LKH 1 Optional 2665 Reserved to IANA 2 - 192 2666 Private Use 193 - 255 2668 as defined in Section 7.4.1.2 . 2670 The encryption of this payload only covers the data subsequent to the 2671 Generic Payload header (Number of Items and Key Download Data Items 2672 fields). 2674 The payload type for the Key Download Packet is two (2). 2676 7.4.1.1 Key Datum Structure 2678 A Key Datum contains all the information for a key. Figure 12 shows 2679 the format for this structure. 2681 Key Type (2 octets) -- This is the cryptographic algorithm for 2682 which this key data is to be used. This value is specified in 2683 the Policy Token. See Table 16 for the possible values of this 2684 field. This field is treated as an unsigned value. 2686 Key ID (4 octets) -- This is the permanent ID of all versions of 2687 the key. This value MAY be defined by the Policy Token. This 2688 field is treated as an octet string. 2690 Key Handle (4 octets) -- This is the value to uniquely identify a 2691 version (particular instance) of a key. This field is treated as 2692 an octet string. 2694 Key Creation Date (15 octets) -- This is the time value of when 2695 this key data was originally generated. This field contains the 2696 timestamp in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year 2697 (0000 - 9999), MM is the numerical value of the month (01 - 12), 2698 DD is the day of the month (01 - 31), HH is the hour of the day 2699 0 1 2 3 2700 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 2701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2702 ! Key Type ! Key ID ~ 2703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2704 ~ ! Key Handle ~ 2705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2706 ~ ! Key Creation Date ~ 2707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2708 ~ ~ 2709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2710 ~ ~ 2711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2712 ~ ~ 2713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2714 ! ! Key Expiration Date ~ 2715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2716 ~ ! 2717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2718 ~ ! 2719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2720 ~ ! ~ 2721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2722 ~ Key Data ~ 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2725 Figure 12: Key Datum Format 2727 Table 16: Cryptographic Key Types 2729 Cryptographic_Key_Types Value Description/Defined In 2730 _____________________________________________________________________ 2732 Reserved 0 - 2 2733 3DES_CBC64_192 3 See [RFC 2451]. 2734 Reserved 4 - 11 2735 AES_CBC_128 12 This type MUST be 2736 supported. See [IKEv2]. 2737 AES_CTR 13 See [IKEv2]. 2738 Reserved to IANA 14 - 49152 2739 Private Use 49153 - 65535 2741 (00 - 23), MM is the minute within the hour (00 - 59), SS is the 2742 seconds within the minute (00 - 59), and followed by the letter Z 2743 to indicate that this is Zulu time. This format is loosely based 2744 on [RFC 3161]. 2746 Key Expiration Date (15 octets) -- This is the time value of when 2747 this key is no longer valid for use. This field contains the 2748 timestamp in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year 2749 (0000 - 9999), MM is the numerical value of the month (01 - 12), 2750 DD is the day of the month (01 - 31), HH is the hour of the day 2751 (00 - 23), MM is the minute within the hour (00 - 59), SS is the 2752 seconds within the minute (00 - 59), and followed by the letter Z 2753 to indicate that this is Zulu time. This format is loosely based 2754 on [RFC 3161]. 2756 Key Data (variable length) -- This is the actual key data, which is 2757 dependent on the Key Type algorithm for its format. 2759 NOTE: The combination of the Key ID and the Key Handle MUST be unique 2760 within the group. This combination will be used to uniquely identify 2761 a key. 2763 7.4.1.2 Rekey Array Structure 2765 A Rekey Array contains the information for the set of KEKs that is 2766 associated with a Group Member. Figure 13 shows the format for this 2767 structure. 2769 Rekey Version (1 octet) -- Contains the version of the Rekey 2770 protocol in which the data is formatted. For Key Download Data 2771 Item Type of Rekey - LKH, refer to Section A.2 for a description 2772 0 1 2 3 2773 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 2774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2775 ! Rekey Version#! Member ID ~ 2776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2777 ~ ! Number of KEK Keys ! ~ 2778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2779 ~ Key Datum(s) ~ 2780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2782 Figure 13: Rekey Array Structure Format 2784 of this value. This field is treated as an unsigned value. 2786 Member ID (4 octets) -- This is the Member ID of the Rekey sequence 2787 contained in this Rekey Array. This field is treated as an octet 2788 string. For Key Download Data Item Type of Rekey - LKH, refer to 2789 Section A.2 for a description of this value. 2791 Number of KEK Keys (2 octets) -- This value is the number of 2792 distinct KEK keys in this sequence. This value is treated as an 2793 unsigned integer in network byte order format. 2795 Key Datum(s) (variable length) -- The sequence of KEKs in Key 2796 Datum format. The format for each Key Datum in this sequence is 2797 defined in section 7.4.1.1. 2799 Key ID - For Key ID within the Rekey - LKH space, refer to 2800 Section A.2 for a description of this value. 2802 7.4.2 Key Download Payload Processing 2804 Prior to processing its data, the payload contents MUST be decrypted. 2806 When processing the Key Download Payload, the following fields MUST 2807 be checked for correct values: 2809 1. Next Payload, RESERVED, Payload Length - These fields are 2810 processed as defined in Section 7.2.2, Generic Payload Header 2811 Processing. 2813 2. KDD Item Type - All KDD Item Type fields MUST be checked to be 2814 a valid Key Download Data Item type as defined by Table 15. 2815 If the value is not valid, then an error is logged and if in 2816 Verbose mode an appropriate message containing notification value 2817 Payload-Malformed will be sent. 2819 3. Key Type - All Key Type fields MUST be checked to be a 2820 valid encryption type as defined by table 16. If the value 2821 is not valid, then an error is logged and if in Verbose 2822 mode an appropriate message containing notification value 2823 Invalid-Key-Information will be sent. 2825 4. Key Expiration Date - All Key Expiration Date fields MUST be 2826 checked confirm that their values represent a future and not a 2827 past time value. If the value is not valid, then an error is 2828 logged and if in Verbose mode an appropriate message containing 2829 notification value Invalid-Key-Information will be sent. 2831 The length and counter fields in the payload are used to help process 2832 the payload. If any field is found to be incorrect, then an error 2833 is logged and if in Verbose mode an appropriate message containing 2834 notification value Payload-Malformed will be sent. 2836 7.5 Rekey Event Payload 2838 Refer to the terminology section for the different terms relating to 2839 keys used within this section. 2841 7.5.1 Rekey Event Payload Structure 2843 The Rekey Event Payload MAY contain multiple keys encrypted in 2844 Wrapping KEKs. Figure 14 shows the format of the payload. If the 2845 data to be contained within a Rekey Event Payload is too large for 2846 the payload, the sequence can be split across multiple Rekey Event 2847 Payloads at a Rekey Event Data boundary. 2849 The Rekey Event Payload fields are defined as follows: 2851 Next Payload (1 octet) - Identifier for the payload type of the 2852 next payload in the message. If the current payload is the last 2853 in the message, then this field will be 0. This field provides 2854 the ``chaining`` capability. Table 12 identifies the payload 2855 types. This field is treated as an unsigned value. 2857 RESERVED (1 octet) - Unused, set to 0. 2859 Payload Length (2 octets) - Length in octets of the current 2860 payload, including the generic payload header. This field is 2861 0 1 2 3 2862 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 2863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2864 ! Next Payload ! RESERVED ! Payload Length ! 2865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2866 ! RekeyEvnt Type! Rekey Event Header ~ 2867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2868 ~ Rekey Event Data(s) ~ 2869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2871 Figure 14: Rekey Event Payload Format 2873 treated as an unsigned integer in network byte order format. 2875 Rekey Event Type (1 octet) - Specifies the type of Rekey Event 2876 being used. Table 17 presents the types of Rekey events. This 2877 field is treated as an unsigned value. 2879 Table 17: Rekey Event Types 2881 Rekey_Event_Type Value Definition/Defined In 2882 ______________________________________________________________________ 2884 None 0 This type MUST be implemented. 2885 In this case, the size of the Rekey 2886 Event Data field will be zero bytes 2887 long. The purpose of a Rekey Event 2888 Payload with type None is when it is 2889 necessary to send out a new token 2890 with no rekey information. GSAKMP 2891 Rekey Msg requires a Rekey Event 2892 Payload, and in this instance it 2893 would have rekey data of type None. 2894 GSAKMP_LKH 1 The rekey data will be of 2895 type LKH formatted according to 2896 GSAKMP. The format for this field 2897 is defined in Section 7.5.1.2. 2898 Reserved to IANA 2 - 192 2899 Private Use 193 - 255 2901 Rekey Event Header (variable length) - This is the header 2902 information for the Rekey Event. The format for this is defined 2903 in Section 7.5.1.1, Rekey Event Header Structure. 2905 Rekey Event Data(s) (variable length) - This is the rekey 2906 information for the Rekey Event. The format for this is defined 2907 in Section 7.5.1.2, Rekey Event Data(s) Structure. 2909 The Rekey Event payload type is three (3). 2911 7.5.1.1 Rekey Event Header Structure 2913 The format for the Rekey Event Header is shown in Figure 15. 2915 0 1 2 3 2916 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 2917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2918 ! Group ID Value ~ 2919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2920 ~ Group ID Value ! 2921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2922 ! Time/Date Stamp ~ 2923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2924 ~ ~ 2925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2926 ~ ~ 2927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2928 ~ ! RekeyEnt Type ~ 2929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2930 ! Algorithm Ver ! # of Rekey Event Data(s) ! 2931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2933 Figure 15: Rekey Event Header Format 2935 Group Identification Value (variable length) - Indicates the 2936 name/title of the group to be rekeyed. This is the same format, 2937 length and value as the Group Identification Value in Section 2938 7.1 GSAKMP Message Header. 2940 Time/Date Stamp (15 octets) -- This is the time value when the 2941 Rekey Event Data was generated. This field contains the 2942 timestamp in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year 2943 (0000 - 9999), MM is the numerical value of the month (01 - 12), 2944 DD is the day of the month (01 - 31), HH is the hour of the day 2945 (00 - 23), MM is the minute within the hour (00 - 59), SS is the 2946 seconds within the minute (00 - 59), and followed by the letter Z 2947 to indicate that this is Zulu time. This format is loosely based 2948 on [RFC 3161]. 2950 Rekey Event Type (1 octet) - This is the Rekey algorithm being 2951 used for this group. The values for this field can be found in 2952 Table 17. This field is treated as an unsigned value. 2954 Algorithm Version (1 octet) - Indicates the version of the Rekey 2955 Type being used. For Rekey Event Type of GSAKMP_LKH, refer to 2956 Section A.2 for a description of this value. This field is 2957 treated as an unsigned value. 2959 # of Rekey Event Data(s) (2 octets) - The number of Rekey Event 2960 Data(s) contained in the Rekey Data. This value is treated as an 2961 unsigned integer in network byte order. 2963 7.5.1.2 Rekey Event Data Structure 2965 As defined in the Rekey Event Header, # of Rekey Data(s) field, 2966 multiple pieces of information are sent in a Rekey Event Data. Each 2967 end user, will be interested in only one Rekey Event Data among all 2968 of the information sent. Each Rekey Event Data, will contain all 2969 the Key Packages that a user requires. For each Rekey Event Data, 2970 the data following the Wrapping fields is encrypted with the key 2971 identified in the Wrapping Header. Figure 16 shows the format of 2972 each Rekey Event Data. 2973 0 1 2 3 2974 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 2975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2976 ! Packet Length ! Wrapping KeyID ~ 2977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2978 ~ ! Wrapping Key Handle ~ 2979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2980 ~ ! # of Key Packages ! 2981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2982 ! Key Packages(s) ~ 2983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2985 Figure 16: Rekey Event Data Format 2987 Packet Length (2 octets) - Length in octets of the Rekey Event 2988 Data, which consists of the # of Key Packages and the Key 2989 Packages(s). This value is treated as an unsigned integer in 2990 network byte order. 2992 Wrapping KeyID (4 octets) - This is the Key ID of the KEK that is 2993 being used for encryption/decryption of the new (rekeyed) keys. 2994 For Rekey Event Type of Rekey - LKH, refer to Section A.2 for a 2995 description of this value. 2997 Wrapping Key Handle (4 octets) - This is a Key Handle of the KEK 2998 that is being used for encryption/decryption of the new (rekeyed) 2999 keys. Refer to Section 7.4.1.1 for the values of this field. 3001 # of Key Packages (2 octets) - The number of key packages contained 3002 in this Rekey Event Data. This value is treated as an unsigned 3003 integer in network byte order. 3005 Key Package(s) (variable length) - The type/length/value 3006 format of a Key Datum. The format for this is defined in 3007 Section 7.5.1.2.1. 3009 7.5.1.2.1 Key Package Structure 3011 Each Key Package contains all the information about the key. 3012 Figure 17 shows the format for a Key Package. 3013 0 1 2 3 3014 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 3015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3016 ! KeyPkg Type ! Key Package Length ! Key Datum ~ 3017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3019 Figure 17: Key Package Format 3021 Key Package Type (1 octet) - The type of key in this key package. 3022 Legal values for this field are defined in Table 15, Key Download 3023 Data Types. This field is treated as an unsigned value. 3025 Key Package Length (2 octets) - The length of the Key Datum. This 3026 field is treated as an unsigned integer in network byte order 3027 format. 3029 Key Datum (variable length) - The actual data of the key. The 3030 format for this field is defined in Section 7.4.1.1, Key Datum. 3032 7.5.2 Rekey Event Payload Processing 3034 When processing the Rekey Event Payload, the following fields MUST be 3035 checked for correct values: 3037 1. Next Payload, RESERVED, Payload Length - These fields are 3038 processed as defined in Section 7.2.2, Generic Payload Header 3039 Processing. 3041 2. Rekey Event Type field within "Rekey Event" payload header - The 3042 Rekey Event Type MUST be checked to be a valid rekey event type 3043 as defined by Table 17. If the Rekey Event Type is not valid, 3044 then regardless of mode (e.g., Terse or Verbose) an error is 3045 logged. No response error message is generated for receipt of a 3046 Group Management Message. 3048 3. Group ID Value - The Group ID value of the Rekey Event Header 3049 received message MUST be checked against the GroupID of the Group 3050 Component. If no match is found, the payload is discarded, then 3051 regardless of mode (e.g., Terse or Verbose) an error is logged. 3052 No response error message is generated for receipt of a Group 3053 Management Message. 3055 4. Date/Time Stamp - The Date/Time Stamp value of the Rekey Event 3056 Header MAY be checked to determine if the Rekey Event generation 3057 time is recent relative to network delay and processing times. 3058 If the TimeStamp is judged not to be recent, an error is logged. 3059 No response error message is generated for receipt of a Group 3060 Management Message. 3062 5. Rekey Event Type field within the "Rekey Event Header" - The 3063 Rekey Event Type of the Rekey Event Header received message 3064 MUST be checked to be a valid rekey event type as defined by 3065 Table 17 and the same value of the Rekey Event Type earlier in 3066 this payload. If the Rekey Event Type is not valid or not equal 3067 to the previous value of the Rekey Event Type, then regardless of 3068 mode (e.g., Terse or Verbose) an error is logged. No response 3069 error message is generated for receipt of a Group Management 3070 Message. 3072 6. Algorithm Version - The Rekey Algorithm Version number MUST be 3073 checked that it is supported. If the version is not supported, 3074 then regardless of mode (e.g., Terse or Verbose) an error is 3075 logged. No response error message is generated for receipt of a 3076 Group Management Message. 3078 The length and counter fields are used to help process the message. 3079 If any field is found to be incorrect, then termination processing 3080 MUST be initiated. 3082 A GM MUST process all the Rekey Event Datas as based on the Rekey 3083 method used there is a potential that multiple Rekey Event Datas are 3084 for this GM. The Rekey Event Datas are processed in order until all 3085 Rekey Event Datas are consumed. 3087 1. Wrapping KeyID - The Wrapping KeyID MUST be checked against the 3088 list of stored KEKs that this GM holds. If a match is found, 3089 then continue processing this Rekey Event Data. Otherwise, skip 3090 to the next Rekey Event Data. 3092 2. Wrapping Handle - If a matching Wrapping KeyID was found, then 3093 the Wrapping Handle MUST be checked against the handle of the KEK 3094 for which the KeyID was a match. If the handles match, then the 3095 GM will process the Key Packages associated with this Rekey Event 3096 Data. Otherwise, skip to the next Rekey Event Data. 3098 If a GM has found a matching Wrapping KeyID and Wrapping Handle, the 3099 GM decrypts the remaining data in this Rekey Event Data according to 3100 policy using the KEK defined by the Wrapping KeyID and Handle. After 3101 decrypting the data, the GM extracts the # of Key Packages field 3102 to help process the subsequent Key Packages. The Key Packages are 3103 processed as follows: 3105 1. Key Package Type - The Key Package Type MUST be checked to be 3106 a valid key package type as defined by Table 15. If the Key 3107 Package Type is not valid, then regardless of mode (e.g., Terse 3108 or Verbose) an error is logged. No response error message is 3109 generated for receipt of a Group Management Message. 3111 2. Key Package Length - The Key Package Length is used to process 3112 the subsequent Key Datum information. 3114 3. Key Type - The Key Type MUST be checked to be a valid key type as 3115 defined by Table 16. If the Key Package Type is not valid, then 3116 regardless of mode (e.g., Terse or Verbose) an error is logged. 3117 No response error message is generated for receipt of a Group 3118 Management Message. 3120 4. Key ID - The Key ID MUST be checked against the set of Key IDs 3121 that this user maintains for this Key Type. If no match is 3122 found, then regardless of mode (e.g., Terse or Verbose) an error 3123 is logged. No response error message is generated for receipt of 3124 a Group Management Message. 3126 5. Key Handle - The Key Handle is extracted as is and is used to be 3127 the new Key Handle for the Key currently associated with the Key 3128 Package's Key ID. 3130 6. Key Creation Date - The Key Creation Date MUST be checked that 3131 it is subsequent to the Key Creation Date for the currently 3132 held key. If this date is prior to the currently held key, then 3133 regardless of mode (e.g., Terse or Verbose) an error is logged. 3134 No response error message is generated for receipt of a Group 3135 Management Message. 3137 7. Key Expiration Date - The Key Expiration Date MUST be checked 3138 that it is subsequent to the Key Creation Date just received and 3139 that the time rules conform with policy. If the expiration date 3140 is not subsequent to the creation date or does not conform with 3141 policy, then regardless of mode (e.g., Terse or Verbose) an error 3142 is logged. No response error message is generated for receipt of 3143 a Group Management Message. 3145 8. Key Data - The Key Data is extracted based on the length 3146 information in the key package. 3148 If there were no errors when processing the Key Package, the key 3149 represented by the KeyID will have all of its data updated based upon 3150 the received information. 3152 7.6 Identification Payload 3154 7.6.1 Identification Payload Structure 3156 The Identification Payload contains entity-specific data used to 3157 exchange identification information. This information is used to 3158 verify the identities of members. Figure 18 shows the format of the 3159 Identification Payload. 3161 0 1 2 3 3162 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 3163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3164 ! Next Payload ! RESERVED ! Payload Length ! 3165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3166 ! ID Classif ! ID Type ! Identification Data ~ 3167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3169 Figure 18: Identification Payload Format 3171 The Identification Payload fields are defined as follows: 3173 Next Payload (1 octet) - Identifier for the payload type of the 3174 next payload in the message. If the current payload is the last 3175 in the message, then this field will be 0. This field provides 3176 the ``chaining`` capability. Table 12 identifies the payload 3177 types. This field is treated as an unsigned value. 3179 RESERVED (1 octet) - Unused, set to 0. 3181 Payload Length (2 octets) - Length in octets of the current 3182 payload, including the generic payload header. This field is 3183 treated as an unsigned integer in network byte order format. 3185 Identification (ID) Classification (1 octet) - Classifies the 3186 ownership of the Identification Data. Table 18 identifies 3187 possible values for this field. This field is treated as an 3188 unsigned value. 3190 Table 18: Identification Classification 3192 ID_Classification Value 3193 _______________________________ 3195 Sender 0 3196 Receiver 1 3197 Third Party 2 3198 Reserved to IANA 3 - 192 3199 Private Use 193 - 255 3201 Identification (ID) Type (1 octet) - Specifies the type of 3202 Identification being used. Table 19 identifies possible values 3203 for this type. This field is treated as an unsigned value. All 3204 defined types are OPTIONAL unless otherwise stated. 3206 Identification Data (variable length) - Contains identity 3207 information. The values for this field are group-specific and 3208 the format is specified by the ID Type field. The format for 3209 this field is stated in conjunction with the type in Table 19. 3211 The payload type for the Identification Payload is four (4). 3213 Table 19: Identification Types 3215 ID_Type Value PKIX Cert Description 3216 Field Defined In 3217 ______________________________________________________________________ 3219 Reserved 0 3220 ID_IPV4_ADDR 1 SubjAltName See [IKEv2] 3221 iPAddress sec 3.5. 3222 ID_FQDN 2 SubjAltName See [IKEv2] 3223 dNSName sec 3.5. 3224 ID_RFC822_ADDR 3 SubjAltName See [IKEv2] 3225 rfc822Name sec 3.5. 3226 Reserved 4 3227 ID_IPV6_ADDR 5 SubjAltName See [IKEv2] 3228 iPAddress sec 3.5. 3229 Reserved 6 - 8 3230 ID_DER_ASN1_DN 9 Entire Subject, See [IKEv2] 3231 bitwise Compare sec 3.5. 3232 Reserved 10 3233 ID_KEY_ID 11 N/A See [IKEv2] 3234 Reserved 12 - 29 sec 3.5. 3235 Unencoded Name 30 Subject The format for 3236 (ID_U_NAME) this type is 3237 defined in 3238 Section 7.6.1.1. 3239 ID_DN_STRING 31 Subject See [OpenLDAP]. 3240 This type MUST be 3241 implemented. 3242 Reserved to IANA 32 - 192 3243 Private Use 193 - 255 3245 7.6.1.1 ID_U_NAME Structure 3247 The format for type Unencoded Name (ID_U_NAME) is shown in Figure 19. 3249 0 1 2 3 3250 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 3251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3252 ! Serial Number ~ 3253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3254 ~ ~ 3255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3256 ~ ~ 3257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3258 ~ ~ 3259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3260 ~ ! 3261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3262 ! Length ! 3263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3264 ! DN Data ~ 3265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3267 Figure 19: Unencoded Name (ID-U-NAME) Format 3269 Serial Number (20 octets) -- The certificate serial number. This 3270 field is treated as an unsigned integer in network byte order 3271 format. 3273 Length (4 octets) -- Length in octets of the DN Data field. This 3274 field is treated as an unsigned integer in network byte order 3275 format. 3277 DN Data (variable length) -- The actual UTF-8 DN value (Subject 3278 field) using the slash (/) character for field delimiters. 3279 (e.g., "/C=US/ST=MD/L=Somewhere/O=ACME, Inc./OU=DIV1/CN=user1/ 3280 Email=user1@acme.com" without the surrounding quotes) 3282 7.6.2 Identification Payload Processing 3284 When processing the Identification Payload, the following fields MUST 3285 be checked for correct values: 3287 1. Next Payload, RESERVED, Payload Length - These fields are 3288 processed as defined in Section 7.2.2, Generic Payload Header 3289 Processing. 3291 2. Identification Classification - The Identification Classification 3292 value MUST be checked to be a valid identification classification 3293 type as defined by Table 18. If the value is not valid, then 3294 an error is logged and if in Verbose mode an appropriate message 3295 containing notification value Payload-Malformed will be sent. 3297 3. Identification Type - The Identification Type value MUST be 3298 checked to be a valid identification type as defined by Table 19. 3299 If the value is not valid, then an error is logged and if in 3300 Verbose mode an appropriate message containing notification value 3301 Payload-Malformed will be sent. 3303 4. Identification Data - This Identification Data MUST be processed 3304 according to the identification type specified. The type will 3305 define the format of the data. If the identification data 3306 is being used to find a match and no match is found, then an 3307 error is logged and if in Verbose mode an appropriate message 3308 containing notification value Invalid-ID-Information will be 3309 sent. 3311 7.6.2.1 ID_U_NAME Processing 3313 When processing the Identification Data of type ID_U_NAME, the 3314 following fields MUST be checked for correct values: 3316 1. Serial Number - The serial number MUST be a greater than or equal 3317 to one (1) to be a valid serial number from a conforming CA [RFC 3318 3280]. If the value is not valid, then an error is logged and 3319 if in Verbose mode an appropriate message containing notification 3320 value Payload-Malformed will be sent. 3322 2. DN Data - The DN data is processed as a UTF-8 string. 3324 3. The CA MUST be a valid trusted policy creation authority as 3325 defined by the Policy Token. 3327 These 2 pieces of information, Serial Number and DN Data, in 3328 conjunction will then be used for party identification. These values 3329 are also used to help identify the certificate when necessary. 3331 7.7 Certificate Payload 3333 7.7.1 Certificate Payload Structure 3335 The Certificate Payload provides a means to transport certificates 3336 or other certificate-related information via GSAKMP and can appear 3337 in any GSAKMP message. Certificate payloads SHOULD be included 3338 in an exchange whenever an appropriate directory service (e.g. 3339 Secure DNS [DNSSEC]) is not available to distribute certificates. 3340 Multiple certificate payloads MAY be sent to enable verification of 3341 certificate chains. Conversely, zero (0) certificate payloads may 3342 be sent and the receiving GSAKMP MUST rely on some other mechanism to 3343 retrieve certificates for verification purposes. Figure 20 shows the 3344 format of the Certificate Payload. 3346 0 1 2 3 3347 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 3348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3349 ! Next Payload ! RESERVED ! Payload Length ! 3350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3351 ! Cert Type ! Certificate Data ~ 3352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3354 Figure 20: Certificate Payload Format 3356 The Certificate Payload fields are defined as follows: 3358 Next Payload (1 octet) - Identifier for the payload type of the 3359 next payload in the message. If the current payload is the last 3360 in the message, then this field will be 0. This field provides 3361 the ``chaining`` capability. Table 12 identifies the payload 3362 types. This field is treated as an unsigned value. 3364 RESERVED (1 octet) - Unused, set to 0. 3366 Payload Length (2 octets) - Length in octets of the current 3367 payload, including the generic payload header. This field is 3368 treated as an unsigned integer in network byte order format. 3370 Certificate Type (2 octets) - This field indicates the type of 3371 certificate or certificate-related information contained in 3372 the Certificate Data field. Table 20 presents the types of 3373 certificate payloads. This field is treated as an unsigned 3374 integer in network byte order format. 3376 Certificate Data (variable length) - Actual encoding of certificate 3377 Table 20: Certificate Payload Types 3379 Certificate_Type Value Description/ 3380 Defined In 3381 ______________________________________________________________________ 3383 None 0 3384 Reserved 1 - 3 3385 X.509v3 Certificate 4 This type MUST be 3386 -- Signature implemented. 3387 -- DER Encoding Contains a DER 3388 encoded X.509 3389 certificate. 3390 Reserved 5 - 6 3391 Certificate Revocation List 7 Contains a BER 3392 (CRL) encoded X.509 CRL. 3393 Reserved 8 - 9 3394 X.509 Certificate 10 See [IKEv2] sec 3.6. 3395 -- Attribute 3396 Raw RSA Key 11 See [IKEv2] sec 3.6. 3397 Hash and URL of X.509 12 See [IKEv2] sec 3.6. 3398 Certificate 3399 Hash and URL of X.509 13 See [IKEv2] sec 3.6. 3400 bundle 3401 Reserved to IANA 14 -- 49152 3402 Private Use 49153 -- 65535 3404 data. The type of certificate is indicated by the Certificate 3405 Type/Encoding field. 3407 The payload type for the Certificate Payload is six (6). 3409 7.7.2 Certificate Payload Processing 3411 When processing the Certificate Payload, the following fields MUST be 3412 checked for correct values: 3414 1. Next Payload, RESERVED, Payload Length - These fields are 3415 processed as defined in Section 7.2.2, Generic Payload Header 3416 Processing. 3418 2. Certificate Type - The Certificate Type value MUST be checked 3419 to be a valid certificate type as defined by Table 20. If the 3420 value is not valid, then an error is logged and if in Verbose 3421 mode an appropriate message containing notification value 3422 Cert-Type-Unsupported will be sent. 3424 3. Certificate Data - This Certificate Data MUST be processed 3425 according to the certificate type specified. The type will 3426 define the format of the data. Receipt of a certificate of the 3427 trusted policy creation authority in a Certificate payload causes 3428 the payload to be discarded. This received certificate MUST NOT 3429 be used to verify the message. The certificate of the trusted 3430 policy creation authority MUST be retrieved by other means. 3432 7.8 Signature Payload 3434 7.8.1 Signature Payload Structure 3436 The Signature Payload contains data generated by the digital 3437 signature function. The digital signature, as defined by the 3438 dissection of each message, covers the message from the GSAKMP 3439 Message Header through the Signature Payload up to but not including 3440 the Signature Data Length. Figure 21 shows the format of the 3441 Signature Payload. 3443 0 1 2 3 3444 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 3445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3446 ! Next Payload ! RESERVED ! Payload Length ! 3447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3448 ! Signature Type ! Sig ID Type ! ~ 3449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3450 ~ Signature Timestamp ~ 3451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3452 ~ ~ 3453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3454 ~ ~ 3455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3456 ~ ! Signer ID Length ! 3457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3458 ! Signer ID Data ~ 3459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3460 ! Signature Length ! Signature Data ~ 3461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3462 ~ ~ 3463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3465 Figure 21: Signature Payload Format 3467 The Signature Payload fields are defined as follows: 3469 Next Payload (1 octet) - Identifier for the payload type of the 3470 next payload in the message. If the current payload is the last 3471 in the message, then this field will be 0. This field provides 3472 the ``chaining`` capability. Table 12 identifies the payload 3473 types. This field is treated as an unsigned value. 3475 RESERVED (1 octet) - Unused, set to 0. 3477 Payload Length (2 octets) - Length in octets of the current 3478 payload, including the generic payload header. This field is 3479 treated as an unsigned integer in network byte order format. 3481 Signature Type (2 octets) -- Indicates the type of signature. 3482 Table 21 presents the allowable signature types. This field is 3483 treated as an unsigned integer in network byte order format. 3485 Table 21: Signature Types 3487 Signature Type Value Description/ 3488 Defined In 3489 ______________________________________________________________________ 3491 DSS/SHA1 with ASN.1/DER encoding 0 This type MUST be 3492 (DSS-SHA1-ASN1-DER) supported. 3493 RSA1024-MD5 1 See [RFC 3447]. 3494 ECDSA-P384-SHA3 2 See [FIPS 186-2]. 3495 Reserved to IANA 3 - 41952 3496 Private Use 41953 - 65536 3498 Signature ID Type (1 octet) -- Indicates the format for the 3499 Signature ID Data. These values are the same as those defined 3500 for the Identification Payload Identification types which can be 3501 found in Table 19. This field is treated as an unsigned value. 3503 Signature Timestamp (15 octets) -- This is the time value when the 3504 digital signature was applied. This field contains the timestamp 3505 in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 - 3506 9999), MM is the numerical value of the month (01 - 12), DD is 3507 the day of the month (01 - 31), HH is the hour of the day (00 3508 - 23), MM is the minute within the hour (00 - 59), SS is the 3509 seconds within the minute (00 - 59), and followed by the letter Z 3510 to indicate that this is Zulu time. This format is loosely based 3511 on [RFC 3161]. 3513 Signer ID Length (2 octets) - Length in octets of the Signer' ID. 3514 This field is treated as an unsigned integer in network byte 3515 order format. 3517 Signer ID Data (variable length) -- Data identifying the Signer's 3518 ID (e.g., DN). The format for this field is based on the 3519 Signature ID Type field and is shown where that type is defined. 3520 The contents of this field MUST be checked against the Policy 3521 Token to determine the authority and access of the Signer within 3522 the context of the group. 3524 Signature Length (2 octets) -- Length in octets of the Signature 3525 Data. This field is treated as an unsigned integer in network 3526 byte order format. 3528 Signature Data (variable length) - Data that results from applying 3529 the digital signature function to the GSAKMP message and/or 3530 payload. 3532 The payload type for the Signature Payload is eight (8). 3534 7.8.2 Signature Payload Processing 3536 When processing the Signature Payload, the following fields MUST be 3537 checked for correct values: 3539 1. Next Payload, RESERVED, Payload Length - These fields are 3540 processed as defined in Section 7.2.2, Generic Payload Header 3541 Processing. 3543 2. Signature Type - The Signature Type value MUST be checked to 3544 be a valid signature type as defined by Table 21. If the 3545 value is not valid, then an error is logged and if in Verbose 3546 mode an appropriate message containing notification value 3547 Payload-Malformed will be sent. 3549 3. Signature ID Type - The Signature ID Type value MUST be checked 3550 to be a valid signature ID type as defined by Table 19. If the 3551 value is not valid, then an error is logged and if in Verbose 3552 mode an appropriate message containing notification value 3553 Payload-Malformed will be sent. 3555 4. Signature Timestamp - This field MAY be checked to determine 3556 if the transaction signing time is fresh relative to expected 3557 network delays. Such a check is appropriate for systems in which 3558 archived sequences of events is desired. 3560 NOTE: The maximum acceptable age of a signature timestamp 3561 relative to the local system clock is a locally configured 3562 parameter that can be tuned by its GSAKMP management interface. 3564 5. Signature ID Data - This field will be used to identify the 3565 sending party. This information MUST then be used to confirm 3566 that the correct party sent this information. This field is also 3567 used to retrieve the appropriate public key of the certificate to 3568 verify the message. 3570 6. Signature Data - This value MUST be compared to the recomputed 3571 signature to verify the message. Information on how to verify 3572 certificates used to ascertain the validity of the signature 3573 can be found in [RFC 3280]. Only after the certificate 3574 identified by the Signature ID Data is verified can the signature 3575 be computed to compare to the signature data for signature 3576 verification. A potential error that can occur during signature 3577 verification is Authentication-Failed. Potential errors 3578 that can occur while processing certificates for signature 3579 verification are: Invalid-Certificate, Invalid-Cert-Authority, 3580 Cert-Type-Unsupported, and Certificate-Unavailable. 3582 The length fields in the Signature Payload are used to process the 3583 remainder of the payload. If any field is found to be incorrect, 3584 then termination processing MUST be initiated. 3586 7.9 Notification Payload 3588 7.9.1 Notification Payload Structure 3590 The Notification Payload can contain both GSAKMP and group specific 3591 data and is used to transmit informational data, such as error 3592 conditions, to a GSAKMP peer. It is possible to send multiple 3593 independent Notification payloads in a single GSAKMP message. 3594 Figure 22 shows the format of the Notification Payload. 3596 0 1 2 3 3597 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 3598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3599 ! Next Payload ! RESERVED ! Payload Length ! 3600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3601 ! Notification Type ! Notification Data ~ 3602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3604 Figure 22: Notification Payload Format 3606 The Notification Payload fields are defined as follows: 3608 Next Payload (1 octet) - Identifier for the payload type of the 3609 next payload in the message. If the current payload is the last 3610 in the message, then this field will be 0. This field provides 3611 the ``chaining`` capability. Table 12 identifies the payload 3612 types. This field is treated as an unsigned value. 3614 RESERVED (1 octet) - Unused, set to 0. 3616 Payload Length (2 octets) - Length in octets of the current 3617 payload, including the generic payload header. This field is 3618 treated as an unsigned integer in network byte order format. 3620 Notification Type (2 octets) - Specifies the type of notification 3621 message. Table 22 presents the Notify Payload Types. This field 3622 is treated as an unsigned integer in network byte order format. 3624 Notification Data (variable length) - Informational or error data 3625 transmitted in addition to the Notify Payload Type. Values for 3626 this field are Domain of Interpretation (DOI)-specific. 3628 The payload type for the Notification Payload is nine (9). 3630 Table 22: Notification Types 3632 Notification Type Value 3633 __________________________________________________________ 3635 None 0 3636 Invalid-Payload-Type 1 3637 Reserved 2 - 3 3638 Invalid-Version 4 3639 Invalid-Group-ID 5 3640 Invalid-Sequence-ID 6 3641 Payload-Malformed 7 3642 Invalid-Key-Information 8 3643 Invalid-ID-Information 9 3644 Reserved 10 - 11 3645 Cert-Type-Unsupported 12 3646 Invalid-Cert-Authority 13 3647 Authentication-Failed 14 3648 Reserved 15 - 16 3649 Certificate-Unavailable 17 3650 Reserved 18 3651 Unauthorized-Request 19 3652 Reserved 20 - 22 3653 Acknowledgment 23 3654 Reserved 24 - 25 3655 Nack 26 3656 Cookie-Required 27 3657 Cookie 28 3658 Mechanism Choices 29 3659 Leave Group 30 3660 Departure Accepted 31 3661 Request to Depart Error 32 3662 Invalid Exchange Type 33 3663 IPv4 Value 34 3664 IPv6 Value 35 3665 Prohibited by Group Policy 36 3666 Prohibited by Locally Configured Policy 37 3667 Reserved to IANA 38 - 49152 3668 Private Use 49153 -- 65535 3670 7.9.1.1 Notification Data - Acknowledgment (ACK) Payload Type 3672 The data portion of the Notification payload of type ACK serves 3673 either for confirmation of correct receipt of the Key Download 3674 message, or, when needed, can provide other receipt information when 3675 included in a signed message. Figure 23 shows the format of the 3676 Notification Data - Acknowledge Payload Type. 3678 0 1 2 3 3679 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 3680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3681 ! Ack Type ! Acknowledgment Data ~ 3682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3684 Figure 23: Notification Data - Acknowledge Payload Type Format 3686 The Notification Data - Acknowledgment Payload Type data fields are 3687 defined as follows: 3689 Ack Type (1 octet) - Specifies the type of acknowledgment. 3690 Table 23 presents the Notify Acknowledgment Payload Types. This 3691 field is treated as an unsigned value. 3693 Table 23: Acknowledgment Types 3695 ACK_Type Value Definition 3696 _____________________________________________________ 3698 Simple 0 Data portion null. 3699 Reserved to IANA 1 - 192 3700 Private Use 193 - 255 3702 7.9.1.2 Notification Data - Cookie_Required and Cookie Payload Type 3704 The data portion of the Notification payload of types Cookie_Required 3705 and Cookie contain the Cookie value. The value for this field will 3706 have been computed by the responder GC/KS and sent to the GM. The 3707 GM will take the value received and copy it into the Notification 3708 payload Notification Data field of type Cookie that is transmitted in 3709 the "Request to Join with Cookie Info" back to the GC/KS. The cookie 3710 value MUST NOT be modified. 3712 The format for this is already described in the discussion on cookies 3713 in section 5.2.2. 3715 7.9.1.3 Notification Data - Mechanism Choices Payload Type 3717 The data portion of the Notification payload of types Mechanism 3718 Choices contains the mechanisms the GM is requesting to use for the 3719 negotiation with the GC/KS. This information will be supplied by the 3720 GM in a RTJ message. Figure 24 shows the format of the Notification 3721 Data - Mechanism Choices Payload Type. Multiple type|length|data 3722 choices are strung together in one notification payload to allow a 3723 user to transmit all relevant information within one Notification 3724 Payload. The length of the payload will control the parsing of the 3725 Notification Data Mechanism Choices field. 3727 0 1 2 3 3728 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 3729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3730 ! Mech Type ! Mechanism Choice Data ! 3731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.. 3733 Figure 24: Notification Data - Mechanism Choices Payload Type Format 3735 The Notification Data - Mechanism Choices Payload Type data fields 3736 are defined as follows: 3738 Mechanism Type (1 octet) - Specifies the type of mechanism. 3739 Table 24 presents the Notify Mechanism Choices Mechanism Types. 3740 This field is treated as an unsigned value. 3742 Table 24: Mechanism Types 3744 Mechanism_Type Value Mechanism Choice 3745 Data Value Table Reference 3746 ___________________________________________________________________ 3748 Key Creation Algorithm 0 Table 26 3749 Encryption Algorithm 1 Table 16 3750 Nonce Hash Algorithm 2 Table 25 3751 Reserved to IANA 3 - 192 3752 Private Use 193 - 255 3754 Mechanism Choice Data (2 octets) - The data value for the mechanism 3755 type being selected. The values are specific to each Mechanism 3756 Type defined. All tables necessary to define the values that 3757 are not defined elsewhere (in this specification or others) are 3758 defined here. This field is treated as an unsigned integer in 3759 network byte order format. 3761 Table 25: Nonce Hash Types 3763 Nonce_Hash_Type Value Description 3764 ___________________________________________________________________ 3766 Reserved 0 3767 SHA-1 1 This type MUST be supported. 3768 Reserved to IANA 2 - 49152 3769 Private Use 49153 - 65535 3771 7.9.1.4 Notification Data - IPv4 and IPv6 Value Payload Types 3773 The data portion of the Notification payload of type IPv4 and IPv6 3774 value contains the appropriate IP value in network byte order. This 3775 value will be set by the creator of the message for consumption by 3776 the receiver of the message. 3778 7.9.2 Notification Payload Processing 3780 When processing the Notification Payload, the following fields MUST 3781 be checked for correct values: 3783 1. Next Payload, RESERVED, Payload Length - These fields are 3784 processed as defined in Section 7.2.2, Generic Payload Header 3785 Processing. 3787 2. Notification Type - The Notification type value MUST be checked 3788 to be a notification type as defined by Table 22. If the 3789 value is not valid, then an error is logged and if in Verbose 3790 mode an appropriate message containing notification value 3791 Payload-Malformed will be sent. 3793 3. Notification Data - This Notification Data MUST be processed 3794 according to the notification type specified. The type will 3795 define the format of the data. When processing this data, 3796 any type field MUST be checked against the appropriate table 3797 for correct values. If the contents of the Notification Data 3798 are not valid, then an error is logged and if in Verbose 3799 mode an appropriate message containing notification value 3800 Payload-Malformed will be sent. 3802 7.10 Vendor ID Payload 3804 7.10.1 Vendor ID Payload Structure 3806 The Vendor ID Payload contains a vendor defined constant. The 3807 constant is used by vendors to identify and recognize remote 3808 instances of their implementations. This mechanism allows a 3809 vendor to experiment with new features while maintaining backwards 3810 compatibility. Figure 25 shows the format of the payload. 3812 0 1 2 3 3813 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 3814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3815 ! Next Payload ! RESERVED ! Payload Length ! 3816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3817 ! Vendor ID (VID) ~ 3818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3820 Figure 25: Vendor ID Payload Format 3822 A Vendor ID payload MAY announce that the sender is capable to 3823 accepting certain extensions to the protocol, or it MAY simply 3824 identify the implementation as an aid in debugging. A Vendor ID 3825 payload MUST NOT change the interpretation of any information defined 3826 in this specification. Multiple Vendor ID payloads MAY be sent. An 3827 implementation is NOT REQUIRED to send any Vendor ID payload at all. 3829 A Vendor ID payload may be sent as part of any message. Reception 3830 of a familiar Vendor ID payload allows an implementation to make 3831 use of Private Use numbers described throughout this specification 3832 -- private payloads, private exchanges, private notifications, etc. 3833 This implies that all the processing rules defined for all the 3834 payloads are now modified to recognize all values defined by this 3835 Vendor ID for all fields of all payloads. Unfamiliar Vendor IDs MUST 3836 be ignored. 3838 Writers of Internet-Drafts who wish to extend this protocol MUST 3839 define a Vendor ID payload to announce the ability to implement the 3840 extension in the Internet-Draft. It is expected that Internet-Drafts 3841 which gain acceptance and are standardized will be given assigned 3842 values out of the Reserved to IANA range and the requirement to use 3843 a Vendor ID payload will go away. 3845 The VendorID Payload fields are defined as follows: 3847 Next Payload (1 octet) - Identifier for the payload type of the 3848 next payload in the message. If the current payload is the last 3849 in the message, then this field will be 0. This field provides 3850 the ``chaining`` capability. Table 12 identifies the payload 3851 types. This field is treated as an unsigned value. 3853 RESERVED (1 octet) - Unused, set to 0. 3855 Payload Length (2 octets) - Length in octets of the current 3856 payload, including the generic payload header. This field is 3857 treated as an unsigned integer in network byte order format. 3859 Vendor ID (variable length) - The Vendor ID value. The 3860 minimum length for this field is four (4) octets. It is the 3861 responsibility of the person choosing the Vendor ID to assure its 3862 uniqueness in spite of the absence of any central registry for 3863 IDs. Good practice is to include a company name, a person name 3864 or similar type data. A message digest of a long unique string 3865 is preferable to the long unique string itself. 3867 The payload type for the Vendor ID Payload is ten (10). 3869 7.10.2 Vendor ID Payload Processing 3871 When processing the Vendor ID Payload, the following fields MUST be 3872 checked for correct values: 3874 1. Next Payload, RESERVED, Payload Length - These fields are 3875 processed as defined in Section 7.2.2, Generic Payload Header 3876 Processing. 3878 2. Vendor ID - The Vendor ID Data MUST be processed to determine if 3879 the Vendor ID value is recognized by the implementation. If the 3880 Vendor ID value is not recognized, then regardless of mode (e.g., 3881 Terse or Verbose) this information is logged. Processing of the 3882 message MUST continue regardless of recognition of this value. 3884 It is recommended that implementations that want to use Vendor ID 3885 specific information attempt to process the Vendor ID payloads of an 3886 incoming message prior to the remainder of the message processing. 3887 This will allow the implementation to recognize that when processing 3888 other payloads that it can use the larger set of values for payload 3889 fields (Private Use values, etc.) as defined by the recognized 3890 Vendor IDs. 3892 7.11 Key Creation Payload 3894 7.11.1 Key Creation Payload Structure 3896 The Key Creation Payload contains information used to create key 3897 encryption keys. The security attributes for this payload are 3898 provided in the Policy Token. Figure 26 shows the format of the 3899 payload. 3901 0 1 2 3 3902 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 3903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3904 ! Next Payload ! RESERVED ! Payload Length ! 3905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3906 ! Key Creation Type ! Key Creation Data ~ 3907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3909 Figure 26: Key Creation Payload Format 3911 The Key Creation Payload fields are defined as follows: 3913 Next Payload (1 octet) - Identifier for the payload type of the 3914 next payload in the message. If the current payload is the last 3915 in the message, then this field will be 0. This field provides 3916 the ``chaining`` capability. Table 12 identifies the payload 3917 types. This field is treated as an unsigned value. 3919 RESERVED (1 octet) - Unused, set to 0. 3921 Payload Length (2 octets) - Length in octets of the current 3922 payload, including the generic payload header. This field is 3923 treated as an unsigned integer in network byte order format. 3925 Key Creation Type (2 octets) - Specifies the type of Key Creation 3926 being used. Table 26 identifies the types of key creation 3927 information. This field is treated as an unsigned integer in 3928 network byte order format. 3930 Key Creation Data (variable length) - Contains Key Creation 3931 information. The values for this field are group specific and 3932 the format is specified by the key creation type field. 3934 The payload type for the Key Creation Packet is eleven (11). 3936 Table 26: Types Of Key Creation Information 3938 Key Creation Type Value Definition/Defined In 3939 ______________________________________________________________________ 3941 Reserved 0 - 1 3942 Diffie-Hellman 2 This type MUST be supported. 3943 1024-bit MODP Group Defined in [IKEv2] B.2. 3944 Truncated If the output of the process 3945 is longer than needed for 3946 the defined mechanism, use 3947 the first X low order bits, 3948 and truncate the remainder. 3949 Reserved 3 - 13 3950 Diffie-Hellman 14 Defined in [RFC 3526]. 3951 2048-bit MODP Group If the output of the process 3952 Truncated is longer than needed for 3953 the defined mechanism, use 3954 the first X low order bits, 3955 and truncate the remainder. 3956 Reserved to IANA 15 - 49152 3957 Private Use 49153 - 65535 3959 7.11.2 Key Creation Payload Processing 3961 The specifics of the Key Creation Payload are defined in 3962 section 7.11. 3964 When processing the Key Creation Payload, the following fields MUST 3965 be checked for correct values: 3967 1. Next Payload, RESERVED, Payload Length - These fields are 3968 processed as defined in Section 7.2.2, Generic Payload Header 3969 Processing. 3971 2. Key Creation Type - The Key Creation Type value MUST be checked 3972 to be a valid key creation type as defined by Table 26. If the 3973 value is not valid, then an error is logged and if in Verbose 3974 mode an appropriate message containing notification value 3975 Payload-Malformed will be sent. 3977 3. Key Creation Data - This Key Creation Data MUST be processed 3978 according to the key creation type specified to generate the KEK 3979 to protect the information to be sent in the appropriate message. 3980 The type will define the format of the data. 3982 Implementations that want to derive other keys from the initial Key 3983 Creation keying material, for example, DH Secret keying material, 3984 MUST define a Key Creation Type other than one of those shown in 3985 Table 26. The new Key Creation Type must specify that derivation's 3986 algorithm, for which the KEK MAY be one of the keys derived. 3988 7.12 Nonce Payload 3990 7.12.1 Nonce Payload Structure 3992 The Nonce Payload contains random data used to guarantee freshness 3993 during an exchange and protect against replay attacks. Figure 27 3994 shows the format of the Nonce Payload. 3995 0 1 2 3 3996 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 3997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3998 ! Next Payload ! RESERVED ! Payload Length ! 3999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4000 ! Nonce Type ! Nonce Data ~ 4001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4003 Figure 27: Nonce Payload Format 4005 The Nonce Payload fields are defined as follows: 4007 Next Payload (1 octet) - Identifier for the payload type of the 4008 next payload in the message. If the current payload is the last 4009 in the message, then this field will be 0. This field provides 4010 the ``chaining`` capability. Table 12 identifies the payload 4011 types. This field is treated as an unsigned value. 4013 RESERVED (1 octet) - Unused, set to 0. 4015 Payload Length (2 octets) - Length in octets of the current 4016 payload, including the generic payload header. This field is 4017 treated as an unsigned integer in network byte order format. 4019 Nonce Type (1 octet) - Specifies the type of Nonce being used. 4020 Table 27 identifies the types of nonces. This field is treated 4021 as an unsigned value. 4023 Nonce Data (variable length) - Contains the nonce information. 4024 The values for this field are group-specific and the format 4025 is specified by the Nonce Type field. If no group-specific 4026 Table 27: Nonce Types 4028 Nonce_Type Value Definition 4029 ______________________________________________________________________ 4031 None 0 4032 Initiator (Nonce_I) 1 4033 Responder (Nonce_R) 2 4034 Combined (Nonce_C) 3 Hash (Append 4035 (Initiator_Value,Responder_Value)) 4036 The hash type comes from the 4037 Policy (e.g., Security Suite 4038 Definition of Policy Token). 4039 Reserved to IANA 4 - 192 4040 Private Use 192 - 255 4042 information is provided, the minimum length for this field is 4 4043 bytes. 4045 The payload type for the Nonce Payload is twelve (12). 4047 7.12.2 Nonce Payload Processing 4049 When processing the Nonce Payload, the following fields MUST be 4050 checked for correct values: 4052 1. Next Payload, RESERVED, Payload Length - These fields are 4053 processed as defined in Section 7.2.2, Generic Payload Header 4054 Processing. 4056 2. Nonce Type - The Nonce Type value MUST be checked to be a valid 4057 nonce type as defined by Table 27. If the value is not valid, 4058 then an error is logged and if in Verbose mode an appropriate 4059 message containing notification value Payload-Malformed will be 4060 sent. 4062 3. Nonce Data - This is the nonce data and it must be checked 4063 according to its content. The size of this field is defined 4064 in Nonce Payload section 7.12. Refer to the Message Processing 4065 Group Establishment section (Section 5.2) for interpretation of 4066 this field. 4068 8 GSAKMP State Diagram 4070 Figure 28 presents the states encountered in the use of this 4071 protocol. Table 28 defines the states. Table 29 defines the 4072 transitions. 4074 !-----------------> ( ) 4075 ! !-------------> ( Idle ) <------------------! 4076 ! ! ( ) ! 4077 ! ! ! ! ! 4078 ! ! ! ! ! 4079 ! ! (1a) (1) ! 4080 ! ! ! ! ! 4081 ! ! ! ! ! 4082 ! ! V V ! 4083 ! !---(5a)--- (Wait for ) (Wait for ) ----(5)-----! 4084 ! (Group ) (GC/KS Event) <--- 4085 ! (Membership) ^ ! \ \ 4086 ! ! ! ! \ \ 4087 ! ! ! ! \--(2)---\ 4088 ! (2a) (4)(3) 4089 ! ! ! ! 4090 ! ! ! ! 4091 ! V ! V 4092 !-------(4a)--- (Wait for ) (Wait for ) 4093 (Group ) (Response ) 4094 (Membership) (from Key ) 4095 /--> (Event ) (Download ) 4096 / / 4097 / / 4098 /--(3a)---/ 4100 Figure 28: GSAKMP State Diagram 4101 Table 28: GSAKMP States 4102 ______________________________________________________________________ 4104 Idle : GSAKMP Application waiting for input 4105 ______________________________________________________________________ 4107 Wait for GC/KS Event : GC/KS up and running, waiting for events 4108 ______________________________________________________________________ 4110 Wait for Response : GC/KS has sent Key Download, 4111 from Key Download : waiting for response from GM 4112 ______________________________________________________________________ 4114 Wait for Group : GM in process of joining group 4115 Membership : 4116 ______________________________________________________________________ 4118 Wait for Group : GM has group key, waiting for 4119 Membership Event : group management messages. 4120 ______________________________________________________________________ 4121 Table 29: State Transition Events 4122 ____________________________________________________________________ 4124 Transition 1 : Create group command 4125 ______________:_____________________________________________________ 4126 : 4127 Transition 2 : Receive bad RTJ 4128 : Receive valid command to change group membership 4129 : Send Compromise message x times 4130 : Member Deregistration 4131 ______________:_____________________________________________________ 4132 : 4133 Transition 3 : Receive valid RTJ 4134 ______________:_____________________________________________________ 4135 : 4136 Transition 4 : Timeout 4137 : Receive Ack 4138 : Receive Nack 4139 ______________:_____________________________________________________ 4140 : 4141 Transition 5 : Delete group command 4142 ______________:_____________________________________________________ 4143 : 4144 Transition 1a : Join group command 4145 ______________:_____________________________________________________ 4146 : 4147 Transition 2a : Send Ack 4148 ______________:_____________________________________________________ 4149 : 4150 Transition 3a : Receipt of group management messages 4151 ______________:_____________________________________________________ 4152 : 4153 Transition 4a : Delete group command 4154 : Deregistration command 4155 ______________:_____________________________________________________ 4156 : 4157 Transition 5a : Time out 4158 : Msg failure 4159 : errors 4160 : 4162 ____________________________________________________________________ 4164 9 IANA Considerations 4166 9.1 IANA Port Number Assignment 4168 IANA has provided GSAKMP port number 3761 in both the UDP and TCP 4169 spaces. All implementations MUST use this port assignment in the 4170 appropriate manner. 4172 9.2 Initial IANA Registry Contents 4174 The following registry entries should be created: 4176 GSAKMP Group Identification Types (section 7.1.1) 4177 GSAKMP Payload Types (section 7.1.1) 4178 GSAKMP Exchange Types (section 7.1.1) 4179 GSAKMP Policy Token Types (section 7.3.1) 4180 GSAKMP Key Download Data Item Types (section 7.4.1) 4181 GSAKMP Cryptographic Key Types (section 7.4.1.1) 4182 GSAKMP Rekey Event Types (section 7.5.1) 4183 GSAKMP Identification Classification (section 7.6.1) 4184 GSAKMP Identification Types (section 7.6.1) 4185 GSAKMP Certificate Types (section 7.7.1) 4186 GSAKMP Signature Types (section 7.8.1) 4187 GSAKMP Notification Types (section 7.9.1) 4188 GSAKMP Acknowledgment Types (section 7.9.1.1) 4189 GSAKMP Mechanism Types (section 7.9.1.3) 4190 GSAKMP Nonce Hash Types (section 7.9.1.3) 4191 GSAKMP Key Creation Types (section 7.11.1) 4192 GSAKMP Nonce Types (section 7.12.1) 4194 Changes and additions to the following registries are by IETF 4195 Standards Action: 4197 GSAKMP Group Identification Types 4198 GSAKMP Payload Types 4199 GSAKMP Exchange Types 4200 GSAKMP Policy Token Types 4201 GSAKMP Key Download Data Item Types 4202 GSAKMP Rekey Event Types 4203 GSAKMP Identification Classification 4204 GSAKMP Notification Types 4205 GSAKMP Acknowledgment Types 4206 GSAKMP Mechanism Types 4207 GSAKMP Nonce Types 4209 Changes and additions to the following registries are by Expert 4210 Review: 4212 GSAKMP Cryptographic Key Types 4213 GSAKMP Identification Types 4214 GSAKMP Certificate Types 4215 GSAKMP Signature Types 4216 GSAKMP Nonce Hash Types 4217 GSAKMP Key Creation Types 4219 10 Acknowledgments 4221 This document is the collaborative effort of many individuals. If 4222 there were no limit to the number of authors that could appear on an 4223 RFC, the following, in alphabetical order would have been listed: 4224 Haitham S. Cruickshank of University of Surrey, Sunil Iyengar of 4225 University Of Surrey Gavin Kenny of LogicaCMG, Patrick McDaniel of 4226 AT&T Labs Research, and Angela Schuett of NSA. 4228 The following individuals deserve recognition and thanks for their 4229 contributions which have greatly improved this protocol: Eric Harder 4230 is an author to the Tunneled-GSAKMP, whose concepts are found in 4231 GSAKMP as well. Rod Fleischer, also a Tunneled-GSAKMP author, and 4232 Peter Lough were both instrumental in coding a prototype of the 4233 GSAKMP software and helped define many areas of the protocol that 4234 were vague at best. Andrew McFarland and Gregory Bergren provided 4235 critical analysis of early versions of the specification. Ran 4236 Canetti analyzed the security of the protocol and provided denial of 4237 service suggestions leading to optional "cookie protection". 4239 11 References 4241 The following references were used in the preparation of this 4242 document. 4244 11.1 Normative References 4246 [CH02] Colegrove A., Harney H., ``Group Policy Token Version 1 with 4247 Application to GSAKMP'', draft-ietf-msec-policy-token-sec-02.txt, 4248 March 2005 4250 [DH77] Diffie, W., and M. Hellman, ``New Directions in 4251 Cryptography'', IEEE Transactions on Information Theory, June 1977 4253 [FIPS 186-2] NIST, "Digital Signature Standard", FIPS PUB 186-2, 4254 National Institute of Standards and Technology, U.S. Department of 4255 Commerce, January 2000 4257 [FIPS 196] ``Entity Authentication Using Public Key Cryptography,'' 4258 Federal Information Processing Standards Publication 196, NIST, 4259 February 1997 4261 [IKEv2] C. Kaufman, ``Internet Key Exchange (IKEv2) Protocol'', 4262 draft-ietf-ipsec-ikev2-12.txt, January 2004 4264 [OpenLDAP] Zeilenga, K., ``LDAP: String Representation of 4265 Distinguished Names'', draft-ietf-ldapbis-dn-16.txt, February 2005 4267 [RFC 2119] Bradner, S., "Key Words for use in RFCs to indicate 4268 Requirement Levels", BCP 14, March 1997 4270 [RFC 2409] Harkins D. and Carrel D., ``The Internet Key Exchange 4271 (IKE)'', RFC 2409, Proposed Standard, November 1998 4273 [RFC 2412] Orman H. K., ``The OAKLEY Key Determination Protocol'', 4274 RFC 2412, Informational, November 1998 4276 [RFC 2627] D. Wallner, E. Harder, R. Agee, Key Management for 4277 Multicast: Issues and Architectures, June 1999 4279 [RFC 3280] R. Housley, W. Polk, W. Ford, D. Solo, Internet X.509 4280 Public Key Infrastructure Certificate and Certificate Revocation List 4281 (CRL) Profile, April 2002 4283 [RFC 3629] F. Yergeau, UTF-8, a transformation format of ISO 10646, 4284 November 2003 4286 11.2 Informative References 4288 [BMS] Balenson D., McGrew D., Sherman A., ``Key Management for 4289 Large Dynamic Groups: One-Way Function Trees and Amortized 4290 Initialization'', Internet Draft, February 1999 4292 [HCM] H. Harney, A. Colegrove, P. McDaniel, "Principles of Policy 4293 in Secure Groups", Proceedings of Network and Distributed Systems 4294 Security 2001 Internet Society, San Diego, CA, February 2001 4296 [HHMCD01] Thomas Hardjono, Hugh Harney, Pat McDaniel, Andrea 4297 Colgrove, Pete Dinsmore, Group Security Policy Token: Definition and 4298 Payloads', draft-ietf-msec-gspt-00.txt, Work in progress 4300 [MSST98] Maughan, D., Schertler, M., Schneider, M., and J. Turner, 4301 ``Internet Security Association and Key Management Protocol 4302 (ISAKMP)'', RFC 2408, November 1998 4304 [RFC 1750] Eastlake D., Crocker S. Schiller J., ``Randomness 4305 Recommendations for Security'', RFC 1750, Informational, December 4306 1994 4308 [RFC 2093] Harney H., Muckenhirn C., and Rivers T., ``Group Key, 4309 Management Protocol Specification'', RFC 2093, Experimental, July 4310 1997 4312 [RFC 2094] Harney H., Muckenhirn C., and Rivers T., ``Group Key 4313 Management Protocol Architecture'', RFC 2094, Experimental, July 1997 4315 [RFC 2104] Krawczyk H., Bellare M., and Canetti R., ``HMAC: 4316 Keyed-Hashing for Message Authentication'', RFC 2104, Informational, 4317 February 4319 [RFC 2401] Kent S. and Atkinson, R., ``Security Architecture for the 4320 Internet Protocol'', RFC 2401, November 1998, Proposed Standard 4322 [RFC 2402] Kent S. and Atkinson, R., ``IP Authentication Header'', 4323 RFC 2402, November 1998, Proposed Standard.1997 4325 [RFC 2406] Kent S. and Atkinson, R., ``IP Encapsulating Security 4326 Payload (ESP)'', RFC 2406, November 1998, Proposed Standard 4328 [RFC 2408] Maughan D., Schertler M., Schneider M., and Turner 4329 J., ``Internet Security Association and Key Management Protocol 4330 (ISAKMP)'', RFC 2408, Proposed Standard, November 1998 4332 [RFC 2451] Pereira R., Adams R., ``The ESP CBC-Mode Cipher 4333 Algorithms'', November 1998 4335 [RFC 2974] M. Handley, C. Perkins, E. Whelan, Session Announcement 4336 Protocol, October 2000 4338 [RFC 3161] C. Adams, P. Cain, D. Pinkas, R. Zuccherato, Internet 4339 X.509 Public Key Infrastructure Time-Stamp Protocol (TSP), August 4340 2001 4342 [RFC 3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, 4343 J. Peterson, R. Sparks, M. Handley, E. Schooler, `` SIP: Session 4344 Initiation Protocol'', June 2002 4346 [RFC 3447] J. Jonsson, B. Kaliski, Public-Key Cryptography Standards 4347 (PKCS) #1: RSA Cryptography Specifications Version 2.1, February 4348 2003 4350 [RFC 3526] T. Kivinen, M. Kojo, More Modular Exponential (MODP) 4351 Diffie-Hellman groups for Internet Key Exchange (IKE), May 2003 4353 [RFC 3740] Hardjono T., Weis B., ``The Multicast Group Security 4354 Architecture'', RFC 3740, March 2004, Informational 4356 A APPENDIX A -- LKH Information 4358 This appendix will give an overview of LKH, define the values for 4359 fields within GSAKMP messages that are specific to LKH, and give an 4360 example of a Rekey Event Message using the LKH scheme. 4362 A.1 LKH Overview 4364 LKH provides a topology for handling key distribution for a group 4365 rekey. It rekeys a group based upon a tree structure and subgroup 4366 keys. In the LKH tree shown in Figure 29, members are represented by 4367 the leaf nodes on the tree, while intermediate tree nodes represent 4368 abstract key groups. A member will possess multiple keys: the group 4369 traffic protection key (GTPK), subgroup keys for every node on its 4370 path to the root of the tree, and a personal key. For example, the 4371 member labeled as #3 will have the GTPK, Key A, Key D, and Key 3. 4372 root 4373 / \ 4374 / \ 4375 A B 4376 / \ / \ 4377 / \ / \ 4378 C D E F 4379 / \ / \ / \ / \ 4380 / \ / \ / \ / \ 4381 1 2 3 4 5 6 7 8 4383 Figure 29: A. 1: LKH Tree 4385 This keying topology provides for a rapid rekey to all but a 4386 compromised member of the group. If member 3 were to be compromised, 4387 the new GTPK (GTPK') would need to be distributed to the group under 4388 a key not possessed by member 3. Additionally, new Keys A and D 4389 (Key A' and Key D') would also need to be securely distributed to 4390 the other members of those subtrees. Encrypting the GTPK' with Key B 4391 would securely distribute that key to members 5, 6, 7, and 8. Key C 4392 can be used to encrypt both the GTPK' and Key A' for members 1 and 2. 4393 Member 3's nearest neighbor, Member 4 can obtain GTPK', Key D', and 4394 Key A' encrypted under its personal key, Key 4. At the end of this 4395 process, the group is securely rekeyed with Member 3 fully excluded. 4397 A.2 LKH and GSAKMP 4399 When using LKH with GSAKMP the following issues require attention: 4401 1. Rekey Version # - The Rekey Version # in the Rekey Array of the 4402 Key Download Payload MUST contain the value one (1). 4404 2. Algorithm Version - The Algorithm Version in the Rekey Event 4405 Payload MUST contain the value one (1). 4407 3. Degree of Tree - The LKH tree used can be of any degree, it need 4408 not be binary. 4410 4. Node Identification - Each node in the tree is treated as a KEK. 4411 A KEK is just a special key. As the rule stated for all keys in 4412 GSAKMP, the set of the KeyID and the KeyHandle MUST be unique. A 4413 suggestion on how to do this will be given in this section. 4415 5. Wrapping KeyID and Handle - This is the KeyID and Handle of the 4416 LKH node used to wrap/encrypt the data in a Rekey Event Data. 4418 For the following discussion, refer to Figure 30. 4420 Key: 4421 o: a node in the LKH tree 4422 N: this line contains the KeyID node number 4423 L: this line contains the MemberID number for all leaves ONLY 4425 LEVEL 4426 ---- 4427 root o 4428 N: / 1 \ 4429 / \ 4430 1 o o 4431 N: / 2 \ / 3 \ 4432 / \ / \ 4433 2 o o o o 4434 N: /4\ /5\ /6\ /7\ 4435 / \ / \ / \ / \ 4436 3 o o o o o o o o 4437 N: 8 9 10 11 12 13 14 15 4438 L: 1 2 3 4 5 6 7 8 4440 Figure 30: A. 2: GSAKMP LKH Tree 4442 To guarantee uniqueness of KeyID, the Rekey Controller SHOULD build a 4443 virtual tree and label the KeyID of each node doing a breadth first 4444 search of a fully populated tree regardless of whether or not the 4445 tree is actually full. For simplicity of this example, the root 4446 of the tree was given KeyID value of one (1). These KeyID values 4447 will be static throughout the life of this tree. Additionally, the 4448 rekey arrays distributed to GMs requires a MemberID value associated 4449 with them to be distributed with the KeyDownload Payload. These 4450 MemberID values MUST be unique. Therefore, the set associated with 4451 each leaf node (the nodes from that leaf back to the root) are given 4452 a MemberID. In this example, the leftmost leaf node is given MemberID 4453 value of one (1). These 2 sets of values, the KeyIDs (represented 4454 on lines N) and the MemberIDs (represented on line L) will give 4455 sufficient information in the KeyDownload and RekeyEvent Payloads 4456 to disseminate information. The KeyHandle associated with these 4457 keys is regenerated each time the key is replace in the tree due to 4458 compromise. 4460 A.3 LKH Examples 4462 Definition of values: 4463 0xLLLL - length value 4464 0xHHHHHHH# - handle value 4465 YYYYMMDDHHMMSSZ - Time Value 4467 A.3.1 LKH Key Download Example 4469 This section will give an example of the data for the Key Download 4470 payload. The GM will be given MemberID 1 and its associated keys. 4471 The data shown will be subsequent to the Generic Payload Header. 4473 | GTPK | MemberID 1 | KeyID 2 | KeyID 4 | KeyID 8 4475 Number of Items - 0x0002 4476 Item #1: 4477 Key Download Data Item Type - 0x00 (GTPK) 4478 Key Download Data Item Length - 0xLLLL 4479 Key Type - 0x03 (3DES`CBC64`192) 4480 Key ID - KEY1 4481 Key Handle - 0xHHHHHHH0 4482 Key Creation Date - YYYYMMDDHHMMSSZ 4483 Key Expiration Date - YYYYMMDDHHMMSSZ 4484 Key Data - variable, based on key definition 4485 Item #2: 4486 Key Download Data Item Type - 0x01 (Rekey - LKH) 4487 Key Download Data Item Length - 0xLLLL 4488 Rekey Version Number - 0x01 4489 Member ID - 0x00000001 4490 Number of KEK Keys - 0x0003 4491 KEK #1: 4492 Key Type - 0x03 (3DES`CBC64`192) 4493 Key ID - 0x00000002 4494 Key Handle - 0xHHHHHHH2 4495 Key Creation Date - YYYYMMDDHHMMSSZ 4496 Key Expiration Date - YYYYMMDDHHMMSSZ 4497 Key Data - variable, based on key definition 4498 KEK #2: 4499 Key Type - 0x03 (3DES`CBC64`192) 4500 Key ID - 0x00000004 4501 Key Handle - 0xHHHHHHH4 4502 Key Creation Date - YYYYMMDDHHMMSSZ 4503 Key Expiration Date - YYYYMMDDHHMMSSZ 4504 Key Data - variable, based on key definition 4505 KEK #3: 4506 Key Type - 0x03 (3DES`CBC64`192) 4507 Key ID - 0x00000008 4508 Key Handle - 0xHHHHHHH8 4509 Key Creation Date - YYYYMMDDHHMMSSZ 4510 Key Expiration Date - YYYYMMDDHHMMSSZ 4511 Key Data - variable, based on key definition 4513 A.3.2 LKH Rekey Event Example 4515 This section will give an example of the data for the Rekey Event 4516 payload. The GM with MemberID 6 will be keyed out of the group. The 4517 data shown will be subsequent to the Generic Payload Header. 4519 | Rekey Event Type | GroupID | Date/Time | Rekey Type | Algorithm Ver| 4520 # of Packets| { (GTPK)2, (GTPK, 3', 6')12, (GTPK, 3')7 } 4522 This data shows that three packets are being transmitted. Read each 4523 packet as: 4524 a) GTPK wrapped in LKH KeyID 2 4525 b) GTPK, LKH KeyIDs 3' & 6', all wrapped in LKH KeyID 12 4526 c) GTPK and LKH KeyID 3', all wrapped in LKH KeyID 7 4528 NOTE: Although in this example multiple keys are encrypted under one 4529 key, alternative pairings are legal (e.g., (GTPK)2, (GTPK)3', (3')6', 4530 (3')7', (6')12). 4532 We will show format for all header data, and packet (b). 4534 Rekey Event Type - 0x01 (GSAKMP`LKH) 4535 GroupID - 0xAABBCCDD 4536 0x12345678 4537 Time/Date Stamp - YYYYMMDDHHMMSSZ 4538 Rekey Event Type - 0x01 (GSAKMP`LKH) 4539 Algorithm Vers - 0x01 4540 # of RkyEvt Pkts - 0x0003 4541 For Packet (b): 4542 Packet Length - 0xLLLL 4543 Wrapping KeyID - 0x000C 4544 Wrapping Key Handle - 0xHHHHHHHD 4545 # of Key Packages - 0x0003 4546 Key Package 1: 4547 Key Pkg Type - 0x00 (GTPK) 4548 Pack Length - 0xLLLL 4549 Key Type - 0x03 (3DES`CBC64`192) 4550 Key ID - KEY1 4551 Key Handle - 0xHHHHHHH0 4552 Key Creation Date - YYYYMMDDHHMMSSZ 4553 Key Expiration Date - YYYYMMDDHHMMSSZ 4554 Key Data - variable, based on key definition 4555 Key Package 2: 4556 Key Pkg Type - 0x01 (Rekey - LKH) 4557 Pack Length - 0xLLLL 4558 Key Type - 0x03 (3DES`CBC64`192) 4559 Key ID - 0x00000003 4560 Key Handle - 0xHHHHHHH3 4561 Key Creation Date - YYYYMMDDHHMMSSZ 4562 Key Expiration Date - YYYYMMDDHHMMSSZ 4563 Key Data - variable, based on key definition 4564 Key Package 3: 4565 Key Pkg Type - 0x01 (Rekey - LKH) 4566 Pack Length - 0xLLLL 4567 Key Type - 0x03 (3DES`CBC64`192) 4568 Key ID - 0x00000006 4569 Key Handle - 0xHHHHHHH6 4570 Key Creation Date - YYYYMMDDHHMMSSZ 4571 Key Expiration Date - YYYYMMDDHHMMSSZ 4572 Key Data - variable, based on key definition 4574 B APPENDIX B -- Change History (To Be Removed from RFC) 4576 B.1 Changes from GSAKMP-00 to GSAKMP-01 February 2003 4578 This specification was based on two earlier versions of GSAKMP 4579 drafts, referred to to GSAKMP and GSAKMP-Light. These two 4580 specifications were merged to incorporate all information necessary 4581 to allow the original GSAKMP-Light specification to stand on its own. 4583 The original GSAKMP protocol no longer exists as a standard, it has 4584 been subsumed by GSAKMP-Light. GSAKMP-Light is now called GSAKMP. 4586 Major modifications to the specification are 4588 Removed Payloads: Authorization, Certificate Request, Vendor ID, 4589 and Hash. 4591 Removed Messages: Group Removal/Destruction. 4593 Signature Processing: The signature processing has been modified. 4595 B.2 Changes from GSAKMP-01 to GSAKMP-02 June 2003 4597 1. The specification was modified to confirm that key words are used 4598 as defined by RFC2119. 4600 2. The Protocol Considerations section for IANA port number was 4601 added. 4603 3. The Cookie section for mitigation of DoS attacks was added. 4605 4. The Protocol State Diagram was added. 4607 B.3 Changes from GSAKMP-02 to GSAKMP-03 August 2003 4609 1. Clarified Nonce value in Request to Join With Cookie msg. 4611 2. Added Signature ID Type to Security Suite 1 definition. 4613 3. Clarified format of Identification information used in Signature 4614 and Identification Payloads. 4616 4. Split Signature Type field into it's two appropriate fields. 4617 This was not a change in the payload, just cleaning up the 4618 definition. 4620 B.4 Changes from GSAKMP-03 to GSAKMP-04 October 2003 4622 1. Terminology Section 4624 (a) Rekey definition was made more verbose. 4626 2. Security Considerations Section 4628 (a) ISAKMP Section 4630 i. Corrected GSAKMPs relationship definition to ISAKMP. 4632 (b) Rekey Availability Section 4634 i. Added this new section. 4636 3. Architecture Section 4638 (a) This section in its entirety was added for this revision of 4639 the specification. 4641 4. Group Life Cycle Section 4643 (a) Group Establishment Section 4645 i. Introduced Verbose and Terse concept. 4647 (b) Standard Group Establishment Section 4649 i. Added messages Request to Join Error and Lack_of_Ack to 4650 ladder diagram to show verbose error messaging. 4652 ii. Modified definition of Ack message on ladder diagram to 4653 be consistent with new naming convention. 4655 iii. Reworked all section wording to convey the new message 4656 transmissions. 4658 (c) Request to Join Section 4660 i. Completely reworked to better define the process of 4661 building and processing the RTJ message by the GM and 4662 GC/KS. 4664 (d) Key Download Section 4666 i. Completely reworked to better define the process of 4667 building and processing the KeyDL message by the GC/KS 4668 and GM. 4670 (e) Request to Join Error Section 4672 i. New section added for this new verbose message. 4674 (f) Key Download = Ack/Failure Section 4676 i. Completely reworked to better define the process of 4677 building and processing the KeyDL-A/F message by the GM 4678 and GC/KS. 4680 (g) Lack_of_Ack Section 4682 i. New section added for this new verbose message. 4684 (h) Added the following new Sub-sections to this section. 4686 i. Leaving Group 4688 ii. Eviction 4690 iii. Voluntary Departure without Notice 4692 iv. De-registration 4694 v. Request to Depart Message 4696 vi. Departure Response Message 4698 vii. Departure Ack Message 4700 5. GSAKMP Payload Structure Section 4702 (a) Added note that all all integer fields larger than one 4703 octet MUST be converted to Network Byte Order prior to 4704 transmission. 4706 (b) GSAKMP Header Section 4708 i. Existing section became the Structure subsection. 4710 ii. Added the Processing subsection. 4712 iii. GroupID Type was modified to GroupID Length with the 4713 appropriate definitions. 4715 iv. New Exchange Types added for verbose mode. 4717 v. Sequence ID definition was modified for: 4719 A. New initial value. 4721 B. Rollover handling responsibility. 4723 (c) GSAKMP Payload Header Section 4725 i. Existing section became the Structure subsection. 4727 ii. Added the Processing subsection. 4729 (d) Policy Token Payload Section 4731 i. The header paragraph was corrected to not levy any 4732 requirements from GSAKMP on the Policy Token. 4734 ii. The PT Type field was expanded from one (1) to two (2) 4735 octets. 4737 iii. The values of the PT Types were modified and defined to 4738 reflect the true purpose. 4740 (e) Rekey Event Payload Section 4742 i. Renamed Type field to be unique within specification. 4744 ii. The values of the Rekey Type field were modified and 4745 defined to reflect their true purpose. 4747 (f) Signature Payload Section 4749 i. Existing section became the Structure subsection. 4751 ii. Added the Processing subsection. 4753 iii. Removed the one (1) octet field Signature ID Role from 4754 the payload, it contained irrelevant data. 4756 iv. Expanded the definition of Singer ID Data to inform the 4757 user how to interpret this field. 4759 (g) Notification Payload Section 4761 i. Removed the one (1) octet Status Type field from the 4762 payload. It was irrelevant information. Additionally, 4763 all references to Status Type were removed from the 4764 payload definition. 4766 ii. Added new Notification Payload Type "Mechanism Choices". 4768 iii. Added section "Notification Data - Mechanism Choices 4769 Payload Type" to define the format of a Notification 4770 Payload of type Mechanism Choices. 4772 (h) Key Creation Payload Section 4774 i. Existing section became the Structure subsection. 4776 ii. Added the Processing subsection. 4778 iii. Renamed Type field to be unique within specification. 4780 (i) Nonce Payload Section 4782 i. Existing section became the Structure subsection. 4784 ii. Added the Processing subsection. 4786 B.5 Changes from GSAKMP-04 to GSAKMP-05 February 2004 4788 B.5.1 Major Modification/Reorganization of Specification 4790 B.5.1.1 Key Terms and Payloads Modified 4792 In the previous version of the specification, there was a lot of 4793 confusion with respect to the terminology used for anything to 4794 do with keys and rekey. Therefore, all the terminology has been 4795 modified to make this more comprehensible. Additionally, all key 4796 information that was found in the appendices was generalized and 4797 incorporated into the main sections of the specification. 4799 Following is a list of old terms mapped to new terms: 4801 - LKH ID - Key ID, this field is now also in a GTPK, was not there 4802 previously. 4804 - Key Pack - Key Datum 4806 - Key Pack Data - Key Package 4808 - Rekey Event Packet Data - Rekey Event Data 4810 To accommodate all these changes, the Key Download Payload, Rekey 4811 Event Payload, and LKH Appendix sections were completely reworked to 4812 reflect these changes. 4814 Other major changes in these sections with respect to bits on the 4815 wire: 4817 - KeyID - All keys now have a 4 octet ID field. This was not so 4818 before. Also, this field is now 4 octets long, it was previously 4819 2 octets. 4821 - Date Fields - These fields are now 15 bytes long and ascii 4822 format. 4824 THEREFORE, look closely at the Key Download Payload and Rekey 4825 Event Payload as the formats for these payloads have both changed 4826 dramatically the bits on the wire. 4828 B.5.2 Modification By Section 4830 1. Protocol Considerations Section - Moved to new section entitled 4831 IANA Considerations Section. 4833 2. Terminology Section 4835 (a) Modified the following terms: GTEK became GTPK 4837 (b) Added the following terms: Key Datum, KEK, Key Handle, Key 4838 ID, Key Package, Rekey Array, Rekey Key, Wrapping KeyID, 4839 Wrapping Key Handle 4841 3. Security Considerations Section 4843 (a) Security Assumptions Section 4845 i. Added an assumption with respect to system clock. 4847 (b) Rekey Availability Section 4849 i. Stated retransmission of rekey messages required for 4850 implementations. 4852 4. Group Establishment Section 4854 (a) Added phrase concerning error message always indicates first 4855 error found. 4857 (b) Key Download Section 4859 i. Fixed second paragraph. 4861 (c) Rekey Events Section - Made as subsection under new section 4862 Group Management. 4864 5. GSAKMP Payload Structure Section 4865 (a) Added verbiage that no padding in any payloads. 4867 (b) All processing sections updated to indicate error 4868 processing. 4870 6. Split following sections into Structure and Processing 4871 subsections: 4873 (a) Policy Token Payload 4875 (b) Key Download Payload 4877 (c) Rekey Event Payload 4879 (d) Identification Payload 4881 (e) Certificate Payload 4883 7. GSAKMP Header Section 4885 (a) Group ID Length and Sequence ID - Fixed definitions. 4887 (b) Updated values in tables. 4889 (c) Reworded processing section to be more precise. 4891 8. Policy Token Payload Section 4893 (a) PT Type field in diagram was updated to reflect that this is 4894 really a 2 octet field and not a 1 octet field. 4896 (b) Updated tables. 4898 9. Key Download and Rekey Event Payload Sections 4900 (a) Completely reworked sections. Refer to Section B.5.1.1 4901 above for the modifications to these sections. 4903 (b) Basically, reread these sections closely as a lot has 4904 changed. 4906 10. Identification Payload Section 4907 (a) U-NAME Definition was incorporated directly into this 4908 section. 4910 (b) Updated tables. 4912 11. Certificate Payload Section 4914 (a) Added words to structure section about zero or multiple 4915 certificate payloads within a GSAKMP message. 4917 (b) Updated tables. 4919 12. Signature Payload Section 4921 (a) Updated Tables. 4923 (b) Signature Type field is now 2 octets long. 4925 (c) Signature Payload Span field has been removed, it no longer 4926 exists. 4928 (d) Signature Timestamp field is now 15 bytes long to conform to 4929 the 4931 (e) Processing section was updated. new date/time format begin 4932 used throughout the spec. 4934 13. Notification Payload Section 4936 (a) Updated Tables. 4938 (b) Removed Length field from Notification Data Mechanism 4939 Choices Payload Types format. 4941 (c) Made field Mechanism Choice Data field to be a static length 4942 of 2 octets. 4944 14. Key Creation Payload Section 4946 (a) Updated Tables. 4948 (b) Key Creation Type field is now 2 octets long. 4950 (c) Updated Processing subsection. 4952 15. Nonce Payload Section 4954 (a) Updated Tables. 4956 (b) Updated Processing subsection. 4958 16. Added new section IANA Considerations. 4960 B.6 Changes from GSAKMP-05 to GSAKMP-06 May 2004 4962 NOTE: Minor editorial modifications are not listed here. 4964 1. Security Considerations Section 4966 (a) Security Assumptions Section 4968 i. Added considerations as pointed out by gmg. 4970 (b) Protocol Considerations Section 4972 i. Fixed wording between subsections to remove contradiction 4973 of how and when to use Diffie-Hellman. 4975 2. Architecture Section 4977 (a) S-GC/KS Operations section replaced with Autonomous 4978 Distributed GSAKMP Operations Section 4980 (b) GSAKMP Interactions with NAT Traversal section removed. 4982 3. Group Life Cycle Section 4984 (a) To all subsection, modified the message dissection and 4985 discussion for Nonces. Nonces are now an optional payload 4986 with a caveat. Systems that have synchronized time do not 4987 use Nonce payloads. Systems that do not have synchronized 4988 time MUST use Nonce payloads. 4990 (b) Added information concerning Vendor ID payload processing. 4992 (c) Added optional VendorID payload to all messages. 4994 (d) Group Establishment Section 4996 i. Added paragraph that Verbose mode is controlled by 4997 policy and how to handle it. 4999 ii. Standard Group Establishment Section 5001 A. Defined all possible error conditions. 5003 B. Verbosely identified that message identification is 5004 via the exchange type within the header. 5006 C. Introduced concept of synchronized time. 5008 iii. RTJ Section 5010 A. Added the NotifPL of type IPValue and explanation to 5011 this message type and discussion. 5013 iv. Key Download - Ack/Failure Section 5015 A. Added that upon successful registration all state 5016 information should be removed. 5018 v. Cookie Section 5020 A. Added information for calculation of cookie value in 5021 a NATted environment. 5023 (e) Group Maintenance Section 5025 i. Group Management Section 5026 A. Added sections Policy Update and Group Destruction. 5028 ii. Leaving a Group Section 5030 A. De-Registration Section - Added the GM SHOULD 5031 support and GC/KS MUST support. 5033 B. De-Registration Section - Fixed with respect to 5034 Terse/Verbose mode processing. 5036 4. GSAKMP Payload Structure Section 5038 (a) Added pointed to VendorID section on how to process messages 5039 that contain this payload. 5041 (b) GSAKMP Header Section 5043 i. GSAKMP Header Structure Section 5045 A. Updated GroupID Types table and added subsections to 5046 define the format for each type. 5048 B. Added VendorID value to Payload Types table. 5050 ii. GSAKMP Header Processing Section 5052 A. Updated processing rule for GroupID and Version. 5054 B. Added discussion for interoperability with future 5055 versions. 5057 (c) Key Download Payload Section 5059 i. Key Datum Structure Section 5061 A. Fixed Key Type to be a 2 byte field as indicated by 5062 the table which shows its values. 5064 B. Updated structure definition for Key ID, Key Handle, 5065 Key Creation Date, and Key Expiration Date. 5067 (d) Rekey Event Payload Section 5069 i. Rekey Event Payload Structure Section 5071 A. Defined how to break up the data across multiple 5072 payloads. 5074 B. Rekey Event Header Structure Section - Update 5075 structure definition of Time/Date Stamp. 5077 C. Rekey Event Data Structure Section - Clarified 5078 information of which/how many Rekey Event Datas each 5079 user is interested in. 5081 i. Rekey Event Payload Processing Section 5083 A. Updated Date/Time Stamp processing rules. 5085 (e) Identification Payload Section 5087 i. Added ID Classification octet to payload, associated 5088 table, and associated processing information. 5090 ii. Updated Identification Types table. 5092 iii. ID-U-NAME Structure Section 5094 A. Updated DN Data definition for UTF-8. 5096 iv. ID-U-NAME Processing Section 5098 A. Updated Serial Number and DN Data processing rules. 5100 B. Added a new rule for CA being a trust anchor. 5102 (f) Certificate Payload Section 5104 i. Certificate Payload Structure Section 5105 A. Updated Certificate Type values. 5107 (g) Signature Payload Section 5109 i. Signature Payload Structure Section 5111 A. Updated Signature Timestamp definition for UTF-8 and 5112 how to deal with time differential from local. 5114 B. Updated Signature Type table values. 5116 C. Signature ID type is now aligned with IdentificationPL 5117 ID Type. 5119 ii. Signature Payload Processing Section 5121 A. Updated processing instructions for Signature 5122 Timestamp, Signature ID Data, and Signature Data. 5124 (h) Notification Payload Section 5126 i. Notification Payload Structure Section 5128 A. Updated Notification Types table. 5130 (i) Vendor ID Payload Section 5132 i. This whole section was added. 5134 (j) Key Creation Payload Section 5136 i. Key Creation Payload Structure Section 5138 A. Updated Key Creation Type table. 5140 ii. Key Creation Payload Processing Section 5141 A. Updated Key Creation Data processing instructions. 5143 5. GSAKMP State Diagram Section 5145 (a) Updated State Transition Events table. 5147 6. IANA Considerations Section 5149 (a) Updated all types sections for new values. 5151 B.7 Changes from GSAKMP-06 to GSAKMP-07 December 2004 5153 NOTE: Minor editorial modifications are not listed here. 5155 1. General/Global Revisions 5157 (a) Wherever necessary, was more verbose in that LKH is an 5158 optional feature. 5160 (b) Outstanding references fixed. 5162 (c) Added/Modified references, both normative and informative. 5164 (d) Replaced term 'trust anchor' with 'trusted policy creation 5165 authority'. 5167 (e) Removed reference to draft policy token which is no longer 5168 in effect [HCLM00]. 5170 2. Overview section now has introductory remarks to the paper. 5172 3. Security Considerations Section 5174 (a) Security Assumptions Section 5176 i. Updated information about Nonce with respect to replay 5177 attacks. 5179 (b) Related Protocols - Diffie-Hellman 5180 i. Updated discussion on key size to be generic to more 5181 algorithm types. 5183 B.8 Changes from GSAKMP-07 to GSAKMP-08 March 2005 5185 This draft was generated specifically to address the comments brought 5186 up during IESG review. In addition to addressing these comments, 5187 some of the references were updated as some of the RFCs/Drafts had 5188 been replaced by newer RFCs. 5190 1. Grp Life Cycle/Grp Est/Std Grp Est/Request to Join Section 5192 (a) Added words to description that GM MUST be able to manually 5193 configure the destination of the RTJ. 5195 (b) Fixed dissection and added words to description that Nonces 5196 are required and the GC/KS will determine if they will be 5197 used. 5199 (c) Reordered GM resend of RTJ 3 times and GC/KS processing no 5200 more than one RTJ from this GM to clear up this interaction. 5202 2. Cryptographic Key Types Table updated to make AES the MUST 5203 instead of 3DES. 5205 3. Certificate Payload Processing section Certificate Data 5206 definition was fixed from root CA certificate to certificate of 5207 the trusted policy creation authority. 5209 4. Identification Types was modified to add LDAP DN string 5210 representation. This was made the MUST type. Security Suite 1 5211 was updated to now use this type. Reference to this document was 5212 added. 5214 B.9 Changes from GSAKMP-08 to GSAKMP-09 April 2005 5216 This draft was generated to shore up the modification rules for IANA 5217 registry entries. To accomplish this, the subsections of section 9.2 5218 were removed. When this was done, modifications to tables within 5219 the payload definitions were modified where necessary to insure that 5220 they included the 'Defined In' information that used to be in these 5221 tables (only 2 entries in one table were missing). Then general 5222 modifications rules for the registry entries were defined. 5224 Also, it was recognized that one informative reference was missing 5225 and it was added. 5227 B.10 Changes from GSAKMP-09 to GSAKMP-10 May 2005 5229 1. The following IDNits issues were addressed: 5231 (a) Line length was too long, corrected to max of 72 chars per 5232 line. 5234 (b) Added correct boilerplate for front page, copyright, and 5235 IPR. 5237 2. Insured that all terms were fully spelled out prior to initial 5238 use as an acronym. 5240 3. Clarified in the Security Considerations Rekey Availability 5241 section that rekey capability is optional. There was confusion 5242 with the MUST clause for retransmission, this MUST only applies 5243 when using the optional rekey capability. 5245 4. Expanded section name to Creation of Policy Token from acronym 5246 PT. 5248 5. Modified AES CBC key length from 192 bits to 128 both in the 5249 Security Suite 1 definition and in the Cryptographic Key Types 5250 table. 5252 Authors' Addresses 5254 Hugh Harney (point-of-contact) 5255 SPARTA, Inc. 5256 7075 Samuel Morse Drive 5257 Columbia, MD 21046 5258 (410) 872-1515 ext 203 5259 FAX (410) 872-8079 5260 hh@sparta.com 5262 Uri Meth 5263 SPARTA, Inc. 5264 7075 Samuel Morse Drive 5265 Columbia, MD 21046 5266 (410) 872-1515 ext 233 5267 FAX (410) 872-8079 5268 umeth@sparta.com 5269 Andrea Colegrove 5270 SPARTA, Inc. 5271 7075 Samuel Morse Drive 5272 Columbia, MD 21046 5273 (410) 872-1515 ext 232 5274 FAX (410) 872-8079 5275 acc@sparta.com 5277 George Gross 5278 IdentAware Security 5279 82 Old Mountain Road 5280 Lebanon, NJ 08833 5281 (908) 268 - 1629 5282 gmgross@identaware.com 5284 Full Copyright Statement 5286 Copyright (C) The Internet Society (2005). This document is subject 5287 to the rights, licenses and restrictions contained in BCP 78, and 5288 except as set forth therein, the authors retain all their rights. 5290 This document and the information contained herein are provided 5291 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 5292 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 5293 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 5294 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 5295 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5296 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5298 IPR Considerations 5300 By submitting this Internet-Draft, each author represents that any 5301 applicable patent or other IPR claims of which he or she is aware 5302 have been or will be disclosed, and any of which he or she becomes 5303 aware will be disclosed, in accordance with Section 6 of BCP 79. 5305 The IETF takes no position regarding the validity or scope of any 5306 Intellectual Property Rights or other rights that might be claimed 5307 to pertain to the implementation or use of the technology described 5308 in this document or the extent to which any license under such rights 5309 might or might not be available; nor does it represent that it has 5310 made any independent effort to identify any such rights. Information 5311 on the procedures with respect to rights in RFC documents can be 5312 found in BCP 78 and BCP 79. 5314 Copies of IPR disclosures made to the IETF Secretariat and any 5315 assurances of licenses to be made available, or the result of an 5316 attempt made to obtain a general license or permission for the 5317 use of such proprietary rights by implementers or users of this 5318 specification can be obtained from the IETF on-line IPR repository 5319 at http://www.ietf.org/ipr. 5321 The IETF invites any interested party to bring to its attention any 5322 copyrights, patents or patent applications, or other proprietary 5323 rights that may cover technology that may be required to implement 5324 this standard. Please address the information to the IETF at ietf- 5325 ipr@ietf.org. 5327 Document expiration: November 16, 2005