idnits 2.17.1 draft-yeung-g-ikev2-12.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 29, 2017) is 2370 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) -- 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) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Weis 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track Y. Nir 5 Expires: May 2, 2018 Dell EMC 6 V. Smyslov 7 ELVIS-PLUS 8 October 29, 2017 10 Group Key Management using IKEv2 11 draft-yeung-g-ikev2-12 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 May 2, 2018. 39 Copyright Notice 41 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . 4 58 1.2. Relationship to GDOI . . . . . . . . . . . . . . . . . . 4 59 1.3. G-IKEv2 Payloads . . . . . . . . . . . . . . . . . . . . 4 60 2. G-IKEv2 integration into IKEv2 protocol . . . . . . . . . . . 5 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 . . . . . . . . . . . . . 8 68 3.1.4. GM Registration Operations . . . . . . . . . . . . . 8 69 3.1.5. GCKS Registration Operations . . . . . . . . . . . . 9 70 3.2. Counter-based modes of operation . . . . . . . . . . . . 10 71 3.3. G-IKEv2 group maintenance channel . . . . . . . . . . . . 12 72 3.3.1. G-IKEv2 GSA_REKEY exchange . . . . . . . . . . . . . 12 73 3.3.2. Forward and Backward Access Control . . . . . . . . . 14 74 3.3.3. Forward Access Control Requirements . . . . . . . . . 14 75 3.3.4. Deletion of SAs . . . . . . . . . . . . . . . . . . . 15 76 3.3.5. GSA_REKEY GCKS Operations . . . . . . . . . . . . . . 15 77 3.3.6. GSA_REKEY GM Operations . . . . . . . . . . . . . . . 16 78 4. Header and Payload Formats . . . . . . . . . . . . . . . . . 17 79 4.1. The G-IKEv2 Header . . . . . . . . . . . . . . . . . . . 17 80 4.2. Group Identification (IDg) Payload . . . . . . . . . . . 17 81 4.3. Security Association - GM Supported Transforms (SAg) . . 17 82 4.4. Group Security Association Payload . . . . . . . . . . . 18 83 4.4.1. GSA Policy . . . . . . . . . . . . . . . . . . . . . 18 84 4.5. KEK Policy . . . . . . . . . . . . . . . . . . . . . . . 19 85 4.5.1. KEK Attributes . . . . . . . . . . . . . . . . . . . 20 86 4.5.2. KEK_MANAGEMENT_ALGORITHM . . . . . . . . . . . . . . 21 87 4.5.3. KEK_ENCR_ALGORITHM . . . . . . . . . . . . . . . . . 21 88 4.5.4. KEK_KEY_LENGTH . . . . . . . . . . . . . . . . . . . 22 89 4.5.5. KEK_KEY_LIFETIME . . . . . . . . . . . . . . . . . . 22 90 4.5.6. KEK_INTEGRITY_ALGORITHM . . . . . . . . . . . . . . . 22 91 4.5.7. KEK_AUTH_METHOD . . . . . . . . . . . . . . . . . . . 22 92 4.5.8. KEK_AUTH_HASH . . . . . . . . . . . . . . . . . . . . 22 93 4.5.9. KEK_MESSAGE_ID . . . . . . . . . . . . . . . . . . . 23 94 4.6. GSA TEK Policy . . . . . . . . . . . . . . . . . . . . . 23 95 4.6.1. TEK ESP and AH Protocol-Specific Policy . . . . . . . 24 96 4.7. GSA Group Associated Policy . . . . . . . . . . . . . . . 25 97 4.7.1. ACTIVATION_TIME_DELAY/DEACTIVATION_TIME_DELAY . . . . 26 98 4.8. Key Download Payload . . . . . . . . . . . . . . . . . . 27 99 4.8.1. TEK Download Type . . . . . . . . . . . . . . . . . . 28 100 4.8.2. KEK Download Type . . . . . . . . . . . . . . . . . . 29 101 4.8.3. LKH Download Type . . . . . . . . . . . . . . . . . . 30 102 4.8.4. SID Download Type . . . . . . . . . . . . . . . . . . 33 103 4.9. Delete Payload . . . . . . . . . . . . . . . . . . . . . 34 104 4.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 35 105 4.11. Authentication Payload . . . . . . . . . . . . . . . . . 36 106 5. Security Considerations . . . . . . . . . . . . . . . . . . . 36 107 5.1. GSA registration and secure channel . . . . . . . . . . . 36 108 5.2. GSA maintenance channel . . . . . . . . . . . . . . . . . 36 109 5.2.1. Authentication/Authorization . . . . . . . . . . . . 36 110 5.2.2. Confidentiality . . . . . . . . . . . . . . . . . . . 36 111 5.2.3. Man-in-the-Middle Attack Protection . . . . . . . . . 36 112 5.2.4. Replay/Reflection Attack Protection . . . . . . . . . 36 113 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 114 6.1. New registries . . . . . . . . . . . . . . . . . . . . . 37 115 6.2. New payload and exchange types added to the existing 116 IKEv2 registry . . . . . . . . . . . . . . . . . . . . . 37 117 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 118 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 38 119 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 120 9.1. Normative References . . . . . . . . . . . . . . . . . . 39 121 9.2. Informative References . . . . . . . . . . . . . . . . . 39 122 Appendix A. Differences between G-IKEv2 and RFC 6407 . . . . . . 41 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 125 1. Introduction and Overview 127 This document presents a group key management protocol protected by 128 IKEv2. The data communications within the group are protected by a 129 key pushed to the group members (GMs) by the Group Controller/Key 130 Server (GCKS) using IKEv2 [RFC7296]. The GCKS pushes policy and keys 131 for the group to the GM after authenticating it using new payloads 132 included in a new exchange called GSA_AUTH (similar to the IKE_AUTH 133 exchange). This document references IKEv2 [RFC7296] but it intended 134 to be a separate document. GDOI update document [RFC6407] presented 135 GDOI using IKEv1 syntax. This document uses IKEv2 syntax. The 136 message semantics of IKEv2 are preserved, in that all communications 137 consists of message request-response pairs. The exception to this 138 rule are the rekeying messages, which are sent in multicast without a 139 response. A number of payloads were deemed unnecessary since 140 [RFC6407] are described in Appendix A 142 1.1. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in RFC 147 2119 [RFC2119]. 149 1.2. Relationship to GDOI 151 GDOI protocol specified in [RFC6407] is protected by IKEv1 phase1 152 security association defined in [RFC2407], [RFC2408] and [RFC2409]; 153 these documents are obsoleted and replaced by a new version of the 154 IKE protocol defined in RFC 7296. G-IKEv2 provides group key 155 management between the Group Member and GCKS using the new IKEv2 156 protocol and inherits the following key advantages over GDOI: 158 1. Provide a simple mechanism for the responder to keep minimal 159 state and avoid DoS attack from forged IP address using cookie 160 challenge exchange. 162 2. Improve performance and network latency by the reduced number of 163 initial messages to complete the G-IKEv2 protocol from (10 164 messages in Main mode and Quick mode, 7 messages in Aggressive 165 mode and Quick) to 4 messages. 167 3. Fix cryptographic weakness with authentication HASH (IKEv1 168 authentication HASH specified in RFC 2409 does not include all 169 ISAKMP payloads and does not include ISAKMP header). This issue 170 is documented at [IKE-HASH]. 172 4. Improve protocol reliability where all unicast messages are 173 acknowledged and sequenced. 175 5. Well defined behavior for error conditions to improve 176 interoperability. 178 1.3. G-IKEv2 Payloads 180 1. IDg (group ID) - The GM requests the GCKS for membership into the 181 group by sending its IDg payload. 183 2. GSA (Group Security Association) - The GCKS sends the group 184 policy to the GM using this payload. 186 3. KD (Key Download) - The GCKS sends the control and data keys to 187 the GM using the KD payload. 189 2. G-IKEv2 integration into IKEv2 protocol 191 The G-IKEv2 protocol uses the security mechanisms of IKEv2 (peer 192 authentication, confidentiality, message integrity) to protect the 193 group negotiations required for G-IKEv2. The G-IKEv2 exchange 194 further provides group authorization, and secure policy and key 195 download from the GCKS to its group members. 197 It is assumed that readers are familiar with the IKEv2 protocol, so 198 this document skips many details that are described in [RFC7296]. 200 2.1. UDP port 202 G-IKEv2 SHOULD use port 848, the same as GDOI [RFC6407], because they 203 serve a similar function. They can use the same ports, just as IKEv1 204 and IKEv2 can share port 500. The version number in the IKEv2 header 205 distinguishes the G-IKEv2 protocol from GDOI protocol [RFC6407]. 207 3. G-IKEv2 Protocol 209 3.1. G-IKEv2 member registration and secure channel establishment 211 The registration protocol consists of a minimum of two message 212 exchanges, IKE_SA_INIT and GSA_AUTH; member registration may have a 213 few more messages exchanged if the EAP method, cookie challenge (for 214 DoS protection) or negotiation of Diffie-Hellman group is included. 215 Each exchange consists of request/response pairs. The first exchange 216 IKE_SA_INIT is defined in IKEv2 [RFC7296]. This exchange negotiates 217 cryptographic algorithms, exchanges nonces and does a Diffie-Hellman 218 exchange between the group member (GM) and the Group Controller/Key 219 Server (GCKS). 221 The second exchange GSA_AUTH authenticates the previous messages, 222 exchanges identities and certificates. These messages are encrypted 223 and integrity protected with keys established through the IKE_SA_INIT 224 exchange, so the identities are hidden from eavesdroppers and all 225 fields in all the messages are authenticated. The GCKS SHOULD 226 authorize group members to be allowed into the group as part of the 227 GSA_AUTH exchange. Once the GCKS accepts a group member to join a 228 group it will download the data security keys (TEKs) and/or group key 229 encrypting key (KEK) or KEK array as part of the GSA_AUTH response 230 message. In the following descriptions, the payloads contained in 231 the message are indicated by names as listed below. Payloads defined 232 as part of other IKEv2 extensions MAY also be included in these 233 exchanges. 235 Notation Payload 236 ------------------------------------------------------------ 237 AUTH Authentication 238 CERT Certificate 239 CERTREQ Certificate Request 240 GSA Group Security Association 241 HDR IKEv2 Header 242 IDg Identification - Group 243 IDi Identification - Initiator 244 IDr Identification - Responder 245 KD Key Download 246 KE Key Exchange 247 Ni, Nr Nonce 248 SA Security Association 249 SAg Security Association - GM Supported Transforms 251 The details of the contents of each payload are described in 252 Section 4. Payloads that may optionally appear will be shown in 253 brackets, such as [ CERTREQ ], to indicate that a certificate request 254 payload can optionally be included. 256 3.1.1. GSA_AUTH exchange 258 After the group member and GCKS use the IKE_SA_INIT exchange to 259 negotiate cryptographic algorithms, exchange nonces, and perform a 260 Diffie-Hellman exchange as defined in IKEv2 [RFC7296], the GSA_AUTH 261 exchange MUST complete before any other exchanges can be done. The 262 security properties of the GSA_AUTH exchange are the same as the 263 properties of the IKE_AUTH exchange. It is used to authenticate the 264 IKE_SA_INIT messages, exchange identities and certificates. G-IKEv2 265 also uses this exchange for group member registration and 266 authorization. Even though the IKE_AUTH does contain the SA2, TSi, 267 and TSr payload the GSA_AUTH does not. They are not needed because 268 policy is not negotiated between the group member and the GCKS, but 269 instead downloaded from the GCKS to the group member. 271 Initiator (Member) Responder (GCKS) 272 -------------------- ------------------ 273 HDR, SK { IDi, [CERT,] [CERTREQ, ] [IDr, ] 274 AUTH, IDg, [SAg, ] [N ] } --> 276 After the IKE_SA_INIT exchange completes, the group member initiates 277 a GSA_AUTH request to join a group indicated by the IDg payload. The 278 GM MAY include an SAg payload declaring which Transforms that it is 279 willing to accept, and also MAY include the Notify payload status 280 type SENDER_ID_REQUEST to request SIDs for a Counter-based cipher 281 from the GCKS. 283 <-- HDR, SK { IDr, [CERT, ] AUTH, [ GSA, KD, ] [D, ] } 285 The GCKS responds with IDr, optional CERT, and AUTH material as if it 286 were an IKE_AUTH. It also informs the group member of the 287 cryptographic policies of the group in the GSA payload and the key 288 material in the KD payload. The GCKS can also include a Delete (D) 289 payload instructing the group member to delete existing SAs it might 290 have as the result of a previous group member registration. 292 In addition to the IKEv2 error handling, the GCKS can reject the 293 registration request when the IDg is invalid or authorization fails, 294 etc. In these cases, see Section 4.10, the GSA_AUTH response will 295 not include the GSA and KD, but will include a Notify payload 296 indicating errors. If the group member included an SAg payload, and 297 the GCKS chooses to evaluate it, and it detects that that group 298 member cannot support the security policy defined for the group, then 299 the GCKS SHOULD return a NO_PROPOSAL_CHOSEN. When the GCKS indicates 300 errors, and the group member cannot resolve the errors, the group 301 member MUST delete the registration IKE SA. 303 Initiator (Member) Responder (GCKS) 304 -------------------- ------------------ 305 <-- HDR, SK { N } 307 If the group member finds the policy sent by the GCKS is 308 unacceptable, the member SHOULD notify the GCKS by sending IDg and 309 the Notify type NO_PROPOSAL_CHOSEN as shown below. 311 Initiator (Member) Responder (GCKS) 312 -------------------- ------------------ 313 HDR, SK {IDg [N,]} --> 315 <-- HDR, SK {} 317 3.1.2. GSA_REGISTRATION Exchange 319 When a secure channel is already established between a GM and the 320 GCKS, the GM registration for a group can reuse the established 321 secure channel. In this scenario the GM will use the 322 GSA_REGISTRATION exchange by including the desired group ID (IDg) to 323 request data security keys (TEKs) and/or group key encrypting keys 324 (KEKs) from the GCKS. If the group member includes an SAg payload, 325 and the GCKS chooses to evaluate it, and it detects that group member 326 cannot support the security policy defined for the group, then the 327 GCKS SHOULD return a NO_PROPOSAL_CHOSEN. The GM MAY also include the 328 Notify payload status type SENDER_ID_REQUEST to request SIDs for a 329 Counter-based cipher from the GCKS. The GCKS response payloads are 330 created and processed as in the GSA_AUTH reply. 332 Initiator (Member) Responder (GCKS) 333 -------------------- ------------------ 334 HDR, SK {IDg, [SAg, ][N ] } --> 336 <-- HDR, SK { GSA, KD, [D ] } 338 This exchange can also be used if the group member finds the policy 339 sent by the GCKS is unacceptable. The group member SHOULD notify the 340 GCKS by sending IDg and the Notify type NO_PROPOSAL_CHOSEN, as shown 341 below. The GCKS MUST unregister the group member. 343 Initiator (Member) Responder (GCKS) 344 -------------------- ------------------ 345 HDR, SK {IDg [N,]} --> 347 <-- HDR, SK {} 349 3.1.3. IKEv2 Header Initialization 351 The Major Version is (2) and Minor Version is (0) according to IKEv2 352 [RFC7296], and maintained in this document. The G-IKEv2 IKE_SA_INIT, 353 GSA_AUTH and GSA_REGISTRATION use the IKE SPI according to IKEv2 354 [RFC7296], section 2.6. 356 3.1.4. GM Registration Operations 358 A G-IKEv2 Initiator (GM) requesting registration contacts the GCKS 359 using the IKE_SA_INIT exchange and receives the response from the 360 GCKS. This exchange is unchanged from the IKE_SA_INIT in IKEv2 361 protocol. 363 Upon completion of parsing and verifying the IKE_SA_INIT response, 364 the GM sends the GSA_AUTH message with the IKEv2 payloads from 365 IKE_AUTH (without the SAi2, TSi and TSr payloads) along with the 366 Group ID informing the GCKS of the group the initiator wishes to 367 join. The initiator MAY specify how many Sender-ID values it would 368 like to receive in the Notify payload status type, SENDER_ID_REQUEST, 369 in case the Data Security SA supports a counter mode cipher (see 370 Section 3.2). 372 An initiator may be limited in the types of Transforms that it is 373 able or willing to use, and may find it useful to inform the GCKS 374 which Transforms that it is willing to accept. It can OPTIONALLY 375 include an SAg payload, which can include ESP and/or AH Proposals. 376 Each Proposal contains a list of Transforms that it is willing to 377 support for that protocol. A Proposal of type ESP can include ENCR, 378 INTEG, and ESN Transforms. A Proposal of type AH can include INTEG, 379 and ESN Transforms. The SPI length of each Proposal in an SAg MUST 380 be zero, and the SPI field is null. Generally, a single Proposal of 381 each type will suffice, because the group member is not negotiating 382 Transform sets, simply alerting the GCKS to restrictions it may have. 384 Upon receiving the GSA_AUTH response, the initiator parses the 385 response from the GCKS authenticating the exchange using the IKEv2 386 method, then processes the GSA and KD. 388 The GSA payload contains the security policy and cryptographic 389 protocols used by the group. This policy describes the Rekey SA 390 (KEK), if present, Data-security SAs (TEK), and other group policy 391 (GAP). If the policy in the GSA payload is not acceptable to the GM, 392 it SHOULD notify the GCKS with a NO_PROPOSAL_CHOSEN Notify payload 393 (see Section 3.1.1 and Section 3.1.2). Finally the KD is parsed 394 providing the keying material for the TEK and/or KEK. The GM 395 interprets the KD key packets, where each key packet includes the 396 keying material for SAs distributed in the GSA payload. Keying 397 material is matched by comparing the SPIs in the key packets to SPIs 398 previously included in the GSA payloads. Once TEK keys and policy 399 are matched, the GM provides them to the data security subsystem, and 400 it is ready to send or receive packets matching the TEK policy. 402 The GSA KEK policy MUST include KEK attribute KEK_MESSAGE_ID with a 403 Message ID. The Message ID in the KEK_MESSAGE_ID attribute MUST be 404 checked against any previously received Message ID for this group. 405 If it is less than the previously received number, it should be 406 considered stale and ignored. This could happen if two GSA_AUTH 407 exchanges happened in parallel, and the Message ID changed. This 408 KEK_MESSAGE_ID is used by the GM to prevent GSA_REKEY message replay 409 attacks. The first GSA_REKEY message that the GM receives from the 410 GCKS must have a Message ID greater or equal to the Message ID 411 received in the KEK_MESSAGE_ID attribute. 413 3.1.5. GCKS Registration Operations 415 A G-IKEv2 GCKS passively listens for incoming requests from group 416 members. When the GCKS receives an IKE_SA_INIT request, it selects 417 an IKE proposal and generates a nonce and DH to include them in the 418 IKE_SA_INIT response. 420 Upon receiving the GSA_AUTH request, the GCKS authenticates the group 421 member using the same procedures as in the IKEv2 IKE_AUTH. The GCKS 422 then authorizes the group member according to group policy before 423 preparing to send the GSA_AUTH response. If the GCKS fails to 424 authorize the GM, it will respond with an AUTHORIZATION_FAILED notify 425 message. 427 The GSA_AUTH response will include the group policy in the GSA 428 payload and keys in the KD payload. If the GCKS policy includes a 429 group rekey option, this policy is constructed in the GSA KEK and the 430 key is constructed in the KD KEK. The GSA KEK MUST include the 431 KEK_MESSAGE_ID attribute, specifying the starting Message ID the GCKS 432 will use when sending the GSA_REKEY message to the group member. 433 This Message ID is used to prevent GSA_REKEY message replay attacks 434 and will be increased each time a GSA_REKEY message is sent to the 435 group. The GCKS data traffic policy is included in the GSA TEK and 436 keys are included in the KD TEK. The GSA GAP MAY also be included to 437 provide the ATD and/or DTD (Section 4.7.1) specifying activation and 438 deactivation delays for SAs generated from the TEKs. If one or more 439 Data Security SAs distributed in the GSA payload included a counter 440 mode of operation, the GCKS includes at least one SID value in the KD 441 payload, and possibly more depending on the request received in the 442 Notify payload status type SENDER_ID_REQUEST requesting the number of 443 SIDs from the group member. 445 If the GCKS receives a GSA_REGISTRATION exchange with a request to 446 register a GM to a group, the GCKS will need to authorize the GM with 447 the new group (IDg) and respond with the corresponding group policy 448 and keys. If the GCKS fails to authorize the GM, it will respond 449 with the AUTHORIZATION_FAILED notification. 451 If a group member includes an SAg in its GSA_AUTH or GSA_REGISTRATION 452 request, the GCKS MAY evaluate it according to an implementation 453 specific policy. 455 o The GCKS could evaluate the list of Transforms and compare it to 456 its current policy for the group. If the group member did not 457 include all of the ESP or AH Transforms in its current policy, 458 then it could return a NO_PROPOSAL_CHOSEN Notification. 460 o The GCKS could store the list of Transforms, with the goal of 461 migrating the group policy to a different Transform when all of 462 the group members indicate that they can support that Transform. 464 o The GCKS could store the list of Transforms and adjust the current 465 group policy based on the capabilities of the devices as long as 466 they fall within the acceptable security policy of the GCKS. 468 3.2. Counter-based modes of operation 470 Several new counter-based modes of operation have been specified for 471 ESP (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES-CCM [RFC4309], 472 AES-GMAC [RFC4543]) and AH (e.g., AES-GMAC [RFC4543]). These 473 counter-based modes require that no two senders in the group ever 474 send a packet with the same Initialization Vector (IV) using the same 475 cipher key and mode. This requirement is met in G-IKEv2 when the 476 following requirements are met: 478 o The GCKS distributes a unique key for each Data-Security SA. 480 o The GCKS uses the method described in [RFC6054], which assigns each 481 sender a portion of the IV space by provisioning each sender with one 482 or more unique SID values. 484 When at least one Data-Security SA included in the group policy 485 includes a counter-based mode of operation, the GCKS automatically 486 allocates and distributes one SID to each group member acting in the 487 role of sender on the Data-Security SA. The SID value is used 488 exclusively by the group member to which it was allocated. The group 489 member uses the same SID for each Data-Security SA specifying the use 490 of a counter-based mode of operation. A GCKS MUST distribute unique 491 keys for each Data-Security SA including a counter-based mode of 492 operation in order to maintain unique key and nonce usage. 494 During registration, the group member can choose to request one or 495 more SID values. Requesting a value of 1 is not necessary since the 496 GCKS will automatically allocate exactly one to the group member. A 497 group member MUST request as many SIDs matching the number of 498 encryption modules in which it will be installing the TEKs in the 499 outbound direction. Alternatively, a group member MAY request more 500 than one SID and use them serially. This could be useful when it is 501 anticipated that the group member will exhaust their range of Data- 502 Security SA nonces using a single SID too quickly (e.g., before the 503 time-based policy in the TEK expires). 505 When the group policy includes a counter-based mode of operation, a 506 GCKS SHOULD use the following method to allocate SID values, which 507 ensures that each SID will be allocated to just one group member. 509 1. A GCKS maintains an SID-counter, which records the SIDs that have 510 been allocated. SIDs are allocated sequentially, with zero as the 511 first allocated SID. 513 2. Each time an SID is allocated, the current value of the counter 514 is saved and allocated to the group member. The SID-counter is then 515 incremented in preparation for the next allocation. 517 3. When the GCKS specifies a counter-based mode of operation in the 518 Data Security SA a group member may request a count of SIDs during 519 registration in a Notify payload information of type SEND_ID_REQUEST. 520 When the GCKS receives this request, it increments the SID-counter 521 once for each requested SID, and distributes each SID value to the 522 group member. 524 4. A GCKS allocates new SID values for each GSA_REGISTRATION 525 exchange originated by a sender, regardless of whether a group member 526 had previously contacted the GCKS. In this way, the GCKS is not 527 required to maintaining a record of which SID values it had 528 previously allocated to each group member. More importantly, since 529 the GCKS cannot reliably detect whether the group member had sent 530 data on the current group Data-Security SAs it does not know what 531 Data-Security counter-mode nonce values that a group member has used. 532 By distributing new SID values, the key server ensures that each time 533 a conforming group member installs a Data-Security SA it will use a 534 unique set of counter-based mode nonces. 536 5. When the SID-counter maintained by the GCKS reaches its final SID 537 value, no more SID values can be distributed. Before distributing 538 any new SID values, the GCKS MUST delete the Data-Security SAs for 539 the group, followed by creation of new Data-Security SAs, and 540 resetting the SID-counter to its initial value. 542 6. The GCKS SHOULD send a GSA_REKEY message deleting all Data- 543 Security SAs and the Rekey SA for the group. This will result in the 544 group members initiating a new GSA_REGISTRATION exchange, in which 545 they will receive both new SID values and new Data-Security SAs. The 546 new SID values can safely be used because they are only used with the 547 new Data-Security SAs. Note that deletion of the Rekey SA is 548 necessary to ensure that group members receiving a GSA_REKEY exchange 549 before the re-register do not inadvertently use their old SIDs with 550 the new Data-Security SAs. Using the method above, at no time can 551 two group members use the same IV values with the same Data-Security 552 SA key. 554 3.3. G-IKEv2 group maintenance channel 556 The GCKS indicates that it will be delivering group rekey messages 557 when the KEK policy and keys are present in the G-IKEv2 GSA and KD 558 payloads. Though the G-IKEv2 Rekey is optional, it plays a crucial 559 role for large and dynamic groups. The GCKS is responsible for 560 rekeying the secure group per the group policy. The GCKS uses IP 561 multicast to transport the rekey message. The G-IKEv2 protocol uses 562 the GSA_REKEY exchange type in the G-IKEv2 header identifying it as a 563 rekey message. This rekey message is protected by the registration 564 exchanges. 566 3.3.1. G-IKEv2 GSA_REKEY exchange 568 The GCKS initiates the G-IKEv2 Rekey securely using IP multicast. 569 Since this multicast rekey does not require a response and it sends 570 to multiple GMs, G-IKEv2 rekeying MUST NOT support windowing. The 571 GCKS rekey message replaces the rekey GSA KEK or KEK array, and/or 572 creates a new Data-Security GSA TEK. The SID Download attribute in 573 the Key Download payload (defined in Section 4.8.4) MUST NOT be part 574 of the Rekey Exchange as this is sender specific information and the 575 Rekey Exchange is group specific. The GCKS initiates the GSA_REKEY 576 exchange as following: 578 Members (Responder) GCKS (Initiator) 579 -------------------- ------------------ 580 <-- HDR, SK { GSA, KD, [D,] AUTH } 582 HDR is defined in Section 4.1. The Message ID in this message will 583 start with the same value the GCKS sent to the group members in the 584 KEK attribute KEK_MESSAGE_ID during registration; this Message ID 585 will be increased each time a new GSA_REKEY message is sent to the 586 group members. 588 The GSA payload contains the current rekey and data security SAs. 589 The GSA may contain a new rekey SA and/or a new data security SA, 590 which, optionally contains an LKH rekey SA, Section 4.4. 592 The KD payload contains the keys for the policy included in the GSA. 593 If the data security SA is being refreshed in this rekey message, the 594 IPsec keys are updated in the KD, and/or if the rekey SA is being 595 refreshed in this rekey message, the rekey Key or the LKH KEK array 596 is updated in the KD payload. 598 A Delete payload MAY be included to instruct the GM to delete 599 existing SAs. 601 The AUTH payload is included to authenticate the GSA_REKEY message 602 using a method defined in the IKEv2 Authentication Method IANA 603 registry [IKEV2-IANA]. The method SHOULD be a digital signature 604 authentication scheme to ensure that the message was originated from 605 an authorized GCKS. A Shared Key Integrity Code SHOULD NOT be used 606 as it doesn't provide source origin authentication (although a small 607 group may not require source origin authentication). During group 608 member registration, the GCKS sends the authentication key in the GSA 609 KEK payload, KEK_AUTH_KEY attribute, which the group member uses to 610 authenticate the key server. Before the current Authentication Key 611 expires, the GCKS will send a new KEK_AUTH_KEY to the group members 612 in a GSA_REKEY message. The AUTH key that is used in the rekey 613 message may not be the same as the authentication key used in 614 GSA_AUTH. Typically a rekey message is sent as multicast and 615 received by all group members, therefore the same AUTH key is 616 distributed to all group members. 618 After adding the AUTH payload to the rekey message, the current KEK 619 encryption key is used to encrypt all of the payloads following the 620 HDR. 622 3.3.2. Forward and Backward Access Control 624 Through the G-IKEv2 rekey, G-IKEv2 supports algorithms such as LKH 625 that have the property of denying access to a new group key by a 626 member removed from the group (forward access control) and to an old 627 group key by a member added to the group (backward access control). 628 An unrelated notion to PFS, "forward access control" and "backward 629 access control" have been called "perfect forward security" and 630 "perfect backward security" in the literature [RFC2627]. 632 Group management algorithms providing forward and backward access 633 control other than LKH have been proposed in the literature, 634 including OFT [OFT] and Subset Difference [NNL]. These algorithms 635 could be used with G-IKEv2, but are not specified as a part of this 636 document. 638 Support for group management algorithms are supported via the 639 KEY_MANAGEMENT_ALGORITHM attribute which is sent in the GSA KEK 640 policy. G-IKEv2 specifies one method by which LKH can be used for 641 forward and backward access control. Other methods of using LKH, as 642 well as other group management algorithms such as OFT or Subset 643 Difference may be added to G-IKEv2 as part of a later document. 645 3.3.3. Forward Access Control Requirements 647 When group membership is altered using a group management algorithm 648 new GSA TEKs (and their associated keys) are usually also needed. 649 New GSAs and keys ensure that members who were denied access can no 650 longer participate in the group. 652 If forward access control is a desired property of the group, new GSA 653 TEKs and the associated key packets in the KD payload MUST NOT be 654 included in a G-IKEv2 rekey message which changes group membership. 655 This is required because the GSA TEK policy and the associated key 656 packets in the KD payload are not protected with the new KEK. A 657 second G-IKEv2 rekey message can deliver the new GSA TEKS and their 658 associated key packets because it will be protected with the new KEK, 659 and thus will not be visible to the members who were denied access. 661 If forward access control policy for the group includes keeping group 662 policy changes from members that are denied access to the group, then 663 two sequential G-IKEv2 rekey messages changing the group KEK MUST be 664 sent by the GCKS. The first G-IKEv2 rekey message creates a new KEK 665 for the group. Group members, which are denied access, will not be 666 able to access the new KEK, but will see the group policy since the 667 G-IKEv2 rekey message is protected under the current KEK. A 668 subsequent G-IKEv2 rekey message containing the changed group policy 669 and again changing the KEK allows complete forward access control. A 670 G-IKEv2 rekey message MUST NOT change the policy without creating a 671 new KEK. 673 If other methods of using LKH or other group management algorithms 674 are added to G-IKEv2, those methods MAY remove the above restrictions 675 requiring multiple G-IKEv2 rekey messages, providing those methods 676 specify how the forward access control policy is maintained within a 677 single G-IKEv2 rekey message. 679 3.3.4. Deletion of SAs 681 There are occasions when the GCKS may want to signal to group members 682 to delete policy at the end of a broadcast, or if group policy has 683 changed. Deletion of keys MAY be accomplished by sending the G-IKEv2 684 Delete Payload [RFC7296], section 3.11 as part of the GSA_REKEY 685 Exchange as shown below. 687 Members (Responder) GCKS (Initiator) 688 -------------------- ------------------ 689 <-- HDR, SK { 690 [GSA ], [KD ], [D, ] AUTH } 692 The GSA MAY specify the remaining active time of the remaining policy 693 by using the DTD attribute in the GSA GAP. If a GCKS has no further 694 SAs to send to group members, the GSA and KD payloads MUST be omitted 695 from the message. There may be circumstances where the GCKS may want 696 to start over with a clean slate. If the administrator is no longer 697 confident in the integrity of the group, the GCKS can signal deletion 698 of all the policies of a particular TEK protocol by sending a TEK 699 with a SPI value equal to zero in the delete payload. For example, 700 if the GCKS wishes to remove all the KEKs and all the TEKs in the 701 group, the GCKS SHOULD send a Delete payload with a SPI of zero and a 702 protocol_id of a TEK protocol_id value defined in Section 4.6, 703 followed by another Delete payload with a SPI of zero and protocol_id 704 of zero, indicating that the KEK SA should be deleted. 706 3.3.5. GSA_REKEY GCKS Operations 708 The GCKS may initiate a rekey message if group membership and/or 709 policy has changed, or if the keys are about to expire. The GCKS 710 builds the rekey message with a Message ID value that is one greater 711 than the value included in the previous rekey. If the message is 712 using a new KEK attribute, the Message ID is reset to 1 in this 713 message. The GSA and KD follow with the same characteristics as in 714 the GSA Registration exchange. The AUTH payload is the final payload 715 added to the message. It is created by hashing the string "G-IKEv2" 716 and the message created so far, and then is digitally signed. 717 Finally, the content of the Encrypted payload is encrypted and 718 authenticated using the current KEK keys. 720 Because GSA_REKEY messages are not acknowledged and could be 721 discarded by the network, one or more GMs may not receive the 722 message. To mitigate such lost messages, during a rekey event the 723 GCKS SHOULD transmit several GSA_REKEY messages with the new policy. 724 A GCKS MUST NOT re-transmit exactly the same GSA_REKEY message, 725 because time-to-live lifetimes in the message will be incorrect, 726 resulting in GMs with unsynchronized TEK and KEK lifetimes. 728 3.3.6. GSA_REKEY GM Operations 730 When a group member receives the Rekey Message from the GCKS it 731 decrypts the message using the current KEK, validates the signature 732 using the public key retrieved in a previous G-IKEv2 exchange, 733 verifies the Message ID, and processes the GSA and KD payloads. The 734 group member then downloads the new data security SA and/or new Rekey 735 GSA. The parsing of the payloads is identical to the parsing done in 736 the registration exchange. 738 Replay protection is achieved by a group member rejecting a GSA_REKEY 739 message which has a Message ID smaller than the current Message ID 740 that the GM is expecting. The GM expects the Message ID in the first 741 GSA_REKEY message it receives to be equal or greater than the message 742 id it receives in the KEK_MESSAGE_ID attribute. The GM expects the 743 message ID in subsequent GSA_REKEY messages to be greater than the 744 last valid GSA_REKEY message ID it received. 746 If the GSA payload includes a Data-Security SA including a counter- 747 modes of operation and the receiving group member is a sender for 748 that SA, the group member uses its current SID value with the Data- 749 Security SAs to create counter-mode nonces. If it is a sender and 750 does not hold a current SID value, it MUST NOT install the Data- 751 Security SAs. It MAY initiate a GSA_REGISTRATION exchange to the 752 GCKS in order to obtain an SID value (along with current group 753 policy). 755 If the GM receives a notification that a Data-Security SA is about to 756 expire (such as a "soft lifetime" expiration as described in 757 Section 4.4.2.1 of [RFC4301]), it SHOULD initiate a registration to 758 the GCKS. This registration serves as a request for current SAs, and 759 will result in the download of replacement SAs, assuming the GCKS 760 policy has created them. 762 4. Header and Payload Formats 764 Refer to IKEv2 [RFC7296] for existing payloads. Some payloads used 765 in G-IKEv2 exchanges are not aligned to 4-octet boundaries, which is 766 also the case for some IKEv2 payloads (see Section 3.2 of [RFC7296]). 768 4.1. The G-IKEv2 Header 770 G-IKEv2 uses the same IKE header format as specified in RFC 7296 771 section 3.1. 773 Several new payload formats are required in the group security 774 exchanges. 776 Next Payload Type Value 777 ----------------- ----- 778 Group Identification (IDg) 50 779 Group Security Association (GSA) 51 780 Key Download (KD) 52 782 New exchange types GSA_AUTH, GSA_REGISTRATION and GSA_REKEY are added 783 to the IKEv2 [RFC7296] protocol. 785 Exchange Type Value 786 -------------- ----- 787 GSA_AUTH 39 788 GSA_REGISTRATION 40 789 GSA_REKEY 41 791 Major Version is 2 and Minor Version is 0 as in IKEv2 [RFC7296]. IKE 792 SA Initiator's SPI, IKE SA Responder's SPI, Flags, Message ID, and 793 Length are as specified in [RFC7296]. 795 4.2. Group Identification (IDg) Payload 797 The IDg Payload allows the group member to indicate which group it 798 wants to join. The payload is constructed by using the IKEv2 799 Identification Payload (section 3.5 of [RFC7296]). ID type ID_KEY_ID 800 MUST be supported. ID types ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, 801 ID_IPV6_ADDR SHOULD be supported. ID types ID_DER_ASN1_DN and 802 ID_DER_ASN1_GN are not expected to be used. 804 4.3. Security Association - GM Supported Transforms (SAg) 806 The SAg payload declares which Transforms a GM is willing to accept. 807 The payload is constructed using the format of the IKEv2 Security 808 Association payload (section 3.3 of [RFC7296]). The Payload Type for 809 SAg is identical to the SA Payload Type. 811 4.4. Group Security Association Payload 813 The Group Security Association payload is used by the GCKS to assert 814 security attributes for both Rekey and Data-security SAs. 816 0 1 2 3 817 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 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Next Payload |C| RESERVED | Payload Length | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 The Security Association Payload fields are defined as follows: 824 o Next Payload (1 octet) -- Identifies the next payload type for the 825 G-IKEv2 registration or the G-IKEv2 rekey message. 827 o Critical (1 bit) -- Set according to [RFC7296]. 829 o RESERVED (7 bits) -- Must be zero. 831 o Payload Length (2 octets) -- Is the octet length of the current 832 payload including the generic header and all TEK and KEK policies. 834 4.4.1. GSA Policy 836 Following the GSA generic payload header are GSA policies for group 837 rekeying (KEK), data traffic SAs (TEK) and/or Group Associated Policy 838 (GAP). There may be zero or one GSA KEK policy, zero or one GAP 839 policies, and zero or more GSA TEK policies, where either one GSA KEK 840 or GSA TEK payload MUST be present. 842 This latitude allows various group policies to be accommodated. For 843 example if the group policy does not require the use of a Rekey SA, 844 the GCKS would not need to send a GSA KEK attribute to the group 845 member since all SA updates would be performed using the Registration 846 SA. Alternatively, group policy might use a Rekey SA but choose to 847 download a KEK to the group member only as part of the Registration 848 SA. Therefore, the GSA KEK policy would not be necessary as part of 849 the GSA_REKEY message. 851 Specifying multiple GSA TEKs allows multiple related data streams 852 (e.g., video, audio, and text) to be associated with a session, but 853 each protected with an individual security association policy. 855 A GAP payload allows for the distribution of group-wise policy, such 856 as instructions for when to activate and de-activate SAs. 858 Policies following the GSA payload use the following common header. 860 0 1 2 3 861 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 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Type | RESERVED | Length | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 Type is defined as follows: 869 ID Class Value 870 -------- ----- 871 RESERVED 0 872 KEK 1 873 GAP 2 874 TEK 3 875 Expert Review 4-127 876 Private Use 128-255 878 4.5. KEK Policy 880 The GSA KEK policy contains security attributes for the KEK method 881 for a group and parameters specific to the G-IKEv2 registration 882 operation. The source and destination traffic selectors describe the 883 network identities used for the rekey messages. 885 0 1 2 3 886 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 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Type = 1 ! RESERVED ! Length | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | | 891 ~ SPI ~ 892 | | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | | 895 ~ ~ 896 | | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | | 899 ~ ~ 900 | | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 ~ KEK Attributes ~ 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 The GSA KEK Payload fields are defined as follows: 907 o Type = 1 (1 octet) -- Identifies the GSA payload type as KEK in 908 the G-IKEv2 registration or the G-IKEv2 rekey message. 910 o RESERVED (1 octet) -- Must be zero. 912 o Length (2 octets) -- Length of this structure including KEK 913 attributes. 915 o SPI (16 octets) -- Security Parameter Index for the rekey message. 916 The SPI must be the IKEv2 Header SPI pair where the first 8 octets 917 become the "Initiator's SPI" field in the G-IKEv2 rekey message 918 IKEv2 HDR, and the second 8 octets become the "Responder's SPI" in 919 the same HDR. As described above, these SPIs are assigned by the 920 GCKS. 922 o Source & Destination Traffic Selectors - Substructures describing 923 the source and destination of the network identities. These 924 identities refer to the source and destination of the next KEK 925 rekey SA. Defined format and values are specified by IKEv2 926 [RFC7296], section 3.13.1. 928 o KEK Attributes -- Contains KEK policy attributes associated with 929 the group. The following sections describe the possible 930 attributes. Any or all attributes may be optional, depending on 931 the group policy. 933 4.5.1. KEK Attributes 935 The following attributes may be present in a GSA KEK policy. The 936 attributes must follow the format defined in the IKEv2 [RFC7296] 937 section 3.3.5. In the table, attributes that are defined as TV are 938 marked as Basic (B); attributes that are defined as TLV are marked as 939 Variable (V). The terms Reserved, Unassigned, and Private Use are to 940 be applied as defined in [RFC8126]. The registration procedure is 941 Expert Review. 943 ID Class Value Type 944 -------- ----- ---- 945 Reserved 0 946 KEK_MANAGEMENT_ALGORITHM 1 B 947 KEK_ENCR_ALGORITHM 2 B 948 KEK_KEY_LENGTH 3 B 949 KEK_KEY_LIFETIME 4 V 950 KEK_INTEGRITY_ALGORITHM 5 B 951 KEK_AUTH_METHOD 6 B 952 KEK_AUTH_HASH 7 B 953 KEK_MESSAGE_ID 8 V 954 Unassigned 9-16383 955 Private Use 16384-32767 957 The following attributes may only be included in a G-IKEv2 958 registration message: KEK_MANAGEMENT_ALGORITHM. 960 Minimum attributes that must be sent as part of an GSA KEK: 961 KEK_ENCR_ALGORITHM, KEK_KEY_LENGTH (if the cipher definition includes 962 a variable length key), KEK_MESSAGE_ID, KEK_KEY_LIFETIME, 963 KEK_INTEGRITY_ALGORITHM, KEK_AUTH_METHOD, and KEK_AUTH_HASH (except 964 for DSA based algorithms). 966 4.5.2. KEK_MANAGEMENT_ALGORITHM 968 The KEK_MANAGEMENT_ALGORITHM attribute specifies the group KEK 969 management algorithm used to provide forward or backward access 970 control (i.e., used to exclude group members). Defined values are 971 specified in the following table. The terms Reserved, Unassigned, 972 and Private Use are to be applied as defined in [RFC8126]. The 973 registration procedure is Expert Review. 975 KEK Management Type Value 976 ------------------- ----- 977 Reserved 0 978 LKH 1 979 Unassigned 2-16383 980 Private Use 16384-32767 982 4.5.3. KEK_ENCR_ALGORITHM 984 The KEK_ENCR_ALGORITHM attribute specifies the encryption algorithm 985 used with the KEK. This value is a value from the IKEv2 Transform 986 Type 1 - Encryption Algorithm Transform IDs registry[IKEV2-IANA]. If 987 a KEK_MANAGEMENT_ALGORITHM is defined which defines multiple keys 988 (e.g., LKH), and if the management algorithm does not specify the 989 algorithm for those keys, then the algorithm defined by the 990 KEK_ENCR_ALGORITHM attribute MUST be used for all keys which are 991 included as part of this KEK management. 993 4.5.4. KEK_KEY_LENGTH 995 The KEK_KEY_LENGTH attribute specifies the KEK Algorithm key length 996 (in bits). 998 The Group Controller/Key Server (GCKS) adds the KEK_KEY_LENGTH 999 attribute to the GSA payload when distributing KEK policy to group 1000 members. The group member verifies whether or not it has the 1001 capability of using a cipher key of that size. If the cipher 1002 definition includes a fixed key length, the group member can make its 1003 decision solely using the KEK_ENCR_ALGORITHM attribute and does not 1004 need the KEK_KEY_LENGTH attribute. Sending the KEK_KEY_LENGTH 1005 attribute in the GSA payload is OPTIONAL if the KEK cipher has a 1006 fixed key length. 1008 4.5.5. KEK_KEY_LIFETIME 1010 The KEK_KEY_LIFETIME attribute specifies the maximum time for which 1011 the KEK is valid. The GCKS may refresh the KEK at any time before 1012 the end of the valid period. The value is a four (4) octet number 1013 defining a valid time period in seconds. 1015 4.5.6. KEK_INTEGRITY_ALGORITHM 1017 The KEK_INTEGRITY attribute specifies the integrity algorithm used to 1018 protect the rekey message. This integrity algorithm is a value from 1019 the IKEv2 Transform Type 3 - Integrity Algorithm Transform IDs 1020 registry [IKEV2-IANA]. 1022 4.5.7. KEK_AUTH_METHOD 1024 The KEK_AUTH_METHOD attribute specifies the method of authentication 1025 used. This value is from the IKEv2 Authentication Method registry 1026 [IKEV2-IANA]. 1028 4.5.8. KEK_AUTH_HASH 1030 The KEK_AUTH_HASH attribute specifies the hash algorithm used to 1031 generate the AUTH key to authenticate GSA_REKEY messages. Hash 1032 algorithms are defined in IANA registry IKEv2 Hash Algorithms 1033 [IKEV2-IANA]. This attribute can be used by a group member to 1034 determine in advance if it supports the algorithm used in the rekey 1035 message. 1037 4.5.9. KEK_MESSAGE_ID 1039 The KEK_MESSAGE_ID attribute defines the initial Message ID to be 1040 used by the GCKS in the GSA_REKEY messages. The Message ID is a 4 1041 octet unsigned integer in network byte order. 1043 4.6. GSA TEK Policy 1045 The GSA TEK policy contains security attributes for a single TEK 1046 associated with a group. 1048 0 1 2 3 1049 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 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Type = 3 | RESERVED | Length | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Protocol-ID | TEK Protocol-Specific Payload | 1054 +-+-+-+-+-+-+-+-+ ~ 1055 ~ | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 The GSA TEK Payload fields are defined as follows: 1060 o Type = 3 (1 octet) -- Identifies the GSA payload type as TEK in 1061 the G-IKEv2 registration or the G-IKEv2 rekey message. 1063 o RESERVED (1 octet) -- Must be zero. 1065 o Length (2 octets) -- Length of this structure, including the TEK 1066 Protocol-Specific Payload. 1068 o Protocol-ID (1 octet) -- Value specifying the Security Protocol. 1069 The following table defines values for the Security Protocol. 1070 Support for the GSA_PROTO_IPSEC_AH GSA TEK is OPTIONAL. The terms 1071 Reserved, Unassigned, and Private Use are to be applied as defined 1072 in [RFC8126]. The registration procedure is Expert Review. 1074 Protocol ID Value 1075 ----------- ----- 1076 Reserved 0 1077 GSA_PROTO_IPSEC_ESP 1 1078 GSA_PROTO_IPSEC_AH 2 1079 Unassigned 3-127 1080 Private Use 128-255 1082 o TEK Protocol-Specific Payload (variable) -- Payload which 1083 describes the attributes specific for the Protocol-ID. 1085 4.6.1. TEK ESP and AH Protocol-Specific Policy 1087 The TEK Protocol-Specific policy contains two traffic selectors one 1088 for the source and one for the destination of the protected traffic, 1089 SPI, Transforms, and Attributes. 1091 The TEK Protocol-Specific policy for ESP and AH is as follows: 1093 0 1 2 3 1094 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 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | SPI | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | | 1099 ~ ~ 1100 | | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 | | 1103 ~ ~ 1104 | | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | | 1107 ~ ~ 1108 | | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 ~ TEK Attributes ~ 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 The GSA TEK Policy fields are defined as follows: 1115 o SPI (4 octets) -- Security Parameter Index. 1117 o Source & Destination Traffic Selectors - The traffic selectors 1118 describe the source and the destination of the protected traffic. 1119 The format and values are defined in IKEv2 [RFC7296], section 1120 3.13.1. 1122 o Transform Substructure List -- A list of Transform Substructures 1123 specifies the transform information. The format and values are 1124 defined in IKEv2 [RFC7296], section 3.3.2. Valid Transform Types 1125 for ESP are ENCR, INTEG, and ESN. Valid Transform Types for AH 1126 are INTEG and ESN. As described in the IKEv2 registries 1127 [IKEV2-IANA]. The Last Substruc value in each Transform 1128 Substructure will be set to 3 except for the last one in the list, 1129 which is set to 0. 1131 o TEK Attributes -- Contains the TEK policy attributes associated 1132 with the group, in the format defined in Section 3.3.5 of 1134 [RFC7296]. All attributes are optional, depending on the group 1135 policy. 1137 Attribute Types are as follows. The terms Reserved, Unassigned, and 1138 Private Use are to be applied as defined in [RFC8126]. The 1139 registration procedure is Expert Review. 1141 ID Class Value Type 1142 -------- ----- ---- 1143 Reserved 0 1144 TEK_KEY_LIFETIME 1 V 1145 TEK_MODE 2 B 1146 Unassigned 3-16383 1147 Private Use 16384-32767 1149 It is NOT RECOMMENDED that the GCKS distribute both ESP and AH 1150 Protocol-Specific Policies for the same set of Traffic Selectors. 1152 4.6.1.1. TEK_KEY_LIFETIME 1154 The TEK_KEY_LIFETIME attribute specifies the maximum time for which 1155 the TEK is valid. When the TEK expires, the AH or ESP security 1156 association and all keys downloaded under the security association 1157 are discarded. The GCKS may refresh the TEK at any time before the 1158 end of the valid period. 1160 The value is a four (4) octet number defining a valid time period in 1161 seconds. If unspecified the default value of 28800 seconds (8 hours) 1162 shall be assumed. 1164 4.6.1.2. TEK_MODE 1166 The value of 0 is used for tunnel mode and 1 for transport mode. In 1167 the absence of this attribute tunnel mode will be used. 1169 4.7. GSA Group Associated Policy 1171 Group specific policy that does not belong to rekey policy (GSA KEK) 1172 or traffic encryption policy (GSA TEK) can be distributed to all 1173 group member using GSA GAP (Group Associated Policy). 1175 The GSA GAP payload is defined as follows: 1177 0 1 2 3 1178 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 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | Type = 2 ! RESERVED ! Length | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 ~ Group Associated Policy Attributes ~ 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 The GSA GAP payload fields are defined as follows: 1187 o Type = 2 (1 octet) -- Identifies the GSA payload type as GAP in 1188 the G-IKEv2 registration or the G-IKEv2 rekey message. 1190 o RESERVED (1 octet) -- Must be zero. 1192 o Length (2 octets) -- Length of this structure, including the GSA 1193 GAP header and Attributes. 1195 o Group Associated Policy Attributes (variable) -- Contains 1196 attributes following the format defined in Section 3.3.5 of 1197 [RFC7296]. 1199 Attribute Types are as follows. The terms Reserved, Unassigned, and 1200 Private Use are to be applied as defined in [RFC8126]. The 1201 registration procedure is Expert Review. 1203 Attribute Type Value Type 1204 -------------- ----- ---- 1205 Reserved 0 1206 ACTIVATION_TIME_DELAY 1 B 1207 DEACTIVATION_TIME_DELAY 2 B 1208 Unassigned 3-16383 1209 Private Use 16384-32767 1211 4.7.1. ACTIVATION_TIME_DELAY/DEACTIVATION_TIME_DELAY 1213 Section 4.2.1 of RFC 5374 specifies a key rollover method that 1214 requires two values be provided to group members. The 1215 ACTIVATION_TIME_DELAY attribute allows a GCKS to set the Activation 1216 Time Delay (ATD) for SAs generated from TEKs. The ATD defines how 1217 long after receiving new SAs that they are to be activated by the GM. 1218 The ATD value is in seconds. 1220 The DEACTIVATION_TIME_DELAY allows the GCKS to set the Deactivation 1221 Time Delay (DTD) for previously distributed SAs. The DTD defines how 1222 long after receiving new SAs it should deactivate SAs that are 1223 destroyed by the rekey event. The value is in seconds. 1225 The values of ATD and DTD are independent. However, the DTD value 1226 should be larger, which allows new SAs to be activated before older 1227 SAs are deactivated. Such a policy ensures that protected group 1228 traffic will always flow without interruption. 1230 4.8. Key Download Payload 1232 The Key Download Payload contains the group keys for the group 1233 specified in the GSA Payload. These key download payloads can have 1234 several security attributes applied to them based upon the security 1235 policy of the group as defined by the associated GSA Payload. 1237 0 1 2 3 1238 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 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | Next Payload |C| RESERVED | Length | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | Number of Key Packets | RESERVED2 | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1244 ~ Key Packets ~ 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 The Key Download Payload fields are defined as follows: 1249 o Next Payload (1 octet) -- Identifier for the payload type of the 1250 next payload in the message. If the current payload is the last 1251 in the message, then this field will be zero. 1253 o Critical (1 bit) -- Set according to [RFC7296]. 1255 o RESERVED (7 bits) -- Unused, set to zero. 1257 o Payload Length (2 octets) -- Length in octets of the current 1258 payload, including the generic payload header. 1260 o Number of Key Packets (2 octets) -- Contains the total number of 1261 Key Packets passed in this data block. 1263 o Key Packets (variable) -- Contains Key Packets. Several types of 1264 key packets are defined. Each Key Packet has the following 1265 format. 1267 0 1 2 3 1268 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 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | KD Type | RESERVED | KD Length | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | SPI Size | SPI (variable) ~ 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 ~ Key Packet Attributes ~ 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 o Key Download (KD) Type (1 octet) -- Identifier for the Key Data 1278 field of this Key Packet. In the following table the terms 1279 Reserved, Unassigned, and Private Use are to be applied as defined 1280 in [RFC8126]. The registration procedure is Expert Review. 1282 Key Download Type Value 1283 ----------------- ----- 1284 Reserved 0 1285 TEK 1 1286 KEK 2 1287 LKH 3 1288 SID 4 1289 Unassigned 5-127 1290 Private Use 128-255 1292 o RESERVED (1 octet) -- Unused, set to zero. 1294 o Key Download Length (2 octets) -- Length in octets of the Key 1295 Packet data, including the Key Packet header. 1297 o SPI Size (1 octet) -- Value specifying the length in octets of the 1298 SPI as defined by the Protocol-Id. 1300 o SPI (variable length) -- Security Parameter Index which matches a 1301 SPI previously sent in an GSA KEK or GSA TEK Payload. 1303 o Key Packet Attributes (variable length) -- Contains Key 1304 information. The format of this field is specific to the value of 1305 the KD Type field. The following sections describe the format of 1306 each KD Type. 1308 4.8.1. TEK Download Type 1310 The following attributes may be present in a TEK Download Type. 1311 Exactly one attribute matching each type sent in the GSA TEK payload 1312 MUST be present. The attributes must follow the format defined in 1313 IKEv2 (Section 3.3.5 of [RFC7296]). In the table, attributes defined 1314 as TV are marked as Basic (B); attributes defined as TLV are marked 1315 as Variable (V). The terms Reserved, Unassigned, and Private Use are 1316 to be applied as defined in [RFC8126]. The registration procedure is 1317 Expert Review. 1319 TEK Class Value Type 1320 --------- ----- ---- 1321 Reserved 0 1322 TEK_ALGORITHM_KEY 1 V 1323 TEK_INTEGRITY_KEY 2 V 1324 Unassigned 3-16383 1325 Private Use 16384-32767 1327 It is possible that the GCKS will send no TEK key packets in a 1328 Registration KD payload (as well as no corresponding GSA TEK payloads 1329 in the GSA payload), after which the TEK payloads will be sent in a 1330 rekey message. At least one TEK MUST be included in each Rekey KD 1331 payload. 1333 4.8.1.1. TEK_ALGORITHM_KEY 1335 The TEK_ALGORITHM_KEY class contains encryption keying material for 1336 the corresponding SPI. This keying material will be used with the 1337 encryption algorithm specified in the GSA TEK payload, and according 1338 to the IPsec transform describing that encryption algorithm. The 1339 keying material is treated equivalent to IKEv2 KEYMAT derived for 1340 that IPsec transform. If the encryption algorithm requires a nonce 1341 (e.g., AES-GCM), the nonce is chosen as shown in Section 3.2. 1343 4.8.1.2. TEK_INTEGRITY_KEY 1345 The TEK_INTEGRITY_KEY class declares that the integrity key for the 1346 corresponding SPI is contained in the Key Packet Attribute. Readers 1347 should refer to [IKEV2-IANA] for the latest values. 1349 4.8.2. KEK Download Type 1351 The following attributes may be present in a KEK Download Type. 1352 Exactly one attribute matching each type sent in the GSA KEK payload 1353 MUST be present. The attributes must follow the format defined in 1354 IKEv2 (Section 3.3.5 of [RFC7296]). In the table, attributes defined 1355 as TV are marked as Basic (B); attributes defined as TLV are marked 1356 as Variable (V). The terms Reserved, Unassigned, and Private Use are 1357 to be applied as defined in [RFC8126]. The registration procedure is 1358 Expert Review. 1360 KEK Class Value Type 1361 --------- ----- ---- 1362 Reserved 0 1363 KEK_ENCR_KEY 1 V 1364 KEK_INTEGRITY_KEY 2 V 1365 KEK_AUTH_KEY 3 V 1366 Unassigned 4-16383 1367 Private Use 16384-32767 1369 If the KEK Key Packet is included, there MUST be only one present in 1370 the KD payload. 1372 4.8.2.1. KEK_ENCR_KEY 1374 The KEK_ENCR_KEY class declares that the encryption key for the 1375 corresponding SPI is contained in the Key Packet Attribute. The 1376 encryption algorithm that will use this key was specified in the GSA 1377 KEK payload. 1379 If the mode of operation for the algorithm requires an Initialization 1380 Vector (IV), an explicit IV MUST be included in the KEK_ENCR_KEY 1381 before the actual key. 1383 4.8.2.2. KEK_INTEGRITY_KEY 1385 The KEK_INTEGRITY_KEY class declares the integrity key for this SPI 1386 is contained in the Key Packet Attribute. The integrity algorithm 1387 that will use this key was specified in the GSA KEK payload. 1389 4.8.2.3. KEK_AUTH_KEY 1391 The KEK_AUTH_KEY class declares that the authentication key for this 1392 SPI is contained in the Key Packet Attribute. The signature 1393 algorithm that will use this key was specified in the GSA KEK 1394 payload. An RSA public key format is defined in RFC 3447, 1395 Section A.1.1. DSS public key format is defined in RFC 3279 1396 Section 2.3.2. For ECDSA Public keys, use format described in RFC 1397 5480 Section 2.2. 1399 4.8.3. LKH Download Type 1401 The LKH key packet is comprised of attributes representing different 1402 leaves in the LKH key tree. 1404 The following attributes are used to pass an LKH KEK array in the KD 1405 payload. The attributes must follow the format defined in IKEv2 1406 (Section 3.3.5 of [RFC7296]). In the table, attributes defined as TV 1407 are marked as Basic (B); attributes defined as TLV are marked as 1408 Variable (V). The terms Reserved, Unassigned, and Private Use are to 1409 be applied as defined in [RFC8126]. The registration procedure is 1410 Expert Review. 1412 LKH Download Class Value Type 1413 ------------------ ----- ---- 1414 Reserved 0 1415 LKH_DOWNLOAD_ARRAY 1 V 1416 LKH_UPDATE_ARRAY 2 V 1417 Unassigned 3-16383 1418 Private Use 16384-32767 1420 If an LKH key packet is included in the KD payload, there MUST be 1421 only one present. 1423 4.8.3.1. LKH_DOWNLOAD_ARRAY 1425 The LKH_DOWNLOAD_ARRAY class is used to download a set of LKH keys to 1426 a group member. It MUST NOT be included in a IKEv2 rekey message KD 1427 payload if the IKEv2 rekey is sent to more than one group member. If 1428 an LKH_DOWNLOAD_ARRAY attribute is included in a KD payload, there 1429 MUST be only one present. 1431 This attribute consists of a header block, followed by one or more 1432 LKH keys. 1434 0 1 2 3 1435 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 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 | # of LKH Keys | RESERVED | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 ~ LKH Keys ~ 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 The KEK_LKH attribute fields are defined as follows: 1444 o Number of LKH Keys (2 octets) -- This value is the number of 1445 distinct LKH keys in this sequence. 1447 o RESERVED (1 octet) -- Unused, set to zero. 1449 Each LKH Key is defined as follows: 1451 0 1 2 3 1452 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 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 ! LKH ID | Encr Alg | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 | Key Handle | 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 ~ Key Data ~ 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 o LKH ID (2 octets) -- This is the position of this key in the 1462 binary tree structure used by LKH. 1464 o Encr Alg (2 octets) -- This is the encryption algorithm for which 1465 this key data is to be used. This value is specified in 1466 Section 4.5.3. 1468 o RESERVED (1 octet) -- Unused, set to zero. 1470 o Key Handle (4 octets) -- This is a randomly generated value to 1471 uniquely identify a key within an LKH ID. 1473 o Key Data (variable length) -- This is the actual encryption key 1474 data, which is dependent on the Encr Alg algorithm for its format. 1475 If the mode of operation for the algorithm requires an 1476 Initialization Vector (IV), an explicit IV MUST be included in the 1477 Key Data field before the actual key. 1479 The first LKH Key structure in an LKH_DOWNLOAD_ARRAY attribute 1480 contains the Leaf identifier and key for the group member. The rest 1481 of the LKH Key structures contain keys along the path of the key tree 1482 in the order starting from the leaf, culminating in the group KEK. 1484 4.8.3.2. LKH_UPDATE_ARRAY 1486 The LKH_UPDATE_ARRAY class is used to update the LKH keys for a 1487 group. It is most likely to be included in a G-IKEv2 rekey message 1488 KD payload to rekey the entire group. This attribute consists of a 1489 header block, followed by one or more LKH keys, as defined in 1490 Section 4.8.3.1. 1492 There may be any number of LKH_UPDATE_ARRAY attributes included in a 1493 KD payload. 1495 0 1 2 3 1496 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 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 | # of LKH Keys | LKH ID | 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 | Key Handle | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 ~ LKH Keys ~ 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 o Number of LKH Keys (2 octets) -- This value is the number of 1506 distinct LKH keys in this sequence. 1508 o LKH ID (2 octets) -- This is the node identifier associated with 1509 the key used to encrypt the first LKH Key. 1511 o Key Handle (4 octets) -- This is the value that uniquely 1512 identifies the key within the LKH ID which was used to encrypt the 1513 first LKH key. 1515 The LKH Keys are as defined in Section 4.8.3.1. The LKH Key 1516 structures contain keys along the path of the key tree in the order 1517 from the LKH ID found in the LKH_UPDATE_ARRAY header, culminating in 1518 the group KEK. The Key Data field of each LKH Key is encrypted with 1519 the LKH key preceding it in the LKH_UPDATE_ARRAY attribute. The 1520 first LKH Key is encrypted under the key defined by the LKH ID and 1521 Key Handle found in the LKH_UPDATE_ARRAY header. 1523 4.8.4. SID Download Type 1525 The SID attribute is used to download one or more Sender-ID (SID) 1526 values for the exclusive use of a group member. The terms Reserved, 1527 Unassigned, and Private Use are to be applied as defined in 1528 [RFC8126]. The registration procedure is Expert Review. 1530 SID Download Class Value Type 1531 ------------------ ----- ---- 1532 Reserved 0 1533 NUMBER_OF_SID_BITS 1 B 1534 SID_VALUE 2 V 1535 Unassigned 3-16383 1536 Private Use 16384-32767 1538 Because a SID value is intended for a single group member, the SID 1539 Download type MUST NOT be distributed in a GSA_REKEY message 1540 distributed to multiple group members. 1542 4.8.4.1. NUMBER_OF_SID_BITS 1544 The NUMBER_OF_SID_BITS class declares how many bits of the cipher 1545 nonce in which to represent an SID value. This value is applied to 1546 each SID value distributed in the SID Download. 1548 4.8.4.2. SID_VALUE 1550 The SID_VALUE class declares a single SID value for the exclusive use 1551 of this group member. Multiple SID_VALUE attributes MAY be included 1552 in a SID Download. 1554 4.8.4.3. GM Semantics 1556 The SID_VALUE attribute value distributed to the group member MUST be 1557 used by that group member as the SID field portion of the IV for all 1558 Data-Security SAs including a counter-based mode of operation 1559 distributed by the GCKS as a part of this group. When the Sender- 1560 Specific IV (SSIV) field for any Data-Security SA is exhausted, the 1561 group member MUST NOT act as a sender on that SA using its active 1562 SID. The group member SHOULD re-register, at which time the GCKS 1563 will issue a new SID to the group member, along with either the same 1564 Data-Security SAs or replacement ones. The new SID replaces the 1565 existing SID used by this group member, and also resets the SSIV 1566 value to its starting value. A group member MAY re-register prior to 1567 the actual exhaustion of the SSIV field to avoid dropping data 1568 packets due to the exhaustion of available SSIV values combined with 1569 a particular SID value. 1571 A group member MUST ignore an SID Download Type KD payload present in 1572 a GSA-REKEY message, otherwise more than one GM may end up using the 1573 same SID. 1575 4.8.4.4. GCKS Semantics 1577 If any KD payload includes keying material that is associated with a 1578 counter-mode of operation, an SID Download Type KD payload containing 1579 at least one SID_VALUE attribute MUST be included. The GCKS MUST NOT 1580 send the SID Download Type KD payload as part of a GSA_REKEY message, 1581 because distributing the same sender-specific policy to more than one 1582 group member will reduce the security of the group. 1584 4.9. Delete Payload 1586 There are occasions when the GCKS may want to signal to group members 1587 to delete policy at the end of a broadcast, or if policy has changed. 1588 Deletion of keys MAY be accomplished by sending an IKEv2 Delete 1589 Payload, section 3.11 of [RFC7296] as part of the GSA_AUTH or 1590 GSA_REKEY Exchange. One or more Delete payloads MAY be placed 1591 following the HDR payload in the GSA_AUTH or GSA_REKEY Exchange. 1593 The Protocol ID MUST be 41 for GSA_REKEY Exchange, 2 for AH or 3 for 1594 ESP. Note that only one protocol id value can be defined in a Delete 1595 payload. If a TEK and a KEK SA for GSA_REKEY Exchange must be 1596 deleted, they must be sent in different Delete payloads. Similarly, 1597 if a TEK specifying ESP and a TEK specifying AH need to be deleted, 1598 they must be sent in different Delete payloads. 1600 There may be circumstances where the GCKS may want to reset the 1601 policy and keying material for the group. The GCKS can signal 1602 deletion of all policy of a particular TEK by sending a TEK with a 1603 SPI value equal to zero in the delete payload. In the event that the 1604 administrator is no longer confident in the integrity of the group 1605 they may wish to remove all KEK and all the TEKs in the group. This 1606 is done by having the GCKS send a delete payload with a SPI of zero 1607 and a Protocol-ID of AH or ESP to delete all TEKs, followed by 1608 another delete payload with a SPI value of zero and Protocol-ID of 1609 KEK SA to delete the KEK SA. 1611 4.10. Notify Payload 1613 G-IKEv2 uses the same Notify payload as specified in [RFC7296], 1614 section 3.10. 1616 There are additional Notify Message types introduced by G-IKEv2 to 1617 communicate error conditions and status. 1619 NOTIFY messages - error types Value 1620 ------------------------------------------------------------------- 1621 INVALID_GROUP_ID - 45 1622 Indicates the group id sent during the registration process is 1623 invalid. 1625 AUTHORIZATION_FAILED - 46 1626 Sent in the response to a GSA_AUTH message when authorization failed. 1628 NOTIFY messages - status types Value 1629 ------------------------------------------------------------------- 1630 SENDER_ID_REQUEST - 16429 1631 Sent in GSA_AUTH or GSA_REGISTRATION to request SIDs from the GCKS. 1632 The data includes a count of how many SID values it desires. 1634 4.11. Authentication Payload 1636 G-IKEv2 uses the same Authentication payload as specified in 1637 [RFC7296], section 3.8, to sign the rekey message. 1639 5. Security Considerations 1641 5.1. GSA registration and secure channel 1643 G-IKEv2 registration exchange uses IKEv2 IKE_SA_INIT protocols, 1644 inheriting all the security considerations documented in [RFC7296] 1645 section 5 Security Considerations, including authentication, 1646 confidentiality, protection against man-in-the-middle, protection 1647 against replay/reflection attacks, and denial of service protection. 1648 The GSA_AUTH and GSA_REGISTRATION exchanges also take advantage of 1649 those protections. In addition, G-IKEv2 brings in the capability to 1650 authorize a particular group member regardless of whether they have 1651 the IKEv2 credentials. 1653 5.2. GSA maintenance channel 1655 The GSA maintenance channel is cryptographically and integrity 1656 protected using the cryptographic algorithm and key negotiated in the 1657 GSA member registration exchanged. 1659 5.2.1. Authentication/Authorization 1661 Authentication is implicit, the public key of the identity is 1662 distributed during the registration, and the receiver of the rekey 1663 message uses that public key and identity to verify the message came 1664 from the authorized GCKS. 1666 5.2.2. Confidentiality 1668 Confidentiality is provided by distributing a confidentiality key as 1669 part of the GSA member registration exchange. 1671 5.2.3. Man-in-the-Middle Attack Protection 1673 GSA maintenance channel is integrity protected by using a digital 1674 signature. 1676 5.2.4. Replay/Reflection Attack Protection 1678 The GSA_REKEY message includes a monotonically increasing sequence 1679 number to protect against replay and reflection attacks. A group 1680 member will recognize a replayed message by comparing the Message ID 1681 number to that of the last received rekey message, any rekey message 1682 containing a Message ID number less than or equal to the last 1683 received value MUST be discarded. Implementations should keep a 1684 record of recently received GSA rekey messages for this comparison. 1686 6. IANA Considerations 1688 6.1. New registries 1690 A new set of registries should be created for G-IKEv2, on a new page 1691 titled Group Key Management using IKEv2 (G-IKEv2) Parameters. The 1692 following registries should be placed on that page. The terms 1693 Reserved, Expert Review and Private Use are to be applied as defined 1694 in [RFC8126]. 1696 GSA Policy Type Registry, see Section 4.4.1 1698 KEK Attributes Registry, see Section 4.5.1 1700 KEK Management Algorithm Registry, see Section 4.5.2 1702 GSA TEK Payload Protocol ID Type Registry, see Section 4.6 1704 TEK Attributes Registry, see Section 4.6 1706 Key Download Type Registry, see Section 4.8 1708 TEK Download Type Attributes Registry, see Section 4.8.1 1710 KEK Download Type Attributes Registry, see Section 4.8.2 1712 LKH Download Type Attributes Registry, see Section 4.8.3 1714 SID Download Type Attributes Registry, see Section 4.8.4 1716 6.2. New payload and exchange types added to the existing IKEv2 1717 registry 1719 The following new payloads and exchange types specified in this memo 1720 have already been allocated by IANA and require no further action, 1721 other than replacing the draft name with an RFC number. 1723 The present document describes new IKEv2 Next Payload types, see 1724 Section 4.1 1726 The present document describes new IKEv2 Exchanges types, see 1727 Section 4.1 1728 The present document describes new IKEv2 notification types, see 1729 Section 4.10 1731 7. Acknowledgements 1733 The authors thank Lakshminath Dondeti and Jing Xiang for first 1734 exploring the use of IKEv2 for group key management and providing the 1735 basis behind the protocol. Mike Sullenberger was instrumental in 1736 helping resolve many issues in several versions of the document. 1738 8. Contributors 1740 The following individuals made substantial contributions to early 1741 versions of this memo. 1743 Sheela Rowles 1744 Cisco Systems 1745 170 W. Tasman Drive 1746 San Jose, California 95134-1706 1747 USA 1749 Phone: +1-408-527-7677 1750 Email: sheela@cisco.com 1752 Aldous Yeung 1753 Cisco Systems 1754 170 W. Tasman Drive 1755 San Jose, California 95134-1706 1756 USA 1758 Phone: +1-408-853-2032 1759 Email: cyyeung@cisco.com 1761 Paulina Tran 1762 Cisco Systems 1763 170 W. Tasman Drive 1764 San Jose, California 95134-1706 1765 USA 1767 Phone: +1-408-526-8902 1768 Email: ptran@cisco.com 1770 9. References 1771 9.1. Normative References 1773 [RFC6054] McGrew, D. and B. Weis, "Using Counter Modes with 1774 Encapsulating Security Payload (ESP) and Authentication 1775 Header (AH) to Protect Group Traffic", RFC 6054, 1776 DOI 10.17487/RFC6054, November 2010, . 1779 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1780 Kivinen, "Internet Key Exchange Protocol Version 2 1781 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1782 2014, . 1784 9.2. Informative References 1786 [IKE-HASH] 1787 Kivinen, T., "Fixing IKE Phase 1 & 2 Authentication 1788 HASHs", November 2001, . 1791 [IKEV2-IANA] 1792 IANA, "Internet Key Exchange Version 2 (IKEv2) 1793 Parameters", February 2016, 1794 . 1797 [NNL] Naor, D., Noal, M., and J. Lotspiech, "Revocation and 1798 Tracing Schemes for Stateless Receivers", Advances in 1799 Cryptology, Crypto '01, Springer-Verlag LNCS 2139, 2001, 1800 pp. 41-62, 2001, 1801 . 1803 [OFT] McGrew, D. and A. Sherman, "Key Establishment in Large 1804 Dynamic Groups Using One-Way Function Trees", Manuscript, 1805 submitted to IEEE Transactions on Software Engineering, 1806 1998, . 1809 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1810 Requirement Levels", BCP 14, RFC 2119, 1811 DOI 10.17487/RFC2119, March 1997, . 1814 [RFC2407] Piper, D., "The Internet IP Security Domain of 1815 Interpretation for ISAKMP", RFC 2407, 1816 DOI 10.17487/RFC2407, November 1998, . 1819 [RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, 1820 "Internet Security Association and Key Management Protocol 1821 (ISAKMP)", RFC 2408, DOI 10.17487/RFC2408, November 1998, 1822 . 1824 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1825 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 1826 . 1828 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 1829 Multicast: Issues and Architectures", RFC 2627, 1830 DOI 10.17487/RFC2627, June 1999, . 1833 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 1834 Counter Mode With IPsec Encapsulating Security Payload 1835 (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, 1836 . 1838 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 1839 (GCM) in IPsec Encapsulating Security Payload (ESP)", 1840 RFC 4106, DOI 10.17487/RFC4106, June 2005, 1841 . 1843 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1844 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1845 December 2005, . 1847 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 1848 Mode with IPsec Encapsulating Security Payload (ESP)", 1849 RFC 4309, DOI 10.17487/RFC4309, December 2005, 1850 . 1852 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 1853 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 1854 DOI 10.17487/RFC4543, May 2006, . 1857 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1858 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 1859 October 2011, . 1861 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1862 Writing an IANA Considerations Section in RFCs", BCP 26, 1863 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1864 . 1866 Appendix A. Differences between G-IKEv2 and RFC 6407 1868 KE Payload - The KE payload is no longer needed with the availability 1869 of newer algorithms such as AES and GCM which provide adequate 1870 protection therefore not needing the PFS capability the KE payload 1871 offers. 1873 SIG Payload - The AUTH payload is used for the same purpose instead. 1875 DOI/Situation - The DOI and Situation fields in the SA payload are no 1876 longer needed in the G-IKEv2 protocol as port 848 will distinguish 1877 the IKEv2 messages from the G-IKEv2 messages. 1879 SEQ Payload - The SEQ payload is no longer needed since IKEv2 header 1880 has message id which is used to prevent message replay attacks. 1882 Authors' Addresses 1884 Brian Weis 1885 Cisco Systems 1886 170 W. Tasman Drive 1887 San Jose, California 95134-1706 1888 USA 1890 Phone: +1-408-526-4796 1891 Email: bew@cisco.com 1893 Yoav Nir 1894 Dell EMC 1895 9 Andrei Sakharov St 1896 Haifa 3190500 1897 Israel 1899 Email: ynir.ietf@gmail.com 1901 Valery Smyslov 1902 ELVIS-PLUS 1903 PO Box 81 1904 Moscow (Zelenograd) 124460 1905 Russian Federation 1907 Phone: +7 495 276 0211 1908 Email: svan@elvis.ru