idnits 2.17.00 (12 Aug 2021) /tmp/idnits34170/draft-ietf-ipsecme-g-ikev2-06.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 (April 6, 2022) is 38 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 2450, but not defined == Missing Reference: 'S' is mentioned on line 2383, but not defined == Missing Reference: 'M' is mentioned on line 2332, but not defined -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 0 errors (**), 0 flaws (~~), 3 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 Updates: 7296 (if approved) Independent 6 Intended status: Standards Track April 6, 2022 7 Expires: October 8, 2022 9 Group Key Management using IKEv2 10 draft-ietf-ipsecme-g-ikev2-06 12 Abstract 14 This document presents an extension to the Internet Key Exchange 15 version 2 (IKEv2) protocol for the purpose of a group key management. 16 The protocol is in conformance with the Multicast Security (MSEC) key 17 management architecture, which contains two components: member 18 registration and group rekeying. Both components require a Group 19 Controller/Key Server to download IPsec group security associations 20 to authorized members of a group. The group members then exchange IP 21 multicast or other group traffic as IPsec packets. This document 22 obsoletes RFC 6407. This documents also updates RFC 7296 by renaming 23 one of transform types defined there. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 8, 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 62 2. G-IKEv2 Protocol . . . . . . . . . . . . . . . . . . . . . . 7 63 2.1. G-IKEv2 Integration into IKEv2 Protocol . . . . . . . . . 7 64 2.1.1. G-IKEv2 Transport and Port . . . . . . . . . . . . . 7 65 2.2. G-IKEv2 Payloads . . . . . . . . . . . . . . . . . . . . 8 66 2.3. G-IKEv2 Member Registration and Secure Channel 67 Establishment . . . . . . . . . . . . . . . . . . . . . . 9 68 2.3.1. GSA_AUTH exchange . . . . . . . . . . . . . . . . . . 9 69 2.3.2. GSA_REGISTRATION Exchange . . . . . . . . . . . . . . 11 70 2.3.3. GM Registration Operations . . . . . . . . . . . . . 12 71 2.3.4. GCKS Registration Operations . . . . . . . . . . . . 14 72 2.4. Group Maintenance Channel . . . . . . . . . . . . . . . . 15 73 2.4.1. GSA_REKEY . . . . . . . . . . . . . . . . . . . . . . 16 74 2.4.2. GSA_INBAND_REKEY Exchange . . . . . . . . . . . . . . 22 75 2.4.3. Deletion of SAs . . . . . . . . . . . . . . . . . . . 22 76 2.5. Counter-based modes of operation . . . . . . . . . . . . 23 77 2.5.1. Allocation of SIDs . . . . . . . . . . . . . . . . . 24 78 2.5.2. GM Usage of SIDs . . . . . . . . . . . . . . . . . . 25 79 2.6. Replay Protection for Multicast Data-Security SAs . . . . 25 80 3. Group Key Management and Access Control . . . . . . . . . . . 26 81 3.1. Key Wrap Keys . . . . . . . . . . . . . . . . . . . . . . 26 82 3.1.1. Default Key Wrap Key . . . . . . . . . . . . . . . . 27 83 3.2. GCKS Key Management Semantics . . . . . . . . . . . . . . 27 84 3.2.1. Forward Access Control Requirements . . . . . . . . . 28 85 3.3. GM Key Management Semantics . . . . . . . . . . . . . . . 28 86 3.4. SA Keys . . . . . . . . . . . . . . . . . . . . . . . . . 30 87 4. Header and Payload Formats . . . . . . . . . . . . . . . . . 31 88 4.1. G-IKEv2 Header . . . . . . . . . . . . . . . . . . . . . 31 89 4.2. Group Identification Payload . . . . . . . . . . . . . . 31 90 4.3. Security Association - GM Supported Transforms Payload . 31 91 4.4. Group Security Association Payload . . . . . . . . . . . 32 92 4.4.1. Group Policies . . . . . . . . . . . . . . . . . . . 32 93 4.4.2. Group Security Association Policy Substructure . . . 33 94 4.4.3. Group Associated Policy Substructure . . . . . . . . 40 95 4.5. Key Download Payload . . . . . . . . . . . . . . . . . . 42 96 4.5.1. Wrapped Key Format . . . . . . . . . . . . . . . . . 42 97 4.5.2. Group Key Packet Substructure . . . . . . . . . . . . 44 98 4.5.3. Member Key Packet Substructure . . . . . . . . . . . 46 99 4.6. Delete Payload . . . . . . . . . . . . . . . . . . . . . 48 100 4.7. Notify Payload . . . . . . . . . . . . . . . . . . . . . 48 101 4.7.1. USE_TRANSPORT_MODE Notification . . . . . . . . . . . 49 102 4.8. Authentication Payload . . . . . . . . . . . . . . . . . 50 103 5. Usigng G-IKEv2 Attributes . . . . . . . . . . . . . . . . . . 50 104 6. Interaction with other IKEv2 Protocol Extensions . . . . . . 52 105 6.1. Mixing Preshared Keys in IKEv2 for Post-quantum Security 53 106 7. Security Considerations . . . . . . . . . . . . . . . . . . . 55 107 7.1. GSA Registration and Secure Channel . . . . . . . . . . . 55 108 7.2. GSA Maintenance Channel . . . . . . . . . . . . . . . . . 55 109 7.2.1. Authentication/Authorization . . . . . . . . . . . . 55 110 7.2.2. Confidentiality . . . . . . . . . . . . . . . . . . . 55 111 7.2.3. Man-in-the-Middle Attack Protection . . . . . . . . . 55 112 7.2.4. Replay/Reflection Attack Protection . . . . . . . . . 55 113 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 114 8.1. New Registries . . . . . . . . . . . . . . . . . . . . . 56 115 8.2. Changes in the Existing IKEv2 Registries . . . . . . . . 57 116 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 59 117 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 60 118 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 119 11.1. Normative References . . . . . . . . . . . . . . . . . . 60 120 11.2. Informative References . . . . . . . . . . . . . . . . . 61 121 Appendix A. Use of LKH in G-IKEv2 . . . . . . . . . . . . . . . 65 122 A.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 65 123 A.2. Group Creation . . . . . . . . . . . . . . . . . . . . . 65 124 A.3. Simple Group SA Rekey . . . . . . . . . . . . . . . . . . 66 125 A.4. Group Member Exclusion . . . . . . . . . . . . . . . . . 66 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 128 1. Introduction and Overview 130 A group key management protocol provides IPsec keys and policy to a 131 set of IPsec devices which are authorized to communicate using a 132 Group Security Association (GSA) defined in [RFC3740]. The data 133 communications within the group (e.g., IP multicast packets) are 134 protected by a key pushed to the group members (GMs) by the Group 135 Controller/Key Server (GCKS). This document presents an extension to 136 IKEv2 [RFC7296] called G-IKEv2, that allows to perform a group key 137 management. 139 G-IKEv2 conforms to the Multicast Group Security Architecture 140 [RFC3740], Multicast Extensions to the Security Architecture for the 141 Internet Protocol [RFC5374] and the Multicast Security (MSEC) Group 142 Key Management Architecture [RFC4046]. G-IKEv2 replaces GDOI 143 [RFC6407], which defines a similar group key management protocol 144 using IKEv1 [RFC2409] (since deprecated by IKEv2). When G-IKEv2 is 145 used, group key management use cases can benefit from the simplicity, 146 increased robustness and cryptographic improvements of IKEv2 (see 147 Appendix A of [RFC7296]. 149 A GM begins a "registration" exchange when it first joins the group. 150 With G-IKEv2, the GCKS authenticates and authorizes GMs, then pushes 151 policy and keys used by the group to the GM. G-IKEv2 includes two 152 "registration" exchanges. The first is the GSA_AUTH exchange ( 153 Section 2.3.1), which is used when a GM first conatcts a GCKS. The 154 second is the GSA_REGISTRATION exchange (Section 2.3.2), which a GM 155 can use within an established IKE SA. Group rekeys are accomplished 156 using either the GSA_REKEY pseudo-exchange (a single message 157 distributed to all GMs, usually as a multicast message), or as a 158 GSA_INBAND_REKEY exchange delivered individually to group members 159 using existing IKE SAs). 161 Large and small groups may use different sets of these protocols. 162 When a large group of devices are communicating, the GCKS is likely 163 to use the GSA_REKEY message for efficiency. This is shown in 164 Figure 1. (Note: For clarity, IKE_SA_INIT is omitted from the 165 figure.) 167 +--------+ 168 +------------->| GCKS |<-------------+ 169 | +--------+ | 170 | | ^ | 171 | | | | 172 | | GSA_AUTH | 173 | | or | 174 | | GSA_REGISTRATION | 175 | | | | 176 GSA_AUTH | | GSA_AUTH 177 or GSA_REKEY | or 178 GSA_REGISTRATION | | GSA_REGISTRATION 179 | | | | 180 | +------------+-----------------+ | 181 | | | | | | 182 v v v v v v 183 +-------+ +--------+ +-------+ 184 | GM | ... | GM | ... | GM | 185 +-------+ +--------+ +-------+ 186 ^ ^ ^ 187 | | | 188 +-------ESP-------+-------ESP------+ 190 Figure 1: G-IKEv2 used in large groups 192 Alternatively, a small group may simply use the GSA_AUTH as a 193 registration protocol, where the GCKS issues rekeys using the 194 GSA_INBAND_REKEY within the same IKE SA. The GCKS is also likely to 195 be a GM in a small group (as shown in Figure 2.) 197 GSA_AUTH, GSA_INBAND_REKEY 198 +-----------------------------------------------+ 199 | | 200 | GSA_AUTH, GSA_INBAND_REKEY | 201 | +-----------------------------+ | 202 | | | | 203 | | GSA_AUTH, GSA_INBAND_REKEY | | 204 | | +--------+ | | 205 v v v v v v 206 +---------+ +----+ +----+ +----+ 207 | GCKS/GM | | GM | | GM | | GM | 208 +---------+ +----+ +----+ +----+ 209 ^ ^ ^ ^ 210 | | | | 211 +----ESP-----+------ESP-------+-----ESP-----+ 213 Figure 2: G-IKEv2 used in small groups 215 A combination of these approaches is also possible. For example, the 216 GCKS may use more robust GSA_INBAND_REKEY to provide keys for some 217 GMs (for example, those acting as senders in the group) and GSA_REKEY 218 for the rest. 220 IKEv2 message semantics are preserved in that all communications 221 consists of message request-response pairs. The exception to this 222 rule is the GSA_REKEY pseudo-exchange, which is a single message 223 delivering group updates to the GMs. 225 1.1. Requirements Notation 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 229 "OPTIONAL" in this document are to be interpreted as described in BCP 230 14 [RFC2119] [RFC8174] when, and only when, they appear in all 231 capitals, as shown here. 233 1.2. Terminology 235 It is assumed that readers are familiar with the IPsec architecture 236 [RFC4301], its extension for multicast [RFC5374]. This document 237 defines an extension to the IKEv2 protocol [RFC7296], so it is 238 assumed that readers have good understanding of this protocol. 240 The following key terms are used throughout this document (mostly 241 borrowed from [RFC5374] and [RFC6407]). 243 Group 244 A set of devices that work together to protect group 245 communications. 247 Group Member (GM) 248 An IPsec device that belongs to a group. A Group Member is 249 authorized to be a Group Sender and/or a Group Receiver. 251 Group Receiver 252 A Group Member that is authorized to receive packets sent to a 253 group by a Group Sender. 255 Group Sender 256 A Group Member that is authorized to send packets to a group. 258 Group Key Management (GKM) Protocol 259 A key management protocol used by a GCKS to distribute IPsec 260 Security Association policy and keying material. A GKM 261 protocol is used when a group of IPsec devices require the same 262 SAs. For example, when an IPsec SA describes an IP multicast 263 destination, the sender and all receivers need to have the 264 group SA. 266 Group Controller Key Server (GCKS) 267 A Group Key Management (GKM) protocol server that manages IPsec 268 state for a group. A GCKS authenticates and provides the IPsec 269 SA policy and keying material to GKM Group Members. 271 Data-Security SA 272 The security policy distributed by a GDOI GCKS describing 273 traffic that is expected to be protected by group members. 274 This document described the distribution of IPsec AH and ESP 275 Data-Security SAs. 277 Rekey SA 278 The security policy protecting Group Key Management Protocol. 280 Group Security Association (GSA) 281 A collection of Data-Security Associations (SAs) and Rekey SAs 282 necessary for a Group Member to receive key updates. A GSA 283 describes the working policy for a group. Refer to [RFC4046] 284 for additional information. 286 Traffic Encryption Key (TEK) 287 The symmetric cipher key used in a Data-Security SA (e.g., 288 IPsec ESP) to protect trafic. 290 Key Encryption Key (KEK) 291 The symmetric cipher key used in a Rekey SA to protect 292 distribution of new keys. 294 Key Wrap Key (KWK) 295 The symmetric cipher key used to protect another key. 297 Group Associated Policy (GAP) 298 Group-wide policy not related to a particular SA. 300 Sender-ID (SID) 301 A unigue identifier of a Group Sender in the context of an 302 active GSA, used to form Initialization Vector (IV) in counter- 303 based cipher modes. 305 Logical Key Hierarchy (LKH) 306 A group management method defined in Section 5.4 of [RFC2627]. 308 2. G-IKEv2 Protocol 310 2.1. G-IKEv2 Integration into IKEv2 Protocol 312 G-IKEv2 is an extension to IKEv2 and uses its security mechanisms 313 (peer authentication, confidentiality, message integrity) to ensure 314 that only authenticated devices have access to the group policy and 315 keys. G-IKEv2 further provides group authorization, and secure 316 policy and key download from the GCKS to GMs. 318 G-IKEv2 is compatible with most IKEv2 extensions defined so far and 319 it is believed that future IKEv2 extensions will also be possible to 320 use with G-IKEv2. However some IKEv2 extensions require special 321 handling if used with G-IKEv2. See Section 6 for more details. 323 It is assumed that readers are familiar with the IKEv2 protocol, so 324 this document skips many details that are described in [RFC7296]. 326 2.1.1. G-IKEv2 Transport and Port 328 G-IKEv2 SHOULD use UDP port 848, the same as GDOI [RFC6407], because 329 they serve a similar function. They can use the same ports, just as 330 IKEv1 and IKEv2 can share port 500. The version number in the IKE 331 header distinguishes the G-IKEv2 protocol from GDOI protocol 332 [RFC6407]. G-IKEv2 MAY also use the IKEv2 ports (500, 4500), which 333 would provide a better integration with IKEv2. G-IKEv2 MAY also use 334 TCP transport for registration (unicast) IKE SA, as defined in 335 [RFC8229]. 337 Section 2.23 of [RFC7296] describes how IKEv2 deals with NATs. 338 Despite the fact, that with G-IKEv2 the registration SA doesn't 339 create any unicast IPsec SAs and thus there is no unicast ESP traffic 340 between the GM and the GCKS to encapsulate in UDP if NAT is present, 341 the actions described in this section concerned with the IKE SA MUST 342 be honored. If the GM and the GCKS used UDP port 848 for the 343 IKE_SA_INIT exchange, they MUST behave as if they used UDP port 500. 345 2.2. G-IKEv2 Payloads 347 In the following descriptions, the payloads contained in the G-IKEv2 348 messages are indicated by names as listed below. 350 Notation Payload 351 ------------------------------------------------------------ 352 AUTH Authentication 353 CERT Certificate 354 CERTREQ Certificate Request 355 D Delete 356 GSA Group Security Association 357 HDR IKEv2 Header 358 IDg Identification - Group 359 IDi Identification - Initiator 360 IDr Identification - Responder 361 KD Key Download 362 KE Key Exchange 363 Ni, Nr Nonce 364 N Notify 365 SA Security Association 366 SAg Security Association - GM Supported Transforms 368 Payloads defined as part of other IKEv2 extensions MAY also be 369 included in these messages. Payloads that may optionally appear in 370 G-IKEv2 messages will be shown in brackets, such as [CERTREQ]. 372 G-IKEv2 defines several new payloads not used in IKEv2: 374 o IDg (Group ID) -- The GM requests the GCKS for membership into the 375 group by sending its IDg payload. 377 o GSA (Group Security Association) -- The GCKS sends the group 378 policy to the GM using this payload. 380 o KD (Key Download) -- The GCKS sends the keys and the security 381 parameters to the GMs using the KD payload. 383 o SAg (Security Association -- GM Supported Transforms) -- the GM 384 sends supported transforms, so that GCKS may select a policy 385 appropriate for all members of the group. 387 The details of the contents of each payload are described in 388 Section 4. 390 2.3. G-IKEv2 Member Registration and Secure Channel Establishment 392 The registration protocol consists of a minimum of two exchanges, 393 IKE_SA_INIT and GSA_AUTH; member registration may have a few more 394 messages exchanged if the EAP method, cookie challenge (for DoS 395 protection), negotiation of Diffie-Hellman group or IKEv2 extensions 396 based on [I-D.ietf-ipsecme-ikev2-intermediate] are used. Each 397 exchange consists of request/response pairs. The first exchange 398 IKE_SA_INIT is defined in IKEv2 [RFC7296]. This exchange negotiates 399 cryptographic algorithms, exchanges nonces and computes a shared key 400 between the GM and the GCKS. 402 The second exchange GSA_AUTH authenticates the previously exchanged 403 messages, exchanges identities and certificates. The GSA_AUTH 404 messages are encrypted and integrity protected with keys established 405 through the previous exchanges, so the identities are hidden from 406 eavesdroppers and all fields in all the messages are authenticated. 407 The GCKS SHOULD authorize group members to be allowed into the group 408 as part of the GSA_AUTH exchange. Once the GCKS accepts a group 409 member to join a group it will download the data security keys (TEKs) 410 and/or group key encrypting key (KEK) as part of the GSA_AUTH 411 response message. 413 2.3.1. GSA_AUTH exchange 415 After the group member and GCKS negotiate cryptographic algorithms, 416 exchange nonces, and compute shared keys as defined in IKEv2 417 [RFC7296], the GSA_AUTH exchange MUST complete before any other 418 exchanges defined in this document can be done. GSA_AUTH is used to 419 authenticate the previous exchanges, exchange identities and 420 certificates. G-IKEv2 also uses this exchange for group member 421 registration and authorization. 423 The GSA_AUTH exchange is identical to the IKE_AUTH exchange with the 424 difference that its goal is to establish multicast Data-Security SAs 425 and optionally provide GM with the keys for Rekey SA. The set of 426 payloads in the GSA_AUTH exchange is slightly different, because 427 policy is not negotiated between the group member and the GCKS, but 428 instead downloaded from the GCKS to the group member. Note also, 429 that GSA_AUTH has its own exchange type, which is different from the 430 IKE_AUTH exchange type. 432 Nevertheless, the security properties of the GSA_AUTH exchange are 433 the same as the properties of the IKE_AUTH exchange and most IKEv2 434 extensions to the IKE_AUTH exchange (like [RFC6467]) can also be used 435 with the GSA_AUTH exchange. 437 Initiator (Member) Responder (GCKS) 438 -------------------- ------------------ 439 HDR, SK{IDi, [CERT,] [CERTREQ,] [IDr,] 440 AUTH, IDg, [SAg,] [N]} --> 442 Figure 3: GSA_AUTH Request 444 A group member initiates a GSA_AUTH request to join a group indicated 445 by the IDg payload. The GM MAY include an SAg payload declaring 446 which Transforms it is willing to accept. A GM that intends to act 447 as Group Sender SHOULD include a Notify payload status type of 448 SENDER, which enables the GCKS to provide any additional policy 449 necessary by group senders. 451 Initiator (Member) Responder (GCKS) 452 -------------------- ------------------ 453 <-- HDR, SK{IDr, [CERT,] 454 AUTH, [GSA, KD,] [N,]} 456 Figure 4: GSA_AUTH Normal Response 458 The GCKS responds with IDr, optional CERT, and AUTH payloads as if it 459 were an IKE_AUTH. It also informs the group member of the 460 cryptographic policies of the group in the GSA payload and the key 461 material in the KD payload. 463 In addition to the IKEv2 error handling, the GCKS can reject the 464 registration request when the IDg is invalid or authorization fails, 465 etc. In these cases, see Section 4.7, the GSA_AUTH response will not 466 include the GSA and KD, but will include a Notify payload indicating 467 errors. If a GM included an SAg payload, and the GCKS chooses to 468 evaluate it, and the GCKS detects that the group member cannot 469 support the security policy defined for the group, then the GCKS 470 SHOULD return a NO_PROPOSAL_CHOSEN. Other types of error 471 notifications can be INVALID_GROUP_ID, AUTHORIZATION_FAILED or 472 REGISTRATION_FAILED. 474 Initiator (Member) Responder (GCKS) 475 -------------------- ------------------ 476 <-- HDR, SK{IDr, [CERT,] AUTH, N} 478 Figure 5: GSA_AUTH Error Response 480 If the group member finds the policy sent by the GCKS is 481 unacceptable, the member SHOULD initiate GSA_REGISTRATION exchange 482 sending IDg and the Notify NO_PROPOSAL_CHOSEN (see Section 2.3.2)). 484 2.3.2. GSA_REGISTRATION Exchange 486 When a secure channel is already established between a GM and the 487 GCKS, the GM registration for a group can reuse the established 488 secure channel. In this scenario the GM will use the 489 GSA_REGISTRATION exchange. Payloads in the exchange are generated 490 and processed as defined in Section 2.3.1. 492 Initiator (Member) Responder (GCKS) 493 -------------------- ------------------ 494 HDR, SK{IDg, [SAg,][N ]} --> 495 <-- HDR, SK{GSA,] [N,]} 497 Figure 6: GSA_REGISTRATION Normal Exchange 499 As with GSA_AUTH exchange, the GCKS can reject the registration 500 request when the IDg is invalid or authorization fails, or GM cannot 501 support the security policy defined for the group (which can be 502 concluded by GCKS by evaluation of SAg payload). In this case the 503 GCKS returns an appropriate error notification as described in 504 Section 2.3.1. 506 Initiator (Member) Responder (GCKS) 507 -------------------- ------------------ 508 HDR, SK{IDg, [SAg,] [N]} --> 509 <-- HDR, SK{N} 511 Figure 7: GSA_REGISTRATION Error Exchange 513 This exchange can also be used if the group member finds the policy 514 sent by the GCKS is unacceptable. The group member SHOULD notify the 515 GCKS by sending IDg and the Notify type NO_PROPOSAL_CHOSEN, as shown 516 below. The GCKS in this case MUST remove the GM from the group IDg. 518 Initiator (Member) Responder (GCKS) 519 -------------------- ------------------ 520 HDR, SK{IDg, N} --> 521 <-- HDR, SK{} 523 Figure 8: GM Reporting Errors in GSA_REGISTRATION Exchange 525 2.3.3. GM Registration Operations 527 A G-IKEv2 Initiator (GM) requesting registration contacts the GCKS 528 using the IKE_SA_INIT exchange and receives the response from the 529 GCKS. This exchange is unchanged from the IKE_SA_INIT in IKEv2 530 protocol. The IKE_SA_INIT exchange may optionally be followed by one 531 or more the IKE_INTERMEDIATE exchanges if the GM and the GCKS 532 negotiated using IKEv2 extensions based on this exchange. 534 Next the GM sends the GSA_AUTH request message with the IKEv2 535 payloads from IKE_AUTH (without the SAi2, TSi and TSr payloads) along 536 with the Group ID informing the GCKS of the group the initiator 537 wishes to join. An initiator intending to emit data traffic SHOULD 538 send a SENDER Notify payload status. The SENDER notification not 539 only signifies that it is a sender, but provides the initiator the 540 ability to request Sender-ID (SID) values, in case the Data-Security 541 SA supports a counter mode cipher. Section 2.5) includes guidance on 542 requesting Sender-ID values. 544 A GM may be limited in the types of Transforms that it is able or 545 willing to use, and may find it useful to inform the GCKS which 546 Transforms it is willing to accept for different security protocols 547 by including the SAg payload into the request message. Proposals for 548 Rekey SA (with protocol GIKE_REKEY) and for Data-Security (AH 549 [RFC4302] and/or ESP [RFC4303]) SAs may be included into SAg. Each 550 Proposal contains a list of Transforms that the GM is able and 551 willing to support for that protocol. Valid transform types depend 552 on the protocol and are defined in Figure 16. Other transform types 553 SHOULD NOT be included. The SPI length of each Proposal in an SAg is 554 set to zero, and thus the SPI field is empty. The GCKS MUST ignore 555 SPI length and SPI fields in the SAg payload. 557 Generally, a single Proposal of each type will suffice, because the 558 group member is not negotiating Transform sets, simply alerting the 559 GCKS to restrictions it may have. In particular, the restriction 560 from Section 3.3 of [RFC7296] that AEAD and non-AEAD transforms must 561 not be combined in a single proposal doesn't hold when the SAg 562 payload is being formed. However if the GM has restrictions on 563 combination of algorithms, this can be expressed by sending several 564 proposals. 566 Proposal Num field in Proposal substructure is treated specially in 567 SAg payload: it allows a GM to indicate that algorithms used in Rekey 568 SA and in Data-Security (AH and/or ESP) SAs are dependent. In 569 particular, Proposals of different types having the same value in 570 Proposal Num field are treated as a set, so that if GCKS uses 571 transforms from one of such Proposal for one protocol, then it MUST 572 only use transforms from one of the Proposals with the same value in 573 Proposal Num field for other protocols. For example, a GM may 574 support algorithms X and Y for both Rekey and Data-Security SAs, but 575 with a restriction that if X is used in Rekey SA, then only X can be 576 used in Data-Security SAs, and the same for Y. To indicate this the 577 GM sends several Proposals marking those of them that must be used in 578 conjunction by putting the same value in their Proposal Num field. 579 In the simplest case when no dependency between transforms exists, 580 all Proposals in SAg payload will have the same value in Proposal Num 581 field. 583 Although the SAg payload is optional, it is RECOMMENDED for the GM to 584 include this payload into the GSA_AUTH request to allow the GCKS to 585 select an appropriate policy. 587 A GM may also indicate the support for IPcomp by inclusion one or 588 more the IPCOMP_SUPPORTED notifications along with the SAg payload. 589 The CPI in these notifications is set to zero and MUST be ignored by 590 the GCKS. 592 Upon receiving the GSA_AUTH response, the initiator parses the 593 response from the GCKS authenticating the exchange using the IKEv2 594 method, then processes the GSA and KD payloads. 596 The GSA payload contains the security policy and cryptographic 597 protocols used by the group. This policy describes the optional 598 Rekey SA (KEK), Data-security SAs (TEK), and optional Group 599 Associated policy (GAP). If the policy in the GSA payload is not 600 acceptable to the GM, it SHOULD notify the GCKS by initiating a 601 GSA_REGISTRATION exchange with a NO_PROPOSAL_CHOSEN Notify payload 602 (see Section 2.3.2). Note, that this should normally not happen if 603 the GM includes SAg payload in the GSA_AUTH request and the GCKS 604 takes it into account. Finally the KD payload is parsed providing 605 the keying material for the TEK and/or KEK. The GM interprets the KD 606 key packets, where each key packet includes the keying material for 607 SAs distributed in the GSA payload. Keying material is matched by 608 comparing the SPIs in the key packets to SPIs previously included in 609 the GSA payloads. Once TEK keys and policy are matched, the GM 610 provides them to the data security subsystem, and it is ready to send 611 or receive packets matching the TEK policy. 613 The GSA KEK policy MUST include the attribute GSA_INITIAL_MESSAGE_ID 614 with a first Message ID the GM should expect to receive if it is non- 615 zero. The value of the attribute MUST be checked by a GM against any 616 previously received Message ID for this group. If it is less than 617 the previously received number, it should be considered stale and 618 ignored. This could happen if two GSA_AUTH exchanges happened in 619 parallel, and the Message ID changed. This attribute is used by the 620 GM to prevent GSA_REKEY message replay attacks. The first GSA_REKEY 621 message that the GM receives from the GCKS must have a Message ID 622 greater or equal to the Message ID received in the 623 GSA_INITIAL_MESSAGE_ID attribute. 625 Once a GM successfully registers to the group it MUST replace any 626 information related to this group (policy, keys) that it might have 627 as a result of a previous registration with a new one. 629 Once a GM has received GIKE_REKEY policy during a registration the 630 IKE SA may be closed. However, the GM SHOULD NOT close IKE SA, it is 631 the GCKS who makes the decision whether to close or keep it, because 632 depending on the policy the IKE SA may be used for inband rekeying 633 for small groups. If inband rekeying is used, then the initial IKE 634 SA is rekeyed (when necessary) via standard IKEv2 mechanism described 635 in Section 1.3.2 of [RFC7296]. If for some reason this SA is teared 636 down and no GIKE_REKEY policy was received during the registration 637 process, the GM MUST consider itself excluded from the group. To 638 continue participating in the group the GM should re-register. 640 2.3.4. GCKS Registration Operations 642 A G-IKEv2 GCKS passively listens for incoming requests from group 643 members. When the GCKS receives an IKE_SA_INIT request, it selects 644 an IKE proposal and generates a nonce and DH to include them in the 645 IKE_SA_INIT response. 647 Upon receiving the GSA_AUTH request, the GCKS authenticates the group 648 member using the same procedures as in the IKEv2 IKE_AUTH. The GCKS 649 then authorizes the group member according to group policy before 650 preparing to send the GSA_AUTH response. If the GCKS fails to 651 authorize the GM, it will respond with an AUTHORIZATION_FAILED notify 652 message. The GCKS may also respond with an INVALID_GROUP_ID notify 653 message if the requested group is unknown to the GCKS or with an 654 REGISTRATION_FAILED notify message if there is a problem with the 655 requested group (for example the capacity of the group is exceeded). 657 The GSA_AUTH response will include the group policy in the GSA 658 payload and keys in the KD payload. If the GCKS policy includes a 659 group rekey option, it MUST include the GSA_INITIAL_MESSAGE_ID 660 attribute, specifying the starting Message ID the GCKS will use when 661 sending the GSA_REKEY message to the group members if this Message ID 662 is non-zero. This Message ID is used to prevent GSA_REKEY message 663 replay attacks and will be increased each time a GSA_REKEY message is 664 sent to the group. The GCKS data traffic policy is included in the 665 GSA TEK and keys are included in the KD TEK. The GAP MAY also be 666 included to provide the ATD and/or DTD (Section 4.4.3.1) specifying 667 activation and deactivation delays for SAs generated from the TEKs. 668 If the group member has indicated that it is a sender of data traffic 669 and one or more Data Security SAs distributed in the GSA payload 670 included a counter mode of operation, the GCKS responds with one or 671 more SIDs (see Section 2.5). 673 [RFC5374] defines two modes of operation for multicast Data-Securirt 674 SAs: transport mode and tunnel mode with address preservation. In 675 the latter case outer source and destination addresses are taken from 676 the inner IP packet. 678 If the GCKS receives a GSA_REGISTRATION exchange with a request to 679 register a GM to a group, the GCKS will need to authorize the GM with 680 the new group (IDg) and respond with the corresponding group policy 681 and keys. If the GCKS fails to authorize the GM, it will respond 682 with the AUTHORIZATION_FAILED notification. The GCKS may also 683 respond with an INVALID_GROUP_ID or REGISTRATION_FAILED notify 684 messages for the reasons described above. 686 If a group member includes an SAg in its GSA_AUTH or GSA_REGISTRATION 687 request, the GCKS may evaluate it according to an implementation 688 specific policy. 690 o The GCKS could evaluate the list of Transforms and compare it to 691 its current policy for the group. If the group member did not 692 include all of the ESP or AH Transforms that match the current 693 group policy, then the GCKS SHOULD return a NO_PROPOSAL_CHOSEN 694 Notification. 696 o The GCKS could store the list of Transforms, with the goal of 697 migrating the group policy to a different Transforms when all of 698 the group members indicate that they can support that Transforms. 700 o The GCKS could store the list of Transforms and adjust the current 701 group policy based on the capabilities of the devices as long as 702 they fall within the acceptable security policy of the GCKS. 704 Depending on its policy, the GCKS may have no need for the IKE SA 705 (e.g., it does not plan to initiate an GSA_INBAND_REKEY exchange). 706 If the GM does not initiate another registration exchange or Notify 707 (e.g., NO_PROPOSAL_CHOSEN), and also does not close the IKE SA and 708 the GCKS is not intended to use the SA, then after a short period of 709 time the GCKS SHOULD close the IKE SA. 711 2.4. Group Maintenance Channel 713 The GCKS is responsible for rekeying the secure group per the group 714 policy. Rekeying is an operation whereby the GCKS provides 715 replacement TEKs and KEK, deleting TEKs, and/or excluding group 716 members. The GCKS may initiate a rekey message if group membership 717 and/or policy has changed, or if the keys are about to expire. Two 718 forms of group maintenance channels are provided in G-IKEv2 to push 719 new policy to group members. 721 GSA_REKEY The GSA_REKEY is a pseudo-exchange initiated by the GCKS, 722 where the rekey policy is usually delivered to group members 723 using IP multicast as a transport. This is not a real IKEv2 724 exchange, since no response messages are sent. This method is 725 valuable for large and dynamic groups, and where policy may 726 change frequently and a scalable rekeying method is required. 727 When the GSA_REKEY is used, the IKE SA protecting the member 728 registration exchanges is usually terminated, and group members 729 await policy changes from the GCKS via the GSA_REKEY messages. 731 GSA_INBAND_REKEY The GSA_INBAND_REKEY is a normal IKEv2 exchange 732 using the IKE SA that was setup to protecting the member 733 registration exchange. This exchange allows the GCKS to rekey 734 without using an independent GSA_REKEY pseudo-exchange. The 735 GSA_INBAND_REKEY exchange provides a reliable policy delivery 736 and is useful when G-IKEv2 is used with a small group of 737 cooperating devices. 739 Depending on its policy the GCKS MAY combine these two methods. For 740 example, it may use the GSA_INBAND_REKEY to deliver key to the GMs in 741 the group acting as senders (as this would provide reliable keys 742 delivery), and the GSA_REKEY for the rest GMs. 744 2.4.1. GSA_REKEY 746 The GCKS initiates the G-IKEv2 Rekey securely, usually using IP 747 multicast. Since this rekey does not require a response and it sends 748 to multiple GMs, G-IKEv2 rekeying MUST NOT use IKE SA windowing 749 mechanism, described in Section 2.3 of [RFC7296]. The GCKS rekey 750 message replaces the rekey GSA KEK or KEK array, and/or creates a new 751 Data-Security GSA TEK. The GM_SID attribute in the Key Download 752 payload (defined in Section 4.5.3.3) MUST NOT be part of the Rekey 753 Exchange as this is sender specific information and the Rekey 754 Exchange is group specific. The GCKS initiates the GSA_REKEY pseudo- 755 exchange as following: 757 Members (Responder) GCKS (Initiator) 758 -------------------- ------------------ 759 <-- HDR, SK{GSA, KD, [N,] [D,] [AUTH]} 761 Figure 9: GSA_REKEY Pseudo-Exchange 763 HDR is defined in Section 4.1. The Message ID in this message will 764 start with the value the GCKS sent to the group members in the 765 attribute GSA_INITIAL_MESSAGE_ID or from zero if this attribute 766 wasn't sent. The Message ID will be incremented each time a new 767 GSA_REKEY message is sent to the group members. 769 The GSA payload contains the current policy for rekey and Data- 770 Security SAs. The GSA may contain a new Rekey SA and/or a new Data- 771 Security SAs Section 4.4. 773 The KD payload contains the keys for the policy included in the GSA. 774 If the Data-Security SA is being refreshed in this rekey message, the 775 IPsec keys are updated in the KD, and/or if the rekey SA is being 776 refreshed in this rekey message, the rekey Key or the LKH KEK array 777 is updated in the KD payload. 779 A Delete payload MAY be included to instruct the GM to delete 780 existing SAs. See Section 4.6 for more detail. 782 The AUTH payload MUST be included to authenticate the GSA_REKEY 783 message if the authentication method is based on public key 784 signatures and MUST NOT be included if authentication is implicit. 785 In the latter case, the fact that a GM can decrypt the GSA_REKEY 786 message and verify its ICV proves that the sender of this message 787 knows the current KEK, thus authenticating the sender as a member of 788 the group. Note, that implicit authentication doesn't provide source 789 origin authentication. For this reason using implicit authentication 790 for GSA_REKEY is NOT RECOMMENDED unless source origin authentication 791 is not required (for example, in a small group of highly trusted 792 GMs). The value of the Auth Method field in the AUTH payload in the 793 GSA_REKEY message MUST NOT be NULL Authentication. 795 During group member registration, the GCKS sends the authentication 796 key in the KD payload, AUTH_KEY attribute, which the group member 797 uses to authenticate the key server. Before the current 798 Authentication Key expires, the GCKS will send a new AUTH_KEY to the 799 group members in a GSA_REKEY message. The AUTH key that is sent in 800 the rekey message may be not the same as the authentication key sent 801 during the GM registration. If implicit authentication is used, then 802 AUTH_KEY MUST NOT be sent to GMs. 804 2.4.1.1. GSA_REKEY Messages Authentication 806 The content of the AUTH payload depends on the authentication method 807 and is either a digital signature or a result of prf applied to the 808 content of the not yet encrypted GSA_REKEY message. 810 The authentication algorithm (prf or digital signing) is applied to 811 the concatenation of two chunks: A and P. The chunk A lasts from the 812 first octet of the G-IKEv2 header (not including prepended four 813 octets of zeros, if port 4500 is used) to the last octet of the 814 Encrypted Payload header. The chunk P consists of the not yet 815 encrypted content of the Encrypted payload, excluding the 816 Initialization Vector, the Padding, the Pad Length and the Integrity 817 Checksum Data fields (see 3.14 of [RFC7296] for description of the 818 Encrypted payload). In other words, the P chunk is the inner 819 payloads of the Encrypted payload in plaintext form. Figure 10 820 illustrates the layout of the P and A chunks in the GSA_REKEY 821 message. 823 Before the AUTH payload calculation the inner payloads of Encrypted 824 payload must be fully formed and ready for encryption except for the 825 AUTH payload. The AUTH payload must have correct values in the 826 Payload Header, the Auth Method and the RESERVED fields. The 827 Authentication Data field is zeroed, but if Digital Signature 828 authentication method is in use, then the ASN.1 Length and the 829 AlgorithmIdentifier fields must be properly filled in, see [RFC7427]. 831 For the purpose of the AUTH payload calculation the Length field in 832 the IKE header and the Payload Length field in the Encrypted Payload 833 header are adjusted so that they don't count the lengths of 834 Initialization Vector, Integrity Checksum Data and Padding (along 835 with Pad Length field). In other words, the Length field in the IKE 836 header (denoted as AdjustedLen in Figure 10 ) is set to the sum of 837 the lengths of A and P, and the Payload Length field in the Encrypted 838 Payload header (denoted as AdjustedPldLen in Figure 10) is set to the 839 length of P plus the size of the Payload header (four octets). 841 DataToAuthenticate = A | P 842 GsaRekeyMessage = GenIKEHDR | EncPayload 843 GenIKEHDR = [ four octets 0 if using port 4500 ] | AdjustedIKEHDR 844 AdjustedIKEHDR = SPIi | SPIr | . . . | AdjustedLen 845 EncPayload = AdjustedEncPldHdr | IV | InnerPlds | Pad | PadLen | ICV 846 AdjustedEncPldHdr = NextPld | C | RESERVED | AdjustedPldLen 847 A = AdjustedIKEHDR | AdjustedEncPldHdr 848 P = InnerPlds 849 1 2 3 850 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 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^ 852 | G-IKEv2 SA Initiator's SPI | | | 853 | | | | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I | 855 | G-IKEv2 SA Responder's SPI | K | 856 | | E | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 858 | Next Payload | MjVer | MnVer | Exchange Type | Flags | H A 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | 860 | Message ID | r | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 862 | AdjustedLen | | | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ x | 864 | Next Payload |C| RESERVED | AdjustedPldLen | | | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v 866 | | | 867 ~ Initialization Vector ~ E 868 | | n 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^ 870 | | r | 871 ~ Inner payloads (not yet encrypted) ~ P 872 | | P | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v 874 ~ Padding (0-255 octets) | Pad Length | d 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 876 | | | 877 ~ Integrity Checksum Data ~ | 878 | | | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 881 Figure 10: Data to Authenticate in the GSA_REKEY Messages 883 The authentication data is calculated using the authentication 884 algorithm from the Authentication Method transform and the current 885 authentication key provided in the AUTH_KEY attribute. Depending on 886 the authentication method the authentication data is a digital 887 signature or a result of applying prf from the Pseudorandom Function 888 transform. The calculated authentication data is placed into the 889 AUTH payload, the Length fields in the IKE Header and the Encryption 890 Payload header are restored, the content of the Encrypted payload is 891 encrypted and the ICV is computed using the current KEK keys. 893 2.4.1.2. IKE Fragmentation 895 IKE fragmentation [RFC7383] can be used to perform fragmentation of 896 large GSA_REKEY messages, however when the GSA_REKEY message is 897 emitted as an IP multicast packet there is a lack of response from 898 the GMs. This has the following implications. 900 o Policy regarding the use of IKE fragmentation is implicit. If a 901 GCKS detects that all GMs have negotiated support of IKE 902 fragmentation in IKE_SA_INIT, then it MAY use IKE fragmentation on 903 large GSA_REKEY messages. 905 o The GCKS must always use IKE fragmentation based on a known 906 fragmentation threshold (unspecified in this memo), as there is no 907 way to check if fragmentation is needed by first sending 908 unfragmented messages and waiting for response. 910 o PMTU probing cannot be performed due to lack of GSA_REKEY response 911 message. 913 The calculation of authentication data MUST be applied to whole 914 messages only, before possible IKE Fragmentation. If the message was 915 received in fragmented form, it should be reconstructed before 916 verifying its authenticity as if it were received unfragmented. The 917 RESERVED field in the reconstructed Encrypted Payload header MUST be 918 set to the value of the RESERVED field in the Encrypted Fragment 919 payload header from the first fragment (that with Fragment Number 920 equal to 1). 922 2.4.1.3. GSA_REKEY GCKS Operations 924 The GCKS builds the rekey message with a Message ID value that is one 925 greater than the value included in the previous rekey message. The 926 first message sent over a new Rekey SA must have the Message ID 0. 927 The GSA, KD, N and D payloads follow with the same characteristics as 928 in the GSA Registration exchange. The AUTH payload (if present) is 929 created as defined in Section 2.4.1.1. 931 Because GSA_REKEY messages are not acknowledged and could be 932 discarded by the network, one or more GMs may not receive the new 933 policy. To mitigate such lost messages, during a rekey event the 934 GCKS may transmit several GSA_REKEY messages with the new policy. 935 The retransmitted messages MUST be bitwise identical and SHOULD be 936 sent within a short time interval (a few seconds) to ensure that 937 time-to-live would not be substantially skewed for the GMs that would 938 receive different copies of the messages. 940 GCKS may also include one or several GSA_NEXT_SPI attributes 941 specifying SPIs for the prospected rekeys, so that listening GMs are 942 able to detect lost rekey messages and recover from this situation. 943 See Sections Section 4.4.2.2.3 for more detail. 945 2.4.1.4. GSA_REKEY GM Operations 947 When a group member receives the Rekey Message from the GCKS it 948 decrypts the message using the current KEK, validates its 949 authenticity using the key retrieved in a previous G-IKEv2 exchange 950 if AUTH payload is present, verifies the Message ID, and processes 951 the GSA and KD payloads. The group member then downloads the new 952 Data-Security SA and/or new Rekey SA. The parsing of the payloads is 953 identical to the parsing done in the registration exchange. 955 Replay protection is achieved by a group member rejecting a GSA_REKEY 956 message which has a Message ID smaller than the current Message ID 957 that the GM is expecting. The GM expects the Message ID in the first 958 GSA_REKEY message it receives to be equal or greater than the Message 959 ID it receives in the GSA_INITIAL_MESSAGE_ID attribute. Note, that 960 if no this attribute was received for the Rekey SA, the GM MUST 961 assume zero as the first expected Message ID. The GM expects the 962 Message ID in subsequent GSA_REKEY messages to be greater than the 963 last valid GSA_REKEY message ID it received. 965 If the GSA payload includes a Data-Security SA using cipher in a 966 counter-modes of operation and the receiving group member is a sender 967 for that SA, the group member uses its current SID value with the 968 Data-Security SAs to create counter-mode nonces. If it is a sender 969 and does not hold a current SID value, it MUST NOT install the Data- 970 Security SAs. It MAY initiate a GSA_REGISTRATION exchange to the 971 GCKS in order to obtain an SID value (along with the current group 972 policy). 974 Once a new Rekey SA is installed as a result of GSA_REKEY message, 975 the current Rekey SA (over which the message was received) MUST be 976 silently deleted after waiting DEACTIVATION_TIME_DELAY interval 977 regardless of its expiration time. If the message includes Delete 978 payload for existing Data-security SA, then after installing a new 979 Data-Security SA the old one, identified by the Protocol and SPI 980 fields in the Delete payload, MUST be silently deleted after waiting 981 DEACTIVATION_TIME_DELAY interval regardless of its expiration time. 983 If a Data-Security SA is not rekeyed yet and is about to expire (a 984 "soft lifetime" expiration is described in Section 4.4.2.1 of 985 [RFC4301]), the GM SHOULD initiate a registration to the GCKS. This 986 registration serves as a request for current SAs, and will result in 987 the download of replacement SAs, assuming the GCKS policy has created 988 them. A GM SHOULD also initiate a registration request if a Rekey SA 989 is about to expire and not yet replaced with a new one. 991 2.4.2. GSA_INBAND_REKEY Exchange 993 When the IKE SA protecting the member registration exchange is 994 maintained while group member participates in the group, the GCKS can 995 use the GSA_INBAND_REKEY exchange to individually provide policy 996 updates to the group member. 998 Member (Responder) GCKS (Initiator) 999 -------------------- ------------------ 1000 <-- HDR, SK{GSA, KD, [N,] [D]} 1001 HDR, SK{} --> 1003 Figure 11: GSA_INBAND_REKEY Exchange 1005 Because this is a normal IKEv2 exchange, the HDR is treated as 1006 defined in [RFC7296]. 1008 2.4.2.1. GSA_INBAND_REKEY GCKS Operations 1010 The GSA, KD, N and D payloads are built in the same manner as in a 1011 registration exchange. 1013 2.4.2.2. GSA_INBAND_REKEY GM Operations 1015 The GM processes the GSA, KD, N and D payloads in the same manner as 1016 if they were received in a registration exchange. 1018 2.4.3. Deletion of SAs 1020 There are occasions when the GCKS may want to signal to group members 1021 to delete policy at the end of a broadcast, or if group policy has 1022 changed. Deletion of SAs is accomplished by sending the G-IKEv2 1023 Delete Payload [RFC7296], section 3.11 as part of the GSA_REKEY 1024 pseudo-exchange as shown below. 1026 Members (Responder) GCKS (Initiator) 1027 -------------------- ------------------ 1028 <-- HDR, SK{[GSA,] [KD,] [N,] [D,] [AUTH]} 1030 Figure 12: SA Deletion in GSA_REKEY 1032 If GCKS has a unicast SA with group member then it can use the 1033 GSA_INBAND_REKEY exchange to delete SAs. 1035 Member (Responder) GCKS (Initiator) 1036 -------------------- ------------------ 1037 <-- HDR, SK{[GSA,] [KD,] [N,] [D,]} 1038 HDR, SK{} --> 1040 Figure 13: SA Deletion in GSA_INBAND_REKEY 1042 The GCKS MAY specify the remaining active time of the policy by using 1043 the GAP_DTD attribute in the GSA GAP substructure. If a GCKS has no 1044 further SAs to send to group members, the GSA and KD payloads MUST be 1045 omitted from the message. 1047 There may be circumstances where the GCKS may want to start over with 1048 a clean state, for example in case it runs out of available SIDs. 1049 The GCKS can signal deletion of all the Data-security SAs by sending 1050 a Delete payload with an SPI value equal to zero. For example, if 1051 the GCKS wishes to remove the Rekey SA and all the Data-security SAs, 1052 the GCKS sends a Delete payload with an SPI of zero and Protocol ID 1053 of AH or ESP, followed by another Delete payload with a SPI of zero 1054 and Protocol ID of GIKE_REKEY. 1056 If a group member receives a Delete payload with zero SPI and 1057 protocol ID of GIKE_REKEY either via multicast Rekey SA or via 1058 unicast SA using the GSA_INBAND_REKEY exchange, it means that the 1059 group member is excluded from the group. The group member MUST re- 1060 register if it wants to continue participating in this group. The 1061 registration is performed as described in Section 2.3. Note, that if 1062 the GSA_INBAND_REKEY exchange is used to exclude a group member from 1063 the group, and thus the unicast SA between the group member and the 1064 GCKS exists, then this SA persists after this exchange and the group 1065 member may use the GSA_REGISTRATION exchange to re-register. 1067 2.5. Counter-based modes of operation 1069 Several counter-based modes of operation have been specified for ESP 1070 (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES-CCM [RFC4309], 1071 ChaCha20-Poly1305 [RFC7634], AES-GMAC [RFC4543]) and AH (e.g., AES- 1072 GMAC [RFC4543]). These counter-based modes require that no two 1073 senders in the group ever send a packet with the same Initialization 1074 Vector (IV) using the same cipher key and mode. This requirement is 1075 met in G-IKEv2 when the following requirements are met: 1077 o The GCKS distributes a unique key for each Data-Security SA. 1079 o The GCKS uses the method described in [RFC6054], which assigns 1080 each sender a portion of the IV space by provisioning each sender 1081 with one or more unique SID values. 1083 2.5.1. Allocation of SIDs 1085 When at least one Data-Security SA included in the group policy 1086 includes a counter-based mode of operation, the GCKS automatically 1087 allocates and distributes one SID to each group member acting in the 1088 role of sender on the Data-Security SA. The SID value is used 1089 exclusively by the group sender to which it was allocated. The group 1090 sender uses the same SID for each Data-Security SA specifying the use 1091 of a counter-based mode of operation. A GCKS MUST distribute unique 1092 keys for each Data-Security SA including a counter-based mode of 1093 operation in order to maintain unique key and nonce usage. 1095 During registration, the group sender can choose to request one or 1096 more SID values. Requesting a value of 1 is not necessary since the 1097 GCKS will automatically allocate exactly one to the group sender. A 1098 group sender MUST request as many SIDs matching the number of 1099 encryption modules in which it will be installing the TEKs in the 1100 outbound direction. Alternatively, a group sender MAY request more 1101 than one SID and use them serially. This could be useful when it is 1102 anticipated that the group sender will exhaust their range of Data- 1103 Security SA nonces using a single SID too quickly (e.g., before the 1104 time-based policy in the TEK expires). 1106 When the group policy includes a counter-based mode of operation, a 1107 GCKS SHOULD use the following method to allocate SID values, which 1108 ensures that each SID will be allocated to just one group sender. 1110 1. A GCKS maintains an SID-counter, which records the SIDs that have 1111 been allocated. SIDs are allocated sequentially, with zero as 1112 the first allocated SID. 1114 2. Each time an SID is allocated, the current value of the counter 1115 is saved and allocated to the group sender. The SID-counter is 1116 then incremented in preparation for the next allocation. 1118 3. When the GCKS specifies a counter-based mode of operation in the 1119 Data-Security SA a group sender may request a count of SIDs 1120 during registration in a Notify payload information of type 1121 SENDER. When the GCKS receives this request, it increments the 1122 SID-counter once for each requested SID, and distributes each SID 1123 value to the group sender. The GCKS SHOULD have a policy-defined 1124 upper bound for the number of SIDs that it will return 1125 irrespective of the number requested by the GM. 1127 4. A GCKS allocates new SID values for each registration operation 1128 by a group sender, regardless of whether the group sender had 1129 previously contacted the GCKS. In this way, the GCKS is not 1130 required to maintaining a record of which SID values it had 1131 previously allocated to each group sender. More importantly, 1132 since the GCKS cannot reliably detect whether the group sender 1133 had sent data on the current group Data-Security SAs it does not 1134 know what Data-Security counter-mode nonce values that a group 1135 sender has used. By distributing new SID values, the key server 1136 ensures that each time a conforming group sender installs a Data- 1137 Security SA it will use a unique set of counter-based mode 1138 nonces. 1140 5. When the SID-counter maintained by the GCKS reaches its final SID 1141 value, no more SID values can be distributed. Before 1142 distributing any new SID values, the GCKS MUST exclude all group 1143 members from the group as described in Section 2.4.3. This will 1144 result in the group members performing re-registration, during 1145 which they will receive new Data-Security SAs and group senders 1146 will additionally receive new SID values. The new SID values can 1147 safely be used because they are only used with the new Data- 1148 Security SAs. 1150 2.5.2. GM Usage of SIDs 1152 A GM applies the SID to Data-Security SA as follows. 1154 o The most significant bits NUMBER_OF_SID_BITS of the IV are taken 1155 to be the SID field of the IV. 1157 o The SID is placed in the least significant bits of the SID field, 1158 where any unused most significant bits are set to zero. If the 1159 SID value doesn't fit into the NUMBER_OF_SID_BITS bits, then the 1160 GM MUST treat this as a fatal error and re-register to the group. 1162 2.6. Replay Protection for Multicast Data-Security SAs 1164 IPsec provides replay protection as part of its security services. 1165 With multicast extension for IPsec replay protection is not always 1166 possible to acieve (see Section 6.1 of [RFC3740]). In particular, if 1167 there are many group senders for a Data-Security SA, then each of 1168 them will independently incement the Sequence Number field in the ESP 1169 header (see Section 2 of [RFC4303]) thus making impossible for the 1170 group receivers to filter out replayed packets. However, if there is 1171 only one group sender for a a Data-Security SA, then it is possible 1172 to acieve replay protection with some restrictions (see 1173 Section 4.4.2.1.3). The GCKS may create several Data-Security SAs 1174 with the same traffic selectors allowing only a single group sender 1175 in each SA if it is desirable to get replay protection with multiple 1176 (but still limited number) of group senders. 1178 In IPsec architecture assumes that it is a local matter for an IPsec 1179 receiver whether replay protection is active or not. In other words, 1180 an IPsec sender always increments the Sequence Number field in the 1181 ESP header and a receiver decides whether to check for replayed 1182 packets or not. With multicast extension for IPsec this approach 1183 generally isn't applicable, since group members don't know how many 1184 group senders exist for a particular Data-Security SA. For this 1185 reason the status or replay protection must be part of the policy 1186 downloaded to GMs by GCKS. 1188 For this purpose this specification re-uses the Extended Sequence 1189 Numbers transform, defined in Section 3.3.2 [RFC7296]. This 1190 specification renames this transform to "Replay Protection" and adds 1191 a new value for possible Transform IDs: "Not Used" (). 1192 The GCKS MUST include this transform in the GSA payload for every 1193 Data-Security SA. Note, that this specification prohibits using 1194 Extended Sequence Numbers (see Section 4.4.2.1.3). 1196 3. Group Key Management and Access Control 1198 Through the G-IKEv2 rekey, G-IKEv2 supports algorithms such as 1199 Logical Key Hierarchy (LKH) that have the property of denying access 1200 to a new group key by a member removed from the group (forward access 1201 control) and to an old group key by a member added to the group 1202 (backward access control). An unrelated notion to PFS, "forward 1203 access control" and "backward access control" have been called 1204 "perfect forward security" and "perfect backward security" in the 1205 literature [RFC2627]. 1207 Group management algorithms providing forward and backward access 1208 control other than LKH have been proposed in the literature, 1209 including OFT [OFT] and Subset Difference [NNL]. These algorithms 1210 could be used with G-IKEv2, but are not specified as a part of this 1211 document. 1213 The Group Key Management Method transform from the GSA policy 1214 specifies how members of the group obtain group keys. This document 1215 specifies a single method for the group key management -- Wrapped Key 1216 Download. This method assumes that all group keys are sent to the 1217 GMs by the GCKS encrypted with some other keys, called Key Wrap Keys 1218 (KWK). 1220 3.1. Key Wrap Keys 1222 Every GM always knows at least one KWK -- the KWK that is associated 1223 with the IKE SA or multicast Rekey SA the wrapped keys are sent over. 1224 In this document it is called default KWK and is denoted as GSK_w. 1226 The GCKS may also send other keys to GMs that will be used as Key 1227 Wrap Keys for the purpose of building key hierarchy. Each KWK is 1228 associated with an encryption algorithm from the Encryption Algorithm 1229 transform used for the SA the key is sent over. The size of a KWK 1230 MUST be of the size of the key for this Encryption Algorithm 1231 transform (taking into consideration the Key Length attribute for 1232 this transform if present). This association persists even if the 1233 key is used later in the context of another SA with possibly 1234 different Encryption Algorithm transform. 1236 To have an ability to provide forward access control the GCKS 1237 provides each GM with a personal key at the time of registration. 1238 Besides, several intermediate keys that form a key hierarchy and are 1239 shared among several GMs may be provided by the GCKS. 1241 3.1.1. Default Key Wrap Key 1243 The default KWK (GSK_w) is only used in the context of a single IKE 1244 SA. Every IKE SA (unicast IKE SA or multicast Rekey SA) will have 1245 its own GSK_w. The GSK_w is used with the algorithm from the 1246 Encryption Algorithm transform for the SA the GSK_w is used in the 1247 context of. The size of GSK_w MUST be of the key size of this 1248 Encryption Algorithm transform (taking into consideration the Key 1249 Length attribute for this transform if present). 1251 For the unicast IKE SA (used for the GM registration and for the 1252 GSA_INBAND_REKEY exchanges, if they are take place) the GSK_w is 1253 computed as follows: 1255 GSK_w = prf+(SK_d, "Key Wrap for G-IKEv2") 1257 where the string "Key Wrap for G-IKEv2" is 20 ASCII characters 1258 without null termination. 1260 For the multicast Rekey SA the GSK_w is provided along with other SA 1261 keys as defined in Section 3.4. 1263 3.2. GCKS Key Management Semantics 1265 Wrapped Key Download method allows the GCKS to employ various key 1266 management methods 1268 o A simple key management methods -- when the GCKS always sends 1269 group SA keys encrypted with the GSK_w. 1271 o An LKH key management method -- when the GCKS provides each GM 1272 with an individual key at the time of the GM registration 1273 (encrypted with GSK_w). Then the GCKS forms an hierarchy of keys 1274 so that the group SA keys are encrypted with other keys which are 1275 encrypted with other keys and so on, tracing back to the 1276 individual GMs' keys. 1278 Other key policies may also be employed by the GCKS. 1280 3.2.1. Forward Access Control Requirements 1282 When group membership is altered using a group management algorithm 1283 new Data-Security SAs and their associated keys are usually also 1284 needed. New Data-Security SAs and keys ensure that members who were 1285 denied access can no longer participate in the group. 1287 If forward access control is a desired property of the group, new TEK 1288 policy and the associated keys MUST NOT be included in a G-IKEv2 1289 rekey message which changes group membership. This is required 1290 because the GSA TEK policy and the associated keys are not protected 1291 with the new KEK. A second G-IKEv2 rekey message can deliver the new 1292 GSA TEKS and their associated keys because it will be protected with 1293 the new KEK, and thus will not be visible to the members who were 1294 denied access. 1296 If forward access control policy for the group includes keeping group 1297 policy changes from members that are denied access to the group, then 1298 two sequential G-IKEv2 rekey messages changing the group KEK MUST be 1299 sent by the GCKS. The first G-IKEv2 rekey message creates a new KEK 1300 for the group. Group members, which are denied access, will not be 1301 able to access the new KEK, but will see the group policy since the 1302 G-IKEv2 rekey message is protected under the current KEK. A 1303 subsequent G-IKEv2 rekey message containing the changed group policy 1304 and again changing the KEK allows complete forward access control. A 1305 G-IKEv2 rekey message MUST NOT change the policy without creating a 1306 new KEK. 1308 If other methods of using LKH or other group management algorithms 1309 are added to G-IKEv2, those methods MAY remove the above restrictions 1310 requiring multiple G-IKEv2 rekey messages, providing those methods 1311 specify how the forward access control policy is maintained within a 1312 single G-IKEv2 rekey message. 1314 3.3. GM Key Management Semantics 1316 This specification defines a GM Key Management semantics in such a 1317 way, that it doesn't depend on the key management method employed by 1318 the GCKS. This allows having all the complexity of key management in 1319 the GCKS, which is free to implement various key management methods, 1320 such as direct transmitting of group SA keys or using some kind of 1321 key hierarchy (e.g. LKH). For all these policies the GM behavior is 1322 the same. 1324 Each key that a GM receives in G-IKEv2 is identified by a 32-bit 1325 number called Key ID. Zero Key ID has a special meaning -- it always 1326 contains keying material from which the keys for protecting Data- 1327 Security SAs and Rekey SA are taken. 1329 All keys in G-IKEv2 are transmitted in encrypted form, as specified 1330 in Section 4.5.1. This format includes a Key ID (ID of a key that is 1331 encrypted) and a KWK ID (ID of a key that was used to encrypt this 1332 key). Keys may be encrypted either with default KWK (GSK_w) or with 1333 other keys, which the GM has received in the WRAP_KEY attributes. If 1334 a key was encrypted with GSK_w, then the KWK ID field is set to zero, 1335 otherwise the KWK ID field identifies the key used for encryption. 1337 When a GM receives a message from the GCKS installing new Data- 1338 Security or Rekey SA, it will contain a KD payload with an SA_KEY 1339 attribute containing keying material for this SA. For a Data- 1340 Security SA exactly one SA_KEY attribute will be present with both 1341 Key ID and KWK ID fields set to zero. This means that the default 1342 KWK (GSK_w) should be used to extract this keying material. 1344 For a multicast Rekey SA multiple SA_KEY attributes may be present 1345 depending on the key management method employed by the GCKS. If 1346 multiple SA_KEY attributes are present then all of them MUST contain 1347 the same keying material encrypted using different KWKs. The GM in 1348 general is unaware of the GCKS's key management method and can always 1349 use the same procedure to get the keys. In particular, the GM's task 1350 is to find a way to decrypt at least one of the SA_KEY attributes 1351 using either the GSK_w or the keys from the WRAP_KEY attributes that 1352 are present in the same message or were receives in previous 1353 messages. 1355 We will use the term "Key Path" to describe an ordered sequence of 1356 keys where each subsequent key was used to encrypt the previous one. 1357 The GM keeps its own Key Path (called Working Key Path) in the memory 1358 associated with each group it is registered to and updates it when 1359 needed. When the GSA_REKEY message is received the GM processes the 1360 received SA_KEY attributes one by one trying to construct a new key 1361 path that starts from this attributes and ends with any key in the 1362 Working Key Path or with the default KWK (GSK_w). 1364 In the simplest case the SA_KEY attribute is encrypted with GSK_w so 1365 that the new Key Path is empty. If more complex key management 1366 methods are used then a Key Path will contain intermediate keys from 1367 the WRAP_KEY attributes received by a GM so far starting from its 1368 registration to the group. If the GM is able to construct a new Key 1369 Path using intermediate keys it has, then it is able to decrypt the 1370 SA_KEY attribute and use its content to form new SA keys. If it is 1371 unable to build a new Key Path, then in means that the GM is excluded 1372 from the group. 1374 Depending on the new Key Path the GM should do the following actions 1375 to be prepared for future key updates: 1377 o If the new Key Path is empty then no actions are needed. This may 1378 happen if no WRAP_KEY attributes from the received message were 1379 used. 1381 o If the new Key Path is non-empty and it ends with the default KWK 1382 (GSK_w), then the whole new Key Path is stored by the GM as the 1383 GM's Working Key Path. This situation may only happen at the time 1384 the GM is registering to the group, when the GCKS is providing it 1385 with its personal key and the other keys from the key tree that 1386 are needed for this GM. These keys form an initial Working Key 1387 Path for this GM. 1389 o In all other cases the new Key Path will end at some intermediate 1390 key from the GM's current Working Key Path. In this case the new 1391 Key Path is constructed by replacing a part of the GM's current 1392 Working Key Path from the beginning and up to (but not including) 1393 the key that the GM has used to decrypt the last key in the new 1394 Key Path. 1396 Appendix A contains an example of how this algorithm works in case of 1397 LKH key management method. 1399 3.4. SA Keys 1401 Keys used for Data-Security SAs or Rekey SA (called here SA keys) are 1402 downloaded to GMs in the form of keying material. The keys for each 1403 algorithm employed in an SA are taken from this keying material as if 1404 they were concatenated to form it. 1406 For a Data-Security SA the keys are taken in accordance to the third 1407 bullet from Section 2.17 of [RFC7296]. In particular, for the ESP 1408 and AH SAs the encryption key (if any) MUST be taken from the first 1409 bits of the keying material and the integrity key (if any) MUST be 1410 taken from the remaining bits. 1412 For a Rekey SA the following keys are taken from the keying material: 1414 GSK_e | GSK_a | GSK_w = KEYMAT 1415 where GSK_e and GSK_a are the keys used for the Encryption Algorithm 1416 and the Integrity Algorithm transforms for the corresponding SA and 1417 GSK_w is a default KWK for this SA. Note, that GSK_w is also used 1418 with the Encryption Algorithm transform as well as GSK_e. If an AEAD 1419 algorithm is used for encryption, then SK_a key will not be used (GM 1420 can use the formula above assuming the length of SK_a is zero). 1422 4. Header and Payload Formats 1424 The G-IKEv2 is an IKEv2 extension and thus inherits its wire format 1425 for data structures. However, the processing of some payloads are 1426 different and several new payloads are defined: Group Identification 1427 (IDg), Group Security Association (GSA) Key Download (KD). New 1428 exchange types GSA_AUTH, GSA_REGISTRATION, GSA_REKEY and 1429 GSA_INBAND_REKEY are also added. 1431 This section describes new payloads and the differences in processing 1432 of existing IKEv2 payloads. 1434 4.1. G-IKEv2 Header 1436 G-IKEv2 uses the same IKE header format as specified in [RFC7296] 1437 section 3.1. Major Version is 2 and Minor Version is 0 as in IKEv2. 1438 IKE SA Initiator's SPI, IKE SA Responder's SPI, Flags, Message ID, 1439 and Length are as specified in [RFC7296]. 1441 4.2. Group Identification Payload 1443 The Group Identification (IDg) payload allows the group member to 1444 indicate which group it wants to join. The payload is constructed by 1445 using the IKEv2 Identification Payload (section 3.5 of [RFC7296]). 1446 ID type ID_KEY_ID MUST be supported. ID types ID_IPV4_ADDR, ID_FQDN, 1447 ID_RFC822_ADDR, ID_IPV6_ADDR SHOULD be supported. ID types 1448 ID_DER_ASN1_DN and ID_DER_ASN1_GN are not expected to be used. The 1449 Payload Type for the Group Identification payload is fifty (50). 1451 4.3. Security Association - GM Supported Transforms Payload 1453 The Security Association - GM Supported Transforms Payload (SAg) 1454 payload declares which Transforms a GM is willing to accept. The 1455 payload is constructed using the format of the IKEv2 Security 1456 Association payload (section 3.3 of [RFC7296]). The Payload Type for 1457 SAg is identical to the SA Payload Type -- thirty-three (33). 1459 4.4. Group Security Association Payload 1461 The Group Security Association (GSA) payload is used by the GCKS to 1462 assert security attributes for both Rekey SA and Data-security SAs. 1463 The Payload Type for the Group Security Association payload is fifty- 1464 one (51). 1466 1 2 3 1467 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 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | Next Payload |C| RESERVED | Payload Length | 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | | 1472 ~ ~ 1473 | | 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 Figure 14: GSA Payload Format 1478 The Security Association Payload fields are defined as follows: 1480 o Next Payload, C, RESERVED, Payload Length fields comprise the 1481 IKEv2 Generic Payload Header and are defined in Section 3.2. of 1482 [RFC7296]. 1484 o Group Policies (variable) -- A set of group policies for the 1485 group. 1487 4.4.1. Group Policies 1489 Croup policies are comprised of two types of policy -- Group SA (GSA) 1490 policy and Group Associated (GA) policy. GSA policy defines 1491 parameters for the Security Association for the group. Depending on 1492 the employed security protocol GSA policies may further be classified 1493 as Rekey SA policy (GSA KEK) and Data-Security SA policy (GSA TEK). 1494 GSA payload may contain zero or one GSA KEK policy, zero or more GSA 1495 TEK policies, and zero or one GA policy, where either one GSA KEK or 1496 GSA TEK policy MUST be present. 1498 This latitude allows various group policies to be accommodated. For 1499 example if the group policy does not require the use of a Rekey SA, 1500 the GCKS would not need to send a GSA KEK policy to the group member 1501 since all SA updates would be performed using the GSA_INBAND_REKEY 1502 exchange via the unicast IKE SA. Alternatively, group policy might 1503 use a Rekey SA but choose to download a KEK to the group member only 1504 as part of the unicast IKE SA. Therefore, the GSA KEK policy would 1505 not be necessary as part of the GSA_REKEY message. 1507 Specifying multiple GSA TEKs allows multiple related data streams 1508 (e.g., video, audio, and text) to be associated with a session, but 1509 each protected with an individual security association policy. 1511 A GAP allows for the distribution of group-wise policy, such as 1512 instructions for when to activate and de-activate SAs. 1514 Policies are distributed in substructures to the GSA payload. The 1515 format of the substructures is defined below in Section 4.4.2 (for 1516 GSA policy) and in Section 4.4.3 (for GA policy). The first octet of 1517 the substructure unambiguously determines its type -- it is zero for 1518 GAP and non-zero (actually, it is a security protocol ID) for GSA 1519 policies. 1521 4.4.2. Group Security Association Policy Substructure 1523 The GSA policy substructure contains parameters for the SA used with 1524 this group. Depending on the security protocol the SA is either a 1525 Rekey SA or a Data-Security SA (ESP and AH). It is NOT RECOMMENDED 1526 that the GCKS distribute both ESP and AH policies for the same set of 1527 Traffic Selectors. 1529 1 2 3 1530 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 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 | Protocol | SPI Size | Length | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | | 1535 ~ SPI ~ 1536 | | 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 | | 1539 ~ Source Traffic Selector ~ 1540 | | 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1542 | | 1543 ~ Destination Traffic Selector ~ 1544 | | 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 | | 1547 ~ ~ 1548 | | 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | | 1551 ~ ~ 1552 | | 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 Figure 15: GSA Policy Substructure Format 1557 The GSA policy fields are defined as follows: 1559 o Protocol (1 octet) -- Identifies the security protocol for this 1560 group SA. The values are defined in the IKEv2 Security Protocol 1561 Identifiers in [IKEV2-IANA]. The valid values for this field are: 1562 (GIKE_REKEY) for Rekey SA and 2 (AH) or 3 (ESP) for Data- 1563 Security SAs. 1565 o SPI Size (1 octet) -- Size of Security Parameter Index (SPI) for 1566 the SA. SPI size depends on the SA protocol. For GIKE_REKEY it 1567 is 16 octets, while for AH and ESP it is 4 octets. 1569 o Length (2 octets, unsigned integer) -- Length of this substructure 1570 including the header. 1572 o SPI (variable) -- Security Parameter Index for the group SA. The 1573 size of this field is determined by the SPI Size field. As 1574 described above, these SPIs are assigned by the GCKS. In case of 1575 GIKE_REKEY the SPI must be the IKEv2 Header SPI pair where the 1576 first 8 octets become the "Initiator's SPI" field in the G-IKEv2 1577 rekey message IKEv2 HDR, and the second 8 octets become the 1578 "Responder's SPI" in the same HDR. When selecting SPI the GCKS 1579 MUST make sure that the sole first 8 octets (corresponding to 1580 "Initiator's SPI" field in the IKEv2 header) uniquely identify the 1581 Rekey SA. 1583 o Source & Destination Traffic Selectors - (variable) -- 1584 Substructures describing the source and destination of the network 1585 identities. The format for these substructures is defined in 1586 IKEv2 [RFC7296], section 3.13.1. For the Rekey SA (with the 1587 GIKE_REKEY protocol) the destination traffic selectors MUST define 1588 a single multicast IP address, an IP protocol (assumed to be UDP) 1589 and a single port the GSA_REKEY messages will be destined to. The 1590 source traffic selector in this case MUST either define a single 1591 IP address, an IP protocol (assumed to be UDP) and a single port 1592 the GSA_REKEY messages will be originated from or be a wildcard 1593 selector. For the Data-Security (AH and ESP) SAs the destination 1594 traffic selectors SHOULD define a single multicast IP address. 1595 The source traffic selector in this case SHOULD define a single IP 1596 address or be a wildcard selector. IP protocol and ports define 1597 the characteristics of traffic protected by this Data-Security SA. 1598 If the Data-Security SAs are created in tunnel mode, then it MUST 1599 BE tunnel mode with address preservation (see [RFC5374]. UDP 1600 encapsulation [RFC3948] is not used for the multicast Data- 1601 Security SAs. 1603 o GSA Transforms (variable) -- A list of Transform Substructures 1604 specifies the policy information for the SA. The format is 1605 defined in IKEv2 [RFC7296], section 3.3.2. The Last Substruc 1606 value in each Transform Substructure will be set to 3 except for 1607 the last one in the list, which is set to 0. Section 4.4.2.1 1608 describes using IKEv2 transforms in GSA policy substructure. 1610 o GSA Attributes (variable) -- Contains policy attributes associated 1611 with the group SA. The following sections describe the possible 1612 attributes. Any or all attributes may be optional, depending on 1613 the protocol and the group policy. Section 4.4.2.2 defines 1614 attributes used in GSA policy substructure. 1616 4.4.2.1. GSA Transforms 1618 GSA policy is defined by means of transforms in the GSA policy 1619 substructure. For this purpose the transforms defined in [RFC7296] 1620 are used. In addition, new transform types are defined for using in 1621 G-IKEv2: Authentication Method (AUTH) and Group Key Management Method 1622 (GKM), see Section 8. 1624 Valid Transform Types depend on the SA protocol and are summarized in 1625 the table below. 1627 Protocol Mandatory Types Optional Types 1628 ------------------------------------------------------------ 1629 GIKE_REKEY ENCR, INTEG*, PRF, AUTH**, GKM** 1630 ESP ENCR INTEG, RP 1631 AH INTEG RP 1633 Figure 16: Valid Transform Types 1635 (*) If AEAD encryption algorithm is used, then INTEG transform MUST 1636 NOT be specified, otherwise it MUST be specified. 1638 (**) May only appear at the time of a GM registration, (in the 1639 GSA_aUTH and GSA_REGISTRATION exchanges). 1641 4.4.2.1.1. Authentication Method Transform 1643 The Authentication Method (AUTH) transform is used in the GIKE_REKEY 1644 policy to convey information of how GCKS will authenticate the 1645 GSA_REKEY messages. This values are from the IKEv2 Authentication 1646 Method registry [IKEV2-IANA]. Note, that this registry defines only 1647 values in a range 0-255, so even that Transform ID field in the 1648 Transform substructure allows for 65536 possible values, in case of 1649 the Authentication Method transform the values 256-65535 MUST NOT 1650 appear. 1652 Among the currently defined authentication methods in the IKEv2 1653 Authentication Method registry, only the following are allowed to be 1654 used in the Authentication Method transform: NULL Authentication and 1655 Digital Signature. Other currently defined authentication methods 1656 MUST NOT be used. The following semantics is associated with each of 1657 the allowed methods. 1659 NULL Authentication -- No additional authentication of the GSA_REKEY 1660 messages will be provided by the GCKS besides the ability for 1661 the GMs to correctly decrypt them and verify their ICV. In 1662 this case the GCKS MUST NOT include the AUTH_KEY attribute into 1663 the KD payload. Additionally, the AUTH payload MUST NOT be 1664 included in the GIKE_REKEY messages. 1666 Digital Signature -- Digital signatures will be used by the GCKS to 1667 authenticate the GSA_REKEY messages. In this case the GCKS 1668 MUST include the AUTH_KEY attribute containing the public key 1669 into the KD payload at the time the GM is registered to the 1670 group. To specify the details of the signature algorithm a new 1671 attribute Algorithm Identifier () is defined. 1673 This attribute contains DER-encoded ASN.1 object 1674 AlgorithmIdentifier, which would specify the signature 1675 algorithm and the hash function that the GCKS will use for 1676 authentication. The AlgorithmIdentifier object is defined in 1677 section 4.1.1.2 of [RFC5280], see also [RFC7427] for the list 1678 of common AlgorithmIdentifier values used in IKEv2. In case of 1679 using digital signature the GCKS MUST include the Algorithm 1680 Identifier attribute in the Authentication Method transform. 1682 The authentication method MUST NOT change as a result of rekey 1683 operations. This means that the Authentication Method transform may 1684 not appear in the rekey messages, it may only appear in the 1685 registration exchange (either GSA_AUTH or GSA_REGISTRATION). 1687 The type of the Authentication Method Transform is . 1689 4.4.2.1.2. Group Key Management Method Transform 1691 The Group Key Management Method (GKM) transform is used in the 1692 GIKE_REKEY policy to convey information of how GCKS will manage the 1693 group keys to provide forward and backward access control (i.e., used 1694 to exclude group members). Possible key management methods are 1695 defined in a new IKEv2 registry "Transform Type -- Group Key 1696 Management Methods" (see Section 8). This document defines one 1697 values for this registry: 1699 Wrapped Key Download () -- Keys are downloaded by GCKS 1700 to the GMs in encrypted form. This algorithm may provide 1701 forward and backward access control if some form of key 1702 hierarchy is used and each GM is provided with a personal key 1703 at the time of registration. Otherwise no access control is 1704 provided. 1706 The group key management method MUST NOT change as a result of rekey 1707 operations. This means that the Group Key Management Method 1708 transform may not appear in the rekey messages, it may only appear in 1709 the registration exchange (either GSA_AUTH or GSA_REGISTRATION). 1711 The type of the Group Key Management Method transform is . 1714 4.4.2.1.3. Replay Protection Transform 1716 The "Extended Sequence Number (ESN)" Transform is defined in 1717 [RFC7296]. This specification renames this transform to "Replay 1718 Protection (RP)". This transform allows to specify whether the 1719 64-bit Extended Sequence Numbers (ESN) are to be used in ESP and AH. 1721 Since both AH [RFC4302] and ESP [RFC4303] are defined in such a way, 1722 that high-order 32 bits of extended sequence numbers are never 1723 transmitted, it makes using ESN in multicast Data-Security SAs 1724 problematic, because GMs that join group long after it is created 1725 will have to somehow learn the current high order 32 bits of ESN for 1726 each sender in the group. The algorithm for doing this described in 1727 [RFC4302] and [RFC4303] is resource-consuming and is only suitable 1728 when a receiver is able to guess the high-order 32 bits close enough 1729 to its real value, which is not the case for multicast SAs. For this 1730 reason extended sequence numbers MUST NOT be used for multicast Data- 1731 Security SAs and thus the value "Extended Sequence Numbers" (1) for 1732 the Replay Protection transform type MUST NOT be used in the GSA 1733 Payload. The GCKS MUST estimate the data rate and rekey Data- 1734 Security SAs freuently enough so that Sequence Numbers (SN) don't 1735 wrap. 1737 4.4.2.2. GSA Attributes 1739 GSA attributes are generally used to provide GMs with additional 1740 parameters for the GSA policy. Unlike security parameters 1741 distributed via transforms, which are expected not to change over 1742 time (unless policy changes), the parameters distributed via GSA 1743 attributes may depend on the time the provision takes place, on the 1744 existence of others group SAs or on other conditions. 1746 This document creates a new IKEv2 IANA registry for the types of the 1747 GSA attributes which is initially filled as described in Section 8. 1748 In particular, the following attributes are initially added. 1750 GSA Attributes Value Type Multiple Protocol 1751 --------------------------------------------------------------------- 1752 Reserved 0 1753 GSA_KEY_LIFETIME 1 V N GIKE_REKEY, AH, ESP 1754 GSA_INITIAL_MESSAGE_ID 2 V N GIKE_REKEY 1755 GSA_NEXT_SPI 3 V Y GIKE_REKEY, AH, ESP 1757 The attributes must follow the format defined in the IKEv2 [RFC7296] 1758 section 3.3.5. In the table, attributes that are defined as TV are 1759 marked as Basic (B); attributes that are defined as TLV are marked as 1760 Variable (V). 1762 4.4.2.2.1. GSA_KEY_LIFETIME Attribute 1764 The GSA_KEY_LIFETIME attribute (1) specifies the maximum time for 1765 which the SA is valid. The value is a 4 octet unsigned integer in a 1766 network byte order, specifying a valid time period in seconds. A 1767 single attribute of this type MUST be included into any GSA policy 1768 substructure. 1770 When the lifetime expires, the group security association and all 1771 associated keys MUST be deleted. The GCKS may delete the SA at any 1772 time before the end of the validity period. 1774 This attribute SHOULD NOT be used if inband rekeying (via the 1775 GSA_INBAND_REKEY exchange) is employed by the GCKS for the GM. 1777 4.4.2.2.2. GSA_INITIAL_MESSAGE_ID Attribute 1779 The GSA_INITIAL_MESSAGE_ID attribute (2) defines the initial Message 1780 ID to be used by the GCKS in the GSA_REKEY messages. The Message ID 1781 is a 4 octet unsigned integer in network byte order. 1783 A single attribute of this type MUST be included into the GSA KEK 1784 policy substructure if the initial Message ID of the Rekey SA is non- 1785 zero. Note, that it is always the case if GMs join the group after 1786 some multicast rekey operations have already taken place, so in these 1787 cases this attribute will be included into the GSA policy at the time 1788 of GMs' registration. 1790 This attribute MUST NOT be used if inband rekeying (via the 1791 GSA_INBAND_REKEY exchange) is employed by the GCKS for the GM. 1793 4.4.2.2.3. GSA_NEXT_SPI Attribute 1795 The optional GSA_NEXT_SPI attribute (3) contains SPI that the GCKS 1796 reserved for the next Rekey SA or Data-Security SAs replacing the 1797 current ones. The length of the attribute data is determined by the 1798 SPI Size field in the GSA Policy substructure the attribute resides 1799 in (see Section 4.4.2), and the attribute data contains SPI as it 1800 would appear on the network. Multiple attributes of this type MAY be 1801 included, meaning that any of the supplied SPIs can be used in the 1802 replacement group SA. 1804 The GM MAY store these values and if later the GM starts receiving 1805 messages with one of these SPIs without seeing a rekey message over 1806 the current Rekey SA, this may be used as an indication, that the 1807 rekey message got lost on its way to this GM. In this case the GM 1808 SHOULD re-register to the group. 1810 Note, that this method of detecting lost rekey messages can only be 1811 used by group receivers. Additionally there is no point to include 1812 this attribute in the GSA_INBAND_REKEY messages, since they use 1813 reliable transport. Note also, that the GCKS is free to forget its 1814 promises and not to use the SPIs it sent in the GSA_NEXT_SPI 1815 attributes before (e.g. in case of the GCKS is rebooted), so the GM 1816 must only treat these information as a "best effort" made by the GCKS 1817 to prepare for future rekeys. 1819 This attribute MUST NOT be used if inband rekeying (via the 1820 GSA_INBAND_REKEY exchange) is employed by the GCKS for the GM. 1822 4.4.3. Group Associated Policy Substructure 1824 Group specific policy that does not belong to any SA policy can be 1825 distributed to all group member using Group Associated Policy (GAP) 1826 substructure. 1828 The GAP substructure is defined as follows: 1830 1 2 3 1831 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 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 | Protocol | RESERVED | Length | 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 | | 1836 ~ ~ 1837 | | 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 Figure 17: GAP Substructure Format 1842 The GAP substructure fields are defined as follows: 1844 o Protocol (1 octet) -- MUST be zero. This value is reserved in 1845 Section 8 and is never used for any security protocol, so it is 1846 used here to indicate that this substructure contains policy not 1847 related to any specific protocol. 1849 o RESERVED ( octet) -- MUST be zero on transmission, MUST be ignored 1850 on receipt. 1852 o Length (2 octets, unsigned integer) -- Length of this substructure 1853 including the header. 1855 o GAP Attributes (variable) -- Contains policy attributes associated 1856 with no specific SA. The following sections describe possible 1857 attributes. Any or all attributes may be optional, depending on 1858 the group policy. 1860 This document creates a new IKEv2 IANA registry for the types of the 1861 GAP attributes which is initially filled as described in Section 8. 1862 In particular, the following attributes are initially added. 1864 GAP Attributes Value Type Multiple 1865 ---------------------------------------------------- 1866 Reserved 0 1867 GAP_ATD 1 B N 1868 GAP_DTD 2 B N 1869 GAP_SID_BITS 3 B N 1871 The attributes must follow the format defined in the IKEv2 [RFC7296] 1872 section 3.3.5. In the table, attributes that are defined as TV are 1873 marked as Basic (B); attributes that are defined as TLV are marked as 1874 Variable (V). 1876 4.4.3.1. GAP_ATD And GAP_DTD Attributes 1878 Section 4.2.1 of [RFC5374] specifies a key rollover method that 1879 requires two values be provided to group members -- Activation Time 1880 Delay (ATD) and Deactivation Time Delay (DTD). 1882 The GAP_ATD attribute (1) allows a GCKS to set the Activation Time 1883 Delay for Data-Security SAs of the group. The ATD defines how long 1884 active members of the group (those who sends traffic) should wait 1885 after receiving new SAs before staring sending traffic over them. 1886 Note, that to achieve smooth rollover passive members of the group 1887 should activate the SAs immediately once they receive them. 1889 The GAP_DTD attribute (2) allows the GCKS to set the Deactivation 1890 Time Delay for previously distributed SAs. The DTD defines how long 1891 after receiving a request to delete Data-Security SAs passive group 1892 members should wait before actually deleting them. Note that active 1893 members of the group should stop sending traffic over these old SAs 1894 once new replacement SAs are activated (after time specified in the 1895 GAP_ATD attribute). 1897 The GAP_ATD and GAP_DTD attributes contain 16 bit unsigned integer in 1898 a network byte order, specifying the delay in seconds. These 1899 attributes are OPTIONAL. If one of them or both are not sent by the 1900 GCKS, then no corresponding delay should be employed. 1902 4.4.3.2. GAP_SID_BITS Attribute 1904 The GAP_SID_BITS attribute (3) declares how many bits of the cipher 1905 nonce are taken to represent an SID value. The bits are applied as 1906 the most significant bits of the IV, as shown in Figure 1 of 1907 [RFC6054] and specified in Section 2.5.2. Guidance for a GCKS 1908 choosing the NUMBER_OF_SID_BITS is provided in Section 3 of 1909 [RFC6054]. This value is applied to each SID value distributed in 1910 the KD payload. 1912 The GCKS MUST include this attribute if there are more than one 1913 sender in the group and any of the Data-Security SAs use counter- 1914 based cipher mode. The number of SID bits is represented as 16 bit 1915 unsigned integer in network byte order. 1917 4.5. Key Download Payload 1919 The Key Download (KD) payload contains the group keys for the SAs 1920 specified in the GSA Payload. The Payload Type for the Key Download 1921 payload is fifty-two (52). 1923 1 2 3 1924 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 1925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 | Next Payload |C| RESERVED | Length | 1927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1928 | | 1929 ~ ~ 1930 | | 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 Figure 18: Key Download Payload Format 1935 The Key Download payload fields are defined as follows: 1937 o Next Payload, C, RESERVED, Payload Length fields comprise the 1938 IKEv2 Generic Payload Header and are defined in Section 3.2. of 1939 [RFC7296]. 1941 o Key Packets (variable) -- Contains Group Key Packet and Member Key 1942 Packet substructures. Each Key Packet contains keys for a single 1943 group rekey or Data-Security SA or a keys and security parameters 1944 for a GM. 1946 Two types of Key Packets are used -- Group Key Packet and Member Key 1947 Packet. 1949 4.5.1. Wrapped Key Format 1951 The symmetric keys in G-IKEv2 are never sent in clear. They are 1952 always encrypted with other keys using the format called Wrapped Key 1953 that is shown below (Figure 19). 1955 The keys are encrypted using algorithm that is used to encrypt the 1956 message the keys are sent in. It means, that in case of unicast IKE 1957 SA (used for GMs registration and rekeying using GSA_INBAND_REKEY) 1958 the encryption algorithm will be the one negotiated during the IKE SA 1959 establishment, while for a GSA_REKEY message the algorithm will be 1960 provided by the GCKS in the Encryption Algorithm transform in the GSA 1961 payload when this multicast SA was being established. 1963 If AEAD mode is used for encryption, then for the purpose of key 1964 encryption the authentication tag MUST NOT be used (both not 1965 calculated and not verified), since the G-IKEv2 provides 1966 authentication of all its messages. In addition there is no AAD in 1967 this case. If encryption algorithm requires padding, then the 1968 encrypted key MUST be padded before encryption to have the required 1969 size. If the encryption algorithm doesn't define the padding 1970 content, then the following scheme SHOULD be used: the Padding bytes 1971 are initialized with a series of (unsigned, 1-byte) integer values. 1972 The first padding byte appended to the plaintext is numbered 1, with 1973 subsequent padding bytes making up a monotonically increasing 1974 sequence: 1, 2, 3, .... The length of the padding is not transmitted 1975 and is implicitly determined, since the length of the key is known. 1977 1 2 3 1978 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 1979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1980 | Key ID | 1981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1982 | KWK ID | 1983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1984 | | 1985 ~ IV ~ 1986 | | 1987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1988 | | 1989 ~ Encrypted Key ~ 1990 | | 1991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 Figure 19: Wrapped Key Format 1995 The Wrapped Key fields are defined as follows: 1997 o Key ID (4 octets) -- ID of the encrypted key. The value zero 1998 means that the encrypted key contains SA keys (in the form of 1999 keying material, see Section 3.4)), otherwise it contains some 2000 intermediate key. 2002 o KWK ID (4 octets) -- ID of the key that was used to encrypt key 2003 with specified Key ID. The value zero means that the default KWK 2004 was used to encrypt the key, otherwise some intermediate key was 2005 used. 2007 o IV (variable) -- Initialization Vector used for encryption. The 2008 size and the content of IV is defined by the employed encryption 2009 transform. 2011 o Encrypted Key (variable) -- The encrypted key bits. These bits 2012 may comprise either a single encrypted key or a result of 2013 encryption of a concatenation of keys (key material) for several 2014 algorithms. 2016 4.5.2. Group Key Packet Substructure 2018 Group Key Packet substructure contains SA key information. This key 2019 information is associated with some group SAs: either with Data- 2020 Security SAs or with group Rekey SA. 2022 1 2 3 2023 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 2024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2025 | Protocol | SPI Size | Length | 2026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2027 | | 2028 ~ SPI ~ 2029 | | 2030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2031 | | 2032 ~ ~ 2033 | | 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 Figure 20: Group Key Packet Substructure Format 2038 o Protocol (1 octet) -- Identifies the security protocol for this 2039 key packet. The values are defined in the IKEv2 Security Protocol 2040 Identifiers in [IKEV2-IANA]. The valid values for this field are: 2041 (GIKE_REKEY) for KEK Key packet and 2 (AH) or 3 (ESP) for 2042 TEK key packet. 2044 o SPI Size (1 octet) -- Size of Security Parameter Index (SPI) for 2045 the corresponding SA. SPI size depends on the security protocol. 2046 For GIKE_REKEY it is 16 octets, while for AH and ESP it is 4 2047 octets. 2049 o Length (2 octets, unsigned integer) -- Length of this substructure 2050 including the header. 2052 o SPI (variable) -- Security Parameter Index for the corresponding 2053 SA. The size of this field is determined by the SPI Size field. 2054 In case of GIKE_REKEY the SPI must be the IKEv2 Header SPI pair 2055 where the first 8 octets become the "Initiator's SPI" field in the 2056 G-IKEv2 rekey message IKEv2 HDR, and the second 8 octets become 2057 the "Responder's SPI" in the same HDR. When selecting SPI the 2058 GCKS MUST make sure that the sole first 8 octets (corresponding to 2059 "Initiator's SPI" field in the IKEv2 header) uniquely identify the 2060 Rekey SA. 2062 o Group Key Packet Attributes (variable length) -- Contains Key 2063 information for the corresponding SA. 2065 This document creates a new IKEv2 IANA registry for the types of the 2066 Group Key Packet attributes which is initially filled as described in 2067 Section 8. In particular, the following attributes are initially 2068 added. 2070 Group Key Packet 2071 Attributes Value Type Multiple Protocol 2072 ---------------------------------------------------------- 2073 Reserved 0 2074 SA_KEY 1 V N/Y* GIKE_REKEY, 2075 N AH, ESP 2077 (*) Multiple SA_KEY attributes may only appear for the GIKE_REKEY 2078 protocol in the GSA_REKEY exchange if the GCKS uses the Group Key 2079 Management method that allows excluding GMs from the group (like 2080 LKH). 2082 The attributes must follow the format defined in the IKEv2 [RFC7296] 2083 section 3.3.5. In the table, attributes that are defined as TV are 2084 marked as Basic (B); attributes that are defined as TLV are marked as 2085 Variable (V). 2087 4.5.2.1. SA_KEY Attribute 2089 The SA_KEY attribute (1) contains a keying material for the 2090 corresponding SA. The content of the attribute is formatted 2091 according to Section 4.5.1 with a precondition that the Key ID field 2092 MUST always be zero. The size of the keying material MUST be equal 2093 to the total size of the keys needed to be taken from this keying 2094 material (see Section 3.4) for the corresponding SA. 2096 If the Key Packet is for a Data-Security SA (AH or ESP protocols), 2097 then exactly one SA_KEY attribute MUST be present with both Key ID 2098 and KWK ID fields set to zero. 2100 If the Key Packet is for a Rekey SA (GIKE_REKEY protocol), then in 2101 the GSA_AUTH, GSA_REGISTRATION and GSA_INBAND_REKEY exchanges exactly 2102 one SA_KEY attribute MUST be present. In the GSA_REKEY exchange at 2103 least one SA_KEY attribute MUST be present, and more attributes MAY 2104 be present (depending on the key management method employed by the 2105 GCKS). 2107 4.5.3. Member Key Packet Substructure 2109 The Member Key Packet substructure contains keys and other parameters 2110 that are specific for a member of the group and are not associated 2111 with any particular group SA. 2113 1 2 3 2114 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 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 | Protocol | RESERVED | Length | 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 | | 2119 ~ ~ 2120 | | 2121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2123 Figure 21: Member Key Packet Substructure Format 2125 The Member Key Packet substructure fields are defined as follows: 2127 o Protocol (1 octet) -- MUST be zero. This value is reserved in 2128 Section 8 and is never used for any security protocol, so it is 2129 used here to indicate that this Key Packet is not associated with 2130 any particular SA. 2132 o RESERVED ( octet) -- MUST be zero on transmission, MUST be ignored 2133 on receipt. 2135 o Length (2 octets, unsigned integer) -- Length of this substructure 2136 including the header. 2138 o Member Key Packet Attributes (variable length) -- Contains Key 2139 information and other parameters exclusively for a particular 2140 member of the group. 2142 Member Key Packet substructure contains sensitive information for a 2143 single GM, for this reason it MUST NOT be sent in GSA_REKEY messages 2144 and MUST only be sent via unicast SA at the time the GM registers to 2145 the group (in either GSA_AUTH or GSA_REGISTRATION exchanges). 2147 This document creates a new IKEv2 IANA registry for the types of the 2148 Member Key Packet attributes which is initially filled as described 2149 in Section 8. In particular, the following attributes are initially 2150 added. 2152 Member Key Packet 2153 Attributes Value Type Multiple 2154 ------------------------------------------------ 2155 Reserved 0 2156 WRAP_KEY 1 V Y 2157 AUTH_KEY 2 V N 2158 GM_SID 3 V Y 2160 The attributes must follow the format defined in the IKEv2 [RFC7296] 2161 section 3.3.5. In the table, attributes that are defined as TV are 2162 marked as Basic (B); attributes that are defined as TLV are marked as 2163 Variable (V). 2165 4.5.3.1. WRAP_KEY Attribute 2167 The WRAP_KEY attribute (1) contains a key that is used to encrypt 2168 other keys. One or more these attributes are sent to GMs if the GCKS 2169 key management method relies on some key hierarchy (e.g. LKH). This 2170 attribute MUST NOT be used if inband rekeying (via the 2171 GSA_INBAND_REKEY exchange) is employed by the GCKS for the GM. 2173 The content of the attribute has a format defined in Section 4.5.1 2174 with a precondition that the Key ID field MUST NOT be zero. The 2175 algorithm associated with the key is from the Encryption Transform 2176 for the SA the WRAP_KEY attributes was sent in. The size of the key 2177 MUST be equal to the key size for this algorithm. 2179 Multiple instances of the WRAP_KEY attributes MAY be present in the 2180 key packet. 2182 4.5.3.2. AUTH_KEY Attribute 2184 The AUTH_KEY attribute (2) contains the key that is used to 2185 authenticate the GSA_REKEY messages. The content of the attribute 2186 depends on the authentication method the GCKS specified in the 2187 Authentication Method transform in the GSA payload. 2189 o If digital signatures are used for the GSA_REKEY messages 2190 authentication then the content of the AUTH_KEY attribute is a 2191 public key used for digital signature authentication. The public 2192 key MUST be represented as DER-encoded ASN.1 object 2193 SubjectPublicKeyInfo, defined in section 4.1.2.7 of [RFC5280]. 2194 The signature algorithm that will use this key was specified in 2195 the Algorithm Identifier attribute of the Authentication Method 2196 transform. The key MUST be compatible with this algorithm. An 2197 RSA public key format is defined in [RFC8017], Section A.1. DSS 2198 public key format is defined in [RFC3279] Section 2.3.2. For 2199 ECDSA Public keys, use format described in [RFC5480] Section 2. 2201 Other algorithms added to the IKEv2 Authentication Method registry 2202 are also expected to include a format of the SubjectPublicKeyInfo 2203 object included in the algorithm specification. 2205 Multiple instances of the AUTH_KEY attributes MUST NOT be sent. This 2206 attribute MUST NOT appear in the rekey operations (in the GSA_REKEY 2207 or GSA_INBAND_REKEY exchanges). 2209 4.5.3.3. GM_SID Attribute 2211 The GM_SID attribute (3) is used to download one or more Sender-ID 2212 values for the exclusive use of a group member. One or more of this 2213 attributes MUST be sent by the GCKS if the GM informed the GCKS that 2214 it would be a sender (by inclusion the SENDER notification to the 2215 request) and at least one of the Data-Security SAs included in the 2216 GSA payload uses counter-based mode of encryption. 2218 If the GMs has requested multiple SID values in the SENDER 2219 notification, then the GCKS SHOULD provide it with the requested 2220 number of SIDs by sending multiple instances of the GM_SID attribute. 2221 The GCKS MAY send fewer SIDs than requested by the GM (e.g. if it is 2222 running out of SIDs), but it MUST NOT send more than requested. 2224 This attribute MUST NOT appear in the rekey operations (in the 2225 GSA_REKEY or GSA_INBAND_REKEY exchanges). 2227 4.6. Delete Payload 2229 Delete payload is used in G-IKEv2 when the GCKS wants to delete Data- 2230 Security and Rekey SAs. The interpretation of the Protocol field in 2231 the Delete payload is extended, so that zero protocol indicates 2232 deletion of whole Group SA (i.e. all Data-Security SAs and Rekey SA). 2233 See Section 2.4.3 for detail. 2235 4.7. Notify Payload 2237 G-IKEv2 uses the same Notify payload as specified in [RFC7296], 2238 section 3.10. 2240 There are additional Notify Message types introduced by G-IKEv2 to 2241 communicate error conditions and status (see Section 8). 2243 o INVALID_GROUP_ID (45) -- error type notification that indicates 2244 that the group ID sent during the registration process is invalid. 2245 The Protocol ID and SPI Size fields in the Notify payload MUST be 2246 zero. There is no data associated with this notification and the 2247 content of the Notification Data field MUST be ignored on receipt. 2249 o AUTHORIZATION_FAILED (46) -- error type notification that is sent 2250 in the response to a GSA_AUTH or GSA_REGISTRATION message when 2251 authorization failed. The Protocol ID and SPI Size fields in the 2252 Notify payload MUST be zero. There is no data associated with 2253 this notification and the content of the Notification Data field 2254 MUST be ignored on receipt. 2256 o REGISTRATION_FAILED () -- error type notification that is 2257 sent by the GCKS when the GM registration request cannot be 2258 satisfied for the reasons not related to this particular GM, for 2259 example if the capacity of the group is exceeded. The Protocol ID 2260 and SPI Size fields in the Notify payload MUST be zero. There is 2261 no data associated with this notification and the content of the 2262 Notification Data field MUST be ignored on receipt. 2264 o SENDER (16429) -- status type notification that is sent in the 2265 GSA_AUTH or the GSA_REGISTRATION exchanges to indicate that the GM 2266 intends to be sender of data traffic. The data includes a count 2267 of how many SID values the GM desires. The count MUST be 4 octets 2268 long and contain the big endian representation of the number of 2269 requested SIDs. The Protocol ID and SPI Size fields in the Notify 2270 payload MUST be zero. 2272 o REKEY_IS_NEEDED () -- status type notification that is sent 2273 in the GSA_AUTH response message to indicate that the GM must 2274 perform an immediate rekey of IKE SA to make it secure against 2275 quantum computers and then start a registration request over. The 2276 Protocol ID and SPI Size fields in the Notify payload MUST be 2277 zero. There is no data associated with this notification and the 2278 content of the Notification Data field MUST be ignored on receipt. 2280 4.7.1. USE_TRANSPORT_MODE Notification 2282 This specification uses the USE_TRANSPORT_MODE notification defined 2283 in section 3.10.1 of [RFC7296] to specify the mode Data-Security SAs 2284 should be created in. The GCKS MUST include the USE_TRANSPORT_MODE 2285 notification in a message containing the GSA payload if Data-Security 2286 SAs are to be created in transport mode and MUST NOT include if they 2287 are to be created in tunnel mode. 2289 Note, that it is not possible with this specification to create a 2290 group where some Data-Security SAs use transport mode and the others 2291 use tunnel mode. If such a configuration is needed two different 2292 groups must be defined. 2294 4.8. Authentication Payload 2296 G-IKEv2 uses the same Authentication payload as specified in 2297 [RFC7296], section 3.8, to authenticate the rekey message. However, 2298 if it is used in the GSA_REKEY messages the content of the payload is 2299 computed differently, as described in Section 2.4.1.1. 2301 5. Usigng G-IKEv2 Attributes 2303 G-IKEv2 defines a number of attributes, that are used to convey 2304 information from GCKS to GMs. There are some restrictions on where 2305 and when these attributes can appear in G-IKEv2 messages, which are 2306 defined when the attributes are introduced. For convenience these 2307 restrictions are summarized in Table 1 (for multicast rekey 2308 operations) and Table 2 (for inband rekey operations) below. 2310 The following notation is used: 2312 S A single attribute of this type must be present 2314 M Multiple attributes of this type may be present 2316 [] Attribute is optional 2318 - Attribute must not be present 2320 Note, that the restrictions are defined per a substructure 2321 corresponding attributes are defined for and not per whole G-IKEv2 2322 message. 2324 +-------------------------+--------------------+--------------------+ 2325 | Attributes | GSA_AUTH | GSA_REKEY | 2326 | | GSA_REGISTRATION | | 2327 +-------------------------+--------------------+--------------------+ 2328 | GSA_KEY_LIFETIME | S | S | 2329 | | | | 2330 | GSA_INITIAL_MESSAGE_ID | [S] | [S] | 2331 | | | | 2332 | GSA_NEXT_SPI | [M] | [M] | 2333 | | | | 2334 | GAP_ATD | [S] | [S] | 2335 | | | | 2336 | GAP_DTD | [S] | [S] | 2337 | | | | 2338 | GAP_SID_BITS | S* | - | 2339 | | | | 2340 | SA_KEY | S | S/[M]** | 2341 | | | | 2342 | WRAP_KEY | [M]** | [M]** | 2343 | | | | 2344 | AUTH_KEY | S*** | [S]**** | 2345 | | | | 2346 | GM_SID | S*/[M]* | - | 2347 +-------------------------+--------------------+--------------------+ 2349 Table 1: Using attributes in G-IKEv2 exchanges when multicast rekey 2350 is used 2352 * The GAP_SID_BITS attribute must be present if the GCKS policy 2353 includes at least one cipher in counter mode of operation and 2354 the GM included the SENDER notify into the registration 2355 request. Otherwise it must not be present. At least one 2356 GM_SID attribute must be present in the former case (and more 2357 may be present if the GM requested more SIDs) and no GM_SID 2358 attributes must be present in the latter case. 2360 ** The WRAP_KEY attributes may be present if the GCKS employs key 2361 management method that relies on key tree (like LKH). 2363 *** The AUTH_KEY attribute must be present if the GCKS employs 2364 authentication method other than NULL Authentication. 2366 *** The AUTH_KEY attribute may be present if the GCKS employs 2367 authentication method based on digital signatures and wants to 2368 change the public key for the following multicast rekey 2369 operations. 2371 +-------------------------+--------------------+--------------------+ 2372 | Attributes | GSA_AUTH | GSA_INBAND_REKEY | 2373 | | GSA_REGISTRATION | | 2374 +-------------------------+--------------------+--------------------+ 2375 | GSA_KEY_LIFETIME | [S] | [S] | 2376 | | | | 2377 | GSA_INITIAL_MESSAGE_ID | - | - | 2378 | | | | 2379 | GSA_NEXT_SPI | - | - | 2380 | | | | 2381 | GAP_ATD | [S] | [S] | 2382 | | | | 2383 | GAP_DTD | [S] | [S] | 2384 | | | | 2385 | GAP_SID_BITS | S* | - | 2386 | | | | 2387 | SA_KEY | S | S | 2388 | | | | 2389 | WRAP_KEY | - | - | 2390 | | | | 2391 | AUTH_KEY | - | - | 2392 | | | | 2393 | GM_SID | S*/[M]* | - | 2394 +-------------------------+--------------------+--------------------+ 2396 Table 2: Using attributes in G-IKEv2 exchanges when inband rekey is 2397 used 2399 * The GAP_SID_BITS attribute must be present if the GCKS policy 2400 includes at least one cipher in counter mode of operation and 2401 the GM included the SENDER notify into the registration 2402 request. Otherwise it must not be present. At least one 2403 GM_SID attribute must be present in the former case (and more 2404 may be present if the GM requested more SIDs) and no GM_SID 2405 attributes must be present in the latter case. 2407 6. Interaction with other IKEv2 Protocol Extensions 2409 A number of IKEv2 extensions is defined that can be used to extend 2410 protocol functionality. G-IKEv2 is compatible with most of them. In 2411 particular, EAP authentication defined in [RFC7296] can be used to 2412 establish registration IKE SA, as well as EAP-only authentication 2413 [RFC5998] and Secure Password authentication [RFC6467]. G-IKEv2 is 2414 compatible with and can use IKEv2 Redirect Mechanism [RFC5685] and 2415 IKEv2 Session Resumption [RFC5723]. G-IKEv2 is also compatible with 2416 Multiple Key Exchanges in IKEv2 framework, defined in 2417 [I-D.ietf-ipsecme-ikev2-multiple-ke]. 2419 The above list of compatible IKEv2 extensions is not exhaustive, 2420 however some IKEv2 extensions require special handling if used in 2421 G-IKEv2. 2423 6.1. Mixing Preshared Keys in IKEv2 for Post-quantum Security 2425 G-IKEv2 can take advantage of the protection provided by Postquantum 2426 Preshared Keys (PPK) for IKEv2 [RFC8784]. However, the use of PPK 2427 leaves the initial IKE SA susceptible to quantum computer (QC) 2428 attacks. While group SA keys are protected with the default KWK 2429 (GSK_w), which is derived from SK_d and thus cannot be broken even by 2430 attacker equipped with a QC, authentication of these keys relies on 2431 authentication of IKE SA messages, which is not secure against QC 2432 until the initial IKE SA is rekeyed. In additional, the other 2433 content of IKE SA messages may also be visible to an attacker with a 2434 QC. See Section 6 of [RFC8784] for details. 2436 For these reasons the GCKS MUST NOT send GSA and KD payloads in the 2437 GSA_AUTH response message and MUST return a new notification 2438 REKEY_IS_NEEDED instead. Upon receiving this notification in the 2439 GSA_AUTH response the GM MUST perform an IKE SA rekey and then 2440 initiate a new GSA_REGISTRATION request for the same group. Below 2441 are possible scenarios involving using PPK. 2443 The GM starts the IKE_SA_INIT exchange requesting using PPK, and the 2444 GCKS responds with agreement to do it, or aborts according to its 2445 "mandatory_or_not" flag: 2447 Initiator (Member) Responder (GCKS) 2448 -------------------- ------------------ 2449 HDR, SAi1, KEi, Ni, N(USE_PPK) --> 2450 <-- DR, SAr1, KEr, Nr, [CERTREQ], 2451 N(USE_PPK) 2453 Figure 22: IKE_SA_INIT Exchange requesting using PPK 2455 The GM then starts the GSA_AUTH exchange with the PPK_ID; if using 2456 PPK is not mandatory for the GM, the NO_PPK_AUTH notification is 2457 included in the request: 2459 Initiator (Member) Responder (GCKS) 2460 -------------------- ------------------ 2461 HDR, SK{IDi, AUTH, IDg, 2462 N(PPK_IDENTITY), N(NO_PPK_AUTH)} --> 2464 Figure 23: GSA_AUTH Request using PPK 2466 If the GCKS has no such PPK and using PPK is not mandatory for it and 2467 the NO_PPK_AUTH is included, then the GCKS continues without PPK; in 2468 this case no rekey is needed: 2470 Initiator (Member) Responder (GCKS) 2471 -------------------- ------------------ 2472 <-- HDR, SK{IDr, AUTH, GSA, KD} 2474 Figure 24: GSA_AUTH Response using no PPK 2476 If the GCKS has no such PPK and either the NO_PPK_AUTH is missing or 2477 using PPK is mandatory for the GCKS, the GCKS aborts the exchange: 2479 Initiator (Member) Responder (GCKS) 2480 -------------------- ------------------ 2481 <-- HDR, SK{N(AUTHENTICATION_FAILED)} 2483 Figure 25: GSA_AUTH Error Response 2485 Assuming the GCKS has the proper PPK it continues with a request to 2486 the GM to immediately perform a rekey by sending the REKEY_IS_NEEDED 2487 notification: 2489 Initiator (Member) Responder (GCKS) 2490 -------------------- ------------------ 2491 <-- HDR, SK{IDr, AUTH, N(PPK_IDENTITY), 2492 N(REKEY_IS_NEEDED) } 2494 Figure 26: GSA_AUTH Response using PPK 2496 The GM initiates the CREATE_CHILD_SA exchange to rekey the initial 2497 IKE SA and then makes a new registration request for the same group 2498 over the new IKE SA: 2500 Initiator (Member) Responder (GCKS) 2501 -------------------- ------------------ 2502 HDR, SK{SA, Ni, KEi} --> 2503 <-- HDR, SK{SA, Nr, KEr} 2504 HDR, SK{IDg} ---> 2505 <-- HDR, SK{GSA, KD} 2507 Figure 27: Rekeying IKE SA followed by GSA_REGISTRATION Exchange 2509 Note, that [I-D.smyslov-ipsecme-ikev2-qr-alt] MAY be used to make the 2510 initial IKE SA secure against QC. 2512 7. Security Considerations 2514 7.1. GSA Registration and Secure Channel 2516 G-IKEv2 registration exchange uses IKEv2 IKE_SA_INIT protocols, 2517 inheriting all the security considerations documented in [RFC7296] 2518 section 5 Security Considerations, including authentication, 2519 confidentiality, protection against man-in-the-middle, protection 2520 against replay/reflection attacks, and denial of service protection. 2521 The GSA_AUTH and GSA_REGISTRATION exchanges also take advantage of 2522 those protections. In addition, G-IKEv2 brings in the capability to 2523 authorize a particular group member regardless of whether they have 2524 the IKEv2 credentials. 2526 7.2. GSA Maintenance Channel 2528 The GSA maintenance channel is cryptographically and integrity 2529 protected using the cryptographic algorithm and key negotiated in the 2530 GSA member registration exchanged. 2532 7.2.1. Authentication/Authorization 2534 The authentication key is distributed during the GM registration, and 2535 the receiver of the rekey message uses that key to verify the message 2536 came from the authorized GCKS. An implicit authentication can also 2537 be used, in which case the ability of the GM to decrypt and to verify 2538 ICV of the received message proved taht a sender of the message is a 2539 member of the group. However, implicit authentication doesn't 2540 provide source origin authentication, so the GM cannot be sure that 2541 the message came from the GCKS. For this reason using implicit 2542 authentication is NOT RECOMMENDED unless in a small group of trusted 2543 parties. 2545 7.2.2. Confidentiality 2547 Confidentiality is provided by distributing a confidentiality key as 2548 part of the GSA member registration exchange. 2550 7.2.3. Man-in-the-Middle Attack Protection 2552 GSA maintenance channel is integrity protected by using a digital 2553 signature. 2555 7.2.4. Replay/Reflection Attack Protection 2557 The GSA_REKEY message includes a monotonically increasing sequence 2558 number to protect against replay and reflection attacks. A group 2559 member will recognize a replayed message by comparing the Message ID 2560 number to that of the last received rekey message, any rekey message 2561 containing a Message ID number less than or equal to the last 2562 received value MUST be discarded. Implementations should keep a 2563 record of recently received GSA rekey messages for this comparison. 2565 8. IANA Considerations 2567 8.1. New Registries 2569 A new set of registries is created for G-IKEv2 on IKEv2 parameters 2570 page [IKEV2-IANA]. The terms Reserved, Expert Review and Private Use 2571 are to be applied as defined in [RFC8126]. 2573 This document creates a new IANA registry "Transform Type - 2574 Group Key Management Methods". The initial values of the new 2575 registry are: 2577 Value Group Key Management Method 2578 ------------------------------------------------------- 2579 Reserved 0 2580 Wrapped Key Download 1 2581 Unassigned 2-1023 2582 Private Use 1024-65535 2584 Changes and additions to the unassigned range of this registry are by 2585 the Expert Review Policy [RFC8126]. 2587 This document creates a new IANA registry "GSA Attributes". The 2588 initial values of the new registry are: 2590 GSA Attributes Value Type Multiple Protocol 2591 --------------------------------------------------------------------- 2592 Reserved 0 2593 GSA_KEY_LIFETIME 1 V N GIKE_REKEY, AH, ESP 2594 GSA_INITIAL_MESSAGE_ID 2 V N GIKE_REKEY 2595 GSA_NEXT_SPI 3 V Y GIKE_REKEY, AH, ESP 2596 Unassigned 5-16383 2597 Private Use 16384-32767 2599 Changes and additions to the unassigned range of this registry are by 2600 the Expert Review Policy [RFC8126]. 2602 This document creates a new IANA registry "GAP Attributes". The 2603 initial values of the new registry are: 2605 GAP Attributes Value Type Multiple 2606 ---------------------------------------------------- 2607 Reserved 0 2608 GAP_ATD 1 B N 2609 GAP_DTD 2 B N 2610 GAP_SID_BITS 3 B N 2611 Unassigned 4-16383 2612 Private Use 16384-32767 2614 Changes and additions to the unassigned range of this registry are by 2615 the Expert Review Policy [RFC8126]. 2617 This document creates a new IANA registry "Group Key Packet 2618 Attributes". The initial values of the new registry are: 2620 Group Key Packet 2621 Attributes Value Type Multiple Protocol 2622 ------------------------------------------------------------ 2623 Reserved 0 2624 SA_KEY 1 V Y GIKE_REKEY, 2625 N AH, ESP 2626 Unassigned 2-16383 2627 Private Use 16384-32767 2629 Changes and additions to the unassigned range of this registry are by 2630 the Expert Review Policy [RFC8126]. 2632 This document creates a new IANA registry "Member Key Packet 2633 Attributes". The initial values of the new registry are: 2635 Member Key Packet 2636 Attributes Value Type Multiple 2637 ------------------------------------------------ 2638 Reserved 0 2639 WRAP_KEY 1 V Y 2640 AUTH_KEY 2 V N 2641 GM_SID 3 V Y 2642 Unassigned 4-16383 2643 Private Use 16384-32767 2645 Changes and additions to the unassigned range of this registry are by 2646 the Expert Review Policy [RFC8126]. 2648 8.2. Changes in the Existing IKEv2 Registries 2650 This document defines new Exchange Types in the "IKEv2 Exchange 2651 Types" registry: 2653 Value Exchange Type 2654 ---------------------------- 2655 39 GSA_AUTH 2656 40 GSA_REGISTRATION 2657 41 GSA_REKEY 2658 GSA_INBAND_REKEY 2660 This document defines new Payload Types in the "IKEv2 Payload Types" 2661 registry: 2663 Value Next Payload Type Notation 2664 ---------------------------------------------------- 2665 50 Group Identification IDg 2666 51 Group Security Association GSA 2667 52 Key Download KD 2669 This document makes the following changes to the "Transform Type 2670 Values" registry: 2672 o Defines two new transform types -- "Authentication Method (AUTH)" 2673 and "Group Key Management Method (GKM)"; 2675 o Renames existing transform type "Extended Sequence Numbers (ESN)" 2676 to "Replay Protection (RP)"; 2678 o Changes the "Used In" column for the existing allocations as 2679 follows; 2681 Type Description Used In 2682 --------------------------------------------------------------------- 2683 1 Encryption Algorithm (ENCR) IKE, GIKE_REKEY and ESP 2684 2 Pseudo-random Function (PRF) IKE, GIKE_REKEY 2685 3 Integrity Algorithm (INTEG) IKE, GIKE_REKEY, AH, 2686 optional in ESP 2687 4 Diffie-Hellman Group (D-H) IKE, optional in AH, ESP 2688 5 Replay Protection (RP) AH and ESP 2689 Authentication Method (AUTH) GIKE_REKEY 2690 Group Key Management Method (GKM) GIKE_REKEY 2692 This document defines a new Attribute Type in the "IKEv2 Transform 2693 Attribute Types" registry: 2695 Value Attribute Type Format 2696 ---------------------------------------------- 2697 Algorithm Identifier TLV 2699 This document renames the "Transform Type 5 - Extended Sequence 2700 Numbers Transform IDs" registry to "Transform Type 5 - Replay 2701 Protection Transform IDs" and also adds a new value into this 2702 registry: 2704 Number Name 2705 --------------------- 2706 Not Used 2708 This document defines new Notify Message Types in the "Notify Message 2709 Types - Error Types" registry: 2711 Value Notify Messages - Error Types 2712 ----------------------------------------- 2713 45 INVALID_GROUP_ID 2714 46 AUTHORIZATION_FAILED 2715 REGISTRATION_FAILED 2717 This document defines new Notify Message Types in the "Notify Message 2718 Types - Status Types" registry: 2720 Value Notify Messages - Status Types 2721 ------------------------------------------ 2722 16429 SENDER 2724 The Notify type with the value 16429 was allocated earlier in the 2725 development of G-IKEv2 document with the name SENDER_REQUEST_ID. 2726 This specification changes its name to SENDER. 2728 This document defines a new Security Protocol Identifier in the 2729 "IKEv2 Security Protocol Identifiers" registry: 2731 Protocol ID Protocol 2732 -------------------------- 2733 GIKE_REKEY 2735 9. Acknowledgements 2737 The authors thank Lakshminath Dondeti and Jing Xiang for first 2738 exploring the use of IKEv2 for group key management and providing the 2739 basis behind the protocol. Mike Sullenberger and Amjad Inamdar were 2740 instrumental in helping resolve many issues in several versions of 2741 the document. 2743 The authors are grateful to Tero Kivinen for his careful review and 2744 valuable proposals how to improve the document. 2746 10. Contributors 2748 The following individuals made substantial contributions to early 2749 versions of this memo. 2751 Sheela Rowles 2752 Cisco Systems 2753 170 W. Tasman Drive 2754 San Jose, California 95134-1706 2755 USA 2757 Phone: +1-408-527-7677 2758 Email: sheela@cisco.com 2760 Aldous Yeung 2761 Cisco Systems 2762 170 W. Tasman Drive 2763 San Jose, California 95134-1706 2764 USA 2766 Phone: +1-408-853-2032 2767 Email: cyyeung@cisco.com 2769 Paulina Tran 2770 Cisco Systems 2771 170 W. Tasman Drive 2772 San Jose, California 95134-1706 2773 USA 2775 Phone: +1-408-526-8902 2776 Email: ptran@cisco.com 2778 Yoav Nir 2779 Dell EMC 2780 9 Andrei Sakharov St 2781 Haifa 3190500 2782 Israel 2784 Email: ynir.ietf@gmail.com 2786 11. References 2788 11.1. Normative References 2790 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2791 Requirement Levels", BCP 14, RFC 2119, 2792 DOI 10.17487/RFC2119, March 1997, 2793 . 2795 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2796 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2797 December 2005, . 2799 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 2800 DOI 10.17487/RFC4302, December 2005, 2801 . 2803 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2804 RFC 4303, DOI 10.17487/RFC4303, December 2005, 2805 . 2807 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2808 Housley, R., and W. Polk, "Internet X.509 Public Key 2809 Infrastructure Certificate and Certificate Revocation List 2810 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2811 . 2813 [RFC6054] McGrew, D. and B. Weis, "Using Counter Modes with 2814 Encapsulating Security Payload (ESP) and Authentication 2815 Header (AH) to Protect Group Traffic", RFC 6054, 2816 DOI 10.17487/RFC6054, November 2010, 2817 . 2819 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2820 Kivinen, "Internet Key Exchange Protocol Version 2 2821 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2822 2014, . 2824 [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in 2825 the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, 2826 DOI 10.17487/RFC7427, January 2015, 2827 . 2829 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2830 Writing an IANA Considerations Section in RFCs", BCP 26, 2831 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2832 . 2834 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2835 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2836 May 2017, . 2838 11.2. Informative References 2840 [I-D.ietf-ipsecme-ikev2-intermediate] 2841 Smyslov, V., "Intermediate Exchange in the IKEv2 2842 Protocol", draft-ietf-ipsecme-ikev2-intermediate-10 (work 2843 in progress), March 2022. 2845 [I-D.ietf-ipsecme-ikev2-multiple-ke] 2846 Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S., 2847 Geest, D. V., Garcia-Morchon, O., and V. Smyslov, 2848 "Multiple Key Exchanges in IKEv2", draft-ietf-ipsecme- 2849 ikev2-multiple-ke-05 (work in progress), March 2022. 2851 [I-D.smyslov-ipsecme-ikev2-qr-alt] 2852 Smyslov, V., "Alternative Approach for Mixing Preshared 2853 Keys in IKEv2 for Post-quantum Security", draft-smyslov- 2854 ipsecme-ikev2-qr-alt-04 (work in progress), August 2021. 2856 [IKEV2-IANA] 2857 IANA, "Internet Key Exchange Version 2 (IKEv2) 2858 Parameters", . 2861 [NNL] Naor, D., Noal, M., and J. Lotspiech, "Revocation and 2862 Tracing Schemes for Stateless Receivers", Advances in 2863 Cryptology, Crypto '01, Springer-Verlag LNCS 2139, 2001, 2864 pp. 41-62, 2001, 2865 . 2867 [OFT] McGrew, D. and A. Sherman, "Key Establishment in Large 2868 Dynamic Groups Using One-Way Function Trees", Manuscript, 2869 submitted to IEEE Transactions on Software Engineering, 2870 1998, . 2873 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2874 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 2875 . 2877 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 2878 Multicast: Issues and Architectures", RFC 2627, 2879 DOI 10.17487/RFC2627, June 1999, 2880 . 2882 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 2883 Identifiers for the Internet X.509 Public Key 2884 Infrastructure Certificate and Certificate Revocation List 2885 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 2886 2002, . 2888 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 2889 Counter Mode With IPsec Encapsulating Security Payload 2890 (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, 2891 . 2893 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 2894 Architecture", RFC 3740, DOI 10.17487/RFC3740, March 2004, 2895 . 2897 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 2898 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 2899 RFC 3948, DOI 10.17487/RFC3948, January 2005, 2900 . 2902 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 2903 "Multicast Security (MSEC) Group Key Management 2904 Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005, 2905 . 2907 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 2908 (GCM) in IPsec Encapsulating Security Payload (ESP)", 2909 RFC 4106, DOI 10.17487/RFC4106, June 2005, 2910 . 2912 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 2913 Mode with IPsec Encapsulating Security Payload (ESP)", 2914 RFC 4309, DOI 10.17487/RFC4309, December 2005, 2915 . 2917 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 2918 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 2919 DOI 10.17487/RFC4543, May 2006, 2920 . 2922 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 2923 Extensions to the Security Architecture for the Internet 2924 Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, 2925 . 2927 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 2928 "Elliptic Curve Cryptography Subject Public Key 2929 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 2930 . 2932 [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for 2933 the Internet Key Exchange Protocol Version 2 (IKEv2)", 2934 RFC 5685, DOI 10.17487/RFC5685, November 2009, 2935 . 2937 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 2938 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 2939 DOI 10.17487/RFC5723, January 2010, 2940 . 2942 [RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension 2943 for EAP-Only Authentication in IKEv2", RFC 5998, 2944 DOI 10.17487/RFC5998, September 2010, 2945 . 2947 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 2948 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 2949 October 2011, . 2951 [RFC6467] Kivinen, T., "Secure Password Framework for Internet Key 2952 Exchange Version 2 (IKEv2)", RFC 6467, 2953 DOI 10.17487/RFC6467, December 2011, 2954 . 2956 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 2957 (IKEv2) Message Fragmentation", RFC 7383, 2958 DOI 10.17487/RFC7383, November 2014, 2959 . 2961 [RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the 2962 Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634, 2963 DOI 10.17487/RFC7634, August 2015, 2964 . 2966 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 2967 "PKCS #1: RSA Cryptography Specifications Version 2.2", 2968 RFC 8017, DOI 10.17487/RFC8017, November 2016, 2969 . 2971 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 2972 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 2973 August 2017, . 2975 [RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, 2976 "Mixing Preshared Keys in the Internet Key Exchange 2977 Protocol Version 2 (IKEv2) for Post-quantum Security", 2978 RFC 8784, DOI 10.17487/RFC8784, June 2020, 2979 . 2981 Appendix A. Use of LKH in G-IKEv2 2983 Section 5.4 of [RFC2627] describes the LKH architecture, and how a 2984 GCKS uses LKH to exclude group members. This section clarifies how 2985 the LKH architecture is used with G-IKEv2. 2987 A.1. Notation 2989 In this section we will use the notation X{Y} where a key with ID Y 2990 is encrypted with the key with ID X. The notation GSK_w{Y} means 2991 that the default wrap key GSK_w (with zero KWK ID)is used to encrypt 2992 key Y, and the notation X{K_sa} means key X is used to encrypt the SA 2993 key K_sa (wich always has zero Key ID). Note, that GSK_w{K_sa} means 2994 that the SA key is encrypted with the default wrap key, in which case 2995 both KWK ID and Key ID are zero. For simplicity we will assume that 2997 The content of the KD payload will be shown as a sequence of Key 2998 Packets. The Group Key Packet substructure will be denoted as 2999 GP(SAn)(), when n is an SPI for the SA, and the Member Key Packet 3000 substructure will be denoted as MP(). The content of the Key Packets 3001 is shown as SA_KEY and WRAP_KEY attributes with the notation 3002 described above. For simplicity the type of the attribute will not 3003 be shown, because it is implicitly defined by the type of Key Packet. 3005 Here is the example of KD payload. 3007 KD(GP1(X{K_sa}),MP(Y{X},Z{Y},GSK_w{Z}) 3009 For simplicity any other attributes in the KD payload are omitted. 3011 We will also use the notation X->Y->Z to describe the Key Path. In 3012 this case key Y is needed to dectypt key X and key Z is needed to 3013 decrypt key Y. In the example above the keys had the following 3014 relation: K_sa->X->Y->Z->GSK_w. 3016 A.2. Group Creation 3018 When a GCKS forms a group, it creates a key tree as shown in the 3019 figure below. The key tree contains logical keys (which are 3020 represented as the values of their Key IDs in the figure) and a 3021 private key shared with only a single GM (the GMs are represented as 3022 letters followed by the corresponding key ID in parentheses in the 3023 figure). The root of the tree contains the multicast Rekey SA key 3024 (which is represented as SAn(K_san). The figure below assumes that 3025 the Key IDs are assigned sequentially; this is not a requirement and 3026 only used for illustrative purposes. The GCKS may create a complete 3027 tree as shown, or a partial tree which is created on demand as 3028 members join the group. 3030 SA1(K_sa1) 3031 +------------------------------+ 3032 1 2 3033 +---------------+ +---------------+ 3034 3 4 5 6 3035 +-------+ +-------+ +--------+ +--------+ 3036 A(7) B(8) C(9) D(10) E(11) F(12) G(13) H(14) 3038 Figure 28: Initial LKH tree 3040 When GM A joins the group, the GCKS provides it with the keys in the 3041 KD payload of the GSA_AUTH or GSA_REGISTRATION exchange. Given the 3042 tree shown in figure above, the KD payload will be: 3044 KD(GP(SA1)(1{K_sa1}),MP(3{1},7{3},GSK_w{7}) 3046 KD Payload for the Group Member A 3048 From these attributes the GM A will construct the Key Path 3049 K_sa1->1->3->7->GSK_w and since it ends up with GSK_w, it will use 3050 all the WRAP_KEY attributes present in the path as its Working Key 3051 Path: 1->3->7. 3053 Similarly, when other GMs will be joining the group they will be 3054 provided with the corresponding keys, so after all the GMs will have 3055 the following Working Key Paths: 3057 A: 1->3->7 B: 1->3->8 C: 1->4->9, D: 1->4->10 3058 E: 2->5->11 F: 2->5->12 G: 2->6->13 H: 2->6->14 3060 A.3. Simple Group SA Rekey 3062 If the GCKS performs a simple SA rekey without changing group 3063 membership, it will only send Group Key Packet in the KD payload with 3064 a new SA key encrypted with the default KWK. 3066 KD(GP(SA2)(GSK_w{K_sa2})) 3068 KD Payload for the Simple Group SA Rekey 3070 All the GMs will be able to decrypt it and no changes in their 3071 Working Key Paths will happen. 3073 A.4. Group Member Exclusion 3075 If the GKCS has reason to believe that a GM should be excluded, then 3076 it can do so by sending a GSA_REKEY message that includes a set of 3077 GM_KEY attributes which would allow all GMs except for the excluded 3078 one to get a new SA key. 3080 In the example below the GCKS excludes GM F. For this purpose it 3081 changes the key tree as follows, replacing the key 2 with the key 15 3082 and the key 5 with the key 16. It also generates a new SA key for a 3083 new SA3. 3085 SA3(K_sa3) 3086 +------------------------------+ 3087 1 15 3088 +---------------+ +---------------+ 3089 3 4 16 6 3090 +-------+ +-------+ +---- +--------+ 3091 A(7) B(8) C(9) D(10) E(11) F(12) G(13) H(14) 3093 Figure 29: LKH tree after F has been excluded 3095 Then it sends the following KD payload for the new Rekey SA3: 3097 KD(GP(SA3)(1{K_sa3},15{K_sa3}),MP(6{15},16{15},11{16}) 3099 KD Payload for the Group Member F 3101 While processing this KD payload: 3103 o GMs A, B, C and D will be able to decrypt the SA_KEY attribute 3104 1{K_sa3} by using the "1" key from their key path. Since no new 3105 GM_KEY attributes are in the new Key Path, they won't update their 3106 Working Key Paths. 3108 o GMs G and H will construct new Key Path 15->6 and will be able to 3109 decrypt the intermediate key 15 using the key 6 from their Working 3110 Key Paths. So, they will update their Working Key Paths replacing 3111 their beginnings up to the key 6 with the new Key Path (thus 3112 replacing the key 2 with the key 15). 3114 o GM E will construct new Key Path 16->15->11 and will be able to 3115 decrypt the intermediate key 16 using the key 11 from its Working 3116 Key Path. So, it will update its Working Key Path replacing its 3117 beginnings up to the key 11 with the new Key Path (thus replacing 3118 the key 2 with the key 15 and the key 5 with the key 16). 3120 o GM F won't be able to construct any Key Path leading to any key he 3121 possesses, so it will be unable to decrypt the new SA key for the 3122 SA3 and thus it will be excluded from the group once the SA3 is 3123 used. 3125 Finally, the GMs will have the following Working Key Paths: 3127 A: 1->3->7 B: 1->3->8 C: 1->4->9, D: 1->4->10 3128 E: 15->16->11 F: excluded G: 15->6->13 H: 15->6->14 3130 Authors' Addresses 3132 Valery Smyslov 3133 ELVIS-PLUS 3134 PO Box 81 3135 Moscow (Zelenograd) 124460 3136 Russian Federation 3138 Phone: +7 495 276 0211 3139 Email: svan@elvis.ru 3141 Brian Weis 3142 Independent 3143 USA 3145 Email: bew.stds@gmail.com