idnits 2.17.1 draft-yeung-g-ikev2-07.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 56 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 04, 2013) is 3819 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'N' is mentioned on line 307, but not defined == Missing Reference: 'D' is mentioned on line 309, but not defined == Unused Reference: 'FIPS197' is defined on line 1627, but no explicit reference was found in the text == Unused Reference: 'SP800-38A' is defined on line 1637, but no explicit reference was found in the text == Unused Reference: 'SP800-38D' is defined on line 1643, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS197' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-38A' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-38D' -- Obsolete informational reference (is this intentional?): RFC 2407 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MSEC Working Group S. Rowles 3 Internet-Draft A. Yeung, Ed. 4 Intended status: Standards Track P. Tran 5 Expires: May 08, 2014 Cisco Systems 6 Y. Nir 7 Check Point Software Technologies Ltd. 8 November 04, 2013 10 Group Key Management using IKEv2 11 draft-yeung-g-ikev2-07 13 Abstract 15 This document presents a new group key distribution protocol. The 16 protocol is in conformance with MSEC key management architecture it 17 contains two components: member registration and group rekeying, both 18 downloading group security associations from the Group Controller Key 19 Server to a member of the group. The new protocol is similar to 20 IKEv2 in message and payload formats as well as message semantics. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 08, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 58 1.2. Why do we need another GSA protocol? . . . . . . . . . . 4 59 1.3. G-IKEv2 Payloads . . . . . . . . . . . . . . . . . . . . 4 60 2. G-IKEv2 integration into IKEv2 protocol . . . . . . . . . . . 5 61 2.1. UDP port . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. G-IKEv2 Protocol . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. G-IKEv2 member registration and secure channel 64 establishment . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1.1. GSA_AUTH exchange . . . . . . . . . . . . . . . . . . 6 66 3.1.2. GSA_REGISTRATION Exchange . . . . . . . . . . . . . . 7 67 3.1.3. IKEv2 Header Initialization . . . . . . . . . . . . . 7 68 3.1.4. GM Registration Operations . . . . . . . . . . . . . 8 69 3.1.5. GCKS Registration Operations . . . . . . . . . . . . 9 70 3.2. Counter-based modes of operation . . . . . . . . . . . . 9 71 3.3. G-IKEv2 group maintenance channel . . . . . . . . . . . . 11 72 3.3.1. G-IKEv2 GSA_REKEY exchange . . . . . . . . . . . . . 11 73 3.3.2. Forward and Backward Access Control . . . . . . . . . 12 74 3.3.3. Forward Access Control Requirements . . . . . . . . . 13 75 3.3.4. Deletion of SAs . . . . . . . . . . . . . . . . . . . 14 76 3.3.5. GSA_REKEY GCKS Operations . . . . . . . . . . . . . . 14 77 3.3.6. GSA_REKEY GM Operations . . . . . . . . . . . . . . . 15 78 4. Header and Payload Formats . . . . . . . . . . . . . . . . . 15 79 4.1. The G-IKEv2 Header . . . . . . . . . . . . . . . . . . . 15 80 4.2. IDgroup Payload . . . . . . . . . . . . . . . . . . . . . 16 81 4.3. Group Security Association Payload . . . . . . . . . . . 16 82 4.3.1. GSA policy . . . . . . . . . . . . . . . . . . . . . 16 83 4.4. KEK Policy . . . . . . . . . . . . . . . . . . . . . . . 18 84 4.4.1. KEK Attributes . . . . . . . . . . . . . . . . . . . 19 85 4.4.2. KEK_MANAGEMENT_ALGORITHM . . . . . . . . . . . . . . 19 86 4.4.3. KEK_ENCR_ALGORITHM . . . . . . . . . . . . . . . . . 20 87 4.4.4. KEK_KEY_LENGTH . . . . . . . . . . . . . . . . . . . 20 88 4.4.5. KEK_KEY_LIFETIME . . . . . . . . . . . . . . . . . . 20 89 4.4.6. KEK_INTEGRITY_ALGORITHM . . . . . . . . . . . . . . . 20 90 4.4.7. KEK_AUTH_METHOD . . . . . . . . . . . . . . . . . . . 20 91 4.4.8. KEK_AUTH_ALGORITHM . . . . . . . . . . . . . . . . . 21 92 4.4.9. KEK_MESSAGE_ID . . . . . . . . . . . . . . . . . . . 21 93 4.5. GSA TEK Policy . . . . . . . . . . . . . . . . . . . . . 21 94 4.5.1. TEK ESP and AH Protocol-Specific Policy . . . . . . . 22 95 4.6. GSA Group Associated Policy . . . . . . . . . . . . . . . 23 96 4.6.1. ACTIVATION_TIME_DELAY/DEACTIVATION_TIME_DELAY . . . . 24 98 4.7. Key Download Payload . . . . . . . . . . . . . . . . . . 25 99 4.7.1. TEK Download Type . . . . . . . . . . . . . . . . . . 26 100 4.7.2. KEK Download Type . . . . . . . . . . . . . . . . . . 27 101 4.7.3. LKH Download Type . . . . . . . . . . . . . . . . . . 28 102 4.7.4. SID Download Type . . . . . . . . . . . . . . . . . . 31 103 4.8. Delete Payload . . . . . . . . . . . . . . . . . . . . . 33 104 4.9. Notify Payload . . . . . . . . . . . . . . . . . . . . . 33 105 4.10. Authentication Payload . . . . . . . . . . . . . . . . . 33 106 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 107 5.1. GSA registration and secure channel . . . . . . . . . . . 33 108 5.2. GSA maintenance channel . . . . . . . . . . . . . . . . . 34 109 5.2.1. Authentication/Authorization . . . . . . . . . . . . 34 110 5.2.2. Confidentiality . . . . . . . . . . . . . . . . . . . 34 111 5.2.3. Man-in-the-Middle Attack Protection . . . . . . . . . 34 112 5.2.4. Replay/Reflection Attack Protection . . . . . . . . . 34 113 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 114 6.1. New registries . . . . . . . . . . . . . . . . . . . . . 34 115 6.2. New payload and exchange types to existing IKEv2 registry 35 116 6.3. Payload Types . . . . . . . . . . . . . . . . . . . . . . 35 117 6.4. New Name spaces . . . . . . . . . . . . . . . . . . . . . 35 118 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 119 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 120 8.1. Normative References . . . . . . . . . . . . . . . . . . 36 121 8.2. Informative References . . . . . . . . . . . . . . . . . 36 122 Appendix A. Differences between G-IKEv2 and RFC 6407 . . . . . . 38 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 125 1. Introduction and Overview 127 This document presents a group key management protocol protected by 128 IKEv2. The data communications within the group are protected by a 129 key pushed to the group members (GMs) by the Group Controller/Key 130 Server (GCKS) using IKEv2 [RFC5996]. The GCKS pushes policy and keys 131 for the group to the GM after authenticating it using new payloads 132 added in the IKE_AUTH exchange. This document references IKEv2 133 [RFC5996] but it intended to be a separate document. GDOI update 134 document [RFC6407] presented GDOI using IKEv1 syntax. This document 135 uses IKEv2 syntax. The message semantics of IKEv2 are preserved, in 136 that all communications consists of message request-response pairs. 137 The exception to this rule are the rekeying messages, which are sent 138 in multicast without a response. A number of payloads were deemed 139 unnecessary since [RFC6407] are described in Appendix A 141 1.1. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 1.2. Why do we need another GSA protocol? 149 GDOI protocol specified in [RFC6407] is protected by IKEv1 phase1 150 security association defined in [RFC2407], [RFC2408] and [RFC2409]; 151 these documents are obsoleted and replaced by a new version of the 152 IKE protocol defined in RFC 5996. G-IKEv2 provides group key 153 management between the group member and group controller key server 154 using the new IKEv2 protocol and inherits the following key 155 advantages over GDOI: 157 1. Provide a simple mechanism for the responder to keep minimal 158 state and avoid DOS attack from forged IP address using cookie 159 challenge exchange. 161 2. Improve performance and network latency by the reduced number of 162 initial messages to complete the G-IKEv2 protocol from (10 163 messages in main mode and quick mode, 7 messages in aggressive 164 mode and quick) to 4 messages. 166 3. Fix cryptographic weakness with authentication HASH (ikev1 167 authentication HASH specified in RFC-2409 does not include all 168 ISAKMP payloads and does not include ISAKMP header). This issue 169 is documented at [IKE-HASH]. 171 4. Improve protocol reliability where all unicast messages are 172 ack'ed and sequenced. 174 5. Well defined behavior for error conditions to improve 175 interoperability. 177 1.3. G-IKEv2 Payloads 179 1. IDg (group ID) - The GM requests the GCKS for membership into the 180 group by sending its IDg payload. 182 2. GSA (Group Security Association) - The GCKS sends the group 183 policy to the GM using this payload. 185 3. KD (Key Download) - The GCKS sends the control and data keys to 186 the GM using the KD payload. 188 2. G-IKEv2 integration into IKEv2 protocol 190 The G-IKEv2 protocol provides the security mechanisms of IKEv2 (peer 191 authentication, confidentiality, message integrity) to protect the 192 group negotiations required for G-IKEv2. The G-IKEv2 exchange 193 further provides group authorization, and secure policy and key 194 download from the GCKS to its group members. 196 2.1. UDP port 198 G-IKEv2 SHOULD use port 848, the same as GDOI [RFC6407] , because 199 they serve a similar function, and can use the same ports, just as 200 IKEv1 and IKEv2 can share port 500. The version number in the IKEv2 201 header distinguishes the G-IKEv2 protocol from GDOI protocol 202 [RFC6407]. 204 3. G-IKEv2 Protocol 206 3.1. G-IKEv2 member registration and secure channel establishment 208 The registration protocol consists of minimum two exchanges 209 IKE_SA_INIT and GSA_AUTH; member registration may have a few more 210 messages exchanged if the EAP method, cookie challenge (for DoS) or 211 invalid KE are used. Each exchange consists of request/response 212 pairs. The first exchange IKE_SA_INIT is defined in IKEv2 [RFC5996]. 213 This exchange negotiates cryptographic algorithms, exchanges nonces 214 and does a Diffie-Hellman exchange between the member and the Group 215 Controller Key Server (GCKS). 217 The second exchange GSA_AUTH authenticates the previous messages, 218 exchange identities and certificates, . Parts of these messages are 219 encrypted and integrity protected with keys established through the 220 IKE_SA_INIT exchange, so the identities are hidden from eavesdroppers 221 and all fields in all the messages are authenticated. The GCKS MAY 222 authorize group members to be allowed into the group as part of the 223 GSA_AUTH exchange. Once the GCKS accepted a group member to join a 224 group it may downloads the data security keys (TEKs) and/or group key 225 encrypting key (KEK) or KEK array as part of GSA_AUTH response 226 message. In the following descriptions, the payloads contained in 227 the message are indicated by names as listed below. 229 Notation Payload 230 ------------------------------------------------------------ 231 AUTH Authentication 232 CERT Certificate 233 CERTREQ Certificate Request 234 GSA Group Security Association 235 HDR IKEv2 Header 236 IDg Identification - Group 237 IDi Identification - Initiator 238 IDr Identification - Responder 239 KD Key Download 240 KE Key Exchange 241 Ni, Nr Nonce SA Security Association 243 The details of the contents of each payload are described in 244 Section 4. Payloads that may optionally appear will be shown in 245 brackets, such as [ CERTREQ], indicate that optionally a certificate 246 request payload can be included. 248 3.1.1. GSA_AUTH exchange 250 After the group member and GCKS uses IKE_SA_INIT exchange to 251 negotiate cryptographic algorithms, exchange nonces, and perform a 252 Diffie-Hellman exchange as defined in IKEv2 [RFC5996], the GSA_AUTH 253 MAY be used for the GCKS to download group policy and keys to the 254 member. The security properties of the GSA_AUTH exchange are the 255 same as the properties of the IKE_AUTH exchange. It is used to 256 authenticate the IKE_SA_INIT messages, exchange identities and 257 certificates. G-IKEv2 also uses this exchange for group member 258 registration and optionally authorization. GSA_AUTH does not include 259 SA2, TSi and TSr since policy is not negotiated between group member 260 and GCKS but downloaded from the GCKS to the group member. 262 Initiator (Member) Responder (GCKS) 263 -------------------- ------------------ 264 HDR, SK { IDi, [ CERT,] [ CERTREQ,] [ IDr,] AUTH, 265 IDg, [N] } --> 267 After an unauthenticated secure channel is established by IKE_SA_INIT 268 exchange, the member initiates a registration request to join a group 269 indicated by the IDg payload. The GM can include 0 or more Notify 270 payload. Notify payload status type SENDER_ID_REQUEST is indicate a 271 request SIDs for Counter-based cipher from the GCKS. 273 <-- HDR, SK { IDr, [ CERT,] AUTH, [GSA, KD,] [D,] } 275 Besides response with IDr, optional CERT, and AUTH material, the GCKS 276 MAY also informs the member the cryptographic policies of the group 277 in the GSA payload and key material in the KD payload. GCKS can also 278 include Delete payload instructing the group member to delete 279 existing SAs it might have. 281 In addition to the IKEv2 error handling, GCKS can reject the 282 registration request when IDg is invalid or authorization fail, etc. 283 In these cases, see Section 4.9, the GSA_AUTH response will include 284 notify indicate errors. The member SHOULD delete the registration 285 IKE SA. 287 Initiator (Member) Responder (GCKS) 288 -------------------- ------------------ 289 <-- HDR, SK { N } 291 When the group member found the policy sent by the GCKS is 292 unacceptable, the member SHOULD send an IKEv2 delete using the 293 INFORMATION message exchange to bring down the authenticated IKE SA. 295 3.1.2. GSA_REGISTRATION Exchange 297 When a secure channel is already established between GM and KS, the 298 GM registration for a group can reuse the established secure channel. 299 In this scenario the GM will use the GSA_REGISTRATION exchange by 300 including the desired group ID (IDg) to request data security keys 301 (TEKs) and/or group key encrypting keys (KEKs) from the GCKS. The GM 302 MAY also include the Notify payload status type SENDER_ID_REQUEST to 303 request SIDs for Counter-based cipher from the GCKS. 305 Initiator (Member) Responder (GCKS) 306 -------------------- ------------------ 307 HDR, SK {IDg, [N] } --> 309 <-- HDR, SK { GSA, KD, [D] } 311 This exchange can also be used when the group member found the policy 312 sent by the GCKS is unacceptable. The group member can notify the 313 GCKS by sending IDg and the NOTIFY type NO_PROPOSAL_CHOSEN as shown 314 below. The GCKS MUST unregister the group member. 316 Initiator (Member) Responder (GCKS) 317 -------------------- ------------------ 318 HDR, SK {IDg [N,]} --> 320 <-- HDR, SK {} 322 3.1.3. IKEv2 Header Initialization 324 The Major Version is (2) and Minor Version number (0) according to 325 IKEv2 [RFC5996], and maintained in this document. The G-IKEv2 326 IKE_SA_INIT, GSA_AUTH and GSA_REGISTRATION use the SPI according to 327 IKEv2 [RFC5996],section 2.6. 329 3.1.4. GM Registration Operations 331 A G-IKEv2 Initiator (GM) requesting registration contacts the GCKS 332 using the IKE_SA_INIT exchange and receives the response from the 333 GCKS. This exchange is unchanged from the IKE_SA_INIT in IKEv2 334 protocol. 336 Upon completion of parsing and verifying the IKE_SA_INIT response, 337 the GM sends the GSA_AUTH message with the IKEv2 payloads from 338 IKE_AUTH (without the SAi2, TSi and TSr) along with the Group ID 339 informing the GCKS of the group the initiator wishes to join. The 340 initiator MAY specify how many Sender-ID values it would like to 341 receive in the Notify payload status type SENDER_ID_REQUEST in case 342 the Data Security SA supports a counter mode cipher [section 3.2]. 344 Upon receiving the GSA_AUTH, the initiator then parses the response 345 from the GCKS authenticating the exchange using the IKEv2 method, 346 then processing the GSA, and KD. 348 The GSA payload contains the security protocol and cryptographic 349 protocols used by the group. This policy describes the Re-key SA 350 (KEK), if present, Data-security SAs (TEK), and other group policy 351 (GAP). If the policy in the GSA payload is not acceptable to the GM, 352 it SHOULD tear down the session after notifying the GCKS. Finally 353 the KD is parsed providing the keying material for the TEK and/or 354 KEK. The GM interprets the KD key packets, where each key packet 355 includes the keying material for SAs distributed in the GSA payload. 356 Keying material is matched by comparing the SPIs in the key packets 357 to SPIs previously included in the GSA payloads. Once TEK keys and 358 policy are matched, the GM provides them to the data security 359 subsystem, and it is ready to send or receive packets matching the 360 TEK policy. 362 The GSA KEK policy MUST include KEK attribute KEK_MESSAGE_ID with a 363 message id. The message id in the KEK_MESSAGE_ID attribute MUST be 364 checked against any previously received message id for this group. 365 If it is less than the previously received number, it should be 366 considered stale and ignored. This could happen if two GSA_AUTH 367 exchanges happened in parallel, and the message id changed. This 368 KEK_MESSAGE_ID is used by the GM to prevent GSA_REKEY message replay 369 attacks. The first GSA_REKEY message that the GM receives from the 370 GCKS has to have message id greater or equal to the message id 371 received in the KEK_MESSAGE_ID attribute. 373 3.1.5. GCKS Registration Operations 375 A G-IKEv2 GCKS passively listens for incoming requests from group 376 members. The GCKS receives the IKE_SA_INIT request, select the IKE 377 proposal, generates nonce and DH to include them in the IKE_SA_INIT 378 response. 380 Upon receiving the GSA_AUTH request, and after authenticate the group 381 member using the same properties as IKEv2, the GCKS locates the group 382 the GM wishes to join, extracts the policy for that group. If the 383 GCKS policy desires authorization, the GCKS authorizes the group 384 member against the specified credentials before preparing to send 385 GSA_AUTH response. The GSA_AUTH response MAY include group policy in 386 GSA payload and keys in the KD payload. If the GCKS policy include 387 group rekey option, this policy is constructed in the GSA KEK and the 388 key is constructed in the KD KEK. The GSA KEK MUST include attribute 389 KEK_MESSAGE_ID specify the starting message id the GCKS will be using 390 when sending the GSA_REKEY message to the group member. This message 391 id is used prevent replay attacks of the GSA_REKEY message and will 392 be increasing each time a GSA_REKEY message is sent to the group. 393 The GCKS data traffic policy is included in the GSA TEK and keys are 394 included in KD TEK. GSA GAP MAY also included to provide the ATD and 395 /or DTD [section 4.6.1] specifying activation and deactivation delays 396 for SAs generated from the TEKs. If one or more Data Security SAs 397 distributed in the GSA payload included a counter mode of operation, 398 the GCKS includes at least one SID value in the KD payload, and 399 possibly more depending on the request received in the NOTIFY payload 400 status type SENDER_ID_REQUEST requesting the number of SIDs from the 401 group member. 403 If the GCKS receives a GSA_REGISTRATION exchange with a request to 404 register a GM to a group, the GCKS will need to authorize the GM with 405 the new group (IDg) and respond with corresponding group policy and 406 keys. If the GCKS fails to authorize the GM, it will respond with 407 the AUTHORIZATION_FAILED notify message. 409 3.2. Counter-based modes of operation 411 Several new counter-based modes of operation have been specified for 412 ESP (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES-CCM [RFC4309], 413 AES-GMAC [RFC4543]) and AH (e.g., AES-GMAC [RFC4543]). These 414 counter-based modes require that no two senders in the group ever 415 send a packet with the same Initialization Vector (IV) using the same 416 cipher key and mode. This requirement is met in G-IKEv2 when the 417 following requirements are met: 419 o The GCKS distributes a unique key for each Data-Security SA. 421 o The GCKS uses the method described in [RFC6054], which assigns each 422 sender a portion of the IV space by provisioning each sender with one 423 or more unique SID values. 425 When at least one Data-Security SA included in the group policy 426 includes a counter-mode, the GCKS automatically allocates and 427 distributes one SID to each group member acting in the role of sender 428 on the Data-Security SA. The SID value is used exclusively by the 429 group member to which it was allocated. The group member uses the 430 same SID for each Data-Security SA specifying the use of a counter- 431 based mode of operation. A GCKS MUST distribute unique keys for each 432 Data-Security SA including a counter-based mode of operation in order 433 to maintain a unique key and nonce usage. 435 During registration, the group member can choose to request one or 436 more SID values. Requesting a value of 1 is not necessary since the 437 GCKS will automatically allocate exactly one to the sending group 438 member. A group member MUST request as many SIDs matching the number 439 of encryption modules in which it will be installing the TEKs in the 440 outbound direction. Alternatively, a group member MAY request more 441 than one SID and use them serially. This could be useful when it is 442 anticipated that the group member will exhaust their range of Data- 443 Security SA nonces using a single SID too quickly (e.g., before the 444 time-based policy in the TEK expires). 446 When group policy includes a counter-based mode of operation, a GCKS 447 SHOULD use the following method to allocate SID values, which ensures 448 that each SID will be allocated to just one group member. 450 1. A GCKS maintains an SID-counter, which records the SIDs that have 451 been allocated. SIDs are allocated sequentially, with the first SID 452 allocated to be zero. 454 2. Each time an SID is allocated, the current value of the counter 455 is saved and allocated to the group member. The SID-counter is then 456 incremented in preparation for the next allocation. 458 3. When the GCKS specifies a counter-based mode of operation in the 459 Data Security SA, and a group member is a sender, a group member may 460 request a count of SIDs during registration in a NOTIFY payload 461 information type SEND_ID_REQUEST. When the GCKS receives this 462 request, it increments the SID- counter once for each requested SID, 463 and distributes each SID value to the group member. 465 4. A GCKS allocates new SID values for each GSA_REGISTRATION 466 exchange originated by a sender, regardless of whether a group member 467 had previously contacted the GCKS. In this way, the GCKS does not 468 have a requirement of maintaining a record of which SID values it had 469 previously allocated to each group member. More importantly, since 470 the GCKS cannot reliably detect whether the group member had sent 471 data on the current group Data-Security SAs it does not know what 472 Data-Security counter-mode nonce values that a group member has used. 473 By distributing new SID values, the key server ensures that each time 474 a conforming group member installs a Data- Security SA it will use a 475 unique set of counter-based mode nonces. 477 5. When the SID-counter maintained by the GCKS reaches its final SID 478 value, no more SID values can be distributed. Before distributing 479 any new SID values, the GCKS MUST delete the Data- Security SAs for 480 the group, followed by creation of new Data- Security SAs, and 481 resetting the SID-counter to its initial value. 483 6. The GCKS SHOULD send a GSA_REKEY message deleting all Data- 484 Security SAs and the Rekey SA for the group. This will result in the 485 group members initiating a new GSA_REGISTRATION exchange, in which 486 they will receive both new SID values and new Data-Security SAs. The 487 new SID values can safely be used because they are only used with the 488 new Data-Security SAs. Note that deletion of the Rekey SA is 489 necessary to ensure that group members receiving a GSA_REKEY exchange 490 before the re-register do not inadvertently use their old SIDs with 491 the new Data-Security SAs. Using the method above, at no time can 492 two group members use the same IV values with the same Data-Security 493 SA key. 495 3.3. G-IKEv2 group maintenance channel 497 The GCKS indicates that it will be delivering group rekey messages 498 when the KEK poilcy and keys are present in the G-IKEv2 GSA and KD 499 payloads. Though the G-IKEv2 Rekey is optional, it plays a crucial 500 role for large and dynamic groups. The GCKS is responsible for 501 rekeying of the secure group per the group policy. The GCKS uses 502 multicast to transport the rekey message. The G-IKEv2 protocol uses 503 GSA_REKEY exchange type in G-IKEv2 header identifying it as a rekey 504 message. This rekey message is protected by the registration 505 exchanges. 507 3.3.1. G-IKEv2 GSA_REKEY exchange 508 The GCKS initiates the G-IKEv2 Rekey securely using IP multicast. 509 Since multicast rekey does not require a response and it sends to 510 multiple GMs, G-IKEv2 rekeying MUST NOT support windowing. The GCKS 511 rekey message replaces the rekey GSA KEK or KEK array, and/or creates 512 a new Data-Security GSA TEK. The SID Download attribute [section 513 4.7.4] in the Key Download payload MUST NOT be part of the Rekey 514 Exchange as this is sender specific information and the Rekey 515 Exchange is group specific. The GCKS initiates the GSA_REKEY 516 exchange as following: 518 Members (Responder) GCKS (Initiator) 519 -------------------- ------------------ 520 <-- HDR, SK {GSA, KD, [D,] AUTH } 522 HDR is defined in Section 4.1. The message id in this message will 523 start with the same value the GCKS sent to group member in the KEK 524 attribute KEK_MESSAGE_ID during registration; this message id will be 525 increasing each time a new GSA_REKEY message is sent to the group 526 members. 528 The GSA payload contains the current rekey and data security SAs. 529 The GSA may contain a new data security SA and/or a new rekey SA, 530 which, optionally contains an LKH rekey SA, Section 4.3. 532 The KD represents the keys for the policy included in the GSA. If 533 the data security SA is being refreshed in this rekey message, the 534 IPSec keys are updated in the KD, and/or if the rekey SA is being 535 refreshed in this rekey message, the rekey Key or the LKH KEK array 536 is updated in the KD payload. 538 The Delete payload is included to instruct the GM to delete existing 539 SAs. 541 The AUTH payload is a signature of the hash of the entire GSA_REKEY 542 message before it has been encrypted. 544 After adding the Signature of the above Hash to the rekey message, 545 the current KEK encryption key encrypts all the payloads following 546 the HDR. 548 3.3.2. Forward and Backward Access Control 550 Through G-IKEv2 rekey, the G-IKEv2 supports algorithms such as LKH 551 that have the property of denying access to a new group key by a 552 member removed from the group (forward access control) and to an old 553 group key by a member added to the group (backward access control). 554 An unrelated notion to PFS, "forward access control" and "backward 555 access control" have been called "perfect forward security" and 556 "perfect backward security" in the literature [RFC2627]. 558 Group management algorithms providing forward and backward access 559 control other than LKH have been proposed in the literature, 560 including OFT [OFT] and Subset Difference [NNL]. These algorithms 561 could be used with G-IKEv2, but are not specified as a part of this 562 document. 564 Support for group management algorithms is supported via the 565 KEY_MANAGEMENT_ALGORITHM attribute which is sent in the GSA KEK 566 policy. G-IKEv2 specifies one method by which LKH can be used for 567 forward and backward access control. Other methods of using LKH, as 568 well as other group management algorithms such as OFT or Subset 569 Difference may be added to G-IKEv2 as part of a later document. Any 570 such addition MUST be due to a Standards Action as defined in 571 [RFC2434]. 573 3.3.3. Forward Access Control Requirements 575 When group membership is altered using a group management algorithm 576 new GSA TEKs (and their associated keys) are usually also needed. 577 New GSAs and keys ensure that members who were denied access can no 578 longer participate in the group. 580 If forward access control is a desired property of the group, new GSA 581 TEKs and the associated key packets in the KD payload MUST NOT be 582 included in a G-IKEv2 rekey message which changes group membership. 583 This is required because the GSA TEK policy and the associated key 584 packets in the KD payload are not protected with the new KEK. A 585 second G-IKEv2 rekey message can deliver the new GSA TEKS and their 586 associated keys because it will be protected with the new KEK, and 587 thus will not be visible to the members who were denied access. 589 If forward access control policy for the group includes keeping group 590 policy changes from members that are denied access to the group, then 591 two sequential G-IKEv2 rekey messages changing the group KEK MUST be 592 sent by the GCKS. The first G-IKEv2 rekey message creates a new KEK 593 for the group. Group members, which are denied access, will not be 594 able to access the new KEK, but will see the group policy since the 595 G-IKEv2 rekey message is protected under the current KEK. A 596 subsequent G-IKEv2 rekey message containing the changed group policy 597 and again changing the KEK allows complete forward access control. A 598 G-IKEv2 rekey message MUST NOT change the policy without creating a 599 new KEK. 601 If other methods of using LKH or other group management algorithms 602 are added to G-IKEv2, those methods MAY remove the above restrictions 603 requiring multiple G-IKEv2 rekey messages, providing those methods 604 specify how forward access control policy is maintained within a 605 single G-IKEv2 rekey message. 607 3.3.4. Deletion of SAs 609 There are occasions the GCKS may want to signal to receivers to 610 delete policy at the end of a broadcast, or if group policy has 611 changed. Deletion of keys MAY be accomplished by sending the G-IKEv2 612 Delete Payload [RFC5996], section 3.11 as part of the G-IKEv2 613 GSA_AUTH or GSA_REKEY Exchange. 615 When a policy delete is required the GCKS sends a rekey of the 616 following format: 618 Members (Responder) GCKS (Initiator) 619 -------------------- ------------------ 620 <-- HDR, SK { 621 [ GSA], [ KD], [D,] AUTH } 623 The GSA MAY specify the remaining active time of the remaining policy 624 by using the DTD attribute in the GSA GAP. If a GCKS has no further 625 SAs to send to group members, the SA and KD payloads MUST be omitted 626 from the message. There may be circumstances where the GCKS may want 627 to start over with a clean slate. If the administrator is no longer 628 confident in the integrity of the group, the GCKS can signal deletion 629 of all policy of a particular TEK protocol by sending a TEK with a 630 SPI value equal to zero in the delete payload. For example, if the 631 GCKS wihses to remove all the KEKs and all the TEKs in the group, the 632 GCKS SHOULD send a delete payload with a spi of zero and a 633 protocol_id of a TEK protocol_id value define in Section 4.5, 634 followed by another delete payload with a spi of zero and protocol_id 635 of zero, indicating that the KEK SA should be deleted. 637 3.3.5. GSA_REKEY GCKS Operations 639 The GCKS may initiate a rekey message if group membership and/or 640 policy has changed, or if the keys are about to expire. The GCKS 641 builds the rekey message with value of the message id that is one 642 greater than the previous rekey. If the message is using a new KEK 643 attribute, the message id is reset to 1 in this message. The GSA and 644 KD follow with the same characteristics as in the GSA Registration 645 exchange. The AUTH payload is created by hashing the string 646 "G-IKEv2" and the message created so far, and then digitally signed. 647 Finally, the payloads following the HDR are encrypted using the 648 current KEK encryption key. 650 3.3.6. GSA_REKEY GM Operations 652 The group member receives the Rekey Message from the GCKS, decrypts 653 the message using the current KEK, validates the signature using the 654 public key retrieved in a previous G-IKEv2 exchange, verifies the 655 message id, and processes the GSA and KD payloads. The group member 656 then downloads the new data security SA and/or new Rekey GSA. The 657 parsing of the payloads is identical to the registration exchange. 659 Anti-replay protection is achieved when the group member rejects 660 GSA_REKEY message which has message id smaller than the current 661 message id that the GM is expecting. The GM expects the message id 662 in the first GSA_REKEY message it receives to be equal or greater 663 than the message id it receives in the KEK_MESSAGE_ID attribute. The 664 GM expects the message id in the subsequence GSA_REKEY message to be 665 greater than the last valid GSA_REKEY message it received. 667 If the SA payload includes Data-Security SA including a counter-modes 668 of operation and the receiving group member is a sender for that SA, 669 the group member uses its current SID value with the Data-Security 670 SAs to create counter-mode nonces. If it is a sender and does not 671 hold a current SID value, it MUST NOT install the Data-Security SAs. 672 It MAY initiate a GSA_REGISTRATION exchange to the GCKS in order to 673 obtain an SID value (along with current group policy). 675 4. Header and Payload Formats 677 Refer to IKEv2 [RFC5996] for existing payloads. 679 4.1. The G-IKEv2 Header 681 G-IKEv2 uses the same IKE header format as specified in RFC 5996 682 section 3.1. 684 Several new payload formats are required in the group security 685 exchanges. 687 Next Payload Type Value 688 ----------------- ----- 689 Group Identification (IDg) TBD 690 Group Security Association (GSA) TBD 691 Key Download (KD) TBD 693 New exchange types GSA_AUTH, GSA_REGISTRATION and GSA_REKEY are added 694 to the IKEv2 [RFC5996] protocol. 696 Exchange Type Value 697 -------------- ----- 698 GSA_AUTH TBD 699 GSA_REGISTRATION TBD 700 GSA_REKEY TBD 702 Major Version is 2 and Minor Version is 0 as in IKEv2 [RFC5996]. IKE 703 SA initiator SPI, IKE SA responder SPI, Flags, Message Id are as 704 specified in [RFC5996]. 706 4.2. IDgroup Payload 708 The IDg Payload allows the group member to indicate which group it 709 wants to join. The payload is constructed by using the IKEv2 710 [RFC5996] Identification Payload. ID type ID_KEY_ID MUST be 711 supported. ID types ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, 712 ID_IPV6_ADDR SHOULD be supported. ID types ID_DER_ASN1_DN and 713 ID_DER_ASN1_GN are not expected to be used. 715 4.3. Group Security Association Payload 717 The Group Security Association payload is used by the GCKS to assert 718 security attributes for both Re-key and Data-security SAs. 720 0 1 2 3 721 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 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 723 ! Next Payload ! RESERVED ! Payload Length ! 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 The Security Association Payload fields are defined as follows: 728 o Next Payload (1 octet) -- Identifies the next payload type for the 729 G-IKEv2 registration or the G-IKEv2 rekey message. 731 o RESERVED (1 octet) -- Must be zero. 733 o Payload Length (2 octets) -- Is the octet length of the current 734 payload including the generic header and all TEK and KEK policies. 736 4.3.1. GSA policy 737 Following GSA generic payload header are GSA policies for group 738 rekeying (KEK) and/or data traffic SAs (TEK). There may be zero or 739 one GSA KEK policy, zero or more GAP policy, and zero or more GSA TEK 740 policies, where either one GSA KEK or GSA TEK payload MUST be 741 present. 743 This latitude allows various group policies to be accommodated. For 744 example if the group policy does not require the use of a Re-key SA, 745 the GCKS would not need to send an GSA KEK attribute to the group 746 member since all SA updates would be performed using the Registration 747 SA. Alternatively, group policy might use a Re-key SA but choose to 748 download a KEK to the group member only as part of the Registration 749 SA. Therefore, the GSA KEK policy would not be necessary as part of 750 the GSA_REKEY message. 752 Specifying multiple GSA TEKs allows multiple sessions to be part of 753 the same group and multiple streams to be associated with a session 754 (e.g., video, audio, and text) but each with individual security 755 association policy. 757 A GAP payload allows for the distribution of group-wise policy, such 758 as instructions as to when to activate and de-activate SAs. 760 Policies following the GSA payload has common header 762 0 1 2 3 763 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 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 ! Type ! RESERVED ! Length ! 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 769 Type is defined as follow: 771 0 - RESERVED 772 1 - KEK 773 2 - GAP 774 3 - TEK 775 4-240 - RESERVED 776 241-255 - private and experimental 778 4.4. KEK Policy 780 The GSA KEK (GSAK) policy contains security attributes for the KEK 781 method for a group and parameters specific to the G-IKEv2 782 registration operation. The source and destination identities 783 describe the identities used for the G-IKEv2 registration datagram. 785 0 1 2 3 786 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 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 788 ! Type ! RESERVED ! Length ! 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 790 ! ! 791 ~ SPI ~ 792 ! ! 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 794 ! ! 795 ~ ~ 796 ! ! 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 798 ! ! 799 ~ ~ 800 ! ! 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 802 ~ KEK Attributes ~ 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 805 The GSAK Payload fields are defined as follows: 807 o Type (1 octet) -- Identifies the GSA payload type KEK present in 808 the G-IKEv2 registration or the G-IKEv2 rekey message. 810 o RESERVED (1 octet) -- Must be zero. 812 o Length (2 octets) -- Length of this structure including KEK 813 attributes. 815 o SPI (16 octets) -- Security Parameter Index for the KEK. The SPI 816 must be the IKEv2 Header SPI pair where the first 8 octets become 817 the "Initiator's SPI" field of the G-IKEv2 rekey message IKEv2 818 HDR, and the second 8 octets become the "Responder's SPI" in the 819 same HDR. As described above, these SPIs are assigned by the 820 GCKS. 822 o Source & Destination Traffic Selectors - Substructures describing 823 the source and destination of the identities. These identities 824 refer to the source and destination of the next KEK rekey SA. 826 Defined format and values are specified by IKEv2 [RFC5996], 827 section 3.13.1. 829 o KEK Attributes -- Contains KEK policy attributes associated with 830 the group. The following sections describe the possible 831 attributes. Any or all attributes may be optional, depending on 832 the group policy. 834 4.4.1. KEK Attributes 836 The following attributes may be present in a GSA KEK policy. The 837 attributes must follow the format defined in IKEv2 [RFC5996] section 838 3.3.5. In the table, attributes that are defined as TV are marked as 839 Basic (B); attributes that are defined as TLV are marked as Variable 840 (V). 842 ID Class Value Type 843 -------- ----- ---- 844 RESERVED 0 845 KEK_MANAGEMENT_ALGORITHM 1 B 846 KEK_ENCR_ALGORITHM 2 B 847 KEK_KEY_LENGTH 3 B 848 KEK_KEY_LIFETIME 4 V 849 KEK_INTEGRITY_ALGORITHM 5 B 850 KEK_AUTH_METHOD 6 B 851 KEK_AUTH_ALGORITHM 7 B 852 KEK_MESSAGE_ID 8 B 854 The following attributes may only be included in a G-IKEv2 855 registration message: KEK_MANAGEMENT_ALGORITHM. 857 Minimum attributes that must be sent as part of an GSA KEK: 858 KEK_ENCR_ALGORITHM, KEK_KEY_LENGTH (if the cipher definition includes 859 a variable length key), KEK_MESSAGE_ID, KEK_KEY_LIFETIME, 860 KEK_INTEGRITY_ALGORITHM, KEK_AUTH_METHOD and KEK_AUTH_ALGORITHM 861 (except for DSA based algorithms). 863 4.4.2. KEK_MANAGEMENT_ALGORITHM 865 The KEK_MANAGEMENT_ALGORITHM class specifies the group KEK management 866 algorithm used to provide forward or backward access control (i.e., 867 used to exclude group members). Defined values are specified in the 868 following table. 870 KEK Management Type Value 871 ------------------- ----- 872 RESERVED 0 873 LKH 1 874 Standards Action 2-127 875 Private Use 128-255 877 4.4.3. KEK_ENCR_ALGORITHM 879 The KEK_ENCR_ALGORITHM class specifies the encryption algorithm using 880 with the KEK. This is the same as IKEv2 encryption algorithm defined 881 in [RFC5996] section 3.3.2. If a KEK_MANAGEMENT_ALGORITHM is defined 882 which defines multiple keys (e.g., LKH), and if the management 883 algorithm does not specify the algorithm for those keys, then the 884 algorithm defined by the KEK_ENCR_ALGORITHM attribute MUST be used 885 for all keys which are included as part of the management. 887 4.4.4. KEK_KEY_LENGTH 889 The KEK_KEY_LENGTH class specifies the KEK Algorithm key length (in 890 bits). 892 The Group Controller/Key Server (GCKS) adds the KEK_KEY_LENGTH 893 attribute to the GSA payload when distributing KEK policy to group 894 members. The group member verifies whether or not it has the 895 capability of using a cipher key of that size. If the cipher 896 definition includes a fixed key length, the group member can make its 897 decision solely using KEK_ENCR_ALGORITHM attribute and does not need 898 the KEK_KEY_LENGTH attribute. Sending the KEK_KEY_LENGTH attribute 899 in the GSA payload is OPTIONAL if the KEK cipher has a fixed key 900 length. 902 4.4.5. KEK_KEY_LIFETIME 904 The KEK_KEY_LIFETIME class specifies the maximum time for which the 905 KEK is valid. The GCKS may refresh the KEK at any time before the 906 end of the valid period. The value is a four (4) octet number 907 defining a valid time period in seconds. 909 4.4.6. KEK_INTEGRITY_ALGORITHM 911 KEK_INTEGRITY specifies the integrity algorithm. This integrity 912 algorithm is specified in IKEv2 RFC 5996 section 3.3.2. 914 4.4.7. KEK_AUTH_METHOD 916 KEK_AUTH_METHOD specifies the method of authentication used. This is 917 the same as IKEv2 Auth Method specified in IKEv2 RFC 5996 section 3.8 919 4.4.8. KEK_AUTH_ALGORITHM 921 KEK_AUTH_ALGORITHM specifies the hash algorithm uses to sign the AUTH 922 payload as defined in IKEv2 [RFC5996] section 3.8 for RSA Digital 923 Signature. The following tables define the algorithms for 924 KEK_AUTHALGORITHM. 926 Algorithm Type Value 927 -------------- ----- 928 RESERVED 0 929 AUTH_HASH_SHA256 1 930 AUTH_HASH_SHA384 2 931 AUTH_HASH_SHA512 3 932 Standards Action 4-127 933 Private Use 128-255 935 4.4.9. KEK_MESSAGE_ID 937 KEK_MESSAGE_ID define the start message id to be used by the GCKS in 938 the GSA_REKEY message. Message ID is 4 octets unsigned integer. 940 4.5. GSA TEK Policy 942 The GSA TEK (GSAT) policy contains security attributes for a single 943 TEK associated with a group. 945 0 1 2 3 946 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 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 948 ! Type ! RESERVED ! Length ! 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 950 ! Protocol-ID ! TEK Protocol-Specific Payload ! 951 +-+-+-+-+-+-+-+-+ ~ 952 ~ ! 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 955 The GSAT Payload fields are defined as follows: 957 o Type (1 octet) -- Identifies the GSA payload type TEK present in 958 the G-IKEv2 registration or the G-IKEv2 rekey message. 960 o RESERVED (1 octet) -- Must be zero. 962 o Length (2 octets) -- Length of this structure, including the TEK 963 Protocol-Specific Payload. 965 o Protocol-ID (1 octet) -- Value specifying the Security Protocol. 966 The following table defines values for the Security Protocol 968 Protocol ID Value 969 ----------- ----- 970 RESERVED 0 971 GSA_PROTO_IPSEC_ESP 1 972 GSA_PROTO_IPSEC_AH 2 973 Standards Action 3-127 974 Private Use 128-255 976 Support for the GSA_PROTO_IPSEC_AH GSA TEK is OPTIONAL. 978 o TEK Protocol-Specific Payload (variable) -- Payload which 979 describes the attributes specific for the Protocol-ID. 981 4.5.1. TEK ESP and AH Protocol-Specific Policy 983 The TEK Protocol-Specific policy contains of two traffic selectors 984 for source and destination of the protecting traffic, SPI, Transform, 985 and Attributes. 987 The TEK Protocol-Specific policy for ESP is as follows: 989 0 1 2 3 990 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 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 ! SPI ! 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 994 | | 995 ~ ~ 996 | | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | | 999 ~ | 1000 | | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1002 | | 1003 ~ ~ 1004 | | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1006 ! TEK Attributes ~ 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1009 The GSAT Policy fields are defined as follows: 1011 o SPI (4 octets) -- Security Parameter Index. 1013 o Source & Destination Traffic Selectors - The traffic selectors 1014 describe the source and the destination of the protecting traffic. 1015 The format and values are defined in IKEv2 [RFC5996], section 1016 3.13.1. 1018 o Transform -- A substructure specifies the transform information. 1019 The format and values are defined in IKEv2 [RFC5996], section 1020 3.3.2. 1022 o TEK Attributes -- Contains TEK policy attributes associated with 1023 the group. The following sections describe the possible 1024 attributes. Any or all attributes may be optional, depending on 1025 the group policy. [RFC5996], section 3.3.5. 1027 Attribute Types 1029 class value type 1030 ------------------------------------------------- 1031 Life Duration 1 V 1033 Specifies the time-to-live for the overall security 1034 association. When the TEK expires, all keys downloaded under 1035 the association (AH or ESP) must be re-rekeyed. The life 1036 duration attribute defines the actual length of the 1037 component lifetime in secondsthat can be protected. 1039 If unspecified, the default value shall be assumed to be 1040 28800 seconds (8 hours). 1042 Transport mode 2 B 1043 Specifies to use transport mode rather than tunnel mode 1045 4.6. GSA Group Associated Policy 1047 Group specific policy that does not belong to rekey policy (GSA KEK) 1048 or traffic encryption policy (GSA TEK) can be distributed to all 1049 group member using GSA GAP (Group Associated Policy). 1051 The GSA GAP payload is defined as follows: 1053 0 1 2 3 1054 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 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1056 ! Type ! RESERVED ! Length ! 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1058 ! Group Associated Policy Attributes ~ 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1061 The GSA GAP payload fields are defined as follows: 1063 o Type (1 octet) -- Identifies the GSA payload type GAP present in 1064 the G-IKEv2 registration or the G-IKEv2 rekey message. 1066 o RESERVED (1 octet) -- Must be zero. 1068 o Length (2 octets) -- Length of this structure, including the GSA 1069 GAP header and Attributes. 1071 o Group Associated Policy Attributes (variable) -- Contains 1072 attributes following the format defined in Section 3.3.5 of 1073 [RFC5996]. 1075 Several group associated policy attributes are defined below. A 1076 G-IKEv2 implementation MUST abort if it encounters an attribute or 1077 capability that it does not understand. 1079 4.6.1. ACTIVATION_TIME_DELAY/DEACTIVATION_TIME_DELAY 1081 Section 4.2.1 of RFC 5374 specifies a key rollover method that 1082 requires two values be given it from the group key management 1083 protocol. The ACTIVATION_TIME_DELAY attribute allows a GCKS to set 1084 the Activation Time Delay (ATD) for SAs generated from TEKs. The ATD 1085 defines how long after receiving new SAs that they are to be 1086 activated by the GM. The ATD value is in seconds. 1088 The DEACTIVATION_TIME_DELAY allows the GCKS to set the Deactivation 1089 Time Delay (DTD) for previously distributed SAs. The DTD defines how 1090 long after receiving new SAs that it should deactivate SAs that are 1091 destroyed by the re-key event. The value is in seconds. 1093 The values of ATD and DTD are independent. However, the DTD value 1094 should be larger, which allows new SAs to be activated before older 1095 SAs are deactivated. Such a policy ensures that protected group 1096 traffic will always flow without interruption. 1098 4.7. Key Download Payload 1100 The Key Download Payload contains group keys for the group specified 1101 in the GSA Payload. These key download payloads can have several 1102 security attributes applied to them based upon the security policy of 1103 the group as defined by the associated GSA Payload. 1105 0 1 2 3 1106 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 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1108 ! Next Payload ! RESERVED ! Length ! 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1110 ! Number of Key Packets ! RESERVED2 ! 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1112 ~ Key Packets ~ 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1115 The Key Download Payload fields are defined as follows: 1117 o Next Payload (1 octet) -- Identifier for the payload type of the 1118 next payload in the message. If the current payload is the last 1119 in the message, then this field will be zero. 1121 o RESERVED (1 octet) -- Unused, set to zero. 1123 o Payload Length (2 octets) -- Length in octets of the current 1124 payload, including the generic payload header. 1126 o Number of Key Packets (2 octets) -- Contains the total number of 1127 both TEK and Rekey arrays being passed in this data block. 1129 o Key Packets Several types of key packets are defined. Each Key 1130 Packet has the following format. 1132 0 1 2 3 1133 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 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1135 ! KD Type ! RESERVED ! KD Length ! 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1137 ! SPI Size ! SPI (variable) ~ 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1139 ~ Key Packet Attributes ~ 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1142 o Key Download (KD) Type (1 octet) -- Identifier for the Key Data 1143 field of this Key Packet. 1145 Key Download Type Value 1146 ----------------- ----- 1147 RESERVED 0 1148 TEK 1 1149 KEK 2 1150 LKH 3 1151 SID TBD-7 1152 Standards Action 4-127 1153 Private Use 128-255 1155 "KEK" is a single key whereas LKH is an array of key-encrypting keys. 1157 o RESERVED (1 octet) -- Unused, set to zero. 1159 o Key Download Length (2 octets) -- Length in octets of the Key 1160 Packet data, including the Key Packet header. 1162 o SPI Size (1 octet) -- Value specifying the length in octets of the 1163 SPI as defined by the Protocol-Id. 1165 o SPI (variable length) -- Security Parameter Index which matches a 1166 SPI previously sent in an GSAK or GSAT Payload. 1168 o Key Packet Attributes (variable length) -- Contains Key 1169 information. The format of this field is specific to the value of 1170 the KD Type field. The following sections describe the format of 1171 each KD Type. 1173 4.7.1. TEK Download Type 1175 The following attributes may be present in a TEK Download Type. 1176 Exactly one attribute matching each type sent in the GSAT payload 1177 MUST be present. The attributes must follow the format defined in 1178 IKEv2 (Section 3.3.5 of [RFC5996]). In the table, attributes defined 1179 as TV are marked as Basic (B); attributes defined as TLV are marked 1180 as Variable (V). 1182 TEK Class Value Type 1183 --------- ----- ---- 1184 RESERVED 0 1185 TEK_ALGORITHM_KEY 1 V 1186 TEK_INTEGRITY_KEY 2 V 1187 TEK_SOURCE_AUTH_KEY 3 V 1189 If no TEK key packets are included in a Registration KD payload, the 1190 group member can expect to receive the TEK as part of a Re-key SA. 1192 At least one TEK must be included in each Re-key KD payload. 1193 Multiple TEKs may be included if multiple streams associated with the 1194 SA are to be rekeyed. 1196 4.7.1.1. TEK_ALGORITHM_KEY 1198 The TEK_ALGORITHM_KEY class declares that the encryption key for this 1199 SPI is contained as the Key Packet Attribute. The encryption 1200 algorithm that will use this key was specified in the GSAT payload. 1202 In the case that the algorithm requires multiple keys, all keys will 1203 be included in one attribute. 1205 4.7.1.2. TEK_INTEGRITY_KEY 1207 The TEK_INTEGRITY_KEY class declares that the integrity key for this 1208 SPI is contained as the Key Packet Attribute. The integrity 1209 algorithm that will use this key was specified in the GSAT payload. 1210 Thus, G-IKEv2 assumes that both the symmetric encryption and 1211 integrity keys are pushed to the member. SHA256 keys will consist of 1212 256 bits. 1214 4.7.1.3. TEK_SOURCE_AUTH_KEY 1216 The TEK_SOURCE_AUTH_KEY class declares that the source authentication 1217 key for this SPI is contained in the Key Packet Attribute. The 1218 source authentication algorithm that will use this key was specified 1219 in the GSAT payload. 1221 4.7.2. KEK Download Type 1223 The following attributes may be present in a KEK Download Type. 1224 Exactly one attribute matching each type sent in the GSAK payload 1225 MUST be present. The attributes must follow the format defined in 1226 IKEv2 (Section 3.3.5 of [RFC5996]). In the table, attributes defined 1227 as TV are marked as Basic (B); attributes defined as TLV are marked 1228 as Variable (V). 1230 KEK Class Value Type 1231 --------- ----- ---- 1232 RESERVED 0 1233 KEK_ALGORITHM_KEY 1 V 1234 KEK_AUTH_KEY 2 V 1236 If the KEK key packet is included, there MUST be only one present in 1237 the KD payload. 1239 4.7.2.1. KEK_ALGORITHM_KEY 1241 The KEK_ALGORITHM_KEY class declares key for this SPI is contained in 1242 the Key Packet Attribute. The encryption and integrity algorithm 1243 that will use this key were specified in the GSAK payload. Then 1244 encryption and integrity keys can be derived using the following 1245 formula 1247 { SK_ai | SK_ar | SK_ei | SK_er } = prf+(KEK key, "G-IKEv2 REKEY" | 1248 SPIi | SPIr) 1250 If the mode of operation for the algorithm requires an Initialization 1251 Vector (IV), an explicit IV MUST be included in the KEK_ALGORITHM_KEY 1252 before the actual key. 1254 4.7.2.2. KEK_AUTH_KEY 1256 The KEK_AUTH_KEY class declares that the public key for this SPI is 1257 contained in the Key Packet Attribute, which may be useful when no 1258 public key infrastructure is available. The signature algorithm that 1259 will use this key was specified in the GSAK payload. 1261 4.7.3. LKH Download Type 1263 The LKH key packet is comprised of attributes representing different 1264 leaves in the LKH key tree. 1266 The following attributes are used to pass an LKH KEK array in the KD 1267 payload. The attributes must follow the format defined in IKEv2 1268 (Section 3.3.5 of [RFC5996]). In the table, attributes defined as TV 1269 are marked as Basic (B); attributes defined as TLV are marked as 1270 Variable (V). 1272 KEK Class Value Type 1273 --------- ----- ---- 1274 RESERVED 0 1275 LKH_DOWNLOAD_ARRAY 1 V 1276 LKH_UPDATE_ARRAY 2 V 1277 AUTH_ALGORITHM_KEY 3 V 1278 Standards Action 4-127 1279 Private Use 128-255 1281 If an LKH key packet is included in the KD payload, there must be 1282 only one present. 1284 4.7.3.1. LKH_DOWNLOAD_ARRAY 1285 This attribute is used to download a set of keys to a group member. 1286 It MUST NOT be included in a IKEv2 rekey message KD payload if the 1287 IKEv2 rekey is sent to more than the group member. If an 1288 LKH_DOWNLOAD_ARRAY attribute is included in a KD payload, there must 1289 be only one present. 1291 This attribute consists of a header block, followed by one or more 1292 LKH keys. 1294 0 1 2 3 1295 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 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 ! LKH Version ! # of LKH Keys ! RESERVED ! 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 ! LKH Keys ! 1300 ~ ~ 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 The KEK_LKH attribute fields are defined as follows: 1305 o LKH version (1 octet) -- Contains the version of the LKH protocol 1306 which the data is formatted in. Must be one. 1308 o Number of LKH Keys (2 octets) -- This value is the number of 1309 distinct LKH keys in this sequence. 1311 o RESERVED (1 octet) -- Unused, set to zero. 1313 Each LKH Key is defined as follows: 1315 0 1 2 3 1316 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 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 ! LKH ID ! Key Type ! RESERVED ! 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 ~ Key Creation Date ! 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 ~ Key expiration Date ! 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 ~ Key Handle ! 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 ! ! 1327 ~ Key Data ~ 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 o LKH ID (2 octets) -- This is the position of this key in the 1330 binary tree structure used by LKH. 1332 o Key Type (1 octet) -- This is the encryption algorithm for which 1333 this key data is to be used. This value is specified in 1334 Section 4.4.3. 1336 o RESERVED (1 octet) -- Unused, set to zero. 1338 o Key Creation Date (4 octets) -- This is the time value of when 1339 this key data was originally generated. A time value of zero 1340 indicates that there is no time before which this key is not 1341 valid. 1343 o Key Expiration Date (4 octets) -- This is the time value of when 1344 this key is no longer valid for use. A time value of zero 1345 indicates that this key does not have an expiration time. 1347 o Key Handle (4 octets) -- This is the randomly generated value to 1348 uniquely identify a key within an LKH ID. 1350 o Key Data (variable length) -- This is the actual encryption key 1351 data, which is dependent on the Key Type algorithm for its format. 1352 If the mode of operation for the algorithm requires an 1353 Initialization Vector (IV), an explicit IV MUST be included in the 1354 Key Data field before the actual key. 1356 The Key Creation Date and Key expiration Dates MAY be zero. This is 1357 necessary in the case where time synchronization within the group is 1358 not possible. 1360 The first LKH Key structure in an LKH_DOWNLOAD_ARRAY attribute 1361 contains the Leaf identifier and key for the group member. The rest 1362 of the LKH Key structures contain keys along the path of the key tree 1363 in order from the leaf, culminating in the group KEK. 1365 4.7.3.2. LKH_UPDATE_ARRAY 1367 This attribute is used to update the keys for a group. It is most 1368 likely to be included in a G-IKEv2 rekey message KD payload to rekey 1369 the entire group. This attribute consists of a header block, 1370 followed by one or more LKH keys, as defined in Section 4.7.3.1. 1372 There may be any number of UPDATE_ARRAY attributes included in a KD 1373 payload. 1375 0 1 2 3 1376 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 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 ! LKH Version ! # of LKH Keys ! RESERVED ! 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 ! LKH ID ! RESERVED2 ! 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 ! Key Handle ! 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 ! LKH Keys ! 1386 ~ ~ 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 o LKH version (1 octet) -- Contains the version of the LKH protocol 1390 which the data is formatted in. Must be one. 1392 o Number of LKH Keys (2 octets) -- This value is the number of 1393 distinct LKH keys in this sequence. 1395 o RESERVED (1 octet) -- Unused, set to zero. 1397 o LKH ID (2 octets) -- This is the node identifier associated with 1398 the key used to encrypt the first LKH Key. 1400 o RESERVED2 (2 octets) -- Unused, set to zero. 1402 o Key Handle (4 octets) -- This is the value to uniquely identify 1403 the key within the LKH ID which was used to encrypt the first LKH 1404 key. 1406 The LKH Keys are as defined in Section 4.7.3.1. The LKH Key 1407 structures contain keys along the path of the key tree in order from 1408 the LKH ID found in the LKH_UPDATE_ARRAY header, culminating in the 1409 group KEK. The Key Data field of each LKH Key is encrypted with the 1410 LKH key preceding it in the LKH_UPDATE_ARRAY attribute. The first 1411 LKH Key is encrypted under the key defined by the LKH ID and Key 1412 Handle found in the LKH_UPDATE_ARRAY header. 1414 4.7.4. SID Download Type 1416 This attribute is used to download one or use more Sender-ID (SID) 1417 values for the exclusive use of a group member. 1419 KEK Class Value Type 1420 --------- ----- ---- 1421 RESERVED 0 1422 NUMBER_OF_SID_BITS 1 V 1423 SID_VALUE 2 V 1424 Standards Action 3-128 1425 Private Use 129-255 1426 Unassigned 256-32767 1428 Because a SID value is intended for a single group member, the SID 1429 Download type MUST NOT be distributed in a GROUPKEY_PUSH message 1430 distributed to multiple group members. 1432 4.7.4.1. NUMBER_OF_SID_BITS 1434 The NUMBER_OF_SID_BITS class declares how many bits of the cipher 1435 nonce in which to represent an SID value. This value applied to each 1436 SID value is distributed in the SID Download. 1438 4.7.4.2. SID_VALUE 1440 The SID_VALUE class declares a single SID value for the exclusive use 1441 of the a group member. Multiple SID_VALUE attributes MAY be included 1442 in a SID Download. 1444 4.7.4.3. GM Semantics 1446 The SID_VALUE attribute value distributed to the group member MUST be 1447 used by that group member as the SID field portion of the IV for all 1448 Data-Security SAs including a counter-based mode of operation 1449 distributed by the GCKS as a part of this group. When the Sender- 1450 Specific IV (SSIV) field for any Data-Security SA is exhausted, the 1451 group member MUST no longer act as a sender on that SA using its 1452 active SID. The group member SHOULD re-register, at which time the 1453 GCKS will issue a new SID to the group member, along with either the 1454 same Data-Security SAs or replacement ones. The new SID replaces the 1455 existing SID used by this group member, and also resets the SSIV 1456 value to its starting value. A group member MAY re-register prior to 1457 the actual exhaustion of the SSIV field to avoid dropping data 1458 packets due to the exhaustion of available SSIV values combined with 1459 a particular SID value. 1461 A group member MUST NOT process an SID Download Type KD payload 1462 present in a GSA-REKEY message. 1464 4.7.4.4. GCKS Semantics 1466 If any KD payload includes keying material that is associated with a 1467 counter-mode of operation, an SID Download Type KD payload containing 1468 at least one SID_VALUE attribute MUST be included. The GCKS MUST NOT 1469 send the SID Download Type KD payload as part of a GSA-REKEY message, 1470 because distributing the same sender-specific policy to more than one 1471 group member will reduce the security of the group. 1473 4.8. Delete Payload 1475 There are occasions the GCKS may want to signal to receivers to 1476 delete policy at the end of a broadcast, or if policy has changed. 1477 Deletion of keys MAY be accomplished by sending an IKEv2 Delete 1478 Payload, section 3.11 of [RFC5996] as part of the GSA_AUTH or 1479 GSA_REKEY Exchange. One or more Delete payloads MAY be placed 1480 following the HDR payload in the GSA_AUTH or GSA_REKEY Exchange. 1482 The Protocol ID MUST be 1 for KEK SA, 2 for TEK AH or 3 for TEK ESP. 1483 Note that only one protocol id value can be defined in a Delete 1484 payload. If a TEK and a KEK SA must be deleted, they must be sent in 1485 different Delete payloads. Similarly, if a TEK specifying ESP and a 1486 TEK specifying AH need to be deleted, they must be sent in different 1487 Delete payloads. 1489 4.9. Notify Payload 1491 G-IKEv2 uses the same notify payload as specified in [RFC5996], 1492 section 3.10. 1494 There are additional notify message types introduced by G-IKEv2 to 1495 communicate error conditions and status. 1497 NOTIFY MESSAGES - ERROR TYPES Value 1498 ------------------------------------------------------------------- 1499 INVALID_GROUP_ID - TBD 1500 Indicates the group id sent during registration process is invalid. 1502 AUTHORIZATION_FAILED - TBD 1503 Sent in the response to GSA_AUTH message when authorization failed. 1505 NOTIFY MESSAGES - STATUS TYPES Value 1506 ------------------------------------------------------------------- 1507 SENDER_REQUEST_ID - TBD 1508 Sent in GSA_AUTH or GSA_REGISTRATION to request SIDs from GCKS. The data includes a count of how many SID values it desires. 1510 4.10. Authentication Payload 1512 G-IKEv2 uses the same Authentication payload as specified in 1513 [RFC5996], section 3.8, to sign the rekey message. 1515 5. Security Considerations 1517 5.1. GSA registration and secure channel 1518 G-IKEv2 registration exchange uses IKEv2 IKE_SA_INIT, GSA_AUTH and 1519 GSA_REGISTRATION inheriting all the security considerations 1520 documented in [RFC5996] section 5 Security Considerations, including 1521 authentication, confidentiality, protection against man-in-the 1522 middle, protection against replay/reflection attacks, and denial of 1523 service protection. In addition, G-IKEv2 brings in the capability to 1524 authorize a particular group member regardless of whether they have 1525 the IKEv2 credentials. 1527 5.2. GSA maintenance channel 1529 The GSA maintenance channel is cryptographically and integrity 1530 protected using the cryptographic algorithm and key negotiated in the 1531 GSA member registration exchanged. 1533 5.2.1. Authentication/Authorization 1535 Authentication is implicit, the public key of the identity is 1536 distributed during the registration, and the receiver of the rekey 1537 message uses that public key and identity to verify the message is 1538 come from the authorized GCKS. 1540 5.2.2. Confidentiality 1542 Confidentiality is provided by distributing a confidentiality key as 1543 part of the GSA member registration exchange. 1545 5.2.3. Man-in-the-Middle Attack Protection 1547 GSA maintenance channel is integrity protected by using digital 1548 signature. 1550 5.2.4. Replay/Reflection Attack Protection 1552 The GSA rekey message includes a monotonically increasing sequence 1553 number to protect against replay and reflection attacks. A group 1554 member will recognize a replayed message by comparing the message id 1555 number to that of the last received rekey message, any rekey message 1556 contains message id number less than or equal to the last received 1557 value SHOULD be discarded. Implementations SHOULD keep a record of 1558 recently received GSA rekey messages for this comparison. 1560 6. IANA Considerations 1562 6.1. New registries 1564 A new set of registries are created for this draft. 1566 KEK Attributes Registry, see Section 4.4.1 1568 KEK Management Algorithm Registry, see Section 4.4.2 1570 GSA TEK Payload Protocol ID Type Registry, see Section 4.5 1572 TEK Attributes Registry, see Section 4.5 1574 Key Download Type Registry, see Section 4.7 1576 TEK Download Type Registry, see Section 4.7.1 1578 KEK Download Type Registry, see Section 4.7.2 1580 LKH Download Type Registry, see Section 4.7.3 1582 SID Download Type Registry, see Section 4.7.4 1584 6.2. New payload and exchange types to existing IKEv2 registry 1586 The present document describes new IKEv2 Next Payload types, see 1587 Section 4.1 1589 The present document describes new IKEv2 Exchanges types, see 1590 Section 4.1 1592 The present document describes new IKEv2 Notify Payload types, see 1593 Section 4.9 1595 6.3. Payload Types 1597 The present document defines new IKEv2 Next Payload types. See 1598 Section 4.0 for the payloads defined in this document, including the 1599 Next Payload values defined by the IANA to identify these payloads. 1601 6.4. New Name spaces 1603 The present document describes many new name spaces for use in the 1604 G-IKEv2 payloads. Those may be found in subsections under 1605 Section 4.0. A new G-IKEv2 registry has been created for these name 1606 spaces. 1608 Portions of name spaces marked "RESERVED" are reserved for IANA 1609 allocation. New values MUST be added due to a Standards Action as 1610 defined in [RFC2434]. 1612 Portions of name spaces marked "Private Use" may be allocated by 1613 implementations for their own purposes. 1615 7. Acknowledgements 1617 The authors thank Lakshminath Dondeti and Jing Xiang for originating 1618 the GKDP document and providing the basis behind the protocol. 1620 The authors also thank reviewers: Brian Weis, Kavitha Kamarthy, Lewis 1621 Chen, Cheryl Madson, and Raghunandan P. 1623 8. References 1625 8.1. Normative References 1627 [FIPS197] , "Advanced Encryption Standard (AES)", United States of 1628 America, National Institute of Science and Technology 1629 Federal Information Processing Standard (FIPS) 197, 1630 November 2001. 1632 [RFC6054] McGrew, D. and B. Weis, "Using Counter Modes with 1633 Encapsulating Security Payload (ESP) and Authentication 1634 Header (AH) to Protect Group Traffic", RFC 6054, November 1635 2010. 1637 [SP800-38A] 1638 Dworkin, M., "Recommendation for Block Cipher Modes of 1639 Operation", United States of America, National Institute 1640 of Science and Technology NIST Special Publication 800-38A 1641 2001 Edition, December 2001. 1643 [SP800-38D] 1644 Dworkin, M., "Recommendation for Block Cipher Modes of 1645 Operation", United States of America, National Institute 1646 of Science and Technology NIST Special Publication 800-38D 1647 2007 Edition, December 2001. 1649 8.2. Informative References 1651 [IKE-HASH] 1652 Kivinen, T., "Fixing IKE Phase 1 & 2 Authentication 1653 HASHs", November 2001, . 1656 [NNL] Naor, D., Noal, M., and J. Lotspiech, "Revocation and 1657 Tracing Schemes for Stateless Receivers", Advances in 1658 Cryptology, Crypto '01, Springer-Verlag LNCS 2139, 2001, 1659 pp. 41-62, 2001, 1660 . 1662 [OFT] McGrew, D. and A. Sherman, "Key Establishment in Large 1663 Dynamic Groups Using One-Way Function Trees", Manuscript, 1664 submitted to IEEE Transactions on Software Engineering, 1665 1998, . 1668 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1669 Requirement Levels", BCP 14, RFC 2119, March 1997. 1671 [RFC2407] Piper, D., "The Internet IP Security Domain of 1672 Interpretation for ISAKMP", RFC 2407, November 1998. 1674 [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet 1675 Security Association and Key Management Protocol 1676 (ISAKMP)", RFC 2408, November 1998. 1678 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1679 (IKE)", RFC 2409, November 1998. 1681 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1682 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1683 October 1998. 1685 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 1686 Multicast: Issues and Architectures", RFC 2627, June 1999. 1688 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 1689 Counter Mode With IPsec Encapsulating Security Payload 1690 (ESP)", RFC 3686, January 2004. 1692 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 1693 (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 1694 4106, June 2005. 1696 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 1697 Mode with IPsec Encapsulating Security Payload (ESP)", RFC 1698 4309, December 2005. 1700 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 1701 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 1702 May 2006. 1704 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1705 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 1706 5996, September 2010. 1708 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1709 of Interpretation", RFC 6407, October 2011. 1711 Appendix A. Differences between G-IKEv2 and RFC 6407 1713 KE Payload - The KE payload is no longer needed with the availability 1714 of newer algorithms such as AES and GCM which provide adequate 1715 protection therefore not needing the PFS capability the KE payload 1716 offers. 1718 SIG Payload - The AUTH payload is used for the same purpose instead. 1720 DOI/Situation - The DOI and Situation fields in the SA payload are no 1721 longer needed in the G-IKEv2 protocol as port 848 will distinguish 1722 the IKEv2 messages from the G-IKEv2 messages. 1724 SEQ Payload - The SEQ payload is no longer needed since IKEv2 header 1725 has message id which is used to prevent message replay attacks. 1727 Authors' Addresses 1729 Sheela Rowles 1730 Cisco Systems 1731 170 W. Tasman Drive 1732 San Jose, California 95134-1706 1733 USA 1735 Phone: +1-408-527-7677 1736 Email: sheela@cisco.com 1738 Aldous Yeung (editor) 1739 Cisco Systems 1740 170 W. Tasman Drive 1741 San Jose, California 95134-1706 1742 USA 1744 Phone: +1-408-853-2032 1745 Email: cyyeung@cisco.com 1747 Paulina Tran 1748 Cisco Systems 1749 170 W. Tasman Drive 1750 San Jose, California 95134-1706 1751 USA 1753 Phone: +1-408-526-8902 1754 Email: ptran@cisco.com 1755 Yoav Nir 1756 Check Point Software Technologies Ltd. 1757 5 Hasolelim St. 1758 Tel Aviv 67897 1759 Israel 1761 Email: ynir@checkpoint.com