idnits 2.17.1 draft-yeung-g-ikev2-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 6, 2015) is 3119 days in the past. Is this intentional? 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: 'CERTREQ' is mentioned on line 244, but not defined == Missing Reference: 'N' is mentioned on line 306, but not defined == Missing Reference: 'D' is mentioned on line 308, but not defined == Missing Reference: 'GSA' is mentioned on line 631, but not defined == Missing Reference: 'KD' is mentioned on line 631, but not defined == Missing Reference: 'RFC2404' is mentioned on line 1224, but not defined == Missing Reference: 'RFC2403' is mentioned on line 1225, but not defined == Missing Reference: 'RFC4868' is mentioned on line 1227, but not defined ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 2407 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Rowles 3 Internet-Draft A. Yeung, Ed. 4 Intended status: Standards Track P. Tran 5 Expires: April 8, 2016 Cisco Systems 6 Y. Nir 7 Check Point Software Technologies Ltd. 8 October 6, 2015 10 Group Key Management using IKEv2 11 draft-yeung-g-ikev2-09 13 Abstract 15 This document presents a new group key distribution protocol. The 16 protocol is in conformance with MSEC key management architecture it 17 contains two components: member registration and group rekeying, both 18 downloading group security associations from the Group Controller Key 19 Server to a member of the group. The new protocol is similar to 20 IKEv2 in message and payload formats as well as message semantics. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 8, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 1.2. Why do we need another GSA protocol? . . . . . . . . . . 4 59 1.3. G-IKEv2 Payloads . . . . . . . . . . . . . . . . . . . . 4 60 2. G-IKEv2 integration into IKEv2 protocol . . . . . . . . . . . 4 61 2.1. UDP port . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. G-IKEv2 Protocol . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. G-IKEv2 member registration and secure channel 64 establishment . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1.1. GSA_AUTH exchange . . . . . . . . . . . . . . . . . . 6 66 3.1.2. GSA_REGISTRATION Exchange . . . . . . . . . . . . . . 7 67 3.1.3. IKEv2 Header Initialization . . . . . . . . . . . . . 7 68 3.1.4. GM Registration Operations . . . . . . . . . . . . . 7 69 3.1.5. GCKS Registration Operations . . . . . . . . . . . . 8 70 3.2. Counter-based modes of operation . . . . . . . . . . . . 9 71 3.3. G-IKEv2 group maintenance channel . . . . . . . . . . . . 11 72 3.3.1. G-IKEv2 GSA_REKEY exchange . . . . . . . . . . . . . 11 73 3.3.2. Forward and Backward Access Control . . . . . . . . . 12 74 3.3.3. Forward Access Control Requirements . . . . . . . . . 13 75 3.3.4. Deletion of SAs . . . . . . . . . . . . . . . . . . . 13 76 3.3.5. GSA_REKEY GCKS Operations . . . . . . . . . . . . . . 14 77 3.3.6. GSA_REKEY GM Operations . . . . . . . . . . . . . . . 14 78 4. Header and Payload Formats . . . . . . . . . . . . . . . . . 15 79 4.1. The G-IKEv2 Header . . . . . . . . . . . . . . . . . . . 15 80 4.2. Group Identification (IDg) Payload . . . . . . . . . . . 15 81 4.3. Group Security Association Payload . . . . . . . . . . . 16 82 4.3.1. GSA policy . . . . . . . . . . . . . . . . . . . . . 16 83 4.4. KEK Policy . . . . . . . . . . . . . . . . . . . . . . . 17 84 4.4.1. KEK Attributes . . . . . . . . . . . . . . . . . . . 18 85 4.4.2. KEK_MANAGEMENT_ALGORITHM . . . . . . . . . . . . . . 19 86 4.4.3. KEK_ENCR_ALGORITHM . . . . . . . . . . . . . . . . . 19 87 4.4.4. KEK_KEY_LENGTH . . . . . . . . . . . . . . . . . . . 19 88 4.4.5. KEK_KEY_LIFETIME . . . . . . . . . . . . . . . . . . 20 89 4.4.6. KEK_INTEGRITY_ALGORITHM . . . . . . . . . . . . . . . 20 90 4.4.7. KEK_AUTH_METHOD . . . . . . . . . . . . . . . . . . . 20 91 4.4.8. KEK_AUTH_ALGORITHM . . . . . . . . . . . . . . . . . 20 92 4.4.9. KEK_MESSAGE_ID . . . . . . . . . . . . . . . . . . . 20 93 4.5. GSA TEK Policy . . . . . . . . . . . . . . . . . . . . . 20 94 4.5.1. TEK ESP and AH Protocol-Specific Policy . . . . . . . 21 95 4.6. GSA Group Associated Policy . . . . . . . . . . . . . . . 23 96 4.6.1. ACTIVATION_TIME_DELAY/DEACTIVATION_TIME_DELAY . . . . 24 98 4.7. Key Download Payload . . . . . . . . . . . . . . . . . . 24 99 4.7.1. TEK Download Type . . . . . . . . . . . . . . . . . . 26 100 4.7.2. KEK Download Type . . . . . . . . . . . . . . . . . . 27 101 4.7.3. LKH Download Type . . . . . . . . . . . . . . . . . . 28 102 4.7.4. SID Download Type . . . . . . . . . . . . . . . . . . 31 103 4.8. Delete Payload . . . . . . . . . . . . . . . . . . . . . 33 104 4.9. Notify Payload . . . . . . . . . . . . . . . . . . . . . 33 105 4.10. Authentication Payload . . . . . . . . . . . . . . . . . 34 106 5. Security Considerations . . . . . . . . . . . . . . . . . . . 34 107 5.1. GSA registration and secure channel . . . . . . . . . . . 34 108 5.2. GSA maintenance channel . . . . . . . . . . . . . . . . . 34 109 5.2.1. Authentication/Authorization . . . . . . . . . . . . 34 110 5.2.2. Confidentiality . . . . . . . . . . . . . . . . . . . 35 111 5.2.3. Man-in-the-Middle Attack Protection . . . . . . . . . 35 112 5.2.4. Replay/Reflection Attack Protection . . . . . . . . . 35 113 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 114 6.1. New registries . . . . . . . . . . . . . . . . . . . . . 35 115 6.2. New payload and exchange types to existing IKEv2 registry 36 116 6.3. New Name spaces . . . . . . . . . . . . . . . . . . . . . 36 117 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 118 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 119 8.1. Normative References . . . . . . . . . . . . . . . . . . 36 120 8.2. Informative References . . . . . . . . . . . . . . . . . 37 121 Appendix A. Differences between G-IKEv2 and RFC 6407 . . . . . . 38 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 124 1. Introduction and Overview 126 This document presents a group key management protocol protected by 127 IKEv2. The data communications within the group are protected by a 128 key pushed to the group members (GMs) by the Group Controller/Key 129 Server (GCKS) using IKEv2 [RFC5996]. The GCKS pushes policy and keys 130 for the group to the GM after authenticating it using new payloads 131 added in the IKE_AUTH exchange. This document references IKEv2 132 [RFC5996] but it intended to be a separate document. GDOI update 133 document [RFC6407] presented GDOI using IKEv1 syntax. This document 134 uses IKEv2 syntax. The message semantics of IKEv2 are preserved, in 135 that all communications consists of message request-response pairs. 136 The exception to this rule are the rekeying messages, which are sent 137 in multicast without a response. A number of payloads were deemed 138 unnecessary since [RFC6407] are described in Appendix A 140 1.1. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 1.2. Why do we need another GSA protocol? 148 GDOI protocol specified in [RFC6407] is protected by IKEv1 phase1 149 security association defined in [RFC2407], [RFC2408] and [RFC2409]; 150 these documents are obsoleted and replaced by a new version of the 151 IKE protocol defined in RFC 5996. G-IKEv2 provides group key 152 management between the group member and group controller key server 153 using the new IKEv2 protocol and inherits the following key 154 advantages over GDOI: 156 1. Provide a simple mechanism for the responder to keep minimal 157 state and avoid DOS attack from forged IP address using cookie 158 challenge exchange. 160 2. Improve performance and network latency by the reduced number of 161 initial messages to complete the G-IKEv2 protocol from (10 162 messages in main mode and quick mode, 7 messages in aggressive 163 mode and quick) to 4 messages. 165 3. Fix cryptographic weakness with authentication HASH (ikev1 166 authentication HASH specified in RFC-2409 does not include all 167 ISAKMP payloads and does not include ISAKMP header). This issue 168 is documented at [IKE-HASH]. 170 4. Improve protocol reliability where all unicast messages are 171 ack'ed and sequenced. 173 5. Well defined behavior for error conditions to improve 174 interoperability. 176 1.3. G-IKEv2 Payloads 178 1. IDg (group ID) - The GM requests the GCKS for membership into the 179 group by sending its IDg payload. 181 2. GSA (Group Security Association) - The GCKS sends the group 182 policy to the GM using this payload. 184 3. KD (Key Download) - The GCKS sends the control and data keys to 185 the GM using the KD payload. 187 2. G-IKEv2 integration into IKEv2 protocol 189 The G-IKEv2 protocol provides the security mechanisms of IKEv2 (peer 190 authentication, confidentiality, message integrity) to protect the 191 group negotiations required for G-IKEv2. The G-IKEv2 exchange 192 further provides group authorization, and secure policy and key 193 download from the GCKS to its group members. 195 2.1. UDP port 197 G-IKEv2 SHOULD use port 848, the same as GDOI [RFC6407] , because 198 they serve a similar function, and can use the same ports, just as 199 IKEv1 and IKEv2 can share port 500. The version number in the IKEv2 200 header distinguishes the G-IKEv2 protocol from GDOI protocol 201 [RFC6407]. 203 3. G-IKEv2 Protocol 205 3.1. G-IKEv2 member registration and secure channel establishment 207 The registration protocol consists of minimum two exchanges 208 IKE_SA_INIT and GSA_AUTH; member registration may have a few more 209 messages exchanged if the EAP method, cookie challenge (for DoS) or 210 invalid KE are used. Each exchange consists of request/response 211 pairs. The first exchange IKE_SA_INIT is defined in IKEv2 [RFC5996]. 212 This exchange negotiates cryptographic algorithms, exchanges nonces 213 and does a Diffie-Hellman exchange between the member and the Group 214 Controller Key Server (GCKS). 216 The second exchange GSA_AUTH authenticates the previous messages, 217 exchange identities and certificates. These messages are encrypted 218 and integrity protected with keys established through the IKE_SA_INIT 219 exchange, so the identities are hidden from eavesdroppers and all 220 fields in all the messages are authenticated. The GCKS MAY authorize 221 group members to be allowed into the group as part of the GSA_AUTH 222 exchange. Once the GCKS accepted a group member to join a group it 223 may downloads the data security keys (TEKs) and/or group key 224 encrypting key (KEK) or KEK array as part of GSA_AUTH response 225 message. In the following descriptions, the payloads contained in 226 the message are indicated by names as listed below. 228 Notation Payload 229 ------------------------------------------------------------ 230 AUTH Authentication 231 CERT Certificate 232 CERTREQ Certificate Request 233 GSA Group Security Association 234 HDR IKEv2 Header 235 IDg Identification - Group 236 IDi Identification - Initiator 237 IDr Identification - Responder 238 KD Key Download 239 KE Key Exchange 240 Ni, Nr Nonce SA Security Association 242 The details of the contents of each payload are described in 243 Section 4. Payloads that may optionally appear will be shown in 244 brackets, such as [CERTREQ], indicate that optionally a certificate 245 request payload can be included. 247 3.1.1. GSA_AUTH exchange 249 After the group member and GCKS uses IKE_SA_INIT exchange to 250 negotiate cryptographic algorithms, exchange nonces, and perform a 251 Diffie-Hellman exchange as defined in IKEv2 [RFC5996], the IKE_AUTH 252 or GSA_AUTH MUST complete before any other exchanges can be done. 253 The security properties of the GSA_AUTH exchange are the same as the 254 properties of the IKE_AUTH exchange. It is used to authenticate the 255 IKE_SA_INIT messages, exchange identities and certificates. G-IKEv2 256 also uses this exchange for group member registration and optionally 257 authorization. GSA_AUTH does not include SA2, TSi and TSr since 258 policy is not negotiated between group member and GCKS but downloaded 259 from the GCKS to the group member. 261 Initiator (Member) Responder (GCKS) 262 -------------------- ------------------ 263 HDR, SK { IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, 264 IDg, [N] } --> 266 After an unauthenticated secure channel is established by IKE_SA_INIT 267 exchange, the member initiates a registration request to join a group 268 indicated by the IDg payload. The GM MAY include the Notify payload 269 status type SENDER_ID_REQUEST to request SIDs for Counter-based 270 cipher from the GCKS. 272 <-- HDR, SK { IDr, [CERT,] AUTH, [GSA, KD,] [D,] } 274 Besides response with IDr, optional CERT, and AUTH material, the GCKS 275 MAY also informs the member the cryptographic policies of the group 276 in the GSA payload and key material in the KD payload. GCKS can also 277 include Delete payload instructing the group member to delete 278 existing SAs it might have. 280 In addition to the IKEv2 error handling, GCKS can reject the 281 registration request when IDg is invalid or authorization fail, etc. 282 In these cases, see Section 4.9, the GSA_AUTH response will include 283 notify indicate errors. The member MUST delete the registration IKE 284 SA. 286 Initiator (Member) Responder (GCKS) 287 -------------------- ------------------ 288 <-- HDR, SK { N } 290 When the group member found the policy sent by the GCKS is 291 unacceptable, the member SHOULD send an IKEv2 delete using the 292 INFORMATION message exchange to bring down the authenticated IKE SA. 294 3.1.2. GSA_REGISTRATION Exchange 296 When a secure channel is already established between GM and KS, the 297 GM registration for a group can reuse the established secure channel. 298 In this scenario the GM will use the GSA_REGISTRATION exchange by 299 including the desired group ID (IDg) to request data security keys 300 (TEKs) and/or group key encrypting keys (KEKs) from the GCKS. The GM 301 MAY also include the Notify payload status type SENDER_ID_REQUEST to 302 request SIDs for Counter-based cipher from the GCKS. 304 Initiator (Member) Responder (GCKS) 305 -------------------- ------------------ 306 HDR, SK {IDg, [N] } --> 308 <-- HDR, SK { GSA, KD, [D] } 310 This exchange can also be used when the group member found the policy 311 sent by the GCKS is unacceptable. The group member can notify the 312 GCKS by sending IDg and the NOTIFY type NO_PROPOSAL_CHOSEN as shown 313 below. The GCKS MUST unregister the group member. 315 Initiator (Member) Responder (GCKS) 316 -------------------- ------------------ 317 HDR, SK {IDg [N,]} --> 319 <-- HDR, SK {} 321 3.1.3. IKEv2 Header Initialization 323 The Major Version is (2) and Minor Version number (0) according to 324 IKEv2 [RFC5996], and maintained in this document. The G-IKEv2 325 IKE_SA_INIT, GSA_AUTH and GSA_REGISTRATION use the SPI according to 326 IKEv2 [RFC5996],section 2.6. 328 3.1.4. GM Registration Operations 330 A G-IKEv2 Initiator (GM) requesting registration contacts the GCKS 331 using the IKE_SA_INIT exchange and receives the response from the 332 GCKS. This exchange is unchanged from the IKE_SA_INIT in IKEv2 333 protocol. 335 Upon completion of parsing and verifying the IKE_SA_INIT response, 336 the GM sends the GSA_AUTH message with the IKEv2 payloads from 337 IKE_AUTH (without the SAi2, TSi and TSr) along with the Group ID 338 informing the GCKS of the group the initiator wishes to join. The 339 initiator MAY specify how many Sender-ID values it would like to 340 receive in the Notify payload status type SENDER_ID_REQUEST in case 341 the Data Security SA supports a counter mode cipher [section 3.2]. 343 Upon receiving the GSA_AUTH, the initiator then parses the response 344 from the GCKS authenticating the exchange using the IKEv2 method, 345 then processing the GSA, and KD. 347 The GSA payload contains the security protocol and cryptographic 348 protocols used by the group. This policy describes the Re-key SA 349 (KEK), if present, Data-security SAs (TEK), and other group policy 350 (GAP). If the policy in the GSA payload is not acceptable to the GM, 351 it SHOULD tear down the session after notifying the GCKS. Finally 352 the KD is parsed providing the keying material for the TEK and/or 353 KEK. The GM interprets the KD key packets, where each key packet 354 includes the keying material for SAs distributed in the GSA payload. 355 Keying material is matched by comparing the SPIs in the key packets 356 to SPIs previously included in the GSA payloads. Once TEK keys and 357 policy are matched, the GM provides them to the data security 358 subsystem, and it is ready to send or receive packets matching the 359 TEK policy. 361 The GSA KEK policy MUST include KEK attribute KEK_MESSAGE_ID with a 362 message id. The message id in the KEK_MESSAGE_ID attribute MUST be 363 checked against any previously received message id for this group. 364 If it is less than the previously received number, it should be 365 considered stale and ignored. This could happen if two GSA_AUTH 366 exchanges happened in parallel, and the message id changed. This 367 KEK_MESSAGE_ID is used by the GM to prevent GSA_REKEY message replay 368 attacks. The first GSA_REKEY message that the GM receives from the 369 GCKS has to have message id greater or equal to the message id 370 received in the KEK_MESSAGE_ID attribute. 372 3.1.5. GCKS Registration Operations 374 A G-IKEv2 GCKS passively listens for incoming requests from group 375 members. The GCKS receives the IKE_SA_INIT request, select the IKE 376 proposal, generates nonce and DH to include them in the IKE_SA_INIT 377 response. 379 Upon receiving the GSA_AUTH request, and after authenticate the group 380 member using the same properties as IKEv2, the GCKS locates the group 381 the GM wishes to join, extracts the policy for that group. If the 382 GCKS policy desires authorization, the GCKS authorizes the group 383 member against the specified credentials before preparing to send 384 GSA_AUTH response. The GSA_AUTH response MAY include group policy in 385 GSA payload and keys in the KD payload. If the GCKS policy include 386 group rekey option, this policy is constructed in the GSA KEK and the 387 key is constructed in the KD KEK. The GSA KEK MUST include attribute 388 KEK_MESSAGE_ID specify the starting message id the GCKS will be using 389 when sending the GSA_REKEY message to the group member. This message 390 id is used prevent replay attacks of the GSA_REKEY message and will 391 be increasing each time a GSA_REKEY message is sent to the group. 392 The GCKS data traffic policy is included in the GSA TEK and keys are 393 included in KD TEK. GSA GAP MAY also included to provide the ATD 394 and/or DTD [section 4.6.1] specifying activation and deactivation 395 delays for SAs generated from the TEKs. If one or more Data Security 396 SAs distributed in the GSA payload included a counter mode of 397 operation, the GCKS includes at least one SID value in the KD 398 payload, and possibly more depending on the request received in the 399 NOTIFY payload status type SENDER_ID_REQUEST requesting the number of 400 SIDs from the group member. 402 If the GCKS receives a GSA_REGISTRATION exchange with a request to 403 register a GM to a group, the GCKS will need to authorize the GM with 404 the new group (IDg) and respond with corresponding group policy and 405 keys. If the GCKS fails to authorize the GM, it will respond with 406 the AUTHORIZATION_FAILED notify message. 408 3.2. Counter-based modes of operation 410 Several new counter-based modes of operation have been specified for 411 ESP (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES-CCM [RFC4309], 412 AES-GMAC [RFC4543]) and AH (e.g., AES-GMAC [RFC4543]). These 413 counter-based modes require that no two senders in the group ever 414 send a packet with the same Initialization Vector (IV) using the same 415 cipher key and mode. This requirement is met in G-IKEv2 when the 416 following requirements are met: 418 o The GCKS distributes a unique key for each Data-Security SA. 420 o The GCKS uses the method described in [RFC6054], which assigns each 421 sender a portion of the IV space by provisioning each sender with one 422 or more unique SID values. 424 When at least one Data-Security SA included in the group policy 425 includes a counter-mode, the GCKS automatically allocates and 426 distributes one SID to each group member acting in the role of sender 427 on the Data-Security SA. The SID value is used exclusively by the 428 group member to which it was allocated. The group member uses the 429 same SID for each Data-Security SA specifying the use of a counter- 430 based mode of operation. A GCKS MUST distribute unique keys for each 431 Data-Security SA including a counter-based mode of operation in order 432 to maintain a unique key and nonce usage. 434 During registration, the group member can choose to request one or 435 more SID values. Requesting a value of 1 is not necessary since the 436 GCKS will automatically allocate exactly one to the sending group 437 member. A group member MUST request as many SIDs matching the number 438 of encryption modules in which it will be installing the TEKs in the 439 outbound direction. Alternatively, a group member MAY request more 440 than one SID and use them serially. This could be useful when it is 441 anticipated that the group member will exhaust their range of Data- 442 Security SA nonces using a single SID too quickly (e.g., before the 443 time-based policy in the TEK expires). 445 When group policy includes a counter-based mode of operation, a GCKS 446 SHOULD use the following method to allocate SID values, which ensures 447 that each SID will be allocated to just one group member. 449 1. A GCKS maintains an SID-counter, which records the SIDs that have 450 been allocated. SIDs are allocated sequentially, with the first SID 451 allocated to be zero. 453 2. Each time an SID is allocated, the current value of the counter 454 is saved and allocated to the group member. The SID-counter is then 455 incremented in preparation for the next allocation. 457 3. When the GCKS specifies a counter-based mode of operation in the 458 Data Security SA, and a group member is a sender, a group member may 459 request a count of SIDs during registration in a NOTIFY payload 460 information type SEND_ID_REQUEST. When the GCKS receives this 461 request, it increments the SID- counter once for each requested SID, 462 and distributes each SID value to the group member. 464 4. A GCKS allocates new SID values for each GSA_REGISTRATION 465 exchange originated by a sender, regardless of whether a group member 466 had previously contacted the GCKS. In this way, the GCKS does not 467 have a requirement of maintaining a record of which SID values it had 468 previously allocated to each group member. More importantly, since 469 the GCKS cannot reliably detect whether the group member had sent 470 data on the current group Data-Security SAs it does not know what 471 Data-Security counter-mode nonce values that a group member has used. 472 By distributing new SID values, the key server ensures that each time 473 a conforming group member installs a Data- Security SA it will use a 474 unique set of counter-based mode nonces. 476 5. When the SID-counter maintained by the GCKS reaches its final SID 477 value, no more SID values can be distributed. Before distributing 478 any new SID values, the GCKS MUST delete the Data- Security SAs for 479 the group, followed by creation of new Data- Security SAs, and 480 resetting the SID-counter to its initial value. 482 6. The GCKS SHOULD send a GSA_REKEY message deleting all Data- 483 Security SAs and the Rekey SA for the group. This will result in the 484 group members initiating a new GSA_REGISTRATION exchange, in which 485 they will receive both new SID values and new Data-Security SAs. The 486 new SID values can safely be used because they are only used with the 487 new Data-Security SAs. Note that deletion of the Rekey SA is 488 necessary to ensure that group members receiving a GSA_REKEY exchange 489 before the re-register do not inadvertently use their old SIDs with 490 the new Data-Security SAs. Using the method above, at no time can 491 two group members use the same IV values with the same Data-Security 492 SA key. 494 3.3. G-IKEv2 group maintenance channel 496 The GCKS indicates that it will be delivering group rekey messages 497 when the KEK policy and keys are present in the G-IKEv2 GSA and KD 498 payloads. Though the G-IKEv2 Rekey is optional, it plays a crucial 499 role for large and dynamic groups. The GCKS is responsible for 500 rekeying of the secure group per the group policy. The GCKS uses 501 multicast to transport the rekey message. The G-IKEv2 protocol uses 502 GSA_REKEY exchange type in G-IKEv2 header identifying it as a rekey 503 message. This rekey message is protected by the registration 504 exchanges. 506 3.3.1. G-IKEv2 GSA_REKEY exchange 508 The GCKS initiates the G-IKEv2 Rekey securely using IP multicast. 509 Since multicast rekey does not require a response and it sends to 510 multiple GMs, G-IKEv2 rekeying MUST NOT support windowing. The GCKS 511 rekey message replaces the rekey GSA KEK or KEK array, and/or creates 512 a new Data-Security GSA TEK. The SID Download attribute [section 513 4.7.4] in the Key Download payload MUST NOT be part of the Rekey 514 Exchange as this is sender specific information and the Rekey 515 Exchange is group specific. The GCKS initiates the GSA_REKEY 516 exchange as following: 518 Members (Responder) GCKS (Initiator) 519 -------------------- ------------------ 520 <-- HDR, SK {GSA, KD, [D,] AUTH } 522 HDR is defined in Section 4.1. The message id in this message will 523 start with the same value the GCKS sent to group member in the KEK 524 attribute KEK_MESSAGE_ID during registration; this message id will be 525 increasing each time a new GSA_REKEY message is sent to the group 526 members. 528 The GSA payload contains the current rekey and data security SAs. 529 The GSA may contain a new data security SA and/or a new rekey SA, 530 which, optionally contains an LKH rekey SA, Section 4.3. 532 The KD represents the keys for the policy included in the GSA. If 533 the data security SA is being refreshed in this rekey message, the 534 IPsec keys are updated in the KD, and/or if the rekey SA is being 535 refreshed in this rekey message, the rekey Key or the LKH KEK array 536 is updated in the KD payload. 538 The Delete payload is included to instruct the GM to delete existing 539 SAs. 541 The AUTH payload is included to authenticate GSA_REKEY message using 542 any of the authentication methods define by IKEv2 section 3.8. 543 Shared Key Integrity Code SHOULD NOT be used as it doesn't provide 544 source origin authentication (although a small group may not require 545 source origin authentication). During group member registration, the 546 GCKS sends the authentication key in the GSAK payload KEK_AUTH_KEY 547 attribute, which the group member uses to authenticate the key 548 server. Before the current Authentication Key expires, GCKS will 549 send a new KEK_AUTH_KEY to its group member in GSA_REKEY message. 550 The AUTH key that is used in the rekey message may not be the same as 551 the authentication key used in GSA_AUTH. Typically rekey message is 552 sent as multicast and receive by all group members, the same AUTH key 553 is distributed to all group members. 555 After adding the AUTH payload to the rekey message, the current KEK 556 encryption key encrypts all payloads following the HDR. 558 3.3.2. Forward and Backward Access Control 560 Through G-IKEv2 rekey, the G-IKEv2 supports algorithms such as LKH 561 that have the property of denying access to a new group key by a 562 member removed from the group (forward access control) and to an old 563 group key by a member added to the group (backward access control). 564 An unrelated notion to PFS, "forward access control" and "backward 565 access control" have been called "perfect forward security" and 566 "perfect backward security" in the literature [RFC2627]. 568 Group management algorithms providing forward and backward access 569 control other than LKH have been proposed in the literature, 570 including OFT [OFT] and Subset Difference [NNL]. These algorithms 571 could be used with G-IKEv2, but are not specified as a part of this 572 document. 574 Support for group management algorithms is supported via the 575 KEY_MANAGEMENT_ALGORITHM attribute which is sent in the GSA KEK 576 policy. G-IKEv2 specifies one method by which LKH can be used for 577 forward and backward access control. Other methods of using LKH, as 578 well as other group management algorithms such as OFT or Subset 579 Difference may be added to G-IKEv2 as part of a later document. Any 580 such addition MUST be due to a Standards Action as defined in 581 [RFC2434]. 583 3.3.3. Forward Access Control Requirements 585 When group membership is altered using a group management algorithm 586 new GSA TEKs (and their associated keys) are usually also needed. 587 New GSAs and keys ensure that members who were denied access can no 588 longer participate in the group. 590 If forward access control is a desired property of the group, new GSA 591 TEKs and the associated key packets in the KD payload MUST NOT be 592 included in a G-IKEv2 rekey message which changes group membership. 593 This is required because the GSA TEK policy and the associated key 594 packets in the KD payload are not protected with the new KEK. A 595 second G-IKEv2 rekey message can deliver the new GSA TEKS and their 596 associated keys because it will be protected with the new KEK, and 597 thus will not be visible to the members who were denied access. 599 If forward access control policy for the group includes keeping group 600 policy changes from members that are denied access to the group, then 601 two sequential G-IKEv2 rekey messages changing the group KEK MUST be 602 sent by the GCKS. The first G-IKEv2 rekey message creates a new KEK 603 for the group. Group members, which are denied access, will not be 604 able to access the new KEK, but will see the group policy since the 605 G-IKEv2 rekey message is protected under the current KEK. A 606 subsequent G-IKEv2 rekey message containing the changed group policy 607 and again changing the KEK allows complete forward access control. A 608 G-IKEv2 rekey message MUST NOT change the policy without creating a 609 new KEK. 611 If other methods of using LKH or other group management algorithms 612 are added to G-IKEv2, those methods MAY remove the above restrictions 613 requiring multiple G-IKEv2 rekey messages, providing those methods 614 specify how forward access control policy is maintained within a 615 single G-IKEv2 rekey message. 617 3.3.4. Deletion of SAs 619 There are occasions the GCKS may want to signal to receivers to 620 delete policy at the end of a broadcast, or if group policy has 621 changed. Deletion of keys MAY be accomplished by sending the G-IKEv2 622 Delete Payload [RFC5996], section 3.11 as part of the G-IKEv2 623 GSA_AUTH or GSA_REKEY Exchange. 625 When a policy delete is required the GCKS sends a rekey of the 626 following format: 628 Members (Responder) GCKS (Initiator) 629 -------------------- ------------------ 630 <-- HDR, SK { 631 [GSA], [KD], [D,] AUTH } 633 The GSA MAY specify the remaining active time of the remaining policy 634 by using the DTD attribute in the GSA GAP. If a GCKS has no further 635 SAs to send to group members, the GSA and KD payloads MUST be omitted 636 from the message. There may be circumstances where the GCKS may want 637 to start over with a clean slate. If the administrator is no longer 638 confident in the integrity of the group, the GCKS can signal deletion 639 of all policy of a particular TEK protocol by sending a TEK with a 640 SPI value equal to zero in the delete payload. For example, if the 641 GCKS wishes to remove all the KEKs and all the TEKs in the group, the 642 GCKS SHOULD send a delete payload with a spi of zero and a 643 protocol_id of a TEK protocol_id value define in Section 4.5, 644 followed by another delete payload with a spi of zero and protocol_id 645 of zero, indicating that the KEK SA should be deleted. 647 3.3.5. GSA_REKEY GCKS Operations 649 The GCKS may initiate a rekey message if group membership and/or 650 policy has changed, or if the keys are about to expire. The GCKS 651 builds the rekey message with value of the message id that is one 652 greater than the previous rekey. If the message is using a new KEK 653 attribute, the message id is reset to 1 in this message. The GSA and 654 KD follow with the same characteristics as in the GSA Registration 655 exchange. The AUTH payload is created by hashing the string 656 "G-IKEv2" and the message created so far, and then digitally signed. 657 Finally, the payloads following the HDR are encrypted using the 658 current KEK encryption key. 660 3.3.6. GSA_REKEY GM Operations 662 The group member receives the Rekey Message from the GCKS, decrypts 663 the message using the current KEK, validates the signature using the 664 public key retrieved in a previous G-IKEv2 exchange, verifies the 665 message id, and processes the GSA and KD payloads. The group member 666 then downloads the new data security SA and/or new Rekey GSA. The 667 parsing of the payloads is identical to the registration exchange. 669 Anti-replay protection is achieved when the group member rejects 670 GSA_REKEY message which has message id smaller than the current 671 message id that the GM is expecting. The GM expects the message id 672 in the first GSA_REKEY message it receives to be equal or greater 673 than the message id it receives in the KEK_MESSAGE_ID attribute. The 674 GM expects the message id in the subsequence GSA_REKEY message to be 675 greater than the last valid GSA_REKEY message it received. 677 If the SA payload includes Data-Security SA including a counter-modes 678 of operation and the receiving group member is a sender for that SA, 679 the group member uses its current SID value with the Data-Security 680 SAs to create counter-mode nonces. If it is a sender and does not 681 hold a current SID value, it MUST NOT install the Data-Security SAs. 682 It MAY initiate a GSA_REGISTRATION exchange to the GCKS in order to 683 obtain an SID value (along with current group policy). 685 4. Header and Payload Formats 687 Refer to IKEv2 [RFC5996] for existing payloads. 689 4.1. The G-IKEv2 Header 691 G-IKEv2 uses the same IKE header format as specified in RFC 5996 692 section 3.1. 694 Several new payload formats are required in the group security 695 exchanges. 697 Next Payload Type Value 698 ----------------- ----- 699 Group Identification (IDg) 50 700 Group Security Association (GSA) 51 701 Key Download (KD) 52 703 New exchange types GSA_AUTH, GSA_REGISTRATION and GSA_REKEY are added 704 to the IKEv2 [RFC5996] protocol. 706 Exchange Type Value 707 -------------- ----- 708 GSA_AUTH 39 709 GSA_REGISTRATION 40 710 GSA_REKEY 41 712 Major Version is 2 and Minor Version is 0 as in IKEv2 [RFC5996]. IKE 713 SA initiator SPI, IKE SA responder SPI, Flags, Message Id are as 714 specified in [RFC5996]. 716 4.2. Group Identification (IDg) Payload 718 The IDg Payload allows the group member to indicate which group it 719 wants to join. The payload is constructed by using the IKEv2 720 [RFC5996] Identification Payload. ID type ID_KEY_ID MUST be 721 supported. ID types ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, 722 ID_IPV6_ADDR SHOULD be supported. ID types ID_DER_ASN1_DN and 723 ID_DER_ASN1_GN are not expected to be used. 725 4.3. Group Security Association Payload 727 The Group Security Association payload is used by the GCKS to assert 728 security attributes for both Re-key and Data-security SAs. 730 0 1 2 3 731 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 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 733 ! Next Payload ! RESERVED ! Payload Length ! 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 The Security Association Payload fields are defined as follows: 738 o Next Payload (1 octet) -- Identifies the next payload type for the 739 G-IKEv2 registration or the G-IKEv2 rekey message. 741 o RESERVED (1 octet) -- Must be zero. 743 o Payload Length (2 octets) -- Is the octet length of the current 744 payload including the generic header and all TEK and KEK policies. 746 4.3.1. GSA policy 748 Following GSA generic payload header are GSA policies for group 749 rekeying (KEK) and/or data traffic SAs (TEK). There may be zero or 750 one GSA KEK policy, zero or more GAP policy, and zero or more GSA TEK 751 policies, where either one GSA KEK or GSA TEK payload MUST be 752 present. 754 This latitude allows various group policies to be accommodated. For 755 example if the group policy does not require the use of a Re-key SA, 756 the GCKS would not need to send an GSA KEK attribute to the group 757 member since all SA updates would be performed using the Registration 758 SA. Alternatively, group policy might use a Re-key SA but choose to 759 download a KEK to the group member only as part of the Registration 760 SA. Therefore, the GSA KEK policy would not be necessary as part of 761 the GSA_REKEY message. 763 Specifying multiple GSA TEKs allows multiple sessions to be part of 764 the same group and multiple streams to be associated with a session 765 (e.g., video, audio, and text) but each with individual security 766 association policy. 768 A GAP payload allows for the distribution of group-wise policy, such 769 as instructions as to when to activate and de-activate SAs. 771 Policies following the GSA payload has common header 773 0 1 2 3 774 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 ! Type ! RESERVED ! Length ! 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 780 Type is defined as follow: 782 0 - RESERVED 783 1 - KEK 784 2 - GAP 785 3 - TEK 786 4-240 - RESERVED 787 241-255 - private and experimental 789 4.4. KEK Policy 791 The GSA KEK (GSAK) policy contains security attributes for the KEK 792 method for a group and parameters specific to the G-IKEv2 793 registration operation. The source and destination identities 794 describe the identities used for the G-IKEv2 registration datagram. 796 0 1 2 3 797 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 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 799 ! Type ! RESERVED ! Length ! 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 801 ! ! 802 ~ SPI ~ 803 ! ! 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 805 ! ! 806 ~ ~ 807 ! ! 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 809 ! ! 810 ~ ~ 811 ! ! 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 813 ~ KEK Attributes ~ 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 816 The GSAK Payload fields are defined as follows: 818 o Type (1 octet) -- Identifies the GSA payload type KEK present in 819 the G-IKEv2 registration or the G-IKEv2 rekey message. 821 o RESERVED (1 octet) -- Must be zero. 823 o Length (2 octets) -- Length of this structure including KEK 824 attributes. 826 o SPI (16 octets) -- Security Parameter Index for the KEK. The SPI 827 must be the IKEv2 Header SPI pair where the first 8 octets become 828 the "Initiator's SPI" field of the G-IKEv2 rekey message IKEv2 829 HDR, and the second 8 octets become the "Responder's SPI" in the 830 same HDR. As described above, these SPIs are assigned by the 831 GCKS. 833 o Source & Destination Traffic Selectors - Substructures describing 834 the source and destination of the identities. These identities 835 refer to the source and destination of the next KEK rekey SA. 836 Defined format and values are specified by IKEv2 [RFC5996], 837 section 3.13.1. 839 o KEK Attributes -- Contains KEK policy attributes associated with 840 the group. The following sections describe the possible 841 attributes. Any or all attributes may be optional, depending on 842 the group policy. 844 4.4.1. KEK Attributes 846 The following attributes may be present in a GSA KEK policy. The 847 attributes must follow the format defined in IKEv2 [RFC5996] section 848 3.3.5. In the table, attributes that are defined as TV are marked as 849 Basic (B); attributes that are defined as TLV are marked as Variable 850 (V). 852 ID Class Value Type 853 -------- ----- ---- 854 RESERVED 0 855 KEK_MANAGEMENT_ALGORITHM 1 B 856 KEK_ENCR_ALGORITHM 2 B 857 KEK_KEY_LENGTH 3 B 858 KEK_KEY_LIFETIME 4 V 859 KEK_INTEGRITY_ALGORITHM 5 B 860 KEK_AUTH_METHOD 6 B 861 KEK_AUTH_ALGORITHM 7 B 862 KEK_MESSAGE_ID 8 B 864 The following attributes may only be included in a G-IKEv2 865 registration message: KEK_MANAGEMENT_ALGORITHM. 867 Minimum attributes that must be sent as part of an GSA KEK: 868 KEK_ENCR_ALGORITHM, KEK_KEY_LENGTH (if the cipher definition includes 869 a variable length key), KEK_MESSAGE_ID, KEK_KEY_LIFETIME, 870 KEK_INTEGRITY_ALGORITHM, KEK_AUTH_METHOD and KEK_AUTH_ALGORITHM 871 (except for DSA based algorithms). 873 4.4.2. KEK_MANAGEMENT_ALGORITHM 875 The KEK_MANAGEMENT_ALGORITHM class specifies the group KEK management 876 algorithm used to provide forward or backward access control (i.e., 877 used to exclude group members). Defined values are specified in the 878 following table. 880 KEK Management Type Value 881 ------------------- ----- 882 RESERVED 0 883 LKH 1 884 Expert Review 2-127 885 Private Use 128-255 887 4.4.3. KEK_ENCR_ALGORITHM 889 The KEK_ENCR_ALGORITHM class specifies the encryption algorithm using 890 with the KEK. This is the same as IKEv2 encryption algorithm defined 891 in [RFC5996] section 3.3.2. If a KEK_MANAGEMENT_ALGORITHM is defined 892 which defines multiple keys (e.g., LKH), and if the management 893 algorithm does not specify the algorithm for those keys, then the 894 algorithm defined by the KEK_ENCR_ALGORITHM attribute MUST be used 895 for all keys which are included as part of the management. 897 4.4.4. KEK_KEY_LENGTH 899 The KEK_KEY_LENGTH class specifies the KEK Algorithm key length (in 900 bits). 902 The Group Controller/Key Server (GCKS) adds the KEK_KEY_LENGTH 903 attribute to the GSA payload when distributing KEK policy to group 904 members. The group member verifies whether or not it has the 905 capability of using a cipher key of that size. If the cipher 906 definition includes a fixed key length, the group member can make its 907 decision solely using KEK_ENCR_ALGORITHM attribute and does not need 908 the KEK_KEY_LENGTH attribute. Sending the KEK_KEY_LENGTH attribute 909 in the GSA payload is OPTIONAL if the KEK cipher has a fixed key 910 length. 912 4.4.5. KEK_KEY_LIFETIME 914 The KEK_KEY_LIFETIME class specifies the maximum time for which the 915 KEK is valid. The GCKS may refresh the KEK at any time before the 916 end of the valid period. The value is a four (4) octet number 917 defining a valid time period in seconds. 919 4.4.6. KEK_INTEGRITY_ALGORITHM 921 KEK_INTEGRITY specifies the integrity algorithm. This integrity 922 algorithm is specified in IKEv2 RFC 5996 section 3.3.2. 924 4.4.7. KEK_AUTH_METHOD 926 KEK_AUTH_METHOD specifies the method of authentication used. This is 927 the same as IKEv2 Auth Method specified in IKEv2 RFC 5996 section 3.8 929 4.4.8. KEK_AUTH_ALGORITHM 931 KEK_AUTH_ALGORITHM specifies the hash algorithm uses to generate AUTH 932 key to authenticate GSA_REKEY message. Hash algorithms are defined 933 in IANA registry IKEv2 Hash Algorithms [IKEV2-IANA]. This attribute 934 can be used by group member to determine in advance if it support the 935 algorithm used in the rekey message. 937 4.4.9. KEK_MESSAGE_ID 939 KEK_MESSAGE_ID define the start message id to be used by the GCKS in 940 the GSA_REKEY message. Message ID is 4 octets unsigned integer. 942 4.5. GSA TEK Policy 944 The GSA TEK (GSAT) policy contains security attributes for a single 945 TEK associated with a group. 947 0 1 2 3 948 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 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 950 ! Type ! RESERVED ! Length ! 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 952 ! Protocol-ID ! TEK Protocol-Specific Payload ! 953 +-+-+-+-+-+-+-+-+ ~ 954 ~ ! 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 957 The GSAT Payload fields are defined as follows: 959 o Type (1 octet) -- Identifies the GSA payload type TEK present in 960 the G-IKEv2 registration or the G-IKEv2 rekey message. 962 o RESERVED (1 octet) -- Must be zero. 964 o Length (2 octets) -- Length of this structure, including the TEK 965 Protocol-Specific Payload. 967 o Protocol-ID (1 octet) -- Value specifying the Security Protocol. 968 The following table defines values for the Security Protocol 970 Protocol ID Value 971 ----------- ----- 972 RESERVED 0 973 GSA_PROTO_IPSEC_ESP 1 974 GSA_PROTO_IPSEC_AH 2 975 Expert Review 3-127 976 Private Use 128-255 978 Support for the GSA_PROTO_IPSEC_AH GSA TEK is OPTIONAL. 980 o TEK Protocol-Specific Payload (variable) -- Payload which 981 describes the attributes specific for the Protocol-ID. 983 4.5.1. TEK ESP and AH Protocol-Specific Policy 985 The TEK Protocol-Specific policy contains of two traffic selectors 986 for source and destination of the protecting traffic, SPI, Transform, 987 and Attributes. 989 The TEK Protocol-Specific policy for ESP is as follows: 991 0 1 2 3 992 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 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 ! SPI ! 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 996 | | 997 ~ ~ 998 | | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | | 1001 ~ | 1002 | | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1004 | | 1005 ~ ~ 1006 | | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1008 ! TEK Attributes ~ 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1011 The GSAT Policy fields are defined as follows: 1013 o SPI (4 octets) -- Security Parameter Index. 1015 o Source & Destination Traffic Selectors - The traffic selectors 1016 describe the source and the destination of the protecting traffic. 1017 The format and values are defined in IKEv2 [RFC5996], section 1018 3.13.1. 1020 o Transform -- A substructure specifies the transform information. 1021 The format and values are defined in IKEv2 [RFC5996], section 1022 3.3.2. 1024 o TEK Attributes -- Contains TEK policy attributes associated with 1025 the group. The following sections describe the possible 1026 attributes. Any or all attributes may be optional, depending on 1027 the group policy. [RFC5996], section 3.3.5. 1029 Attribute Types 1030 class value type 1031 -------------------------------------- 1032 Life Duration 1 V 1034 Specifies the time-to-live for the overall security 1035 association. When the TEK expires, all keys downloaded 1036 under the association (AH or ESP) must be re-rekeyed. 1037 The life duration attribute defines the actual length 1038 of the component lifetime in seconds that can be 1039 protected. 1041 If unspecified, the default value shall be assumed to be 1042 28800 seconds (8 hours). 1044 Mode 2 B 1045 In the absence of this attribute tunnel mode will be used. 1046 Value of 1 is used for transport mode. 1048 4.6. GSA Group Associated Policy 1050 Group specific policy that does not belong to rekey policy (GSA KEK) 1051 or traffic encryption policy (GSA TEK) can be distributed to all 1052 group member using GSA GAP (Group Associated Policy). 1054 The GSA GAP payload is defined as follows: 1056 0 1 2 3 1057 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 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1059 ! Type ! RESERVED ! Length ! 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1061 ! Group Associated Policy Attributes ~ 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1064 The GSA GAP payload fields are defined as follows: 1066 o Type (1 octet) -- Identifies the GSA payload type GAP present in 1067 the G-IKEv2 registration or the G-IKEv2 rekey message. 1069 o RESERVED (1 octet) -- Must be zero. 1071 o Length (2 octets) -- Length of this structure, including the GSA 1072 GAP header and Attributes. 1074 o Group Associated Policy Attributes (variable) -- Contains 1075 attributes following the format defined in Section 3.3.5 of 1076 [RFC5996]. 1078 Attribute Types: 1080 Attribute Type Value Type 1081 -------------- ----- ---- 1082 RESERVED 0 1083 ACTIVATION_TIME_DELAY 1 B 1084 DEACTIVATION_TIME_DELAY 2 B 1085 Unassigned 3-127 1086 Private Use 128-255 1087 Unassigned 256-32767 1089 Several group associated policy attributes are defined below. A 1090 G-IKEv2 implementation MUST abort if it encounters an attribute or 1091 capability that it does not understand. 1093 4.6.1. ACTIVATION_TIME_DELAY/DEACTIVATION_TIME_DELAY 1095 Section 4.2.1 of RFC 5374 specifies a key rollover method that 1096 requires two values be given it from the group key management 1097 protocol. The ACTIVATION_TIME_DELAY attribute allows a GCKS to set 1098 the Activation Time Delay (ATD) for SAs generated from TEKs. The ATD 1099 defines how long after receiving new SAs that they are to be 1100 activated by the GM. The ATD value is in seconds. 1102 The DEACTIVATION_TIME_DELAY allows the GCKS to set the Deactivation 1103 Time Delay (DTD) for previously distributed SAs. The DTD defines how 1104 long after receiving new SAs that it should deactivate SAs that are 1105 destroyed by the re-key event. The value is in seconds. 1107 The values of ATD and DTD are independent. However, the DTD value 1108 should be larger, which allows new SAs to be activated before older 1109 SAs are deactivated. Such a policy ensures that protected group 1110 traffic will always flow without interruption. 1112 4.7. Key Download Payload 1114 The Key Download Payload contains group keys for the group specified 1115 in the GSA Payload. These key download payloads can have several 1116 security attributes applied to them based upon the security policy of 1117 the group as defined by the associated GSA Payload. 1119 0 1 2 3 1120 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 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1122 ! Next Payload ! RESERVED ! Length ! 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1124 ! Number of Key Packets ! RESERVED2 ! 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1126 ~ Key Packets ~ 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1129 The Key Download Payload fields are defined as follows: 1131 o Next Payload (1 octet) -- Identifier for the payload type of the 1132 next payload in the message. If the current payload is the last 1133 in the message, then this field will be zero. 1135 o RESERVED (1 octet) -- Unused, set to zero. 1137 o Payload Length (2 octets) -- Length in octets of the current 1138 payload, including the generic payload header. 1140 o Number of Key Packets (2 octets) -- Contains the total number of 1141 both TEK and Rekey arrays being passed in this data block. 1143 o Key Packets Several types of key packets are defined. Each Key 1144 Packet has the following format. 1146 0 1 2 3 1147 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 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1149 ! KD Type ! RESERVED ! KD Length ! 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1151 ! SPI Size ! SPI (variable) ~ 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1153 ~ Key Packet Attributes ~ 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1156 o Key Download (KD) Type (1 octet) -- Identifier for the Key Data 1157 field of this Key Packet. 1159 Key Download Type Value 1160 ----------------- ----- 1161 RESERVED 0 1162 TEK 1 1163 KEK 2 1164 LKH 3 1165 SID 4 1166 Expert Review 5-127 1167 Private Use 128-255 1169 "KEK" is a single key whereas LKH is an array of key-encrypting keys. 1171 o RESERVED (1 octet) -- Unused, set to zero. 1173 o Key Download Length (2 octets) -- Length in octets of the Key 1174 Packet data, including the Key Packet header. 1176 o SPI Size (1 octet) -- Value specifying the length in octets of the 1177 SPI as defined by the Protocol-Id. 1179 o SPI (variable length) -- Security Parameter Index which matches a 1180 SPI previously sent in an GSAK or GSAT Payload. 1182 o Key Packet Attributes (variable length) -- Contains Key 1183 information. The format of this field is specific to the value of 1184 the KD Type field. The following sections describe the format of 1185 each KD Type. 1187 4.7.1. TEK Download Type 1189 The following attributes may be present in a TEK Download Type. 1190 Exactly one attribute matching each type sent in the GSAT payload 1191 MUST be present. The attributes must follow the format defined in 1192 IKEv2 (Section 3.3.5 of [RFC5996]). In the table, attributes defined 1193 as TV are marked as Basic (B); attributes defined as TLV are marked 1194 as Variable (V). 1196 TEK Class Value Type 1197 --------- ----- ---- 1198 RESERVED 0 1199 TEK_ALGORITHM_KEY 1 V 1200 TEK_INTEGRITY_KEY 2 V 1202 If no TEK key packets are included in a Registration KD payload, the 1203 group member can expect to receive the TEK as part of a Re-key SA. 1204 At least one TEK must be included in each Re-key KD payload. 1205 Multiple TEKs may be included if multiple streams associated with the 1206 SA are to be rekeyed. 1208 4.7.1.1. TEK_ALGORITHM_KEY 1210 The TEK_ALGORITHM_KEY class contains encryption keying material for 1211 this SPI. This keying material will be used with the encryption 1212 algorithm specified in the GSAT payload, and according to the IPsec 1213 transform describing that encryption algorithm. The keying material 1214 is treated equivalent to IKEv2 KEYMAT derived for that IPsec 1215 transform. If the encryption algorithm requires a nonce (e.g., AES- 1216 GCM), the nonce is chose as shown in Section 3.2. 1218 4.7.1.2. TEK_INTEGRITY_KEY 1220 The TEK_INTEGRITY_KEY class declares that the integrity key for this 1221 SPI is contained as the Key Packet Attribute. The integrity 1222 algorithm that will use this key was specified in the GSAT payload. 1223 TEK integrity key type AUTH_HMAC_SHA1_96 keys will consist of 160 1224 bits [RFC2404], and AUTH_HMAC_MD5_96 keys will consist of 128 bits 1225 [RFC2403]. AUTH_HMAC-SHA2_256_128 and AUTH_AES_128_GMAC keys will 1226 have a key length equal to the output length of the hash functions 1227 [RFC4868] [RFC4543]. Readers should refer to IKEV2IANA for the 1228 latest values. 1230 4.7.2. KEK Download Type 1232 The following attributes may be present in a KEK Download Type. 1233 Exactly one attribute matching each type sent in the GSAK payload 1234 MUST be present. The attributes must follow the format defined in 1235 IKEv2 (Section 3.3.5 of [RFC5996]). In the table, attributes defined 1236 as TV are marked as Basic (B); attributes defined as TLV are marked 1237 as Variable (V). 1239 KEK Class Value Type 1240 --------- ----- ---- 1241 RESERVED 0 1242 KEK_ENCR_KEY 1 V 1243 KEK_INTEGRITY_KEY 2 V 1244 KEK_AUTH_KEY 1246 If the KEK key packet is included, there MUST be only one present in 1247 the KD payload. 1249 4.7.2.1. KEK_ENCR_KEY 1251 The KEK_ENCR_KEY class declares the encryption key for this SPI is 1252 contained in the Key Packet Attribute. The encryption algorithm that 1253 will use this key was specified in the GSAK payload. 1255 If the mode of operation for the algorithm requires an Initialization 1256 Vector (IV), an explicit IV MUST be included in the KEK_ALGORITHM_KEY 1257 before the actual key. 1259 4.7.2.2. KEK_INTEGRITY_KEY 1261 The KEK_INTEGRITY_KEY class declares the integrity key for this SPI 1262 is contained in the Key Packet Attribute. The integrity algorithm 1263 that will use this key was specified in the GSAK payload. 1265 4.7.2.3. KEK_AUTH_KEY 1267 The KEK_AUTH_KEY class declares that the public key for this SPI is 1268 contained in the Key Packet Attribute, which may be useful when no 1269 public key infrastructure is available. The signature algorithm that 1270 will use this key was specified in the GSAK payload. RSA public key 1271 format is defined in RFC 3447, Section A.1.1. DSS public key format 1272 is defined in RFC 3270 Section 2.3.2. For ECDSA Public keys, use 1273 format described in RFC 5480 Section 2.2. 1275 4.7.3. LKH Download Type 1277 The LKH key packet is comprised of attributes representing different 1278 leaves in the LKH key tree. 1280 The following attributes are used to pass an LKH KEK array in the KD 1281 payload. The attributes must follow the format defined in IKEv2 1282 (Section 3.3.5 of [RFC5996]). In the table, attributes defined as TV 1283 are marked as Basic (B); attributes defined as TLV are marked as 1284 Variable (V). 1286 KEK Class Value Type 1287 --------- ----- ---- 1288 RESERVED 0 1289 LKH_DOWNLOAD_ARRAY 1 V 1290 LKH_UPDATE_ARRAY 2 V 1291 AUTH_ALGORITHM_KEY 3 V 1292 Expert Review 4-127 1293 Private Use 128-255 1295 If an LKH key packet is included in the KD payload, there must be 1296 only one present. 1298 4.7.3.1. LKH_DOWNLOAD_ARRAY 1300 This attribute is used to download a set of keys to a group member. 1301 It MUST NOT be included in a IKEv2 rekey message KD payload if the 1302 IKEv2 rekey is sent to more than the group member. If an 1303 LKH_DOWNLOAD_ARRAY attribute is included in a KD payload, there must 1304 be only one present. 1306 This attribute consists of a header block, followed by one or more 1307 LKH keys. 1309 0 1 2 3 1310 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 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 ! LKH Version ! # of LKH Keys ! RESERVED ! 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 ! LKH Keys ! 1315 ~ ~ 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 The KEK_LKH attribute fields are defined as follows: 1320 o LKH version (1 octet) -- Contains the version of the LKH protocol 1321 which the data is formatted in. Must be one. 1323 o Number of LKH Keys (2 octets) -- This value is the number of 1324 distinct LKH keys in this sequence. 1326 o RESERVED (1 octet) -- Unused, set to zero. 1328 Each LKH Key is defined as follows: 1330 0 1 2 3 1331 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 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 ! LKH ID ! Key Type ! RESERVED ! 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 ~ Key Creation Date ! 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 ~ Key expiration Date ! 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 ~ Key Handle ! 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 ! ! 1342 ~ Key Data ~ 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 o LKH ID (2 octets) -- This is the position of this key in the 1346 binary tree structure used by LKH. 1348 o Key Type (1 octet) -- This is the encryption algorithm for which 1349 this key data is to be used. This value is specified in 1350 Section 4.4.3. 1352 o RESERVED (1 octet) -- Unused, set to zero. 1354 o Key Creation Date (4 octets) -- This is the time value of when 1355 this key data was originally generated. A time value of zero 1356 indicates that there is no time before which this key is not 1357 valid. 1359 o Key Expiration Date (4 octets) -- This is the time value of when 1360 this key is no longer valid for use. A time value of zero 1361 indicates that this key does not have an expiration time. 1363 o Key Handle (4 octets) -- This is the randomly generated value to 1364 uniquely identify a key within an LKH ID. 1366 o Key Data (variable length) -- This is the actual encryption key 1367 data, which is dependent on the Key Type algorithm for its format. 1368 If the mode of operation for the algorithm requires an 1369 Initialization Vector (IV), an explicit IV MUST be included in the 1370 Key Data field before the actual key. 1372 The Key Creation Date and Key expiration Dates MAY be zero. This is 1373 necessary in the case where time synchronization within the group is 1374 not possible. 1376 The first LKH Key structure in an LKH_DOWNLOAD_ARRAY attribute 1377 contains the Leaf identifier and key for the group member. The rest 1378 of the LKH Key structures contain keys along the path of the key tree 1379 in order from the leaf, culminating in the group KEK. 1381 4.7.3.2. LKH_UPDATE_ARRAY 1383 This attribute is used to update the keys for a group. It is most 1384 likely to be included in a G-IKEv2 rekey message KD payload to rekey 1385 the entire group. This attribute consists of a header block, 1386 followed by one or more LKH keys, as defined in Section 4.7.3.1. 1388 There may be any number of UPDATE_ARRAY attributes included in a KD 1389 payload. 1391 0 1 2 3 1392 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 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 ! LKH Version ! # of LKH Keys ! RESERVED ! 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 ! LKH ID ! RESERVED2 ! 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 ! Key Handle ! 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 ! LKH Keys ! 1401 ~ ~ 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 o LKH version (1 octet) -- Contains the version of the LKH protocol 1405 which the data is formatted in. Must be one. 1407 o Number of LKH Keys (2 octets) -- This value is the number of 1408 distinct LKH keys in this sequence. 1410 o RESERVED (1 octet) -- Unused, set to zero. 1412 o LKH ID (2 octets) -- This is the node identifier associated with 1413 the key used to encrypt the first LKH Key. 1415 o RESERVED2 (2 octets) -- Unused, set to zero. 1417 o Key Handle (4 octets) -- This is the value to uniquely identify 1418 the key within the LKH ID which was used to encrypt the first LKH 1419 key. 1421 The LKH Keys are as defined in Section 4.7.3.1. The LKH Key 1422 structures contain keys along the path of the key tree in order from 1423 the LKH ID found in the LKH_UPDATE_ARRAY header, culminating in the 1424 group KEK. The Key Data field of each LKH Key is encrypted with the 1425 LKH key preceding it in the LKH_UPDATE_ARRAY attribute. The first 1426 LKH Key is encrypted under the key defined by the LKH ID and Key 1427 Handle found in the LKH_UPDATE_ARRAY header. 1429 4.7.4. SID Download Type 1431 This attribute is used to download one or use more Sender-ID (SID) 1432 values for the exclusive use of a group member. 1434 KEK Class Value Type 1435 --------- ----- ---- 1436 RESERVED 0 1437 NUMBER_OF_SID_BITS 1 V 1438 SID_VALUE 2 V 1439 Expert Review 3-128 1440 Private Use 129-255 1441 Unassigned 256-32767 1443 Because a SID value is intended for a single group member, the SID 1444 Download type MUST NOT be distributed in a GROUPKEY_PUSH message 1445 distributed to multiple group members. 1447 4.7.4.1. NUMBER_OF_SID_BITS 1449 The NUMBER_OF_SID_BITS class declares how many bits of the cipher 1450 nonce in which to represent an SID value. This value applied to each 1451 SID value is distributed in the SID Download. 1453 4.7.4.2. SID_VALUE 1455 The SID_VALUE class declares a single SID value for the exclusive use 1456 of the a group member. Multiple SID_VALUE attributes MAY be included 1457 in a SID Download. 1459 4.7.4.3. GM Semantics 1461 The SID_VALUE attribute value distributed to the group member MUST be 1462 used by that group member as the SID field portion of the IV for all 1463 Data-Security SAs including a counter-based mode of operation 1464 distributed by the GCKS as a part of this group. When the Sender- 1465 Specific IV (SSIV) field for any Data-Security SA is exhausted, the 1466 group member MUST no longer act as a sender on that SA using its 1467 active SID. The group member SHOULD re-register, at which time the 1468 GCKS will issue a new SID to the group member, along with either the 1469 same Data-Security SAs or replacement ones. The new SID replaces the 1470 existing SID used by this group member, and also resets the SSIV 1471 value to its starting value. A group member MAY re-register prior to 1472 the actual exhaustion of the SSIV field to avoid dropping data 1473 packets due to the exhaustion of available SSIV values combined with 1474 a particular SID value. 1476 A group member MUST NOT process an SID Download Type KD payload 1477 present in a GSA-REKEY message. 1479 4.7.4.4. GCKS Semantics 1481 If any KD payload includes keying material that is associated with a 1482 counter-mode of operation, an SID Download Type KD payload containing 1483 at least one SID_VALUE attribute MUST be included. The GCKS MUST NOT 1484 send the SID Download Type KD payload as part of a GSA-REKEY message, 1485 because distributing the same sender-specific policy to more than one 1486 group member will reduce the security of the group. 1488 4.8. Delete Payload 1490 There are occasions the GCKS may want to signal to receivers to 1491 delete policy at the end of a broadcast, or if policy has changed. 1492 Deletion of keys MAY be accomplished by sending an IKEv2 Delete 1493 Payload, section 3.11 of [RFC5996] as part of the GSA_AUTH or 1494 GSA_REKEY Exchange. One or more Delete payloads MAY be placed 1495 following the HDR payload in the GSA_AUTH or GSA_REKEY Exchange. 1497 The Protocol ID MUST be TBD1 for GSA_REKEY Exchange, 2 for AH or 3 1498 for ESP. Note that only one protocol id value can be defined in a 1499 Delete payload. If a TEK and a KEK SA for GSA_REKEY Exchange must be 1500 deleted, they must be sent in different Delete payloads. Similarly, 1501 if a TEK specifying ESP and a TEK specifying AH need to be deleted, 1502 they must be sent in different Delete payloads. 1504 There may be circumstances where the GCKS may want to start over with 1505 a clean slate. If the administrator is no longer confident in the 1506 integrity of the group, the GCKS can signal deletion of all policy of 1507 a particular TEK protocol by sending a TEK with an SPI value equal to 1508 zero in the delete payload. For example, if the GCKS wishes to 1509 remove all the KEKs and all the TEKs in the group, the GCKS SHOULD 1510 send a delete payload with an SPI of zero and a Protocol-ID of AH or 1511 ESP Protocol-ID value, followed by another delete payload with an SPI 1512 value of zero and Protocol-ID of KEK SA, indicating that the KEK SA 1513 should be deleted. 1515 4.9. Notify Payload 1517 G-IKEv2 uses the same notify payload as specified in [RFC5996], 1518 section 3.10. 1520 There are additional notify message types introduced by G-IKEv2 to 1521 communicate error conditions and status. 1523 NOTIFY MESSAGES - ERROR TYPES Value 1524 ------------------------------------------------------------------- 1525 INVALID_GROUP_ID - 45 1526 Indicates the group id sent during registration process is invalid. 1528 AUTHORIZATION_FAILED - 46 1529 Sent in the response to GSA_AUTH message when authorization failed. 1531 NOTIFY MESSAGES - STATUS TYPES Value 1532 ------------------------------------------------------------------- 1533 SENDER_REQUEST_ID - 16429 1534 Sent in GSA_AUTH or GSA_REGISTRATION to request SIDs from GCKS. 1535 The data includes a count of how many SID values it desires. 1537 4.10. Authentication Payload 1539 G-IKEv2 uses the same Authentication payload as specified in 1540 [RFC5996], section 3.8, to sign the rekey message. 1542 5. Security Considerations 1544 5.1. GSA registration and secure channel 1546 G-IKEv2 registration exchange uses IKEv2 IKE_SA_INIT, GSA_AUTH and 1547 GSA_REGISTRATION inheriting all the security considerations 1548 documented in [RFC5996] section 5 Security Considerations, including 1549 authentication, confidentiality, protection against man-in-the 1550 middle, protection against replay/reflection attacks, and denial of 1551 service protection. In addition, G-IKEv2 brings in the capability to 1552 authorize a particular group member regardless of whether they have 1553 the IKEv2 credentials. 1555 5.2. GSA maintenance channel 1557 The GSA maintenance channel is cryptographically and integrity 1558 protected using the cryptographic algorithm and key negotiated in the 1559 GSA member registration exchanged. 1561 5.2.1. Authentication/Authorization 1563 Authentication is implicit, the public key of the identity is 1564 distributed during the registration, and the receiver of the rekey 1565 message uses that public key and identity to verify the message is 1566 come from the authorized GCKS. 1568 5.2.2. Confidentiality 1570 Confidentiality is provided by distributing a confidentiality key as 1571 part of the GSA member registration exchange. 1573 5.2.3. Man-in-the-Middle Attack Protection 1575 GSA maintenance channel is integrity protected by using digital 1576 signature. 1578 5.2.4. Replay/Reflection Attack Protection 1580 The GSA rekey message includes a monotonically increasing sequence 1581 number to protect against replay and reflection attacks. A group 1582 member will recognize a replayed message by comparing the message id 1583 number to that of the last received rekey message, any rekey message 1584 contains message id number less than or equal to the last received 1585 value SHOULD be discarded. Implementations SHOULD keep a record of 1586 recently received GSA rekey messages for this comparison. 1588 6. IANA Considerations 1590 6.1. New registries 1592 A new set of registries are created for this draft. 1594 GSA type Registry, see Section 4.3.1 1596 KEK Attributes Registry, see Section 4.4.1 1598 KEK Management Algorithm Registry, see Section 4.4.2 1600 GSA TEK Payload Protocol ID Type Registry, see Section 4.5 1602 TEK Attributes Registry, see Section 4.5 1604 Key Download Type Registry, see Section 4.7 1606 TEK Download Type Registry, see Section 4.7.1 1608 KEK Download Type Registry, see Section 4.7.2 1610 LKH Download Type Registry, see Section 4.7.3 1612 SID Download Type Registry, see Section 4.7.4 1614 6.2. New payload and exchange types to existing IKEv2 registry 1616 The following new payloads and exchange types already allocated by 1617 IANA 1619 The present document describes new IKEv2 Next Payload types, see 1620 Section 4.1 1622 The present document describes new IKEv2 Exchanges types, see 1623 Section 4.1 1625 The present document describes new IKEv2 Notify Payload types, see 1626 Section 4.9 1628 New payload type request to be allocated by IANA 1630 The present document describes a new IKEv2 Security Protocol 1631 Identifiers protocol ID, see Section 4.8. TBD1 represents new IKEv2 1632 Security Protocol Identifiers for GIKEv2_REKEY. 1634 6.3. New Name spaces 1636 The present document describes many new name spaces for use in the 1637 G-IKEv2 payloads. Those may be found in subsections under Section 4. 1638 A new G-IKEv2 registry has been created for these name spaces. 1640 Portions of name spaces marked "RESERVED" are reserved for IANA 1641 allocation. New values MUST be added due to a Standards Action as 1642 defined in [RFC2434]. 1644 Portions of name spaces marked "Private Use" may be allocated by 1645 implementations for their own purposes. 1647 7. Acknowledgements 1649 The authors thank Lakshminath Dondeti and Jing Xiang for originating 1650 the GKDP document and providing the basis behind the protocol. 1652 8. References 1654 8.1. Normative References 1656 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1657 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1658 RFC 5996, DOI 10.17487/RFC5996, September 2010, 1659 . 1661 [RFC6054] McGrew, D. and B. Weis, "Using Counter Modes with 1662 Encapsulating Security Payload (ESP) and Authentication 1663 Header (AH) to Protect Group Traffic", RFC 6054, 1664 DOI 10.17487/RFC6054, November 2010, 1665 . 1667 8.2. Informative References 1669 [IKE-HASH] 1670 Kivinen, T., "Fixing IKE Phase 1 & 2 Authentication 1671 HASHs", November 2001, . 1674 [IKEV2-IANA] 1675 IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters 1676 - Transform Type 3 - Integrity Algorithm Transfrom IDs", 1677 December 2013, . 1680 [NNL] Naor, D., Noal, M., and J. Lotspiech, "Revocation and 1681 Tracing Schemes for Stateless Receivers", Advances in 1682 Cryptology, Crypto '01, Springer-Verlag LNCS 2139, 2001, 1683 pp. 41-62, 2001, 1684 . 1686 [OFT] McGrew, D. and A. Sherman, "Key Establishment in Large 1687 Dynamic Groups Using One-Way Function Trees", Manuscript, 1688 submitted to IEEE Transactions on Software Engineering, 1689 1998, . 1692 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1693 Requirement Levels", BCP 14, RFC 2119, 1694 DOI 10.17487/RFC2119, March 1997, 1695 . 1697 [RFC2407] Piper, D., "The Internet IP Security Domain of 1698 Interpretation for ISAKMP", RFC 2407, 1699 DOI 10.17487/RFC2407, November 1998, 1700 . 1702 [RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, 1703 "Internet Security Association and Key Management Protocol 1704 (ISAKMP)", RFC 2408, DOI 10.17487/RFC2408, November 1998, 1705 . 1707 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1708 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 1709 . 1711 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1712 IANA Considerations Section in RFCs", RFC 2434, 1713 DOI 10.17487/RFC2434, October 1998, 1714 . 1716 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 1717 Multicast: Issues and Architectures", RFC 2627, 1718 DOI 10.17487/RFC2627, June 1999, 1719 . 1721 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 1722 Counter Mode With IPsec Encapsulating Security Payload 1723 (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, 1724 . 1726 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 1727 (GCM) in IPsec Encapsulating Security Payload (ESP)", 1728 RFC 4106, DOI 10.17487/RFC4106, June 2005, 1729 . 1731 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 1732 Mode with IPsec Encapsulating Security Payload (ESP)", 1733 RFC 4309, DOI 10.17487/RFC4309, December 2005, 1734 . 1736 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 1737 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 1738 DOI 10.17487/RFC4543, May 2006, 1739 . 1741 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1742 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 1743 October 2011, . 1745 Appendix A. Differences between G-IKEv2 and RFC 6407 1747 KE Payload - The KE payload is no longer needed with the availability 1748 of newer algorithms such as AES and GCM which provide adequate 1749 protection therefore not needing the PFS capability the KE payload 1750 offers. 1752 SIG Payload - The AUTH payload is used for the same purpose instead. 1754 DOI/Situation - The DOI and Situation fields in the SA payload are no 1755 longer needed in the G-IKEv2 protocol as port 848 will distinguish 1756 the IKEv2 messages from the G-IKEv2 messages. 1758 SEQ Payload - The SEQ payload is no longer needed since IKEv2 header 1759 has message id which is used to prevent message replay attacks. 1761 Authors' Addresses 1763 Sheela Rowles 1764 Cisco Systems 1765 170 W. Tasman Drive 1766 San Jose, California 95134-1706 1767 USA 1769 Phone: +1-408-527-7677 1770 Email: sheela@cisco.com 1772 Aldous Yeung (editor) 1773 Cisco Systems 1774 170 W. Tasman Drive 1775 San Jose, California 95134-1706 1776 USA 1778 Phone: +1-408-853-2032 1779 Email: cyyeung@cisco.com 1781 Paulina Tran 1782 Cisco Systems 1783 170 W. Tasman Drive 1784 San Jose, California 95134-1706 1785 USA 1787 Phone: +1-408-526-8902 1788 Email: ptran@cisco.com 1790 Yoav Nir 1791 Check Point Software Technologies Ltd. 1792 5 Hasolelim St. 1793 Tel Aviv 67897 1794 Israel 1796 Email: ynir@checkpoint.com