idnits 2.17.00 (12 Aug 2021) /tmp/idnits25862/draft-ietf-ipsecme-g-ikev2-05.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 document date (March 18, 2022) is 64 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CERTREQ' is mentioned on line 2398, but not defined == Missing Reference: 'S' is mentioned on line 2328, but not defined == Missing Reference: 'M' is mentioned on line 2282, but not defined == Outdated reference: A later version (-05) exists of draft-ietf-ipsecme-ikev2-multiple-ke-04 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Smyslov 3 Internet-Draft ELVIS-PLUS 4 Obsoletes: 6407 (if approved) B. Weis 5 Intended status: Standards Track Independent 6 Expires: September 19, 2022 March 18, 2022 8 Group Key Management using IKEv2 9 draft-ietf-ipsecme-g-ikev2-05 11 Abstract 13 This document presents an extension to the Internet Key Exchange 14 version 2 (IKEv2) protocol for the purpose of a group key management. 15 The protocol is in conformance with the Multicast Security (MSEC) key 16 management architecture, which contains two components: member 17 registration and group rekeying. Both components require a Group 18 Controller/Key Server to download IPsec group security associations 19 to authorized members of a group. The group members then exchange IP 20 multicast or other group traffic as IPsec packets. This document 21 obsoletes RFC 6407. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 19, 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 60 2. G-IKEv2 Protocol . . . . . . . . . . . . . . . . . . . . . . 7 61 2.1. G-IKEv2 Integration into IKEv2 Protocol . . . . . . . . . 7 62 2.1.1. G-IKEv2 Transport and Port . . . . . . . . . . . . . 7 63 2.2. G-IKEv2 Payloads . . . . . . . . . . . . . . . . . . . . 8 64 2.3. G-IKEv2 Member Registration and Secure Channel 65 Establishment . . . . . . . . . . . . . . . . . . . . . . 9 66 2.3.1. GSA_AUTH exchange . . . . . . . . . . . . . . . . . . 9 67 2.3.2. GSA_REGISTRATION Exchange . . . . . . . . . . . . . . 11 68 2.3.3. GM Registration Operations . . . . . . . . . . . . . 11 69 2.3.4. GCKS Registration Operations . . . . . . . . . . . . 14 70 2.4. Group Maintenance Channel . . . . . . . . . . . . . . . . 15 71 2.4.1. GSA_REKEY . . . . . . . . . . . . . . . . . . . . . . 16 72 2.4.2. GSA_INBAND_REKEY Exchange . . . . . . . . . . . . . . 22 73 2.4.3. Deletion of SAs . . . . . . . . . . . . . . . . . . . 22 74 2.5. Counter-based modes of operation . . . . . . . . . . . . 23 75 2.5.1. Allocation of SIDs . . . . . . . . . . . . . . . . . 24 76 2.5.2. GM Usage of SIDs . . . . . . . . . . . . . . . . . . 25 77 3. Group Key Management and Access Control . . . . . . . . . . . 25 78 3.1. Key Wrap Keys . . . . . . . . . . . . . . . . . . . . . . 26 79 3.1.1. Default Key Wrap Key . . . . . . . . . . . . . . . . 26 80 3.2. GCKS Key Management Semantics . . . . . . . . . . . . . . 27 81 3.2.1. Forward Access Control Requirements . . . . . . . . . 27 82 3.3. GM Key Management Semantics . . . . . . . . . . . . . . . 28 83 3.4. SA Keys . . . . . . . . . . . . . . . . . . . . . . . . . 30 84 4. Header and Payload Formats . . . . . . . . . . . . . . . . . 30 85 4.1. G-IKEv2 Header . . . . . . . . . . . . . . . . . . . . . 30 86 4.2. Group Identification Payload . . . . . . . . . . . . . . 30 87 4.3. Security Association - GM Supported Transforms Payload . 31 88 4.4. Group Security Association Payload . . . . . . . . . . . 31 89 4.4.1. Group Policies . . . . . . . . . . . . . . . . . . . 31 90 4.4.2. Group Security Association Policy Substructure . . . 32 91 4.4.3. Group Associated Policy Substructure . . . . . . . . 39 92 4.5. Key Download Payload . . . . . . . . . . . . . . . . . . 41 93 4.5.1. Wrapped Key Format . . . . . . . . . . . . . . . . . 41 94 4.5.2. Group Key Packet Substructure . . . . . . . . . . . . 43 95 4.5.3. Member Key Packet Substructure . . . . . . . . . . . 45 96 4.6. Delete Payload . . . . . . . . . . . . . . . . . . . . . 47 97 4.7. Notify Payload . . . . . . . . . . . . . . . . . . . . . 47 98 4.7.1. USE_TRANSPORT_MODE Notification . . . . . . . . . . . 48 99 4.8. Authentication Payload . . . . . . . . . . . . . . . . . 49 100 5. Usigng G-IKEv2 Attributes . . . . . . . . . . . . . . . . . . 49 101 6. Interaction with other IKEv2 Protocol Extensions . . . . . . 51 102 6.1. Mixing Preshared Keys in IKEv2 for Post-quantum Security 52 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 54 104 7.1. GSA Registration and Secure Channel . . . . . . . . . . . 54 105 7.2. GSA Maintenance Channel . . . . . . . . . . . . . . . . . 54 106 7.2.1. Authentication/Authorization . . . . . . . . . . . . 54 107 7.2.2. Confidentiality . . . . . . . . . . . . . . . . . . . 54 108 7.2.3. Man-in-the-Middle Attack Protection . . . . . . . . . 55 109 7.2.4. Replay/Reflection Attack Protection . . . . . . . . . 55 110 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 111 8.1. New Registries . . . . . . . . . . . . . . . . . . . . . 55 112 8.2. Changes in the Existing IKEv2 Registries . . . . . . . . 57 113 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 58 114 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 58 115 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 116 11.1. Normative References . . . . . . . . . . . . . . . . . . 59 117 11.2. Informative References . . . . . . . . . . . . . . . . . 60 118 Appendix A. Use of LKH in G-IKEv2 . . . . . . . . . . . . . . . 63 119 A.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 63 120 A.2. Group Creation . . . . . . . . . . . . . . . . . . . . . 64 121 A.3. Simple Group SA Rekey . . . . . . . . . . . . . . . . . . 65 122 A.4. Group Member Exclusion . . . . . . . . . . . . . . . . . 65 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 125 1. Introduction and Overview 127 A group key management protocol provides IPsec keys and policy to a 128 set of IPsec devices which are authorized to communicate using a 129 Group Security Association (GSA) defined in [RFC3740]. The data 130 communications within the group (e.g., IP multicast packets) are 131 protected by a key pushed to the group members (GMs) by the Group 132 Controller/Key Server (GCKS). This document presents an extension to 133 IKEv2 [RFC7296] called G-IKEv2, that allows to perform a group key 134 management. 136 G-IKEv2 conforms to the Multicast Group Security Architecture 137 [RFC3740], Multicast Extensions to the Security Architecture for the 138 Internet Protocol [RFC5374] and the Multicast Security (MSEC) Group 139 Key Management Architecture [RFC4046]. G-IKEv2 replaces GDOI 140 [RFC6407], which defines a similar group key management protocol 141 using IKEv1 [RFC2409] (since deprecated by IKEv2). When G-IKEv2 is 142 used, group key management use cases can benefit from the simplicity, 143 increased robustness and cryptographic improvements of IKEv2 (see 144 Appendix A of [RFC7296]. 146 A GM begins a "registration" exchange when it first joins the group. 147 With G-IKEv2, the GCKS authenticates and authorizes GMs, then pushes 148 policy and keys used by the group to the GM. G-IKEv2 includes two 149 "registration" exchanges. The first is the GSA_AUTH exchange ( 150 Section 2.3.1), which is used when a GM first conatcts a GCKS. The 151 second is the GSA_REGISTRATION exchange (Section 2.3.2), which a GM 152 can use within an established IKE SA. Group rekeys are accomplished 153 using either the GSA_REKEY pseudo-exchange (a single message 154 distributed to all GMs, usually as a multicast message), or as a 155 GSA_INBAND_REKEY exchange delivered individually to group members 156 using existing IKE SAs). 158 Large and small groups may use different sets of these protocols. 159 When a large group of devices are communicating, the GCKS is likely 160 to use the GSA_REKEY message for efficiency. This is shown in 161 Figure 1. (Note: For clarity, IKE_SA_INIT is omitted from the 162 figure.) 164 +--------+ 165 +------------->| GCKS |<-------------+ 166 | +--------+ | 167 | | ^ | 168 | | | | 169 | | GSA_AUTH | 170 | | or | 171 | | GSA_REGISTRATION | 172 | | | | 173 GSA_AUTH | | GSA_AUTH 174 or GSA_REKEY | or 175 GSA_REGISTRATION | | GSA_REGISTRATION 176 | | | | 177 | +------------+-----------------+ | 178 | | | | | | 179 v v v v v v 180 +-------+ +--------+ +-------+ 181 | GM | ... | GM | ... | GM | 182 +-------+ +--------+ +-------+ 183 ^ ^ ^ 184 | | | 185 +-------ESP-------+-------ESP------+ 187 Figure 1: G-IKEv2 used in large groups 189 Alternatively, a small group may simply use the GSA_AUTH as a 190 registration protocol, where the GCKS issues rekeys using the 191 GSA_INBAND_REKEY within the same IKE SA. The GCKS is also likely to 192 be a GM in a small group (as shown in Figure 2.) 193 GSA_AUTH, GSA_INBAND_REKEY 194 +-----------------------------------------------+ 195 | | 196 | GSA_AUTH, GSA_INBAND_REKEY | 197 | +-----------------------------+ | 198 | | | | 199 | | GSA_AUTH, GSA_INBAND_REKEY | | 200 | | +--------+ | | 201 v v v v v v 202 +---------+ +----+ +----+ +----+ 203 | GCKS/GM | | GM | | GM | | GM | 204 +---------+ +----+ +----+ +----+ 205 ^ ^ ^ ^ 206 | | | | 207 +----ESP-----+------ESP-------+-----ESP-----+ 209 Figure 2: G-IKEv2 used in small groups 211 A combination of these approaches is also possible. For example, the 212 GCKS may use more robust GSA_INBAND_REKEY to provide keys for some 213 GMs (for example, those acting as senders in the group) and GSA_REKEY 214 for the rest. 216 IKEv2 message semantics are preserved in that all communications 217 consists of message request-response pairs. The exception to this 218 rule is the GSA_REKEY pseudo-exchange, which is a single message 219 delivering group updates to the GMs. 221 1.1. Requirements Notation 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 225 "OPTIONAL" in this document are to be interpreted as described in BCP 226 14 [RFC2119] [RFC8174] when, and only when, they appear in all 227 capitals, as shown here. 229 1.2. Terminology 231 It is assumed that readers are familiar with the IPsec architecture 232 [RFC4301], its extension for multicast [RFC5374]. This document 233 defines an extension to the IKEv2 protocol [RFC7296], so it is 234 assumed that readers have good understanding of this protocol. 236 The following key terms are used throughout this document (mostly 237 borrowed from [RFC5374] and [RFC6407]). 239 Group 240 A set of devices that work together to protect group 241 communications. 243 Group Member (GM) 244 An IPsec device that belongs to a group. A Group Member is 245 authorized to be a Group Sender and/or a Group Receiver. 247 Group Receiver 248 A Group Member that is authorized to receive packets sent to a 249 group by a Group Sender. 251 Group Sender 252 A Group Member that is authorized to send packets to a group. 254 Group Key Management (GKM) Protocol 255 A key management protocol used by a GCKS to distribute IPsec 256 Security Association policy and keying material. A GKM 257 protocol is used when a group of IPsec devices require the same 258 SAs. For example, when an IPsec SA describes an IP multicast 259 destination, the sender and all receivers need to have the 260 group SA. 262 Group Controller Key Server (GCKS) 263 A Group Key Management (GKM) protocol server that manages IPsec 264 state for a group. A GCKS authenticates and provides the IPsec 265 SA policy and keying material to GKM Group Members. 267 Data-Security SA 268 The security policy distributed by a GDOI GCKS describing 269 traffic that is expected to be protected by group members. 270 This document described the distribution of IPsec AH and ESP 271 Data-Security SAs. 273 Rekey SA 274 The security policy protecting Group Key Management Protocol. 276 Group Security Association (GSA) 277 A collection of Data-Security Associations (SAs) and Rekey SAs 278 necessary for a Group Member to receive key updates. A GSA 279 describes the working policy for a group. Refer to [RFC4046] 280 for additional information. 282 Traffic Encryption Key (TEK) 283 The symmetric cipher key used in a Data-Security SA (e.g., 284 IPsec ESP) to protect trafic. 286 Key Encryption Key (KEK) 287 The symmetric cipher key used in a Rekey SA to protect 288 distribution of new keys. 290 Key Wrap Key (KWK) 291 The symmetric cipher key used to protect another key. 293 Group Associated Policy (GAP) 294 Group-wide policy not related to a particular SA. 296 Sender-ID (SID) 297 A unigue identifier of a Group Sender in the context of an 298 active GSA, used to form Initialization Vector (IV) in counter- 299 based cipher modes. 301 Logical Key Hierarchy (LKH) 302 A group management method defined in Section 5.4 of [RFC2627]. 304 2. G-IKEv2 Protocol 306 2.1. G-IKEv2 Integration into IKEv2 Protocol 308 G-IKEv2 is an extension to IKEv2 and uses its security mechanisms 309 (peer authentication, confidentiality, message integrity) to ensure 310 that only authenticated devices have access to the group policy and 311 keys. G-IKEv2 further provides group authorization, and secure 312 policy and key download from the GCKS to GMs. 314 G-IKEv2 is compatible with most IKEv2 extensions defined so far and 315 it is believed that future IKEv2 extensions will also be possible to 316 use with G-IKEv2. However some IKEv2 extensions require special 317 handling if used with G-IKEv2. See Section 6 for more details. 319 It is assumed that readers are familiar with the IKEv2 protocol, so 320 this document skips many details that are described in [RFC7296]. 322 2.1.1. G-IKEv2 Transport and Port 324 G-IKEv2 SHOULD use UDP port 848, the same as GDOI [RFC6407], because 325 they serve a similar function. They can use the same ports, just as 326 IKEv1 and IKEv2 can share port 500. The version number in the IKE 327 header distinguishes the G-IKEv2 protocol from GDOI protocol 328 [RFC6407]. G-IKEv2 MAY also use the IKEv2 ports (500, 4500), which 329 would provide a better integration with IKEv2. G-IKEv2 MAY also use 330 TCP transport for registration (unicast) IKE SA, as defined in 331 [RFC8229]. 333 2.2. G-IKEv2 Payloads 335 In the following descriptions, the payloads contained in the G-IKEv2 336 messages are indicated by names as listed below. 338 Notation Payload 339 ------------------------------------------------------------ 340 AUTH Authentication 341 CERT Certificate 342 CERTREQ Certificate Request 343 D Delete 344 GSA Group Security Association 345 HDR IKEv2 Header 346 IDg Identification - Group 347 IDi Identification - Initiator 348 IDr Identification - Responder 349 KD Key Download 350 KE Key Exchange 351 Ni, Nr Nonce 352 N Notify 353 SA Security Association 354 SAg Security Association - GM Supported Transforms 356 Payloads defined as part of other IKEv2 extensions MAY also be 357 included in these messages. Payloads that may optionally appear in 358 G-IKEv2 messages will be shown in brackets, such as [CERTREQ]. 360 G-IKEv2 defines several new payloads not used in IKEv2: 362 o IDg (Group ID) - The GM requests the GCKS for membership into the 363 group by sending its IDg payload. 365 o GSA (Group Security Association) - The GCKS sends the group policy 366 to the GM using this payload. 368 o KD (Key Download) - The GCKS sends the keys and the security 369 parameters to the GMs using the KD payload. 371 o SAg (Security Association - GM Supported Transforms) - the GM 372 sends supported transforms, so that GCKS may select a policy 373 appropriate for all members of the group. 375 The details of the contents of each payload are described in 376 Section 4. 378 2.3. G-IKEv2 Member Registration and Secure Channel Establishment 380 The registration protocol consists of a minimum of two exchanges, 381 IKE_SA_INIT and GSA_AUTH; member registration may have a few more 382 messages exchanged if the EAP method, cookie challenge (for DoS 383 protection), negotiation of Diffie-Hellman group or IKEv2 extensions 384 based on [I-D.ietf-ipsecme-ikev2-intermediate] are used. Each 385 exchange consists of request/response pairs. The first exchange 386 IKE_SA_INIT is defined in IKEv2 [RFC7296]. This exchange negotiates 387 cryptographic algorithms, exchanges nonces and computes a shared key 388 between the GM and the GCKS. 390 The second exchange GSA_AUTH authenticates the previously exchanged 391 messages, exchanges identities and certificates. The GSA_AUTH 392 messages are encrypted and integrity protected with keys established 393 through the previous exchanges, so the identities are hidden from 394 eavesdroppers and all fields in all the messages are authenticated. 395 The GCKS SHOULD authorize group members to be allowed into the group 396 as part of the GSA_AUTH exchange. Once the GCKS accepts a group 397 member to join a group it will download the data security keys (TEKs) 398 and/or group key encrypting key (KEK) as part of the GSA_AUTH 399 response message. 401 2.3.1. GSA_AUTH exchange 403 After the group member and GCKS negotiate cryptographic algorithms, 404 exchange nonces, and compute shared keys as defined in IKEv2 405 [RFC7296], the GSA_AUTH exchange MUST complete before any other 406 exchanges defined in this document can be done. GSA_AUTH is used to 407 authenticate the previous exchanges, exchange identities and 408 certificates. G-IKEv2 also uses this exchange for group member 409 registration and authorization. 411 The GSA_AUTH exchange is identical to the IKE_AUTH exchange with the 412 difference that its goal is to establish multicast Data-Security SAs 413 and optionally provide GM with the keys for Rekey SA. The set of 414 payloads in the GSA_AUTH exchange is slightly different, because 415 policy is not negotiated between the group member and the GCKS, but 416 instead downloaded from the GCKS to the group member. Note also, 417 that GSA_AUTH has its own exchange type, which is different from the 418 IKE_AUTH exchange type. 420 Nevertheless, the security properties of the GSA_AUTH exchange are 421 the same as the properties of the IKE_AUTH exchange and most IKEv2 422 extensions to the IKE_AUTH exchange (like [RFC6467]) can also be used 423 with the GSA_AUTH exchange. 425 Initiator (Member) Responder (GCKS) 426 -------------------- ------------------ 427 HDR, SK{IDi, [CERT,] [CERTREQ,] [IDr,] 428 AUTH, IDg, [SAg,] [N]} --> 430 Figure 3: GSA_AUTH Request 432 A group member initiates a GSA_AUTH request to join a group indicated 433 by the IDg payload. The GM MAY include an SAg payload declaring 434 which Transforms it is willing to accept. A GM that intends to act 435 as Group Sender SHOULD include a Notify payload status type of 436 SENDER, which enables the GCKS to provide any additional policy 437 necessary by group senders. 439 Initiator (Member) Responder (GCKS) 440 -------------------- ------------------ 441 <-- HDR, SK{IDr, [CERT,] 442 AUTH, [GSA, KD,] [N,]} 444 Figure 4: GSA_AUTH Normal Response 446 The GCKS responds with IDr, optional CERT, and AUTH payloads as if it 447 were an IKE_AUTH. It also informs the group member of the 448 cryptographic policies of the group in the GSA payload and the key 449 material in the KD payload. 451 In addition to the IKEv2 error handling, the GCKS can reject the 452 registration request when the IDg is invalid or authorization fails, 453 etc. In these cases, see Section 4.7, the GSA_AUTH response will not 454 include the GSA and KD, but will include a Notify payload indicating 455 errors. If a GM included an SAg payload, and the GCKS chooses to 456 evaluate it, and the GCKS detects that the group member cannot 457 support the security policy defined for the group, then the GCKS 458 SHOULD return a NO_PROPOSAL_CHOSEN. Other types of error 459 notifications can be INVALID_GROUP_ID, AUTHORIZATION_FAILED or 460 REGISTRATION_FAILED. 462 Initiator (Member) Responder (GCKS) 463 -------------------- ------------------ 464 <-- HDR, SK{IDr, [CERT,] AUTH, N} 466 Figure 5: GSA_AUTH Error Response 468 If the group member finds the policy sent by the GCKS is 469 unacceptable, the member SHOULD initiate GSA_REGISTRATION exchange 470 sending IDg and the Notify NO_PROPOSAL_CHOSEN (see Section 2.3.2)). 472 2.3.2. GSA_REGISTRATION Exchange 474 When a secure channel is already established between a GM and the 475 GCKS, the GM registration for a group can reuse the established 476 secure channel. In this scenario the GM will use the 477 GSA_REGISTRATION exchange. Payloads in the exchange are generated 478 and processed as defined in Section 2.3.1. 480 Initiator (Member) Responder (GCKS) 481 -------------------- ------------------ 482 HDR, SK{IDg, [SAg,][N ]} --> 483 <-- HDR, SK{GSA,] [N,]} 485 Figure 6: GSA_REGISTRATION Normal Exchange 487 As with GSA_AUTH exchange, the GCKS can reject the registration 488 request when the IDg is invalid or authorization fails, or GM cannot 489 support the security policy defined for the group (which can be 490 concluded by GCKS by evaluation of SAg payload). In this case the 491 GCKS returns an appropriate error notification as described in 492 Section 2.3.1. 494 Initiator (Member) Responder (GCKS) 495 -------------------- ------------------ 496 HDR, SK{IDg, [SAg,] [N]} --> 497 <-- HDR, SK{N} 499 Figure 7: GSA_REGISTRATION Error Exchange 501 This exchange can also be used if the group member finds the policy 502 sent by the GCKS is unacceptable. The group member SHOULD notify the 503 GCKS by sending IDg and the Notify type NO_PROPOSAL_CHOSEN, as shown 504 below. The GCKS in this case MUST remove the GM from the group IDg. 506 Initiator (Member) Responder (GCKS) 507 -------------------- ------------------ 508 HDR, SK{IDg, N} --> 509 <-- HDR, SK{} 511 Figure 8: GM Reporting Errors in GSA_REGISTRATION Exchange 513 2.3.3. GM Registration Operations 515 A G-IKEv2 Initiator (GM) requesting registration contacts the GCKS 516 using the IKE_SA_INIT exchange and receives the response from the 517 GCKS. This exchange is unchanged from the IKE_SA_INIT in IKEv2 518 protocol. The IKE_SA_INIT exchange may optionally be followed by one 519 or more the IKE_INTERMEDIATE exchanges if the GM and the GCKS 520 negotiated using IKEv2 extensions based on this exchange. 522 Next the GM sends the GSA_AUTH request message with the IKEv2 523 payloads from IKE_AUTH (without the SAi2, TSi and TSr payloads) along 524 with the Group ID informing the GCKS of the group the initiator 525 wishes to join. An initiator intending to emit data traffic SHOULD 526 send a SENDER Notify payload status. The SENDER notification not 527 only signifies that it is a sender, but provides the initiator the 528 ability to request Sender-ID (SID) values, in case the Data-Security 529 SA supports a counter mode cipher. Section 2.5) includes guidance on 530 requesting Sender-ID values. 532 A GM may be limited in the types of Transforms that it is able or 533 willing to use, and may find it useful to inform the GCKS which 534 Transforms it is willing to accept for different security protocols 535 by including the SAg payload into the request message. Proposals for 536 Rekey SA (with protocol GIKE_REKEY) and for Data-Security (AH 537 [RFC4302] and/or ESP [RFC4303]) SAs may be included into SAg. Each 538 Proposal contains a list of Transforms that the GM is able and 539 willing to support for that protocol. Valid transform types depend 540 on the protocol and are defined in Figure 16. Other transform types 541 SHOULD NOT be included. The SPI length of each Proposal in an SAg is 542 set to zero, and thus the SPI field is empty. The GCKS MUST ignore 543 SPI length and SPI fields in the SAg payload. 545 Generally, a single Proposal of each type will suffice, because the 546 group member is not negotiating Transform sets, simply alerting the 547 GCKS to restrictions it may have. In particular, the restriction 548 from Section 3.3 of [RFC7296] that AEAD and non-AEAD transforms must 549 not be combined in a single proposal doesn't hold when the SAg 550 payload is being formed. However if the GM has restrictions on 551 combination of algorithms, this can be expressed by sending several 552 proposals. 554 Proposal Num field in Proposal substructure is treated specially in 555 SAg payload: it allows a GM to indicate that algorithms used in Rekey 556 SA and in Data-Security (AH and/or ESP) SAs are dependent. In 557 particular, Proposals of different types having the same value in 558 Proposal Num field are treated as a set, so that if GCKS uses 559 transforms from one of such Proposal for one protocol, then it MUST 560 only use transforms from one of the Proposals with the same value in 561 Proposal Num field for other protocols. For example, a GM may 562 support algorithms X and Y for both Rekey and Data-Security SAs, but 563 with a restriction that if X is used in Rekey SA, then only X can be 564 used in Data-Security SAs, and the same for Y. To indicate this the 565 GM sends several Proposals marking those of them that must be used in 566 conjunction by putting the same value in their Proposal Num field. 568 In the simplest case when no dependency between transforms exists, 569 all Proposals in SAg payload will have the same value in Proposal Num 570 field. 572 Although the SAg payload is optional, it is RECOMMENDED for the GM to 573 include this payload into the GSA_AUTH request to allow the GCKS to 574 select an appropriate policy. 576 A GM may also indicate the support for IPcomp by inclusion one or 577 more the IPCOMP_SUPPORTED notifications along with the SAg payload. 578 The CPI in these notifications is set to zero and MUST be ignored by 579 the GCKS. 581 Upon receiving the GSA_AUTH response, the initiator parses the 582 response from the GCKS authenticating the exchange using the IKEv2 583 method, then processes the GSA and KD payloads. 585 The GSA payload contains the security policy and cryptographic 586 protocols used by the group. This policy describes the optional 587 Rekey SA (KEK), Data-security SAs (TEK), and optional Group 588 Associated policy (GAP). If the policy in the GSA payload is not 589 acceptable to the GM, it SHOULD notify the GCKS by initiating a 590 GSA_REGISTRATION exchange with a NO_PROPOSAL_CHOSEN Notify payload 591 (see Section 2.3.2). Note, that this should normally not happen if 592 the GM includes SAg payload in the GSA_AUTH request and the GCKS 593 takes it into account. Finally the KD payload is parsed providing 594 the keying material for the TEK and/or KEK. The GM interprets the KD 595 key packets, where each key packet includes the keying material for 596 SAs distributed in the GSA payload. Keying material is matched by 597 comparing the SPIs in the key packets to SPIs previously included in 598 the GSA payloads. Once TEK keys and policy are matched, the GM 599 provides them to the data security subsystem, and it is ready to send 600 or receive packets matching the TEK policy. 602 The GSA KEK policy MUST include the attribute GSA_INITIAL_MESSAGE_ID 603 with a first Message ID the GM should expect to receive if it is non- 604 zero. The value of the attribute MUST be checked by a GM against any 605 previously received Message ID for this group. If it is less than 606 the previously received number, it should be considered stale and 607 ignored. This could happen if two GSA_AUTH exchanges happened in 608 parallel, and the Message ID changed. This attribute is used by the 609 GM to prevent GSA_REKEY message replay attacks. The first GSA_REKEY 610 message that the GM receives from the GCKS must have a Message ID 611 greater or equal to the Message ID received in the 612 GSA_INITIAL_MESSAGE_ID attribute. 614 Once a GM successfully registers to the group it MUST replace any 615 information related to this group (policy, keys) that it might have 616 as a result of a previous registration with a new one. 618 Once a GM has received GIKE_REKEY policy during a registration the 619 IKE SA may be closed. However, the GM SHOULD NOT close IKE SA, it is 620 the GCKS who makes the decision whether to close or keep it, because 621 depending on the policy the IKE SA may be used for inband rekeying 622 for small groups. If inband rekeying is used, then the initial IKE 623 SA is rekeyed (when necessary) via standard IKEv2 mechanism described 624 in Section 1.3.2 of [RFC7296]. If for some reason this SA is teared 625 down and no GIKE_REKEY policy was received during the registration 626 process, the GM MUST consider itself excluded from the group. To 627 continue participating in the group the GM should re-register. 629 2.3.4. GCKS Registration Operations 631 A G-IKEv2 GCKS passively listens for incoming requests from group 632 members. When the GCKS receives an IKE_SA_INIT request, it selects 633 an IKE proposal and generates a nonce and DH to include them in the 634 IKE_SA_INIT response. 636 Upon receiving the GSA_AUTH request, the GCKS authenticates the group 637 member using the same procedures as in the IKEv2 IKE_AUTH. The GCKS 638 then authorizes the group member according to group policy before 639 preparing to send the GSA_AUTH response. If the GCKS fails to 640 authorize the GM, it will respond with an AUTHORIZATION_FAILED notify 641 message. The GCKS may also respond with an INVALID_GROUP_ID notify 642 message if the requested group is unknown to the GCKS or with an 643 REGISTRATION_FAILED notify message if there is a problem with the 644 requested group (for example the capacity of the group is exceeded). 646 The GSA_AUTH response will include the group policy in the GSA 647 payload and keys in the KD payload. If the GCKS policy includes a 648 group rekey option, it MUST include the GSA_INITIAL_MESSAGE_ID 649 attribute, specifying the starting Message ID the GCKS will use when 650 sending the GSA_REKEY message to the group members if this Message ID 651 is non-zero. This Message ID is used to prevent GSA_REKEY message 652 replay attacks and will be increased each time a GSA_REKEY message is 653 sent to the group. The GCKS data traffic policy is included in the 654 GSA TEK and keys are included in the KD TEK. The GAP MAY also be 655 included to provide the ATD and/or DTD (Section 4.4.3.1) specifying 656 activation and deactivation delays for SAs generated from the TEKs. 657 If the group member has indicated that it is a sender of data traffic 658 and one or more Data Security SAs distributed in the GSA payload 659 included a counter mode of operation, the GCKS responds with one or 660 more SIDs (see Section 2.5). 662 [RFC5374] defines two modes of operation for multicast Data-Securirt 663 SAs: transport mode and tunnel mode with address preservation. In 664 the latter case outer source and destination addresses are taken from 665 the inner IP packet. 667 If the GCKS receives a GSA_REGISTRATION exchange with a request to 668 register a GM to a group, the GCKS will need to authorize the GM with 669 the new group (IDg) and respond with the corresponding group policy 670 and keys. If the GCKS fails to authorize the GM, it will respond 671 with the AUTHORIZATION_FAILED notification. The GCKS may also 672 respond with an INVALID_GROUP_ID or REGISTRATION_FAILED notify 673 messages for the reasons described above. 675 If a group member includes an SAg in its GSA_AUTH or GSA_REGISTRATION 676 request, the GCKS may evaluate it according to an implementation 677 specific policy. 679 o The GCKS could evaluate the list of Transforms and compare it to 680 its current policy for the group. If the group member did not 681 include all of the ESP or AH Transforms that match the current 682 group policy, then the GCKS SHOULD return a NO_PROPOSAL_CHOSEN 683 Notification. 685 o The GCKS could store the list of Transforms, with the goal of 686 migrating the group policy to a different Transforms when all of 687 the group members indicate that they can support that Transforms. 689 o The GCKS could store the list of Transforms and adjust the current 690 group policy based on the capabilities of the devices as long as 691 they fall within the acceptable security policy of the GCKS. 693 Depending on its policy, the GCKS may have no need for the IKE SA 694 (e.g., it does not plan to initiate an GSA_INBAND_REKEY exchange). 695 If the GM does not initiate another registration exchange or Notify 696 (e.g., NO_PROPOSAL_CHOSEN), and also does not close the IKE SA and 697 the GCKS is not intended to use the SA, then after a short period of 698 time the GCKS SHOULD close the IKE SA. 700 2.4. Group Maintenance Channel 702 The GCKS is responsible for rekeying the secure group per the group 703 policy. Rekeying is an operation whereby the GCKS provides 704 replacement TEKs and KEK, deleting TEKs, and/or excluding group 705 members. The GCKS may initiate a rekey message if group membership 706 and/or policy has changed, or if the keys are about to expire. Two 707 forms of group maintenance channels are provided in G-IKEv2 to push 708 new policy to group members. 710 GSA_REKEY The GSA_REKEY is a pseudo-exchange initiated by the GCKS, 711 where the rekey policy is usually delivered to group members using 712 IP multicast as a transport. This is not a real IKEv2 exchange, 713 since no response messages are sent. This method is valuable for 714 large and dynamic groups, and where policy may change frequently 715 and a scalable rekeying method is required. When the GSA_REKEY is 716 used, the IKE SA protecting the member registration exchanges is 717 usually terminated, and group members await policy changes from 718 the GCKS via the GSA_REKEY messages. 720 GSA_INBAND_REKEY The GSA_INBAND_REKEY is a normal IKEv2 exchange 721 using the IKE SA that was setup to protecting the member 722 registration exchange. This exchange allows the GCKS to rekey 723 without using an independent GSA_REKEY pseudo-exchange. The 724 GSA_INBAND_REKEY exchange provides a reliable policy delivery and 725 is useful when G-IKEv2 is used with a small group of cooperating 726 devices. 728 Depending on its policy the GCKS MAY combine these two methods. For 729 example, it may use the GSA_INBAND_REKEY to deliver key to the GMs in 730 the group acting as senders (as this would provide reliable keys 731 delivery), and the GSA_REKEY for the rest GMs. 733 2.4.1. GSA_REKEY 735 The GCKS initiates the G-IKEv2 Rekey securely, usually using IP 736 multicast. Since this rekey does not require a response and it sends 737 to multiple GMs, G-IKEv2 rekeying MUST NOT use IKE SA windowing 738 mechanism, described in Section 2.3 of [RFC7296]. The GCKS rekey 739 message replaces the rekey GSA KEK or KEK array, and/or creates a new 740 Data-Security GSA TEK. The GM_SID attribute in the Key Download 741 payload (defined in Section 4.5.3.3) MUST NOT be part of the Rekey 742 Exchange as this is sender specific information and the Rekey 743 Exchange is group specific. The GCKS initiates the GSA_REKEY pseudo- 744 exchange as following: 746 Members (Responder) GCKS (Initiator) 747 -------------------- ------------------ 748 <-- HDR, SK{GSA, KD, [N,] [D,] [AUTH]} 750 Figure 9: GSA_REKEY Pseudo-Exchange 752 HDR is defined in Section 4.1. The Message ID in this message will 753 start with the value the GCKS sent to the group members in the 754 attribute GSA_INITIAL_MESSAGE_ID or from zero if this attribute 755 wasn't sent. The Message ID will be incremented each time a new 756 GSA_REKEY message is sent to the group members. 758 The GSA payload contains the current policy for rekey and Data- 759 Security SAs. The GSA may contain a new Rekey SA and/or a new Data- 760 Security SAs Section 4.4. 762 The KD payload contains the keys for the policy included in the GSA. 763 If the Data-Security SA is being refreshed in this rekey message, the 764 IPsec keys are updated in the KD, and/or if the rekey SA is being 765 refreshed in this rekey message, the rekey Key or the LKH KEK array 766 is updated in the KD payload. 768 A Delete payload MAY be included to instruct the GM to delete 769 existing SAs. See Section 4.6 for more detail. 771 The AUTH payload MUST be included to authenticate the GSA_REKEY 772 message if the authentication method is based on public key 773 signatures or a dedicated shared secret and MUST NOT be included if 774 authentication is implicit. In a latter case, the fact that a GM can 775 decrypt the GSA_REKEY message and verify its ICV proves that the 776 sender of this message knows the current KEK, thus authenticating 777 that the sender is a member of the group. Shared secret and implicit 778 authentication don't provide source origin authentication. For this 779 reason using implicit authentication for GSA_REKEY is NOT RECOMMENDED 780 unless source origin authentication is not required (for example, in 781 a small group of highly trusted GMs). If AUTH payload is included 782 then the Auth Method field MUST NOT be NULL Authentication. 784 During group member registration, the GCKS sends the authentication 785 key in the KD payload, AUTH_KEY attribute, which the group member 786 uses to authenticate the key server. Before the current 787 Authentication Key expires, the GCKS will send a new AUTH_KEY to the 788 group members in a GSA_REKEY message. The AUTH key that is sent in 789 the rekey message may be not the same as the authentication key sent 790 during the GM registration. If implicit authentication is used, then 791 AUTH_KEY MUST NOT be sent to GMs. 793 2.4.1.1. GSA_REKEY Messages Authentication 795 The content of the AUTH payload depends on the authentication method 796 and is either a digital signature or a result of prf applied to the 797 content of the not yet encrypted GSA_REKEY message. 799 The authentication algorithm (prf or digital signing) is applied to 800 the concatenation of two chunks: A and P. The chunk A lasts from the 801 first octet of the G-IKEv2 header (not including prepended four 802 octets of zeros, if port 4500 is used) to the last octet of the 803 Encrypted Payload header. The chunk P consists of the not yet 804 encrypted content of the Encrypted payload, excluding the 805 Initialization Vector, the Padding, the Pad Length and the Integrity 806 Checksum Data fields (see 3.14 of [RFC7296] for description of the 807 Encrypted payload). In other words, the P chunk is the inner 808 payloads of the Encrypted payload in plaintext form. Figure 10 809 illustrates the layout of the P and A chunks in the GSA_REKEY 810 message. 812 Before the AUTH payload calculation the inner payloads of Encrypted 813 payload must be fully formed and ready for encryption except for the 814 AUTH payload. The AUTH payload must have correct values in the 815 Payload Header, the Auth Method and the RESERVED fields. The 816 Authentication Data field is zeroed, but if Digital Signature 817 authentication method is in use, then the ASN.1 Length and the 818 AlgorithmIdentifier fields must be properly filled in, see [RFC7427]. 820 For the purpose of the AUTH payload calculation the Length field in 821 the IKE header and the Payload Length field in the Encrypted Payload 822 header are adjusted so that they don't count the lengths of 823 Initialization Vector, Integrity Checksum Data and Padding (along 824 with Pad Length field). In other words, the Length field in the IKE 825 header (denoted as AdjustedLen in Figure 10 ) is set to the sum of 826 the lengths of A and P, and the Payload Length field in the Encrypted 827 Payload header (denoted as AdjustedPldLen in Figure 10) is set to the 828 length of P plus the size of the Payload header (four octets). 830 DataToAuthenticate = A | P 831 GsaRekeyMessage = GenIKEHDR | EncPayload 832 GenIKEHDR = [ four octets 0 if using port 4500 ] | AdjustedIKEHDR 833 AdjustedIKEHDR = SPIi | SPIr | . . . | AdjustedLen 834 EncPayload = AdjustedEncPldHdr | IV | InnerPlds | Pad | PadLen | ICV 835 AdjustedEncPldHdr = NextPld | C | RESERVED | AdjustedPldLen 836 A = AdjustedIKEHDR | AdjustedEncPldHdr 837 P = InnerPlds 838 1 2 3 839 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 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^ 841 | G-IKEv2 SA Initiator's SPI | | | 842 | | | | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I | 844 | G-IKEv2 SA Responder's SPI | K | 845 | | E | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 847 | Next Payload | MjVer | MnVer | Exchange Type | Flags | H A 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | 849 | Message ID | r | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 851 | AdjustedLen | | | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ x | 853 | Next Payload |C| RESERVED | AdjustedPldLen | | | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v 855 | | | 856 ~ Initialization Vector ~ E 857 | | n 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^ 859 | | r | 860 ~ Inner payloads (not yet encrypted) ~ P 861 | | P | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v 863 ~ Padding (0-255 octets) | Pad Length | d 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 865 | | | 866 ~ Integrity Checksum Data ~ | 867 | | | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 870 Figure 10: Data to Authenticate in the GSA_REKEY Messages 872 The authentication data is calculated using the authentication 873 algorithm from the Authentication Method transform and the current 874 authentication key provided in the AUTH_KEY attribute. Depending on 875 the authentication method the authentication data is a digital 876 signature or a result of applying prf from the Pseudorandom Function 877 transform. The calculated authentication data is placed into the 878 AUTH payload, the Length fields in the IKE Header and the Encryption 879 Payload header are restored, the content of the Encrypted payload is 880 encrypted and the ICV is computed using the current KEK keys. 882 2.4.1.2. IKE Fragmentation 884 IKE fragmentation [RFC7383] can be used to perform fragmentation of 885 large GSA_REKEY messages, however when the GSA_REKEY message is 886 emitted as an IP multicast packet there is a lack of response from 887 the GMs. This has the following implications. 889 o Policy regarding the use of IKE fragmentation is implicit. If a 890 GCKS detects that all GMs have negotiated support of IKE 891 fragmentation in IKE_SA_INIT, then it MAY use IKE fragmentation on 892 large GSA_REKEY messages. 894 o The GCKS must always use IKE fragmentation based on a known 895 fragmentation threshold (unspecified in this memo), as there is no 896 way to check if fragmentation is needed by first sending 897 unfragmented messages and waiting for response. 899 o PMTU probing cannot be performed due to lack of GSA_REKEY response 900 message. 902 The calculation of authentication data MUST be applied to whole 903 messages only, before possible IKE Fragmentation. If the message was 904 received in fragmented form, it should be reconstructed before 905 verifying its authenticity as if it were received unfragmented. The 906 RESERVED field in the reconstructed Encrypted Payload header MUST be 907 set to the value of the RESERVED field in the Encrypted Fragment 908 payload header from the first fragment (that with Fragment Number 909 equal to 1). 911 2.4.1.3. GSA_REKEY GCKS Operations 913 The GCKS builds the rekey message with a Message ID value that is one 914 greater than the value included in the previous rekey message. The 915 first message sent over a new Rekey SA must have the Message ID 0. 916 The GSA, KD, N and D payloads follow with the same characteristics as 917 in the GSA Registration exchange. The AUTH payload (if present) is 918 created as defined in Section 2.4.1.1. 920 Because GSA_REKEY messages are not acknowledged and could be 921 discarded by the network, one or more GMs may not receive the new 922 policy. To mitigate such lost messages, during a rekey event the 923 GCKS may transmit several GSA_REKEY messages with the new policy. 924 The retransmitted messages MUST be bitwise identical and SHOULD be 925 sent within a short time interval (a few seconds) to ensure that 926 time-to-live would not be substantially skewed for the GMs that would 927 receive different copies of the messages. 929 GCKS may also include one or several GSA_NEXT_SPI attributes 930 specifying SPIs for the prospected rekeys, so that listening GMs are 931 able to detect lost rekey messages and recover from this situation. 932 See Sections Section 4.4.2.2.3 for more detail. 934 2.4.1.4. GSA_REKEY GM Operations 936 When a group member receives the Rekey Message from the GCKS it 937 decrypts the message using the current KEK, validates its 938 authenticity using the key retrieved in a previous G-IKEv2 exchange 939 if AUTH payload is present, verifies the Message ID, and processes 940 the GSA and KD payloads. The group member then downloads the new 941 Data-Security SA and/or new Rekey SA. The parsing of the payloads is 942 identical to the parsing done in the registration exchange. 944 Replay protection is achieved by a group member rejecting a GSA_REKEY 945 message which has a Message ID smaller than the current Message ID 946 that the GM is expecting. The GM expects the Message ID in the first 947 GSA_REKEY message it receives to be equal or greater than the Message 948 ID it receives in the GSA_INITIAL_MESSAGE_ID attribute. Note, that 949 if no this attribute was received for the Rekey SA, the GM MUST 950 assume zero as the first expected Message ID. The GM expects the 951 Message ID in subsequent GSA_REKEY messages to be greater than the 952 last valid GSA_REKEY message ID it received. 954 If the GSA payload includes a Data-Security SA using cipher in a 955 counter-modes of operation and the receiving group member is a sender 956 for that SA, the group member uses its current SID value with the 957 Data-Security SAs to create counter-mode nonces. If it is a sender 958 and does not hold a current SID value, it MUST NOT install the Data- 959 Security SAs. It MAY initiate a GSA_REGISTRATION exchange to the 960 GCKS in order to obtain an SID value (along with the current group 961 policy). 963 Once a new Rekey SA is installed as a result of GSA_REKEY message, 964 the current Rekey SA (over which the message was received) MUST be 965 silently deleted after waiting DEACTIVATION_TIME_DELAY interval 966 regardless of its expiration time. If the message includes Delete 967 payload for existing Data-security SA, then after installing a new 968 Data-Security SA the old one, identified by the Protocol and SPI 969 fields in the Delete payload, MUST be silently deleted after waiting 970 DEACTIVATION_TIME_DELAY interval regardless of its expiration time. 972 If a Data-Security SA is not rekeyed yet and is about to expire (a 973 "soft lifetime" expiration is described in Section 4.4.2.1 of 974 [RFC4301]), the GM SHOULD initiate a registration to the GCKS. This 975 registration serves as a request for current SAs, and will result in 976 the download of replacement SAs, assuming the GCKS policy has created 977 them. A GM SHOULD also initiate a registration request if a Rekey SA 978 is about to expire and not yet replaced with a new one. 980 2.4.2. GSA_INBAND_REKEY Exchange 982 When the IKE SA protecting the member registration exchange is 983 maintained while group member participates in the group, the GCKS can 984 use the GSA_INBAND_REKEY exchange to individually provide policy 985 updates to the group member. 987 Member (Responder) GCKS (Initiator) 988 -------------------- ------------------ 989 <-- HDR, SK{GSA, KD, [N,] [D]} 990 HDR, SK{} --> 992 Figure 11: GSA_INBAND_REKEY Exchange 994 Because this is a normal IKEv2 exchange, the HDR is treated as 995 defined in [RFC7296]. 997 2.4.2.1. GSA_INBAND_REKEY GCKS Operations 999 The GSA, KD, N and D payloads are built in the same manner as in a 1000 registration exchange. 1002 2.4.2.2. GSA_INBAND_REKEY GM Operations 1004 The GM processes the GSA, KD, N and D payloads in the same manner as 1005 if they were received in a registration exchange. 1007 2.4.3. Deletion of SAs 1009 There are occasions when the GCKS may want to signal to group members 1010 to delete policy at the end of a broadcast, or if group policy has 1011 changed. Deletion of SAs is accomplished by sending the G-IKEv2 1012 Delete Payload [RFC7296], section 3.11 as part of the GSA_REKEY 1013 pseudo-exchange as shown below. 1015 Members (Responder) GCKS (Initiator) 1016 -------------------- ------------------ 1017 <-- HDR, SK{[GSA,] [KD,] [N,] [D,] [AUTH]} 1019 Figure 12: SA Deletion in GSA_REKEY 1021 If GCKS has a unicast SA with group member then it can use the 1022 GSA_INBAND_REKEY exchange to delete SAs. 1024 Member (Responder) GCKS (Initiator) 1025 -------------------- ------------------ 1026 <-- HDR, SK{[GSA,] [KD,] [N,] [D,]} 1027 HDR, SK{} --> 1029 Figure 13: SA Deletion in GSA_INBAND_REKEY 1031 The GCKS MAY specify the remaining active time of the policy by using 1032 the GAP_DTD attribute in the GSA GAP substructure. If a GCKS has no 1033 further SAs to send to group members, the GSA and KD payloads MUST be 1034 omitted from the message. 1036 There may be circumstances where the GCKS may want to start over with 1037 a clean state, for example in case it runs out of available SIDs. 1038 The GCKS can signal deletion of all the Data-security SAs by sending 1039 a Delete payload with an SPI value equal to zero. For example, if 1040 the GCKS wishes to remove the Rekey SA and all the Data-security SAs, 1041 the GCKS sends a Delete payload with an SPI of zero and Protocol ID 1042 of AH or ESP, followed by another Delete payload with a SPI of zero 1043 and Protocol ID of GIKE_REKEY. 1045 If a group member receives a Delete payload with zero SPI and 1046 protocol ID of GIKE_REKEY either via multicast Rekey SA or via 1047 unicast SA using the GSA_INBAND_REKEY exchange, it means that the 1048 group member is excluded from the group. The group member MUST re- 1049 register if it wants to continue participating in this group. The 1050 registration is performed as described in Section 2.3. Note, that if 1051 the GSA_INBAND_REKEY exchange is used to exclude a group member from 1052 the group, and thus the unicast SA between the group member and the 1053 GCKS exists, then this SA persists after this exchange and the group 1054 member may use the GSA_REGISTRATION exchange to re-register. 1056 2.5. Counter-based modes of operation 1058 Several counter-based modes of operation have been specified for ESP 1059 (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES-CCM [RFC4309], 1060 ChaCha20-Poly1305 [RFC7634], AES-GMAC [RFC4543]) and AH (e.g., AES- 1061 GMAC [RFC4543]). These counter-based modes require that no two 1062 senders in the group ever send a packet with the same Initialization 1063 Vector (IV) using the same cipher key and mode. This requirement is 1064 met in G-IKEv2 when the following requirements are met: 1066 o The GCKS distributes a unique key for each Data-Security SA. 1068 o The GCKS uses the method described in [RFC6054], which assigns 1069 each sender a portion of the IV space by provisioning each sender 1070 with one or more unique SID values. 1072 2.5.1. Allocation of SIDs 1074 When at least one Data-Security SA included in the group policy 1075 includes a counter-based mode of operation, the GCKS automatically 1076 allocates and distributes one SID to each group member acting in the 1077 role of sender on the Data-Security SA. The SID value is used 1078 exclusively by the group sender to which it was allocated. The group 1079 sender uses the same SID for each Data-Security SA specifying the use 1080 of a counter-based mode of operation. A GCKS MUST distribute unique 1081 keys for each Data-Security SA including a counter-based mode of 1082 operation in order to maintain unique key and nonce usage. 1084 During registration, the group sender can choose to request one or 1085 more SID values. Requesting a value of 1 is not necessary since the 1086 GCKS will automatically allocate exactly one to the group sender. A 1087 group sender MUST request as many SIDs matching the number of 1088 encryption modules in which it will be installing the TEKs in the 1089 outbound direction. Alternatively, a group sender MAY request more 1090 than one SID and use them serially. This could be useful when it is 1091 anticipated that the group sender will exhaust their range of Data- 1092 Security SA nonces using a single SID too quickly (e.g., before the 1093 time-based policy in the TEK expires). 1095 When the group policy includes a counter-based mode of operation, a 1096 GCKS SHOULD use the following method to allocate SID values, which 1097 ensures that each SID will be allocated to just one group sender. 1099 1. A GCKS maintains an SID-counter, which records the SIDs that have 1100 been allocated. SIDs are allocated sequentially, with zero as 1101 the first allocated SID. 1103 2. Each time an SID is allocated, the current value of the counter 1104 is saved and allocated to the group sender. The SID-counter is 1105 then incremented in preparation for the next allocation. 1107 3. When the GCKS specifies a counter-based mode of operation in the 1108 Data-Security SA a group sender may request a count of SIDs 1109 during registration in a Notify payload information of type 1110 SENDER. When the GCKS receives this request, it increments the 1111 SID-counter once for each requested SID, and distributes each SID 1112 value to the group sender. The GCKS SHOULD have a policy-defined 1113 upper bound for the number of SIDs that it will return 1114 irrespective of the number requested by the GM. 1116 4. A GCKS allocates new SID values for each registration operation 1117 by a group sender, regardless of whether the group sender had 1118 previously contacted the GCKS. In this way, the GCKS is not 1119 required to maintaining a record of which SID values it had 1120 previously allocated to each group sender. More importantly, 1121 since the GCKS cannot reliably detect whether the group sender 1122 had sent data on the current group Data-Security SAs it does not 1123 know what Data-Security counter-mode nonce values that a group 1124 sender has used. By distributing new SID values, the key server 1125 ensures that each time a conforming group sender installs a Data- 1126 Security SA it will use a unique set of counter-based mode 1127 nonces. 1129 5. When the SID-counter maintained by the GCKS reaches its final SID 1130 value, no more SID values can be distributed. Before 1131 distributing any new SID values, the GCKS MUST exclude all group 1132 members from the group as described in Section 2.4.3. This will 1133 result in the group members performing re-registration, during 1134 which they will receive new Data-Security SAs and group senders 1135 will additionally receive new SID values. The new SID values can 1136 safely be used because they are only used with the new Data- 1137 Security SAs. 1139 2.5.2. GM Usage of SIDs 1141 A GM applies the SID to Data-Security SA as follows. 1143 o The most significant bits NUMBER_OF_SID_BITS of the IV are taken 1144 to be the SID field of the IV. 1146 o The SID is placed in the least significant bits of the SID field, 1147 where any unused most significant bits are set to zero. If the 1148 SID value doesn't fit into the NUMBER_OF_SID_BITS bits, then the 1149 GM MUST treat this as a fatal error and re-register to the group. 1151 3. Group Key Management and Access Control 1153 Through the G-IKEv2 rekey, G-IKEv2 supports algorithms such as 1154 Logical Key Hierarchy (LKH) that have the property of denying access 1155 to a new group key by a member removed from the group (forward access 1156 control) and to an old group key by a member added to the group 1157 (backward access control). An unrelated notion to PFS, "forward 1158 access control" and "backward access control" have been called 1159 "perfect forward security" and "perfect backward security" in the 1160 literature [RFC2627]. 1162 Group management algorithms providing forward and backward access 1163 control other than LKH have been proposed in the literature, 1164 including OFT [OFT] and Subset Difference [NNL]. These algorithms 1165 could be used with G-IKEv2, but are not specified as a part of this 1166 document. 1168 The Group Key Management Method transform from the GSA policy 1169 specifies how members of the group obtain group keys. This document 1170 specifies a single method for the group key management - Wrapped Key 1171 Download. This method assumes that all group keys are sent to the 1172 GMs by the GCKS encrypted with some other keys, called Key Wrap Keys 1173 (KWK). 1175 3.1. Key Wrap Keys 1177 Every GM always knows at least one KWK - the KWK that is associated 1178 with the IKE SA or multicast Rekey SA the wrapped keys are sent over. 1179 In this document it is called default KWK and is denoted as GSK_w. 1181 The GCKS may also send other keys to GMs that will be used as Key 1182 Wrap Keys for the purpose of building key hierarchy. Each KWK is 1183 associated with an encryption algorithm from the Encryption Algorithm 1184 transform used for the SA the key is sent over. The size of a KWK 1185 MUST be of the size of the key for this Encryption Algorithm 1186 transform (taking into consideration the Key Length attribute for 1187 this transform if present). This association persists even if the 1188 key is used later in the context of another SA with possibly 1189 different Encryption Algorithm transform. 1191 To have an ability to provide forward access control the GCKS 1192 provides each GM with a personal key at the time of registration. 1193 Besides, several intermediate keys that form a key hierarchy and are 1194 shared among several GMs may be provided by the GCKS. 1196 3.1.1. Default Key Wrap Key 1198 The default KWK (GSK_w) is only used in the context of a single IKE 1199 SA. Every IKE SA (unicast IKE SA or multicast Rekey SA) will have 1200 its own GSK_w. The GSK_w is used with the algorithm from the 1201 Encryption Algorithm transform for the SA the GSK_w is used in the 1202 context of. The size of GSK_w MUST be of the key size of this 1203 Encryption Algorithm transform (taking into consideration the Key 1204 Length attribute for this transform if present). 1206 For the unicast IKE SA (used for the GM registration and for the 1207 GSA_INBAND_REKEY exchanges, if they are take place) the GSK_w is 1208 computed as follows: 1210 GSK_w = prf+(SK_d, "Key Wrap for G-IKEv2") 1212 where the string "Key Wrap for G-IKEv2" is 20 ASCII characters 1213 without null termination. 1215 For the multicast Rekey SA the GSK_w is provided along with other SA 1216 keys as defined in Section 3.4. 1218 3.2. GCKS Key Management Semantics 1220 Wrapped Key Download method allows the GCKS to employ various key 1221 management methods 1223 o A simple key management methods - when the GCKS always sends group 1224 SA keys encrypted with the GSK_w. 1226 o An LKH key management method - when the GCKS provides each GM with 1227 an individual key at the time of the GM registration (encrypted 1228 with GSK_w). Then the GCKS forms an hierarchy of keys so that the 1229 group SA keys are encrypted with other keys which are encrypted 1230 with other keys and so on, tracing back to the individual GMs' 1231 keys. 1233 Other key policies may also be employed by the GCKS. 1235 3.2.1. Forward Access Control Requirements 1237 When group membership is altered using a group management algorithm 1238 new Data-Security SAs and their associated keys are usually also 1239 needed. New Data-Security SAs and keys ensure that members who were 1240 denied access can no longer participate in the group. 1242 If forward access control is a desired property of the group, new TEK 1243 policy and the associated keys MUST NOT be included in a G-IKEv2 1244 rekey message which changes group membership. This is required 1245 because the GSA TEK policy and the associated keys are not protected 1246 with the new KEK. A second G-IKEv2 rekey message can deliver the new 1247 GSA TEKS and their associated keys because it will be protected with 1248 the new KEK, and thus will not be visible to the members who were 1249 denied access. 1251 If forward access control policy for the group includes keeping group 1252 policy changes from members that are denied access to the group, then 1253 two sequential G-IKEv2 rekey messages changing the group KEK MUST be 1254 sent by the GCKS. The first G-IKEv2 rekey message creates a new KEK 1255 for the group. Group members, which are denied access, will not be 1256 able to access the new KEK, but will see the group policy since the 1257 G-IKEv2 rekey message is protected under the current KEK. A 1258 subsequent G-IKEv2 rekey message containing the changed group policy 1259 and again changing the KEK allows complete forward access control. A 1260 G-IKEv2 rekey message MUST NOT change the policy without creating a 1261 new KEK. 1263 If other methods of using LKH or other group management algorithms 1264 are added to G-IKEv2, those methods MAY remove the above restrictions 1265 requiring multiple G-IKEv2 rekey messages, providing those methods 1266 specify how the forward access control policy is maintained within a 1267 single G-IKEv2 rekey message. 1269 3.3. GM Key Management Semantics 1271 This specification defines a GM Key Management semantics in such a 1272 way, that it doesn't depend on the key management method employed by 1273 the GCKS. This allows having all the complexity of key management in 1274 the GCKS, which is free to implement various key management methods, 1275 such as direct transmitting of group SA keys or using some kind of 1276 key hierarchy (e.g. LKH). For all these policies the GM behavior is 1277 the same. 1279 Each key that a GM receives in G-IKEv2 is identified by a 32-bit 1280 number called Key ID. Zero Key ID has a special meaning - it always 1281 contains keying material from which the keys for protecting Data- 1282 Security SAs and Rekey SA are taken. 1284 All keys in G-IKEv2 are transmitted in encrypted form, as specified 1285 in Section 4.5.1. This format includes a Key ID (ID of a key that is 1286 encrypted) and a KWK ID (ID of a key that was used to encrypt this 1287 key). Keys may be encrypted either with default KWK (GSK_w) or with 1288 other keys, which the GM has received in the WRAP_KEY attributes. If 1289 a key was encrypted with GSK_w, then the KWK ID field is set to zero, 1290 otherwise the KWK ID field identifies the key used for encryption. 1292 When a GM receives a message from the GCKS installing new Data- 1293 Security or Rekey SA, it will contain a KD payload with an SA_KEY 1294 attribute containing keying material for this SA. For a Data- 1295 Security SA exactly one SA_KEY attribute will be present with both 1296 Key ID and KWK ID fields set to zero. This means that the default 1297 KWK (GSK_w) should be used to extract this keying material. 1299 For a multicast Rekey SA multiple SA_KEY attributes may be present 1300 depending on the key management method employed by the GCKS. If 1301 multiple SA_KEY attributes are present then all of them MUST contain 1302 the same keying material encrypted using different KWKs. The GM in 1303 general is unaware of the GCKS's key management method and can always 1304 use the same procedure to get the keys. In particular, the GM's task 1305 is to find a way to decrypt at least one of the SA_KEY attributes 1306 using either the GSK_w or the keys from the WRAP_KEY attributes that 1307 are present in the same message or were receives in previous 1308 messages. 1310 We will use the term "Key Path" to describe an ordered sequence of 1311 keys where each subsequent key was used to encrypt the previous one. 1312 The GM keeps its own Key Path (called Working Key Path) in the memory 1313 associated with each group it is registered to and updates it when 1314 needed. When the GSA_REKEY message is received the GM processes the 1315 received SA_KEY attributes one by one trying to construct a new key 1316 path that starts from this attributes and ends with any key in the 1317 Working Key Path or with the default KWK (GSK_w). 1319 In the simplest case the SA_KEY attribute is encrypted with GSK_w so 1320 that the new Key Path is empty. If more complex key management 1321 methods are used then a Key Path will contain intermediate keys from 1322 the WRAP_KEY attributes received by a GM so far starting from its 1323 registration to the group. If the GM is able to construct a new Key 1324 Path using intermediate keys it has, then it is able to decrypt the 1325 SA_KEY attribute and use its content to form new SA keys. If it is 1326 unable to build a new Key Path, then in means that the GM is excluded 1327 from the group. 1329 Depending on the new Key Path the GM should do the following actions 1330 to be prepared for future key updates: 1332 o If the new Key Path is empty then no actions are needed. This may 1333 happen if no WRAP_KEY attributes from the received message were 1334 used. 1336 o If the new Key Path is non-empty and it ends with the default KWK 1337 (GSK_w), then the whole new Key Path is stored by the GM as the 1338 GM's Working Key Path. This situation may only happen at the time 1339 the GM is registering to the group, when the GCKS is providing it 1340 with its personal key and the other keys from the key tree that 1341 are needed for this GM. These keys form an initial Working Key 1342 Path for this GM. 1344 o In all other cases the new Key Path will end at some intermediate 1345 key from the GM's current Working Key Path. In this case the new 1346 Key Path is constructed by replacing a part of the GM's current 1347 Working Key Path from the beginning and up to (but not including) 1348 the key that the GM has used to decrypt the last key in the new 1349 Key Path. 1351 Appendix A contains an example of how this algorithm works in case of 1352 LKH key management method. 1354 3.4. SA Keys 1356 Keys used for Data-Security SAs or Rekey SA (called here SA keys) are 1357 downloaded to GMs in the form of keying material. The keys for each 1358 algorithm employed in an SA are taken from this keying material as if 1359 they were concatenated to form it. 1361 For a Data-Security SA the keys are taken in accordance to the third 1362 bullet from Section 2.17 of [RFC7296]. In particular, for the ESP 1363 and AH SAs the encryption key (if any) MUST be taken from the first 1364 bits of the keying material and the integrity key (if any) MUST be 1365 taken from the remaining bits. 1367 For a Rekey SA the following keys are taken from the keying material: 1369 GSK_e | GSK_a | GSK_w = KEYMAT 1371 where GSK_e and GSK_a are the keys used for the Encryption Algorithm 1372 and the Integrity Algorithm transforms for the corresponding SA and 1373 GSK_w is a default KWK for this SA. Note, that GSK_w is also used 1374 with the Encryption Algorithm transform as well as GSK_e. If an AEAD 1375 algorithm is used for encryption, then SK_a key will not be used (GM 1376 can use the formula above assuming the length of SK_a is zero). 1378 4. Header and Payload Formats 1380 The G-IKEv2 is an IKEv2 extension and thus inherits its wire format 1381 for data structures. However, the processing of some payloads are 1382 different and several new payloads are defined: Group Identification 1383 (IDg), Group Security Association (GSA) Key Download (KD). New 1384 exchange types GSA_AUTH, GSA_REGISTRATION, GSA_REKEY and 1385 GSA_INBAND_REKEY are also added. 1387 This section describes new payloads and the differences in processing 1388 of existing IKEv2 payloads. 1390 4.1. G-IKEv2 Header 1392 G-IKEv2 uses the same IKE header format as specified in [RFC7296] 1393 section 3.1. Major Version is 2 and Minor Version is 0 as in IKEv2. 1394 IKE SA Initiator's SPI, IKE SA Responder's SPI, Flags, Message ID, 1395 and Length are as specified in [RFC7296]. 1397 4.2. Group Identification Payload 1399 The Group Identification (IDg) payload allows the group member to 1400 indicate which group it wants to join. The payload is constructed by 1401 using the IKEv2 Identification Payload (section 3.5 of [RFC7296]). 1403 ID type ID_KEY_ID MUST be supported. ID types ID_IPV4_ADDR, ID_FQDN, 1404 ID_RFC822_ADDR, ID_IPV6_ADDR SHOULD be supported. ID types 1405 ID_DER_ASN1_DN and ID_DER_ASN1_GN are not expected to be used. The 1406 Payload Type for the Group Identification payload is fifty (50). 1408 4.3. Security Association - GM Supported Transforms Payload 1410 The Security Association - GM Supported Transforms Payload (SAg) 1411 payload declares which Transforms a GM is willing to accept. The 1412 payload is constructed using the format of the IKEv2 Security 1413 Association payload (section 3.3 of [RFC7296]). The Payload Type for 1414 SAg is identical to the SA Payload Type - thirty-three (33). 1416 4.4. Group Security Association Payload 1418 The Group Security Association (GSA) payload is used by the GCKS to 1419 assert security attributes for both Rekey SA and Data-security SAs. 1420 The Payload Type for the Group Security Association payload is fifty- 1421 one (51). 1423 1 2 3 1424 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 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 | Next Payload |C| RESERVED | Payload Length | 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 | | 1429 ~ ~ 1430 | | 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 Figure 14: GSA Payload Format 1435 The Security Association Payload fields are defined as follows: 1437 o Next Payload, C, RESERVED, Payload Length fields comprise the 1438 IKEv2 Generic Payload Header and are defined in Section 3.2. of 1439 [RFC7296]. 1441 o Group Policies (variable) - A set of group policies for the group. 1443 4.4.1. Group Policies 1445 Croup policies are comprised of two types of policy - Group SA (GSA) 1446 policy and Group Associated (GA) policy. GSA policy defines 1447 parameters for the Security Association for the group. Depending on 1448 the employed security protocol GSA policies may further be classified 1449 as Rekey SA policy (GSA KEK) and Data-Security SA policy (GSA TEK). 1451 GSA payload may contain zero or one GSA KEK policy, zero or more GSA 1452 TEK policies, and zero or one GA policy, where either one GSA KEK or 1453 GSA TEK policy MUST be present. 1455 This latitude allows various group policies to be accommodated. For 1456 example if the group policy does not require the use of a Rekey SA, 1457 the GCKS would not need to send a GSA KEK policy to the group member 1458 since all SA updates would be performed using the GSA_INBAND_REKEY 1459 exchange via the unicast IKE SA. Alternatively, group policy might 1460 use a Rekey SA but choose to download a KEK to the group member only 1461 as part of the unicast IKE SA. Therefore, the GSA KEK policy would 1462 not be necessary as part of the GSA_REKEY message. 1464 Specifying multiple GSA TEKs allows multiple related data streams 1465 (e.g., video, audio, and text) to be associated with a session, but 1466 each protected with an individual security association policy. 1468 A GAP allows for the distribution of group-wise policy, such as 1469 instructions for when to activate and de-activate SAs. 1471 Policies are distributed in substructures to the GSA payload. The 1472 format of the substructures is defined below in Section 4.4.2 (for 1473 GSA policy) and in Section 4.4.3 (for GA policy). The first octet of 1474 the substructure unambiguously determines its type - it is zero for 1475 GAP and non-zero (actually, it is a security protocol ID) for GSA 1476 policies. 1478 4.4.2. Group Security Association Policy Substructure 1480 The GSA policy substructure contains parameters for the SA used with 1481 this group. Depending on the security protocol the SA is either a 1482 Rekey SA or a Data-Security SA (ESP and AH). It is NOT RECOMMENDED 1483 that the GCKS distribute both ESP and AH policies for the same set of 1484 Traffic Selectors. 1486 1 2 3 1487 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 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | Protocol | SPI Size | Length | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | | 1492 ~ SPI ~ 1493 | | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | | 1496 ~ Source Traffic Selector ~ 1497 | | 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 | | 1500 ~ Destination Traffic Selector ~ 1501 | | 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | | 1504 ~ ~ 1505 | | 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 | | 1508 ~ ~ 1509 | | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1512 Figure 15: GSA Policy Substructure Format 1514 The GSA policy fields are defined as follows: 1516 o Protocol (1 octet) - Identifies the security protocol for this 1517 group SA. The values are defined in the IKEv2 Security Protocol 1518 Identifiers in [IKEV2-IANA]. The valid values for this field are: 1519 (GIKE_REKEY) for Rekey SA and 2 (AH) or 3 (ESP) for Data- 1520 Security SAs. 1522 o SPI Size (1 octet) - Size of Security Parameter Index (SPI) for 1523 the SA. SPI size depends on the SA protocol. For GIKE_REKEY it 1524 is 16 octets, while for AH and ESP it is 4 octets. 1526 o Length (2 octets, unsigned integer) - Length of this substructure 1527 including the header. 1529 o SPI (variable) - Security Parameter Index for the group SA. The 1530 size of this field is determined by the SPI Size field. As 1531 described above, these SPIs are assigned by the GCKS. In case of 1532 GIKE_REKEY the SPI must be the IKEv2 Header SPI pair where the 1533 first 8 octets become the "Initiator's SPI" field in the G-IKEv2 1534 rekey message IKEv2 HDR, and the second 8 octets become the 1535 "Responder's SPI" in the same HDR. When selecting SPI the GCKS 1536 MUST make sure that the sole first 8 octets (corresponding to 1537 "Initiator's SPI" field in the IKEv2 header) uniquely identify the 1538 Rekey SA. 1540 o Source & Destination Traffic Selectors - (variable) - 1541 Substructures describing the source and destination of the network 1542 identities. The format for these substructures is defined in 1543 IKEv2 [RFC7296], section 3.13.1. For the Rekey SA (with protocol 1544 GIKE_REKEY) the destination traffic selectors MUST define a single 1545 multicast IP address, IP protocol and port the GSA_REKEY messages 1546 will be destined to. The source traffic selector in this case 1547 MUST either define a single IP address, IP protocol and port the 1548 GSA_REKEY messages will be originated from or be a wildcard 1549 selector. For the Data-Security (AH and ESP) SAs the destination 1550 traffic selectors SHOULD define a single multicast IP address. 1551 The source traffic selector in this case SHOULD define a single IP 1552 address or be a wildcard selector. IP protocol and ports define 1553 the characteristics of traffic protected by this Data-Security SA. 1555 o GSA Transforms (variable) - A list of Transform Substructures 1556 specifies the policy information for the SA. The format is 1557 defined in IKEv2 [RFC7296], section 3.3.2. The Last Substruc 1558 value in each Transform Substructure will be set to 3 except for 1559 the last one in the list, which is set to 0. Section 4.4.2.1 1560 describes using IKEv2 transforms in GSA policy substructure. 1562 o GSA Attributes (variable) - Contains policy attributes associated 1563 with the group SA. The following sections describe the possible 1564 attributes. Any or all attributes may be optional, depending on 1565 the protocol and the group policy. Section 4.4.2.2 defines 1566 attributes used in GSA policy substructure. 1568 4.4.2.1. GSA Transforms 1570 GSA policy is defined by means of transforms in the GSA policy 1571 substructure. For this purpose the transforms defined in [RFC7296] 1572 are used. In addition, new transform types are defined for using in 1573 G-IKEv2: Authentication Method (AUTH) and Group Key Management Method 1574 (GKM), see Section 8. 1576 Valid Transform Types depend on the SA protocol and are summarized in 1577 the table below. 1579 Protocol Mandatory Types Optional Types 1580 ------------------------------------------------------------ 1581 GIKE_REKEY ENCR, INTEG*, PRF, AUTH**, GKM** 1582 ESP ENCR INTEG, ESN 1583 AH INTEG ESN 1585 Figure 16: Valid Transform Types 1587 (*) If AEAD encryption algorithm is used, then INTEG transform MUST 1588 NOT be specified, otherwise it MUST be specified. 1590 (**) May only appear at the time of a GM registration, (in the 1591 GSA_aUTH and GSA_REGISTRATION exchanges). 1593 4.4.2.1.1. Authentication Method Transform 1595 The Authentication Method (AUTH) transform is used in the GIKE_REKEY 1596 policy to convey information of how GCKS will authenticate the 1597 GSA_REKEY messages. This values are from the IKEv2 Authentication 1598 Method registry [IKEV2-IANA]. Note, that this registry defines only 1599 values in a range 0-255, so even that Transform ID field in the 1600 Transform substructure allows for 65536 possible values, in case of 1601 the Authentication Method transform the values 256-65535 MUST NOT 1602 appear. 1604 Among the currently defined authentication methods in the IKEv2 1605 Authentication Method registry, only the following are allowed to be 1606 used in the Authentication Method transform: Shared Key Message 1607 Integrity Code, NULL Authentication and Digital Signature. Other 1608 currently defined authentication methods MUST NOT be used. The 1609 following semantics is associated with each of the allowed methods. 1611 Shared Key Message Integrity Code - GCKS will authenticates the 1612 GSA_REKEY messages by means of shared secret. In this case the 1613 GCKS MUST include the AUTH_KEY attribute containing the shared key 1614 into the KD payload at the time the GM is registered to the group. 1616 NULL Authentication - No additional authentication of the 1617 GSA_REKEY messages will be provided by the GCKS besides the 1618 ability for the GMs to correctly decrypt them and verify their 1619 ICV. In this case the GCKS MUST NOT include the AUTH_KEY 1620 attribute into the KD payload. Additionally, the AUTH payload 1621 MUST NOT be included in the GIKE_REKEY messages. 1623 Digital Signature - Digital signatures will be used by the GCKS to 1624 authenticate the GSA_REKEY messages. In this case the GCKS MUST 1625 include the AUTH_KEY attribute containing the public key into the 1626 KD payload at the time the GM is registered to the group. To 1627 specify the details of the signature algorithm a new attribute 1628 Algorithm Identifier () is defined. This attribute 1629 contains DER-encoded ASN.1 object AlgorithmIdentifier, which would 1630 specify the signature algorithm and the hash function that the 1631 GCKS will use for authentication. The AlgorithmIdentifier object 1632 is defined in section 4.1.1.2 of [RFC5280], see also [RFC7427] for 1633 the list of common AlgorithmIdentifier values used in IKEv2. In 1634 case of using digital signature the GCKS MUST include the 1635 Algorithm Identifier attribute in the Authentication Method 1636 transform. 1638 The authentication method MUST NOT change as a result of rekey 1639 operations. This means that the Authentication Method transform may 1640 not appear in the rekey messages, it may only appear in the 1641 registration exchange (either GSA_AUTH or GSA_REGISTRATION). 1643 The type of the Authentication Method Transform is . 1645 4.4.2.1.2. Group Key Management Method Transform 1647 The Group Key Management Method (GKM) transform is used in the 1648 GIKE_REKEY policy to convey information of how GCKS will manage the 1649 group keys to provide forward and backward access control (i.e., used 1650 to exclude group members). Possible key management methods are 1651 defined in a new IKEv2 registry "Transform Type - Group Key 1652 Management Methods" (see Section 8). This document defines one 1653 values for this registry: 1655 Wrapped Key Download () - Keys are downloaded by GCKS 1656 to the GMs in encrypted form. This algorithm may provide forward 1657 and backward access control if some form of key hierarchy is used 1658 and each GM is provided with a personal key at the time of 1659 registration. Otherwise no access control is provided. 1661 The group key management method MUST NOT change as a result of rekey 1662 operations. This means that the Group Key Management Method 1663 transform may not appear in the rekey messages, it may only appear in 1664 the registration exchange (either GSA_AUTH or GSA_REGISTRATION). 1666 The type of the Group Key Management Method transform is . 1669 4.4.2.1.3. Extended Sequence Number Transform 1671 Extended Sequence Number (ESN) Transform is defined in [RFC7296] to 1672 allow using 64-bit sequence numbers in ESP and AH. Since both AH 1673 [RFC4302] and ESP [RFC4303] are defined so, that high-order 32 bits 1674 of extended sequence numbers are never transmitted, it makes using 1675 ESN in multicast Data-Security SAs problematic, because GMs that join 1676 group long after it is created will have to somehow learn the current 1677 high order 32 bits of ESN for each sender in the group. The 1678 algorithm for doing this described in [RFC4302] and [RFC4303] is 1679 resource-consuming. For this reason extended sequence numbers SHOULD 1680 NOT be used for multicast Data-Security SAs and thus the ESN 1681 Transform SHOULD NOT be included in the GSA Payload. 1683 4.4.2.2. GSA Attributes 1685 GSA attributes are generally used to provide GMs with additional 1686 parameters for the GSA policy. Unlike security parameters 1687 distributed via transforms, which are expected not to change over 1688 time (unless policy changes), the parameters distributed via GSA 1689 attributes may depend on the time the provision takes place, on the 1690 existence of others group SAs or on other conditions. 1692 This document creates a new IKEv2 IANA registry for the types of the 1693 GSA attributes which is initially filled as described in Section 8. 1694 In particular, the following attributes are initially added. 1696 GSA Attributes Value Type Multiple Protocol 1697 --------------------------------------------------------------------- 1698 Reserved 0 1699 GSA_KEY_LIFETIME 1 V N GIKE_REKEY, AH, ESP 1700 GSA_INITIAL_MESSAGE_ID 2 V N GIKE_REKEY 1701 GSA_NEXT_SPI 3 V Y GIKE_REKEY, AH, ESP 1703 The attributes must follow the format defined in the IKEv2 [RFC7296] 1704 section 3.3.5. In the table, attributes that are defined as TV are 1705 marked as Basic (B); attributes that are defined as TLV are marked as 1706 Variable (V). 1708 4.4.2.2.1. GSA_KEY_LIFETIME Attribute 1710 The GSA_KEY_LIFETIME attribute (1) specifies the maximum time for 1711 which the SA is valid. The value is a 4 octet unsigned integer in a 1712 network byte order, specifying a valid time period in seconds. A 1713 single attribute of this type MUST be included into any GSA policy 1714 substructure. 1716 When the lifetime expires, the group security association and all 1717 associated keys MUST be deleted. The GCKS may delete the SA at any 1718 time before the end of the validity period. 1720 This attribute SHOULD NOT be used if inband rekeying (via the 1721 GSA_INBAND_REKEY exchange) is employed by the GCKS for the GM. 1723 4.4.2.2.2. GSA_INITIAL_MESSAGE_ID Attribute 1725 The GSA_INITIAL_MESSAGE_ID attribute (2) defines the initial Message 1726 ID to be used by the GCKS in the GSA_REKEY messages. The Message ID 1727 is a 4 octet unsigned integer in network byte order. 1729 A single attribute of this type MUST be included into the GSA KEK 1730 policy substructure if the initial Message ID of the Rekey SA is non- 1731 zero. Note, that it is always the case if GMs join the group after 1732 some multicast rekey operations have already taken place, so in these 1733 cases this attribute will be included into the GSA policy at the time 1734 of GMs' registration. 1736 This attribute MUST NOT be used if inband rekeying (via the 1737 GSA_INBAND_REKEY exchange) is employed by the GCKS for the GM. 1739 4.4.2.2.3. GSA_NEXT_SPI Attribute 1741 The optional GSA_NEXT_SPI attribute (3) contains SPI that the GCKS 1742 reserved for the next Rekey SA or Data-Security SAs replacing the 1743 current ones. The length of the attribute data is determined by the 1744 SPI Size field in the GSA Policy substructure the attribute resides 1745 in (see Section 4.4.2), and the attribute data contains SPI as it 1746 would appear on the network. Multiple attributes of this type MAY be 1747 included, meaning that any of the supplied SPIs can be used in the 1748 replacement group SA. 1750 The GM MAY store these values and if later the GM starts receiving 1751 messages with one of these SPIs without seeing a rekey message over 1752 the current Rekey SA, this may be used as an indication, that the 1753 rekey message got lost on its way to this GM. In this case the GM 1754 SHOULD re-register to the group. 1756 Note, that this method of detecting lost rekey messages can only be 1757 used by group receivers. Additionally there is no point to include 1758 this attribute in the GSA_INBAND_REKEY messages, since they use 1759 reliable transport. Note also, that the GCKS is free to forget its 1760 promises and not to use the SPIs it sent in the GSA_NEXT_SPI 1761 attributes before (e.g. in case of the GCKS is rebooted), so the GM 1762 must only treat these information as a "best effort" made by the GCKS 1763 to prepare for future rekeys. 1765 This attribute MUST NOT be used if inband rekeying (via the 1766 GSA_INBAND_REKEY exchange) is employed by the GCKS for the GM. 1768 4.4.3. Group Associated Policy Substructure 1770 Group specific policy that does not belong to any SA policy can be 1771 distributed to all group member using Group Associated Policy (GAP) 1772 substructure. 1774 The GAP substructure is defined as follows: 1776 1 2 3 1777 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 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1779 | Protocol | RESERVED | Length | 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 | | 1782 ~ ~ 1783 | | 1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 Figure 17: GAP Substructure Format 1788 The GAP substructure fields are defined as follows: 1790 o Protocol (1 octet) - MUST be zero. This value is reserved in 1791 Section 8 and is never used for any security protocol, so it is 1792 used here to indicate that this substructure contains policy not 1793 related to any specific protocol. 1795 o RESERVED ( octet) - MUST be zero on transmission, MUST be ignored 1796 on receipt. 1798 o Length (2 octets, unsigned integer) - Length of this substructure 1799 including the header. 1801 o GAP Attributes (variable) - Contains policy attributes associated 1802 with no specific SA. The following sections describe possible 1803 attributes. Any or all attributes may be optional, depending on 1804 the group policy. 1806 This document creates a new IKEv2 IANA registry for the types of the 1807 GAP attributes which is initially filled as described in Section 8. 1808 In particular, the following attributes are initially added. 1810 GAP Attributes Value Type Multiple 1811 ---------------------------------------------------- 1812 Reserved 0 1813 GAP_ATD 1 B N 1814 GAP_DTD 2 B N 1815 GAP_SID_BITS 3 B N 1817 The attributes must follow the format defined in the IKEv2 [RFC7296] 1818 section 3.3.5. In the table, attributes that are defined as TV are 1819 marked as Basic (B); attributes that are defined as TLV are marked as 1820 Variable (V). 1822 4.4.3.1. GAP_ATD And GAP_DTD Attributes 1824 Section 4.2.1 of [RFC5374] specifies a key rollover method that 1825 requires two values be provided to group members - Activation Time 1826 Delay (ATD) and Deactivation Time Delay (DTD). 1828 The GAP_ATD attribute (1) allows a GCKS to set the Activation Time 1829 Delay for Data-Security SAs of the group. The ATD defines how long 1830 active members of the group (those who sends traffic) should wait 1831 after receiving new SAs before staring sending traffic over them. 1832 Note, that to achieve smooth rollover passive members of the group 1833 should activate the SAs immediately once they receive them. 1835 The GAP_DTD attribute (2) allows the GCKS to set the Deactivation 1836 Time Delay for previously distributed SAs. The DTD defines how long 1837 after receiving a request to delete Data-Security SAs passive group 1838 members should wait before actually deleting them. Note that active 1839 members of the group should stop sending traffic over these old SAs 1840 once new replacement SAs are activated (after time specified in the 1841 GAP_ATD attribute). 1843 The GAP_ATD and GAP_DTD attributes contain 16 bit unsigned integer in 1844 a network byte order, specifying the delay in seconds. These 1845 attributes are OPTIONAL. If one of them or both are not sent by the 1846 GCKS, the GMs should use default values for activation and 1847 deactivation time delays. 1849 4.4.3.2. GAP_SID_BITS Attribute 1851 The GAP_SID_BITS attribute (3) declares how many bits of the cipher 1852 nonce are taken to represent an SID value. The bits are applied as 1853 the most significant bits of the IV, as shown in Figure 1 of 1854 [RFC6054] and specified in Section 2.5.2. Guidance for a GCKS 1855 choosing the NUMBER_OF_SID_BITS is provided in Section 3 of 1856 [RFC6054]. This value is applied to each SID value distributed in 1857 the KD payload. 1859 The GCKS MUST include this attribute if there are more than one 1860 sender in the group and any of the Data-Security SAs use counter- 1861 based cipher mode. The number of SID bits is represented as 16 bit 1862 unsigned integer in network byte order. 1864 4.5. Key Download Payload 1866 The Key Download (KD) payload contains the group keys for the SAs 1867 specified in the GSA Payload. The Payload Type for the Key Download 1868 payload is fifty-two (52). 1870 1 2 3 1871 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 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 | Next Payload |C| RESERVED | Length | 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 | | 1876 ~ ~ 1877 | | 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1880 Figure 18: Key Download Payload Format 1882 The Key Download payload fields are defined as follows: 1884 o Next Payload, C, RESERVED, Payload Length fields comprise the 1885 IKEv2 Generic Payload Header and are defined in Section 3.2. of 1886 [RFC7296]. 1888 o Key Packets (variable) - Contains Group Key Packet and Member Key 1889 Packet substructures. Each Key Packet contains keys for a single 1890 group rekey or Data-Security SA or a keys and security parameters 1891 for a GM. 1893 Two types of Key Packets are used - Group Key Packet and Member Key 1894 Packet. 1896 4.5.1. Wrapped Key Format 1898 The symmetric keys in G-IKEv2 are never sent in clear. They are 1899 always encrypted with other keys using the format called Wrapped Key 1900 that is shown below (Figure 19). 1902 The keys are encrypted using algorithm that is used to encrypt the 1903 message the keys are sent in. It means, that in case of unicast IKE 1904 SA (used for GMs registration and rekeying using GSA_INBAND_REKEY) 1905 the encryption algorithm will be the one negotiated during the IKE SA 1906 establishment, while for a GSA_REKEY message the algorithm will be 1907 provided by the GCKS in the Encryption Algorithm transform in the GSA 1908 payload when this multicast SA was being established. 1910 If AEAD mode is used for encryption, then for the purpose of key 1911 encryption the authentication tag MUST NOT be used (both not 1912 calculated and not verified), since the G-IKEv2 provides 1913 authentication of all its messages. In addition there is no AAD in 1914 this case. If encryption algorithm requires padding, then the 1915 encrypted key MUST be padded before encryption to have the required 1916 size. If the encryption algorithm doesn't define the padding 1917 content, then the following scheme SHOULD be used: the Padding bytes 1918 are initialized with a series of (unsigned, 1-byte) integer values. 1919 The first padding byte appended to the plaintext is numbered 1, with 1920 subsequent padding bytes making up a monotonically increasing 1921 sequence: 1, 2, 3, .... The length of the padding is not transmitted 1922 and is implicitly determined, since the length of the key is known. 1924 1 2 3 1925 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 1926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1927 | Key ID | 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 | KWK ID | 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1931 | | 1932 ~ IV ~ 1933 | | 1934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1935 | | 1936 ~ Encrypted Key ~ 1937 | | 1938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1940 Figure 19: Wrapped Key Format 1942 The Wrapped Key fields are defined as follows: 1944 o Key ID (4 octets) - ID of the encrypted key. The value zero means 1945 that the encrypted key contains SA keys (in the form of keying 1946 material, see Section 3.4)), otherwise it contains some 1947 intermediate key. 1949 o KWK ID (4 octets) - ID of the key that was used to encrypt key 1950 with specified Key ID. The value zero means that the default KWK 1951 was used to encrypt the key, otherwise some intermediate key was 1952 used. 1954 o IV (variable) - Initialization Vector used for encryption. The 1955 size and the content of IV is defined by the employed encryption 1956 transform. 1958 o Encrypted Key (variable) - The encrypted key bits. These bits may 1959 comprise either a single encrypted key or a result of encryption 1960 of a concatenation of keys (key material) for several algorithms. 1962 4.5.2. Group Key Packet Substructure 1964 Group Key Packet substructure contains SA key information. This key 1965 information is associated with some group SAs: either with Data- 1966 Security SAs or with group Rekey SA. 1968 1 2 3 1969 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 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1971 | Protocol | SPI Size | Length | 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 | | 1974 ~ SPI ~ 1975 | | 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1977 | | 1978 ~ ~ 1979 | | 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 Figure 20: Group Key Packet Substructure Format 1984 o Protocol (1 octet) - Identifies the security protocol for this key 1985 packet. The values are defined in the IKEv2 Security Protocol 1986 Identifiers in [IKEV2-IANA]. The valid values for this field are: 1987 (GIKE_REKEY) for KEK Key packet and 2 (AH) or 3 (ESP) for 1988 TEK key packet. 1990 o SPI Size (1 octet) - Size of Security Parameter Index (SPI) for 1991 the corresponding SA. SPI size depends on the security protocol. 1992 For GIKE_REKEY it is 16 octets, while for AH and ESP it is 4 1993 octets. 1995 o Length (2 octets, unsigned integer) - Length of this substructure 1996 including the header. 1998 o SPI (variable) - Security Parameter Index for the corresponding 1999 SA. The size of this field is determined by the SPI Size field. 2000 In case of GIKE_REKEY the SPI must be the IKEv2 Header SPI pair 2001 where the first 8 octets become the "Initiator's SPI" field in the 2002 G-IKEv2 rekey message IKEv2 HDR, and the second 8 octets become 2003 the "Responder's SPI" in the same HDR. When selecting SPI the 2004 GCKS MUST make sure that the sole first 8 octets (corresponding to 2005 "Initiator's SPI" field in the IKEv2 header) uniquely identify the 2006 Rekey SA. 2008 o Group Key Packet Attributes (variable length) - Contains Key 2009 information for the corresponding SA. 2011 This document creates a new IKEv2 IANA registry for the types of the 2012 Group Key Packet attributes which is initially filled as described in 2013 Section 8. In particular, the following attributes are initially 2014 added. 2016 Group Key Packet 2017 Attributes Value Type Multiple Protocol 2018 ---------------------------------------------------------- 2019 Reserved 0 2020 SA_KEY 1 V N/Y* GIKE_REKEY, 2021 N AH, ESP 2023 (*) Multiple SA_KEY attributes may only appear for the GIKE_REKEY 2024 protocol in the GSA_REKEY exchange if the GCKS uses the Group Key 2025 Management method that allows excluding GMs from the group (like 2026 LKH). 2028 The attributes must follow the format defined in the IKEv2 [RFC7296] 2029 section 3.3.5. In the table, attributes that are defined as TV are 2030 marked as Basic (B); attributes that are defined as TLV are marked as 2031 Variable (V). 2033 4.5.2.1. SA_KEY Attribute 2035 The SA_KEY attribute (1) contains a keying material for the 2036 corresponding SA. The content of the attribute is formatted 2037 according to Section 4.5.1 with a precondition that the Key ID field 2038 MUST always be zero. The size of the keying material MUST be equal 2039 to the total size of the keys needed to be taken from this keying 2040 material (see Section 3.4) for the corresponding SA. 2042 If the Key Packet is for a Data-Security SA (AH or ESP protocols), 2043 then exactly one SA_KEY attribute MUST be present with both Key ID 2044 and KWK ID fields set to zero. 2046 If the Key Packet is for a Rekey SA (GIKE_REKEY protocol), then in 2047 the GSA_AUTH, GSA_REGISTRATION and GSA_INBAND_REKEY exchanges exactly 2048 one SA_KEY attribute MUST be present. In the GSA_REKEY exchange at 2049 least one SA_KEY attribute MUST be present, and more attributes MAY 2050 be present (depending on the key management method employed by the 2051 GCKS). 2053 4.5.3. Member Key Packet Substructure 2055 The Member Key Packet substructure contains keys and other parameters 2056 that are specific for a member of the group and are not associated 2057 with any particular group SA. 2059 1 2 3 2060 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 2061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2062 | Protocol | RESERVED | Length | 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2064 | | 2065 ~ ~ 2066 | | 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2069 Figure 21: Member Key Packet Substructure Format 2071 The Member Key Packet substructure fields are defined as follows: 2073 o Protocol (1 octet) - MUST be zero. This value is reserved in 2074 Section 8 and is never used for any security protocol, so it is 2075 used here to indicate that this Key Packet is not associated with 2076 any particular SA. 2078 o RESERVED ( octet) - MUST be zero on transmission, MUST be ignored 2079 on receipt. 2081 o Length (2 octets, unsigned integer) - Length of this substructure 2082 including the header. 2084 o Member Key Packet Attributes (variable length) - Contains Key 2085 information and other parameters exclusively for a particular 2086 member of the group. 2088 Member Key Packet substructure contains sensitive information for a 2089 single GM, for this reason it MUST NOT be sent in GSA_REKEY messages 2090 and MUST only be sent via unicast SA at the time the GM registers to 2091 the group (in either GSA_AUTH or GSA_REGISTRATION exchanges). 2093 This document creates a new IKEv2 IANA registry for the types of the 2094 Member Key Packet attributes which is initially filled as described 2095 in Section 8. In particular, the following attributes are initially 2096 added. 2098 Member Key Packet 2099 Attributes Value Type Multiple 2100 ------------------------------------------------ 2101 Reserved 0 2102 WRAP_KEY 1 V Y 2103 AUTH_KEY 2 V N 2104 GM_SID 3 V Y 2106 The attributes must follow the format defined in the IKEv2 [RFC7296] 2107 section 3.3.5. In the table, attributes that are defined as TV are 2108 marked as Basic (B); attributes that are defined as TLV are marked as 2109 Variable (V). 2111 4.5.3.1. WRAP_KEY Attribute 2113 The WRAP_KEY attribute (1) contains a key that is used to encrypt 2114 other keys. One or more these attributes are sent to GMs if the GCKS 2115 key management method relies on some key hierarchy (e.g. LKH). This 2116 attribute MUST NOT be used if inband rekeying (via the 2117 GSA_INBAND_REKEY exchange) is employed by the GCKS for the GM. 2119 The content of the attribute has a format defined in Section 4.5.1 2120 with a precondition that the Key ID field MUST NOT be zero. The 2121 algorithm associated with the key is from the Encryption Transform 2122 for the SA the WRAP_KEY attributes was sent in. The size of the key 2123 MUST be equal to the key size for this algorithm. 2125 Multiple instances of the WRAP_KEY attributes MAY be present in the 2126 key packet. 2128 4.5.3.2. AUTH_KEY Attribute 2130 The AUTH_KEY attribute (2) contains the key that is used to 2131 authenticate the GSA_REKEY messages. The content of the attribute 2132 depends on the authentication method the GCKS specified in the 2133 Authentication Method transform in the GSA payload. 2135 o If a shared secret is used for the GSA_REKEY messages 2136 authentication then the content of the AUTH_KEY attribute is the 2137 shared secret that MUST be represented in the form of Wrapped Key 2138 (see Section 4.5.1) with zero KWK ID. The Key ID in this case is 2139 arbitrary and MUST be ignored by the GM. 2141 o If digital signatures are used for the GSA_REKEY messages 2142 authentication then the content of the AUTH_KEY attribute is a 2143 public key used for digital signature authentication. The public 2144 key MUST be represented as DER-encoded ASN.1 object 2145 SubjectPublicKeyInfo, defined in section 4.1.2.7 of [RFC5280]. 2147 The signature algorithm that will use this key was specified in 2148 the Algorithm Identifier attribute of the Authentication Method 2149 transform. The key MUST be compatible with this algorithm. An 2150 RSA public key format is defined in [RFC8017], Section A.1. DSS 2151 public key format is defined in [RFC3279] Section 2.3.2. For 2152 ECDSA Public keys, use format described in [RFC5480] Section 2. 2153 Other algorithms added to the IKEv2 Authentication Method registry 2154 are also expected to include a format of the SubjectPublicKeyInfo 2155 object included in the algorithm specification. 2157 Multiple instances of the AUTH_KEY attributes MUST NOT be sent. This 2158 attribute MUST NOT appear in the rekey operations (in the GSA_REKEY 2159 or GSA_INBAND_REKEY exchanges). 2161 4.5.3.3. GM_SID Attribute 2163 The GM_SID attribute (3) is used to download one or more Sender-ID 2164 values for the exclusive use of a group member. One or more of this 2165 attributes MUST be sent by the GCKS if the GM informed the GCKS that 2166 it would be a sender (by inclusion the SENDER notification to the 2167 request) and at least one of the Data-Security SAs included in the 2168 GSA payload uses counter-based mode of encryption. 2170 If the GMs has requested multiple SID values in the SENDER 2171 notification, then the GCKS SHOULD provide it with the requested 2172 number of SIDs by sending multiple instances of the GM_SID attribute. 2173 The GCKS MAY send fewer SIDs than requested by the GM (e.g. if it is 2174 running out of SIDs), but it MUST NOT send more than requested. 2176 This attribute MUST NOT appear in the rekey operations (in the 2177 GSA_REKEY or GSA_INBAND_REKEY exchanges). 2179 4.6. Delete Payload 2181 Delete payload is used in G-IKEv2 when the GCKS wants to delete Data- 2182 Security and Rekey SAs. The interpretation of the Protocol field in 2183 the Delete payload is extended, so that zero protocol indicates 2184 deletion of whole Group SA (i.e. all Data-Security SAs and Rekey SA). 2185 See Section 2.4.3 for detail. 2187 4.7. Notify Payload 2189 G-IKEv2 uses the same Notify payload as specified in [RFC7296], 2190 section 3.10. 2192 There are additional Notify Message types introduced by G-IKEv2 to 2193 communicate error conditions and status (see Section 8). 2195 o INVALID_GROUP_ID (45) - error type notification that indicates 2196 that the group ID sent during the registration process is invalid. 2197 The Protocol ID and SPI Size fields in the Notify payload MUST be 2198 zero. There is no data associated with this notification and the 2199 content of the Notification Data field MUST be ignored on receipt. 2201 o AUTHORIZATION_FAILED (46) - error type notification that is sent 2202 in the response to a GSA_AUTH or GSA_REGISTRATION message when 2203 authorization failed. The Protocol ID and SPI Size fields in the 2204 Notify payload MUST be zero. There is no data associated with 2205 this notification and the content of the Notification Data field 2206 MUST be ignored on receipt. 2208 o REGISTRATION_FAILED () - error type notification that is sent 2209 by the GCKS when the GM registration request cannot be satisfied 2210 for the reasons not related to this particular GM, for example if 2211 the capacity of the group is exceeded. The Protocol ID and SPI 2212 Size fields in the Notify payload MUST be zero. There is no data 2213 associated with this notification and the content of the 2214 Notification Data field MUST be ignored on receipt. 2216 o SENDER (16429) - status type notification that is sent in the 2217 GSA_AUTH or the GSA_REGISTRATION exchanges to indicate that the GM 2218 intends to be sender of data traffic. The data includes a count 2219 of how many SID values the GM desires. The count MUST be 4 octets 2220 long and contain the big endian representation of the number of 2221 requested SIDs. The Protocol ID and SPI Size fields in the Notify 2222 payload MUST be zero. 2224 o REKEY_IS_NEEDED () - status type notification that is sent in 2225 the GSA_AUTH response message to indicate that the GM must perform 2226 an immediate rekey of IKE SA to make it secure against quantum 2227 computers and then start a registration request over. The 2228 Protocol ID and SPI Size fields in the Notify payload MUST be 2229 zero. There is no data associated with this notification and the 2230 content of the Notification Data field MUST be ignored on receipt. 2232 4.7.1. USE_TRANSPORT_MODE Notification 2234 This specification uses USE_TRANSPORT_MODE notification defined in 2235 section 3.10.1 of [RFC7296] to specify which mode Data-Security SAs 2236 should be created in. The GCKS MUST include one USE_TRANSPORT_MODE 2237 notification in a message containing the GSA payload for every Data- 2238 Security SAs specified in this payload that is to be created in 2239 transport mode. In other words, there must be as many these 2240 notifications included in the message as many SAs are created in 2241 transport mode. The Protocol ID, SPI Size and SPI fields of the 2242 Notify Payload MUST correctly specify each such SA. 2244 4.8. Authentication Payload 2246 G-IKEv2 uses the same Authentication payload as specified in 2247 [RFC7296], section 3.8, to authenticate the rekey message. However, 2248 if it is used in the GSA_REKEY messages the content of the payload is 2249 computed differently, as described in Section 2.4.1.1. 2251 5. Usigng G-IKEv2 Attributes 2253 G-IKEv2 defines a number of attributes, that are used to convey 2254 information from GCKS to GMs. There are some restrictions on where 2255 and when these attributes can appear in G-IKEv2 messages, which are 2256 defined when the attributes are introduced. For convenience these 2257 restrictions are summarized in Table 1 (for multicast rekey 2258 operations) and Table 2 (for inband rekey operations) below. 2260 The following notation is used: 2262 S A single attribute of this type must be present 2264 M Multiple attributes of this type may be present 2266 [] Attribute is optional 2268 - Attribute must not be present 2270 Note, that the restrictions are defined per a substructure 2271 corresponding attributes are defined for and not per whole G-IKEv2 2272 message. 2274 +-------------------------+--------------------+--------------------+ 2275 | Attributes | GSA_AUTH | GSA_REKEY | 2276 | | GSA_REGISTRATION | | 2277 +-------------------------+--------------------+--------------------+ 2278 | GSA_KEY_LIFETIME | S | S | 2279 | | | | 2280 | GSA_INITIAL_MESSAGE_ID | [S] | [S] | 2281 | | | | 2282 | GSA_NEXT_SPI | [M] | [M] | 2283 | | | | 2284 | GAP_ATD | [S] | [S] | 2285 | | | | 2286 | GAP_DTD | [S] | [S] | 2287 | | | | 2288 | GAP_SID_BITS | S* | - | 2289 | | | | 2290 | SA_KEY | S | S/[M]** | 2291 | | | | 2292 | WRAP_KEY | [M]** | [M]** | 2293 | | | | 2294 | AUTH_KEY | [S]*** | - | 2295 | | | | 2296 | GM_SID | S*/[M]* | - | 2297 +-------------------------+--------------------+--------------------+ 2299 Table 1: Using attributes in G-IKEv2 exchanges when multicast rekey 2300 is used 2302 * The GAP_SID_BITS attribute must be present if the GCKS policy 2303 includes at least one cipher in counter mode of operation and 2304 the GM included the SENDER notify into the registration 2305 request. Otherwise it must not be present. At least one 2306 GM_SID attribute must be present in the former case (and more 2307 may be present if the GM requested more SIDs) and no GM_SID 2308 attributes must be present in the latter case. 2310 ** The WRAP_KEY attributes may be present if the GCKS employs key 2311 management method that relies on key tree (like LKH). 2313 *** The AUTH_KEY attribute must be present if the GCKS employs 2314 authentication method other than NULL Authentication. 2316 +-------------------------+--------------------+--------------------+ 2317 | Attributes | GSA_AUTH | GSA_INBAND_REKEY | 2318 | | GSA_REGISTRATION | | 2319 +-------------------------+--------------------+--------------------+ 2320 | GSA_KEY_LIFETIME | [S] | [S] | 2321 | | | | 2322 | GSA_INITIAL_MESSAGE_ID | - | - | 2323 | | | | 2324 | GSA_NEXT_SPI | - | - | 2325 | | | | 2326 | GAP_ATD | [S] | [S] | 2327 | | | | 2328 | GAP_DTD | [S] | [S] | 2329 | | | | 2330 | GAP_SID_BITS | S* | - | 2331 | | | | 2332 | SA_KEY | S | S | 2333 | | | | 2334 | WRAP_KEY | - | - | 2335 | | | | 2336 | AUTH_KEY | - | - | 2337 | | | | 2338 | GM_SID | S*/[M]* | - | 2339 +-------------------------+--------------------+--------------------+ 2341 Table 2: Using attributes in G-IKEv2 exchanges when inband rekey is 2342 used 2344 * The GAP_SID_BITS attribute must be present if the GCKS policy 2345 includes at least one cipher in counter mode of operation and 2346 the GM included the SENDER notify into the registration 2347 request. Otherwise it must not be present. At least one 2348 GM_SID attribute must be present in the former case (and more 2349 may be present if the GM requested more SIDs) and no GM_SID 2350 attributes must be present in the latter case. 2352 6. Interaction with other IKEv2 Protocol Extensions 2354 A number of IKEv2 extensions is defined that can be used to extend 2355 protocol functionality. G-IKEv2 is compatible with most of them. In 2356 particular, EAP authentication defined in [RFC7296] can be used to 2357 establish registration IKE SA, as well as EAP-only authentication 2358 [RFC5998] and Secure Password authentication [RFC6467]. G-IKEv2 is 2359 compatible with and can use IKEv2 Redirect Mechanism [RFC5685] and 2360 IKEv2 Session Resumption [RFC5723]. G-IKEv2 is also compatible with 2361 Multiple Key Exchanges in IKEv2 framework, defined in 2362 [I-D.ietf-ipsecme-ikev2-multiple-ke]. 2364 The above list of compatible IKEv2 extensions is not exhaustive, 2365 however some IKEv2 extensions require special handling if used in 2366 G-IKEv2. 2368 6.1. Mixing Preshared Keys in IKEv2 for Post-quantum Security 2370 G-IKEv2 can take advantage of the protection provided by Postquantum 2371 Preshared Keys (PPK) for IKEv2 [RFC8784]. However, the use of PPK 2372 leaves the initial IKE SA susceptible to quantum computer (QC) 2373 attacks. Since group SA keys are protected with the default KWK 2374 (GSK_w), which is derived from SK_d and thus cannot be broken even by 2375 attacker tquipped with a QC, authentication of these keys relies on 2376 authentication of IKE SA messages, which is not secure against QC 2377 until the initial IKE SA is rekeyed. In additional, the other 2378 content of IKE SA messages may also be visible to an attacker with a 2379 QC. See Section 6 of [RFC8784] for details. For this reason an 2380 alternative approach for using PPK in IKEv2 defined in 2381 [I-D.smyslov-ipsecme-ikev2-qr-alt] SHOULD be used. 2383 If the alternative approach is not supported by the peers, then the 2384 GCKS MUST NOT send GSA and KD payloads in the GSA_AUTH response 2385 message. Instead, the GCKS MUST return a new notification 2386 REKEY_IS_NEEDED. Upon receiving this notification in the GSA_AUTH 2387 response the GM MUST perform an IKE SA rekey and then initiate a new 2388 GSA_REGISTRATION request for the same group. Below are possible 2389 scenarios involving using PPK. 2391 The GM starts the IKE_SA_INIT exchange requesting using PPK, and the 2392 GCKS responds with agreement to do it, or aborts according to its 2393 "mandatory_or_not" flag: 2395 Initiator (Member) Responder (GCKS) 2396 -------------------- ------------------ 2397 HDR, SAi1, KEi, Ni, N(USE_PPK) --> 2398 <-- DR, SAr1, KEr, Nr, [CERTREQ], 2399 N(USE_PPK) 2401 Figure 22: IKE_SA_INIT Exchange requesting using PPK 2403 The GM then starts the GSA_AUTH exchange with the PPK_ID; if using 2404 PPK is not mandatory for the GM, the NO_PPK_AUTH notification is 2405 included in the request: 2407 Initiator (Member) Responder (GCKS) 2408 -------------------- ------------------ 2409 HDR, SK{IDi, AUTH, IDg, 2410 N(PPK_IDENTITY), N(NO_PPK_AUTH)} --> 2412 Figure 23: GSA_AUTH Request using PPK 2414 If the GCKS has no such PPK and using PPK is not mandatory for it and 2415 the NO_PPK_AUTH is included, then the GCKS continues without PPK; in 2416 this case no rekey is needed: 2418 Initiator (Member) Responder (GCKS) 2419 -------------------- ------------------ 2420 <-- HDR, SK{IDr, AUTH, GSA, KD} 2422 Figure 24: GSA_AUTH Response using no PPK 2424 If the GCKS has no such PPK and either the NO_PPK_AUTH is missing or 2425 using PPK is mandatory for the GCKS, the GCKS aborts the exchange: 2427 Initiator (Member) Responder (GCKS) 2428 -------------------- ------------------ 2429 <-- HDR, SK{N(AUTHENTICATION_FAILED)} 2431 Figure 25: GSA_AUTH Error Response 2433 Assuming the GCKS has the proper PPK it continues with a request to 2434 the GM to immediately perform a rekey by sending the REKEY_IS_NEEDED 2435 notification: 2437 Initiator (Member) Responder (GCKS) 2438 -------------------- ------------------ 2439 <-- HDR, SK{IDr, AUTH, N(PPK_IDENTITY), 2440 N(REKEY_IS_NEEDED) } 2442 Figure 26: GSA_AUTH Response using PPK 2444 The GM initiates the CREATE_CHILD_SA exchange to rekey the initial 2445 IKE SA and then makes a new registration request for the same group 2446 over the new IKE SA: 2448 Initiator (Member) Responder (GCKS) 2449 -------------------- ------------------ 2450 HDR, SK{SA, Ni, KEi} --> 2451 <-- HDR, SK{SA, Nr, KEr} 2452 HDR, SK{IDg} ---> 2453 <-- HDR, SK{GSA, KD} 2455 Figure 27: Rekeying IKE SA followed by GSA_REGISTRATION Exchange 2457 7. Security Considerations 2459 7.1. GSA Registration and Secure Channel 2461 G-IKEv2 registration exchange uses IKEv2 IKE_SA_INIT protocols, 2462 inheriting all the security considerations documented in [RFC7296] 2463 section 5 Security Considerations, including authentication, 2464 confidentiality, protection against man-in-the-middle, protection 2465 against replay/reflection attacks, and denial of service protection. 2466 The GSA_AUTH and GSA_REGISTRATION exchanges also take advantage of 2467 those protections. In addition, G-IKEv2 brings in the capability to 2468 authorize a particular group member regardless of whether they have 2469 the IKEv2 credentials. 2471 7.2. GSA Maintenance Channel 2473 The GSA maintenance channel is cryptographically and integrity 2474 protected using the cryptographic algorithm and key negotiated in the 2475 GSA member registration exchanged. 2477 7.2.1. Authentication/Authorization 2479 The authentication key is distributed during the GM registration, and 2480 the receiver of the rekey message uses that key to verify the message 2481 came from the authorized GCKS. An implicit authentication can also 2482 be used, in which case the ability of the GM to decrypt and to verify 2483 ICV of the received message proved taht a sender of the message is a 2484 member of the group. However, implicit authentication as well as 2485 authentication with preshared key don't provide source origin 2486 authentication, so the GM cannot be sure that the message came from 2487 the GCKS. For this reason using implicit authentication and 2488 authentication with preshared key is NOT RECOMMENDED unless in a 2489 small group of trusted parties. 2491 7.2.2. Confidentiality 2493 Confidentiality is provided by distributing a confidentiality key as 2494 part of the GSA member registration exchange. 2496 7.2.3. Man-in-the-Middle Attack Protection 2498 GSA maintenance channel is integrity protected by using a digital 2499 signature. 2501 7.2.4. Replay/Reflection Attack Protection 2503 The GSA_REKEY message includes a monotonically increasing sequence 2504 number to protect against replay and reflection attacks. A group 2505 member will recognize a replayed message by comparing the Message ID 2506 number to that of the last received rekey message, any rekey message 2507 containing a Message ID number less than or equal to the last 2508 received value MUST be discarded. Implementations should keep a 2509 record of recently received GSA rekey messages for this comparison. 2511 8. IANA Considerations 2513 8.1. New Registries 2515 A new set of registries is created for G-IKEv2 on IKEv2 parameters 2516 page [IKEV2-IANA]. The terms Reserved, Expert Review and Private Use 2517 are to be applied as defined in [RFC8126]. 2519 This document creates a new IANA registry "Transform Type - 2520 Group Key Management Methods". The initial values of the new 2521 registry are: 2523 Value Group Key Management Method 2524 ------------------------------------------------------- 2525 Reserved 0 2526 Wrapped Key Download 1 2527 Unassigned 2-1023 2528 Private Use 1024-65535 2530 Changes and additions to the unassigned range of this registry are by 2531 the Expert Review Policy [RFC8126]. 2533 This document creates a new IANA registry "GSA Attributes". The 2534 initial values of the new registry are: 2536 GSA Attributes Value Type Multiple Protocol 2537 --------------------------------------------------------------------- 2538 Reserved 0 2539 GSA_KEY_LIFETIME 1 V N GIKE_REKEY, AH, ESP 2540 GSA_INITIAL_MESSAGE_ID 2 V N GIKE_REKEY 2541 GSA_NEXT_SPI 3 V Y GIKE_REKEY, AH, ESP 2542 Unassigned 5-16383 2543 Private Use 16384-32767 2544 Changes and additions to the unassigned range of this registry are by 2545 the Expert Review Policy [RFC8126]. 2547 This document creates a new IANA registry "GAP Attributes". The 2548 initial values of the new registry are: 2550 GAP Attributes Value Type Multiple 2551 ---------------------------------------------------- 2552 Reserved 0 2553 GAP_ATD 1 B N 2554 GAP_DTD 2 B N 2555 GAP_SID_BITS 3 B N 2556 Unassigned 4-16383 2557 Private Use 16384-32767 2559 Changes and additions to the unassigned range of this registry are by 2560 the Expert Review Policy [RFC8126]. 2562 This document creates a new IANA registry "Group Key Packet 2563 Attributes". The initial values of the new registry are: 2565 Group Key Packet 2566 Attributes Value Type Multiple Protocol 2567 ------------------------------------------------------------ 2568 Reserved 0 2569 SA_KEY 1 V Y GIKE_REKEY, 2570 N AH, ESP 2571 Unassigned 2-16383 2572 Private Use 16384-32767 2574 Changes and additions to the unassigned range of this registry are by 2575 the Expert Review Policy [RFC8126]. 2577 This document creates a new IANA registry "Member Key Packet 2578 Attributes". The initial values of the new registry are: 2580 Member Key Packet 2581 Attributes Value Type Multiple 2582 ------------------------------------------------ 2583 Reserved 0 2584 WRAP_KEY 1 V Y 2585 AUTH_KEY 2 V N 2586 GM_SID 3 V Y 2587 Unassigned 4-16383 2588 Private Use 16384-32767 2590 Changes and additions to the unassigned range of this registry are by 2591 the Expert Review Policy [RFC8126]. 2593 8.2. Changes in the Existing IKEv2 Registries 2595 This document defines new Exchange Types in the "IKEv2 Exchange 2596 Types" registry: 2598 Value Exchange Type 2599 ---------------------------- 2600 39 GSA_AUTH 2601 40 GSA_REGISTRATION 2602 41 GSA_REKEY 2603 GSA_INBAND_REKEY 2605 This document defines new Payload Types in the "IKEv2 Payload Types" 2606 registry: 2608 Value Next Payload Type Notation 2609 ---------------------------------------------------- 2610 50 Group Identification IDg 2611 51 Group Security Association GSA 2612 52 Key Download KD 2614 This document defines a new Security Protocol Identifier in the 2615 "IKEv2 Security Protocol Identifiers" registry: 2617 GIKE_REKEY 2619 This document defines new Transform Types in the "Transform Type 2620 Values" registry and changes the "Used In" column for the existing 2621 allocations: 2623 Type Description Used In 2624 --------------------------------------------------------------------- 2625 1 Encryption Algorithm (ENCR) IKE, GIKE_REKEY and ESP 2626 2 Pseudo-random Function (PRF) IKE, GIKE_REKEY 2627 3 Integrity Algorithm (INTEG) IKE, GIKE_REKEY, AH, 2628 optional in ESP 2629 4 Diffie-Hellman Group (D-H) IKE, optional in AH, ESP 2630 5 Extended Sequence Numbers (ESN) AH and ESP 2631 Authentication Method (AUTH) GIKE_REKEY 2632 Group Key Management Method (GKM) GIKE_REKEY 2634 This document defines a new Attribute Type in the "IKEv2 Transform 2635 Attribute Types" registry: 2637 Value Attribute Type Format 2638 ---------------------------------------------- 2639 Algorithm Identifier TLV 2640 This document defines new Notify Message Types in the "Notify Message 2641 Types - Status Types" registry: 2643 Value Notify Messages - Status Types 2644 ------------------------------------------ 2645 16429 SENDER 2647 The Notify type with the value 16429 was allocated earlier in the 2648 development of G-IKEv2 document with the name SENDER_REQUEST_ID. 2649 This specification changes its name to SENDER. 2651 This document defines new Notify Message Types in the "Notify Message 2652 Types - Error Types" registry: 2654 Value Notify Messages - Error Types 2655 ----------------------------------------- 2656 45 INVALID_GROUP_ID 2657 46 AUTHORIZATION_FAILED 2658 REGISTRATION_FAILED 2660 9. Acknowledgements 2662 The authors thank Lakshminath Dondeti and Jing Xiang for first 2663 exploring the use of IKEv2 for group key management and providing the 2664 basis behind the protocol. Mike Sullenberger and Amjad Inamdar were 2665 instrumental in helping resolve many issues in several versions of 2666 the document. 2668 The authors are grateful to Tero Kivinen for his careful review and 2669 valuable proposals how to improve the document. 2671 10. Contributors 2673 The following individuals made substantial contributions to early 2674 versions of this memo. 2676 Sheela Rowles 2677 Cisco Systems 2678 170 W. Tasman Drive 2679 San Jose, California 95134-1706 2680 USA 2682 Phone: +1-408-527-7677 2683 Email: sheela@cisco.com 2684 Aldous Yeung 2685 Cisco Systems 2686 170 W. Tasman Drive 2687 San Jose, California 95134-1706 2688 USA 2690 Phone: +1-408-853-2032 2691 Email: cyyeung@cisco.com 2693 Paulina Tran 2694 Cisco Systems 2695 170 W. Tasman Drive 2696 San Jose, California 95134-1706 2697 USA 2699 Phone: +1-408-526-8902 2700 Email: ptran@cisco.com 2702 Yoav Nir 2703 Dell EMC 2704 9 Andrei Sakharov St 2705 Haifa 3190500 2706 Israel 2708 Email: ynir.ietf@gmail.com 2710 11. References 2712 11.1. Normative References 2714 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2715 Requirement Levels", BCP 14, RFC 2119, 2716 DOI 10.17487/RFC2119, March 1997, 2717 . 2719 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2720 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2721 December 2005, . 2723 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 2724 DOI 10.17487/RFC4302, December 2005, 2725 . 2727 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2728 RFC 4303, DOI 10.17487/RFC4303, December 2005, 2729 . 2731 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2732 Housley, R., and W. Polk, "Internet X.509 Public Key 2733 Infrastructure Certificate and Certificate Revocation List 2734 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2735 . 2737 [RFC6054] McGrew, D. and B. Weis, "Using Counter Modes with 2738 Encapsulating Security Payload (ESP) and Authentication 2739 Header (AH) to Protect Group Traffic", RFC 6054, 2740 DOI 10.17487/RFC6054, November 2010, 2741 . 2743 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2744 Kivinen, "Internet Key Exchange Protocol Version 2 2745 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2746 2014, . 2748 [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in 2749 the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, 2750 DOI 10.17487/RFC7427, January 2015, 2751 . 2753 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2754 Writing an IANA Considerations Section in RFCs", BCP 26, 2755 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2756 . 2758 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2759 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2760 May 2017, . 2762 11.2. Informative References 2764 [I-D.ietf-ipsecme-ikev2-intermediate] 2765 Smyslov, V., "Intermediate Exchange in the IKEv2 2766 Protocol", draft-ietf-ipsecme-ikev2-intermediate-10 (work 2767 in progress), March 2022. 2769 [I-D.ietf-ipsecme-ikev2-multiple-ke] 2770 Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S., 2771 Geest, D. V., Garcia-Morchon, O., and V. Smyslov, 2772 "Multiple Key Exchanges in IKEv2", draft-ietf-ipsecme- 2773 ikev2-multiple-ke-04 (work in progress), September 2021. 2775 [I-D.smyslov-ipsecme-ikev2-qr-alt] 2776 Smyslov, V., "Alternative Approach for Mixing Preshared 2777 Keys in IKEv2 for Post-quantum Security", draft-smyslov- 2778 ipsecme-ikev2-qr-alt-04 (work in progress), August 2021. 2780 [IKEV2-IANA] 2781 IANA, "Internet Key Exchange Version 2 (IKEv2) 2782 Parameters", . 2785 [NNL] Naor, D., Noal, M., and J. Lotspiech, "Revocation and 2786 Tracing Schemes for Stateless Receivers", Advances in 2787 Cryptology, Crypto '01, Springer-Verlag LNCS 2139, 2001, 2788 pp. 41-62, 2001, 2789 . 2791 [OFT] McGrew, D. and A. Sherman, "Key Establishment in Large 2792 Dynamic Groups Using One-Way Function Trees", Manuscript, 2793 submitted to IEEE Transactions on Software Engineering, 2794 1998, . 2797 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2798 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 2799 . 2801 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 2802 Multicast: Issues and Architectures", RFC 2627, 2803 DOI 10.17487/RFC2627, June 1999, 2804 . 2806 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 2807 Identifiers for the Internet X.509 Public Key 2808 Infrastructure Certificate and Certificate Revocation List 2809 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 2810 2002, . 2812 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 2813 Counter Mode With IPsec Encapsulating Security Payload 2814 (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, 2815 . 2817 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 2818 Architecture", RFC 3740, DOI 10.17487/RFC3740, March 2004, 2819 . 2821 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 2822 "Multicast Security (MSEC) Group Key Management 2823 Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005, 2824 . 2826 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 2827 (GCM) in IPsec Encapsulating Security Payload (ESP)", 2828 RFC 4106, DOI 10.17487/RFC4106, June 2005, 2829 . 2831 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 2832 Mode with IPsec Encapsulating Security Payload (ESP)", 2833 RFC 4309, DOI 10.17487/RFC4309, December 2005, 2834 . 2836 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 2837 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 2838 DOI 10.17487/RFC4543, May 2006, 2839 . 2841 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 2842 Extensions to the Security Architecture for the Internet 2843 Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, 2844 . 2846 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 2847 "Elliptic Curve Cryptography Subject Public Key 2848 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 2849 . 2851 [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for 2852 the Internet Key Exchange Protocol Version 2 (IKEv2)", 2853 RFC 5685, DOI 10.17487/RFC5685, November 2009, 2854 . 2856 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 2857 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 2858 DOI 10.17487/RFC5723, January 2010, 2859 . 2861 [RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension 2862 for EAP-Only Authentication in IKEv2", RFC 5998, 2863 DOI 10.17487/RFC5998, September 2010, 2864 . 2866 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 2867 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 2868 October 2011, . 2870 [RFC6467] Kivinen, T., "Secure Password Framework for Internet Key 2871 Exchange Version 2 (IKEv2)", RFC 6467, 2872 DOI 10.17487/RFC6467, December 2011, 2873 . 2875 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 2876 (IKEv2) Message Fragmentation", RFC 7383, 2877 DOI 10.17487/RFC7383, November 2014, 2878 . 2880 [RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the 2881 Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634, 2882 DOI 10.17487/RFC7634, August 2015, 2883 . 2885 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 2886 "PKCS #1: RSA Cryptography Specifications Version 2.2", 2887 RFC 8017, DOI 10.17487/RFC8017, November 2016, 2888 . 2890 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 2891 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 2892 August 2017, . 2894 [RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, 2895 "Mixing Preshared Keys in the Internet Key Exchange 2896 Protocol Version 2 (IKEv2) for Post-quantum Security", 2897 RFC 8784, DOI 10.17487/RFC8784, June 2020, 2898 . 2900 Appendix A. Use of LKH in G-IKEv2 2902 Section 5.4 of [RFC2627] describes the LKH architecture, and how a 2903 GCKS uses LKH to exclude group members. This section clarifies how 2904 the LKH architecture is used with G-IKEv2. 2906 A.1. Notation 2908 In this section we will use the notation X{Y} where a key with ID Y 2909 is encrypted with the key with ID X. The notation GSK_w{Y} means 2910 that the default wrap key GSK_w (with zero KWK ID)is used to encrypt 2911 key Y, and the notation X{K_sa} means key X is used to encrypt the SA 2912 key K_sa (wich always has zero Key ID). Note, that GSK_w{K_sa} means 2913 that the SA key is encrypted with the default wrap key, in which case 2914 both KWK ID and Key ID are zero. For simplicity we will assume that 2916 The content of the KD payload will be shown as a sequence of Key 2917 Packets. The Group Key Packet substructure will be denoted as 2918 GP(SAn)(), when n is an SPI for the SA, and the Member Key Packet 2919 substructure will be denoted as MP(). The content of the Key Packets 2920 is shown as SA_KEY and WRAP_KEY attributes with the notation 2921 described above. For simplicity the type of the attribute will not 2922 be shown, because it is implicitly defined by the type of Key Packet. 2924 Here is the example of KD payload. 2926 KD(GP1(X{K_sa}),MP(Y{X},Z{Y},GSK_w{Z}) 2928 For simplicity any other attributes in the KD payload are omitted. 2930 We will also use the notation X->Y->Z to describe the Key Path. In 2931 this case key Y is needed to dectypt key X and key Z is needed to 2932 decrypt key Y. In the example above the keys had the following 2933 relation: K_sa->X->Y->Z->GSK_w. 2935 A.2. Group Creation 2937 When a GCKS forms a group, it creates a key tree as shown in the 2938 figure below. The key tree contains logical keys (which are 2939 represented as the values of their Key IDs in the figure) and a 2940 private key shared with only a single GM (the GMs are represented as 2941 letters followed by the corresponding key ID in parentheses in the 2942 figure). The root of the tree contains the multicast Rekey SA key 2943 (which is represented as SAn(K_san). The figure below assumes that 2944 the Key IDs are assigned sequentially; this is not a requirement and 2945 only used for illustrative purposes. The GCKS may create a complete 2946 tree as shown, or a partial tree which is created on demand as 2947 members join the group. 2949 SA1(K_sa1) 2950 +------------------------------+ 2951 1 2 2952 +---------------+ +---------------+ 2953 3 4 5 6 2954 +-------+ +-------+ +--------+ +--------+ 2955 A(7) B(8) C(9) D(10) E(11) F(12) G(13) H(14) 2957 Figure 28: Initial LKH tree 2959 When GM A joins the group, the GCKS provides it with the keys in the 2960 KD payload of the GSA_AUTH or GSA_REGISTRATION exchange. Given the 2961 tree shown in figure above, the KD payload will be: 2963 KD(GP(SA1)(1{K_sa1}),MP(3{1},7{3},GSK_w{7}) 2965 KD Payload for the Group Member A 2967 From these attributes the GM A will construct the Key Path 2968 K_sa1->1->3->7->GSK_w and since it ends up with GSK_w, it will use 2969 all the WRAP_KEY attributes present in the path as its Working Key 2970 Path: 1->3->7. 2972 Similarly, when other GMs will be joining the group they will be 2973 provided with the corresponding keys, so after all the GMs will have 2974 the following Working Key Paths: 2976 A: 1->3->7 B: 1->3->8 C: 1->4->9, D: 1->4->10 2977 E: 2->5->11 F: 2->5->12 G: 2->6->13 H: 2->6->14 2979 A.3. Simple Group SA Rekey 2981 If the GCKS performs a simple SA rekey without changing group 2982 membership, it will only send Group Key Packet in the KD payload with 2983 a new SA key encrypted with the default KWK. 2985 KD(GP(SA2)(GSK_w{K_sa2})) 2987 KD Payload for the Simple Group SA Rekey 2989 All the GMs will be able to decrypt it and no changes in their 2990 Working Key Paths will happen. 2992 A.4. Group Member Exclusion 2994 If the GKCS has reason to believe that a GM should be excluded, then 2995 it can do so by sending a GSA_REKEY message that includes a set of 2996 GM_KEY attributes which would allow all GMs except for the excluded 2997 one to get a new SA key. 2999 In the example below the GCKS excludes GM F. For this purpose it 3000 changes the key tree as follows, replacing the key 2 with the key 15 3001 and the key 5 with the key 16. It also generates a new SA key for a 3002 new SA3. 3004 SA3(K_sa3) 3005 +------------------------------+ 3006 1 15 3007 +---------------+ +---------------+ 3008 3 4 16 6 3009 +-------+ +-------+ +---- +--------+ 3010 A(7) B(8) C(9) D(10) E(11) F(12) G(13) H(14) 3012 Figure 29: LKH tree after F has been excluded 3014 Then it sends the following KD payload for the new Rekey SA3: 3016 KD(GP(SA3)(1{K_sa3},15{K_sa3}),MP(6{15},16{15},11{16}) 3018 KD Payload for the Group Member F 3020 While processing this KD payload: 3022 o GMs A, B, C and D will be able to decrypt the SA_KEY attribute 3023 1{K_sa3} by using the "1" key from their key path. Since no new 3024 GM_KEY attributes are in the new Key Path, they won't update their 3025 Working Key Paths. 3027 o GMs G and H will construct new Key Path 15->6 and will be able to 3028 decrypt the intermediate key 15 using the key 6 from their Working 3029 Key Paths. So, they will update their Working Key Paths replacing 3030 their beginnings up to the key 6 with the new Key Path (thus 3031 replacing the key 2 with the key 15). 3033 o GM E will construct new Key Path 16->15->11 and will be able to 3034 decrypt the intermediate key 16 using the key 11 from its Working 3035 Key Path. So, it will update its Working Key Path replacing its 3036 beginnings up to the key 11 with the new Key Path (thus replacing 3037 the key 2 with the key 15 and the key 5 with the key 16). 3039 o GM F won't be able to construct any Key Path leading to any key he 3040 possesses, so it will be unable to decrypt the new SA key for the 3041 SA3 and thus it will be excluded from the group once the SA3 is 3042 used. 3044 Finally, the GMs will have the following Working Key Paths: 3046 A: 1->3->7 B: 1->3->8 C: 1->4->9, D: 1->4->10 3047 E: 15->16->11 F: excluded G: 15->6->13 H: 15->6->14 3049 Authors' Addresses 3051 Valery Smyslov 3052 ELVIS-PLUS 3053 PO Box 81 3054 Moscow (Zelenograd) 124460 3055 Russian Federation 3057 Phone: +7 495 276 0211 3058 Email: svan@elvis.ru 3060 Brian Weis 3061 Independent 3062 USA 3064 Email: bew.stds@gmail.com