idnits 2.17.1 draft-weis-gdoi-rekey-ack-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 8, 2017) is 2384 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Weis 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track U. Mangla 5 Expires: March 12, 2018 Juniper Networks Inc. 6 T. Karl 7 Deutsche Telekom 8 N. Maheshwari 9 September 8, 2017 11 GDOI GROUPKEY-PUSH Acknowledgement Message 12 draft-weis-gdoi-rekey-ack-07 14 Abstract 16 The Group Domain of Interpretation (GDOI) includes the ability for a 17 Group Controller/Key Server (GCKS) to provide a set of current Group 18 Member (GM) devices with additional security associations (e.g., to 19 rekey expiring security associations). This memo adds the ability of 20 a GCKS to request the GM devices to return an acknowledgement of 21 receipt of its rekey message, and specifies the acknowledgement 22 method. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 12, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 60 1.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . 4 61 2. Acknowledgement Message Request . . . . . . . . . . . . . . . 4 62 2.1. REKEY_ACK_KEK_SHA256 Type . . . . . . . . . . . . . . . . 5 63 2.2. REKEY_ACK_LKH_SHA256 Type . . . . . . . . . . . . . . . . 5 64 2.3. REKEY_ACK_KEK_SHA512 Type . . . . . . . . . . . . . . . . 5 65 2.4. REKEY_ACK_LKH_SHA512 Type . . . . . . . . . . . . . . . . 6 66 3. GROUPKEY-PUSH Acknowledgement Message . . . . . . . . . . . . 6 67 3.1. HDR . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.2. HASH . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.3. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.4. ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4. Group Member Operations . . . . . . . . . . . . . . . . . . . 8 72 5. GCKS Operations . . . . . . . . . . . . . . . . . . . . . . . 9 73 6. Management Considerations . . . . . . . . . . . . . . . . . . 9 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 7.1. Protection of the GROUPKEY-PUSH ACK . . . . . . . . . . . 11 76 7.2. Transmitting a GROUPKEY-PUSH ACK . . . . . . . . . . . . 12 77 7.3. Receiving a GROUPKEY-PUSH ACK . . . . . . . . . . . . . . 12 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 82 10.2. Informative References . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 The Group Domain of Interpretation (GDOI) [RFC6407] is a group key 88 management method by which a Group Controller/Key Server (GCKS) 89 distributes security associations (i.e., cryptographic policy and 90 keying material) to a set of Group Member (GM) devices. GDOI meets 91 the requirement of the Multicast Security (MSEC) Group Key Management 92 Architecture [RFC4046], and defines both a Registration Protocol and 93 Rekey Protocol. GDOI describes the Rekey Protocol as a GROUPKEY-PUSH 94 message. 96 A GDOI GCKS uses a GROUPKEY-PUSH message (Section 4 of [RFC6407]) to 97 alert group members to updates in policy for the group, including new 98 policy and keying material, replacement policy and keying material, 99 and indications of deleted policy and keying material. Usually the 100 GCKS does not require a notification that the group member actually 101 received the policy. However, in some cases it is beneficial for a 102 GCKS to be told by each receiving GM that it received the rekey 103 message and by implication has reacted to the policy contained 104 within. For example, a GCKS policy can use the acknowledgements to 105 determine which GMs are receiving the current group policy and which 106 GMs are no longer participating in the group. 108 This memo introduces a method by which a GM returns an acknowledgment 109 message to the GCKS. Initially a GCKS requests GM to acknowledge 110 GROUPKEY-PUSH messages as part of distributed group policy. Then 111 (shown in Figure 1) when the GCKS delivers a GROUPKEY-PUSH message, 112 each GM that honors the GCKS request returns a GROUPKEY-PUSH 113 Acknowledgement Message. The rest of this memo describes this method 114 in detail. 116 GCKS GM1 GM2 117 | | | 118 | +---------->| | 119 | GROUPKEY-PUSH | | | 120 |-----------------+ | | 121 | | | | 122 | +-------------------->| 123 | | | 124 |<----------------------------| | 125 | GROUPKEY-PUSH ACK | | 126 | | | 127 |<--------------------------------------| 128 | GROUPKEY-PUSH ACK | | 130 Figure 1: GROUPKEY-PUSH Rekey Event 132 Implementation of the GROUPKEY-PUSH Acknowledgement Message is 133 OPTIONAL. 135 1.1. Requirements notation 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 1.2. Acronyms and Abbreviations 143 The following acronyms and abbreviations are used throughout this 144 document. 146 D Delete Payload 148 GCKS Group Controller/Key Server 150 GDOI Group Domain of Interpretation 152 GM Group Member 154 HDR Header Payload 156 IV Initialization Vector 158 KD Key Download Payload 160 KDF Key Derivation Function 162 KEK Key Encryption Key 164 LKH Logical Key Hierarchy 166 MSEC Multicast Security 168 SA Security Association 170 SEQ Sequence Number Payload 172 SIG Signature Payload 174 SPI Security Parameter Index 176 2. Acknowledgement Message Request 178 When a GM is ready to join a group, it contacts the GCKS with a 179 GROUPKEY-PULL Registration Protocol. When the GCKS has authenticated 180 and verified that the GM is an authorized member of the group it 181 downloads several sets of policy in a Security Association (SA) 182 payload. If the group includes the use of a GROUPKEY-PUSH Rekey 183 Protocol, the SA payload includes an SA Key Encryption Key (KEK) 184 payload (Section 5.3 of [RFC6407]). When necessary the GROUPKEY-PUSH 185 Rekey Protocol also contains an SA payload that includes SA KEK 186 policy. The SA KEK policy indicates how the GM will be receiving and 187 handling the GROUPKEY-PUSH Rekey Protocol. 189 When the GCKS policy includes the use of the GROUPKEY-PUSH 190 Acknowledgement Message, the GCKS reports this policy to the GM 191 within the SA KEK policy. The GCKS includes a new KEK Attribute with 192 the name KEK_ACK_REQUESTED (value TBD-1), which indicates that the GM 193 is requested to return a GROUPKEY-PUSH Acknowledgement Message. 195 As part of the SA KEK policy, the GCKS specifies information on the 196 keying material, that is used to protect the GROUPKEY-PUSH Rekey 197 Protocol (e.g., presence of KEK Management Algorithm). Parts of 198 these information are used by a GM to derive the ack_key (defined in 199 Section 3.2), which protects the GROUPKEY-PUSH Acknowledgement 200 Message. There are different types of Rekey Acknowledgement 201 messages, which share an identical message format but differ in the 202 used keying material. 204 The following values of the KEK_ACK_REQUESTED attribute are defined 205 in this memo. 207 2.1. REKEY_ACK_KEK_SHA256 Type 209 This type of Rekey ACK is used when the KEK KD Type (Section 5.6.2 of 210 [RFC6407]) is part of the group policy. The prf (defined in 211 Section 3.2) is PRF-HMAC-SHA-256 [RFC4868]. The base_key (also 212 defined in Section 3.2) is the KEK_ALGORITHM_KEY used to decrypt the 213 GROUPKEY-PUSH message. Note that for some algorithms the 214 KEK_ALGORITHM_KEY will include an explicit Initialization Vector (IV) 215 before the actual key (Section 5.6.2.1 of [RFC6407]), but it is not 216 used in the definition of the base_key. 218 2.2. REKEY_ACK_LKH_SHA256 Type 220 This type of Rekey ACK can be used when the KEK_MANAGEMENT_ALGORITHM 221 KEK attribute with a value representing Logical Key Hierarchy (LKH) 222 is part of the group policy (Section 5.3.1.1 of [RFC6407]). The prf 223 is PRF-HMAC-SHA-256. The base_key is the Key Data taken from the 224 first LKH Key structure in an LKH_DOWNLOAD_ARRAY attribute (see 225 Section 5.6.3.1 of [RFC6407]). This is a secret symmetric key that 226 the GCKS shares with the group member. Note that for some algorithms 227 the LKH Key structure will include an explicit IV before the actual 228 key (Section 5.6.3.1 of [RFC6407]), but it is not used in the 229 definition of the base_key. 231 2.3. REKEY_ACK_KEK_SHA512 Type 233 This type of Rekey ACK is identical to the REKEY_ACK_KEK_SHA256 Type, 234 except that the prf is PRF-HMAC-SHA-512 (defined in [RFC4868]). 236 2.4. REKEY_ACK_LKH_SHA512 Type 238 This type of Rekey ACK is identical to the REKEY_ACK_LKH_SHA256 Type, 239 except that the prf is PRF-HMAC-SHA-512 (defined in [RFC4868]). 241 3. GROUPKEY-PUSH Acknowledgement Message 243 The GROUPKEY-PUSH message defined in [RFC6407] is reproduced in 244 Figure 2. The SA and Key Download (KD) payloads contain the actual 245 policy and keying material being distributed to the GM. The Sequence 246 Number (SEQ) payload contains a sequence number that is used by the 247 GM for replay protection. This sequence number defines a unique 248 rekey message delivered to that GM. One or more Delete (D) payloads 249 optionally specify the deletion of existing group policy. The 250 Signature (SIG) payload includes a signature of a hash of the entire 251 GROUPKEY-PUSH message (excepting the SIG payload octets) before it 252 has been encrypted 254 GM GCKS 255 -- ---- 256 <---- HDR*, SEQ, [D,] SA, KD, SIG 258 * Protected by the Rekey SA KEK; encryption occurs after HDR 260 Figure 2: GROUPKEY-PUSH from RFC 6407 262 When the GM has received a KEK_ACK_REQUESTED attribute in an SA KEK 263 and it chooses to respond, it returns the value of the Sequence 264 Number taken from the GROUPKEY-PUSH message to the GCKS along with 265 its identity. This tuple alerts the GCKS that the GM has received 266 the GROUPKEY-PUSH message and implemented the policy contained 267 therein. The GROUPKEY-PUSH Acknowledgement Message is shown in 268 Figure 3. 270 GM GCKS 271 -- ---- 272 HDR, HASH, SEQ, ID ----> 274 Figure 3: GROUPKEY-PUSH Acknowledgement Message 276 The IP header for the GROUPKEY-PUSH Acknowledgement Message is 277 constructed as if it were a reply to the GROUPKEY-PUSH message. That 278 is, the Source Address of the GROUPKEY-PUSH message becomes the 279 Destination Address of the GROUPKEY-PUSH Acknowledgement Message and 280 the GM includes its own IP address as the Source Address of the 281 GROUPKEY-PUSH Acknowledgement Message. The Source port in the 282 GROUPKEY-PUSH message UDP header becomes the Destination port of the 283 GROUPKEY-PUSH Acknowledgement Message UDP header, and the Destination 284 port of the GROUPKEY-PUSH message UDP header becomes the Source port 285 of the GROUPKEY-PUSH Acknowledgement Message UDP header. 287 The following sections describe the payloads in the GROUPKEY-PUSH 288 Acknowledgement Message. 290 3.1. HDR 292 The message begins with a header as defined for the GDOI GROUPKEY- 293 PUSH message in Section 4.1 of [RFC6407]. The fields in the HDR MUST 294 be initialized as follows. The Cookies of a GROUPKEY-PUSH message 295 act as a Security Parameter Index (SPI) and are copied to the 296 Acknowledgement Message. Next Payload identifies a Hash payload 297 (value 8) [ISAKMP-NP]. Major Version is 1 and Minor Version is 0. 298 The Exchange Type has value 35 for the GDOI GROUPKEY-PUSH 299 Acknowledgment Message. Flags are set to 0. Message ID MUST be set 300 to zero. Length is according to Section 4.1 of [RFC6407]). 302 3.2. HASH 304 The HASH payload is the same one used in the GDOI GROUPKEY-PULL 305 exchange defined in Section 3.2 of [RFC6407]. The hash data in the 306 HASH payload is created as follows: 308 HASH = prf(ack_key, SEQ | ID) 310 where: 312 o prf is specific to the KEK_ACK_REQUESTED value, and is described 313 as part of that description. 315 o "|" indicates concatenation. 317 o SEQ and ID represent the bytes comprising the Sequence Number and 318 Identification Payloads 320 The ack_key is computed from a Key Derivation Function (KDF) that 321 conforms to KDF in Feedback Mode as defined in NIST SP800-108 322 [SP800-108] where the length of the derived keying material is the 323 same as the output of the prf, there is no initialization vector, and 324 the optional counter is not used. Note: When the derived ack_key is 325 smaller than the prf block size (i.e., 512 bits for PRF-HMAC-SHA- 326 256), it is zero filled to the right, as specified in Section 2.1.2 327 of [RFC4868]. 329 ack_key = prf(base_key, "GROUPKEY-PUSH ACK" | SPI | L) 331 where: 333 o prf is specific to the KEK_ACK_REQUESTED value, and is described 334 as part of that description. 336 o base_key is specific to the KEK_ACK_REQUESTED value, and is 337 described as part of that description. If the base_key is smaller 338 than the prf block size (i.e., 512 bits for PRF-HMAC-SHA-256), 339 then it is zero filled to the right, as specified in Section 2.1.2 340 of [RFC4868]. 342 o "|" indicates concatenation. 344 o "GROUPKEY-PUSH ACK" is a label encoded as a null terminated ASCII 345 string. 347 o SPI is the Initiator Cookie followed by the Responder Cookie taken 348 from the GROUPKEY-PUSH message HDR, which describes the Context of 349 the key usage. 351 o L is a length field matching the number of bits in the ack_key. L 352 MUST match the length of the base_key (i.e., 512 bits for PRF- 353 HMAC-SHA-256). The value L is represented as two octets in 354 network byte order (that is, most significant byte first). 356 3.3. SEQ 358 The Sequence Number Payload is defined in [RFC6407]. The value in 359 the GROUPKEY-PUSH SEQ payload is copied to the SEQ payload. 361 3.4. ID 363 The Identification payload is used as defined in Section 5.1 of 364 [RFC6407]. The ID payload contains an ID Type of ID_IPV4_ADDR, 365 ID_IPV6_ADDR, or ID_OID as defined for GDOI exchanges [RFC8052]. 366 Protocol ID and Port fields MUST be set to 0. The address provided 367 in the ID payload represents the IP address of the GM, and MUST match 368 the source IP address used for the most recent GROUPKEY-PULL 369 exchange. 371 4. Group Member Operations 373 When a GM receives an SA KEK payload (in a GROUPKEY-PULL exchange or 374 GROUPKEY-PUSH message) including a KEK_ACK_REQUESTED attribute, it 375 records in its group state some indication that it is expected to 376 return a GROUPKEY-PUSH ACK message. A GM recognizing the attribute 377 MUST honor the KEK_ACK_REQUESTED attribute by returning 378 Acknowledgments, because it can be expected that the GCKS is likely 379 to take some policy-specific action regarding non-responsive GMs, 380 including ceasing to deliver GROUPKEY-PUSH messages to it. 382 If a GM cannot respond with the requested type of Acknowledgement, it 383 continues with protocol exchange and participates in the group. In 384 any case, if a GM stops receiving GROUPKEY-PUSH messages from a GCKS 385 it will re-register before existing security associations expire, so 386 omitting sending Acknowledgements should not be critical. 388 When a GM receives a GROUPKEY-PUSH message that contains a 389 KEK_ACK_REQUESTED attribute in the SA KEK payload, it processes the 390 message according to RFC 6407. When it concludes successful 391 processing of the message, it formulates the GROUPKEY-PUSH ACK 392 messages as described in Section 3 and delivers the message to the 393 GCKS from which the GROUPKEY-PUSH message was received. A GROUPKEY- 394 PUSH ACK message is sent even if the GROUPKEY-PUSH message contains a 395 Delete payload for the KEK used to protect the GROUPKEY-PUSH message. 397 5. GCKS Operations 399 When a GCKS policy includes requesting a GROUPKEY-PUSH ACK message 400 from Group Members, it includes the KEK_ACK_REQUESTED attribute in 401 the SA KEK payload. It does this each time the SA KEK is delivered, 402 in both GROUPKEY-PULL exchanges and GROUPKEY-PUSH messages. The 403 value of the KEK_ACK_REQUESTED attribute will depend upon the type SA 404 KEK, as described in Section 2. 406 When a GCKS receives a GROUPKEY-PUSH ACK message (identified by an 407 Exchange type of GROUPKEY-PUSH-ACK), it first verifies that the group 408 policy includes receiving GROUPKEY-PUSH ACK messages. If not, the 409 message is discarded. GCKS implementations SHOULD keep a record 410 (e.g., a hash value) of recently received GROUPKEY-PUSH 411 Acknowledgment messages and reject duplicate messages prior to 412 performing cryptographic operations. This enables an early discard 413 of the replayed messages. 415 If the message is expected, the GCKS validates the format of the 416 message, and verifies that the HASH has been properly constructed as 417 described in Section 3.2. If validation fails, the message is 418 discarded. The GCKS extracts the sequence number and identity of the 419 GM from the SEQ and ID payloads respectively, and records the fact 420 that the GM received the GROUPKEY-PUSH message represented by its 421 serial number. 423 6. Management Considerations 425 The GCKS manages both group policy and group membership of a group. 426 Group membership policy includes a strategy to ensure that rekey 427 messages with current group policy reach all live group members. 428 This is discussed briefly in Section 5.3 of the MSEC Group Key 429 Management Architecture [RFC4046]. The GROUPKEY-PUSH Acknowledgement 430 message specified in this memo provides the GCKS an additional method 431 to assess if a group member is live and has received the current 432 group policy. But it is possible for a rekey message or GROUPKEY- 433 PUSH Acknowledgement message to be discarded in the network, which 434 results in a live GM to appear unresponsive. Also a GM might not be 435 able to respond with an GROUPKEY-PUSH ACK. So the GCKS should use 436 caution in using a lack of Acknowledgment as the only factor in 437 determining whether a GM is live. In particular, a GCKS SHOULD NOT 438 consider a GM to have left the group until it has received at least 439 one ACK from the GM. 441 Some management considerations determining how a Group Member handle 442 Acknowledgement messages is as follows: 444 o A GM MUST respond with Acknowledgement messages when requested, as 445 a GCKS can subsequently determine when a GM becomes unexpectedly 446 non-responsive. 448 o A GM receiving GROUPKEY-PUSH message as a multicast message MAY 449 introduce a jitter to the timing of its Acknowledgement message to 450 help the GCKS better manage replies from group members. A GM MUST 451 NOT delay sending an Acknowledgment for more than 5 seconds. a 452 GCKS SHOULD NOT declare an Acknowledgment as missing until it has 453 waited at least 10 seconds. Implementations SHOULD make these 454 timers configurable. 456 Some management considerations determining how the GCKS handles 457 Acknowledgement messages is as follows: 459 o A non-receipt of an Acknowledgement is an indication that a GM is 460 unable to respond. A GCKS SHOULD wait at least several seconds 461 before determining non-receipt, as GMs could add jitter to the 462 response time before sending an acknowledgement. 464 o If the GCKS is aware that GMs are expected to respond, then a non- 465 receipt of an Acknowledgement SHOULD trigger a logging event. The 466 GCKS MAY be configured with additional policy actions such as 467 transmitting the GROUPKEY-PUSH message several times in a short 468 period of time (as suggested in [RFC4046]), which mitigates a 469 packet loss of either the GROUPKEY-PUSH message or an 470 Acknowledgement message. Another policy action could be to 471 alerting GCKS administrators of GMs that do not return several 472 consecutive acknowledgement messages or even removing unresponsive 473 GMs from the group. However, a GCKS with a policy of removing GMs 474 from the group needs to be aware that a GM that has not responded 475 will not receive newer group policy until it initiates contact 476 with the GCKS again. 478 o When a GROUPKEY-PUSH message includes a Delete payload for the KEK 479 used to protect the GROUPKEY-PUSH message, the GCKS SHOULD NOT 480 itself delete the KEK until it has given GMs the opportunity to 481 acknowledge receipt of the GROUPKEY-PUSH message. This could be 482 several seconds, as GMs could add jitter to the response time 483 before sending an acknowledgement. 485 o A GCKS SHOULD log failure events, such as receiving 486 Acknowledgement messages for a group in which the GCKS has not 487 requested Acknowledgements, receiving malformed Acknowledgement, 488 and Acknowledgements that fail validation. 490 7. Security Considerations 492 There are three areas of security considerations to consider: the 493 protection of the GROUPKEY-PUSH ACK message, whether the GM should 494 transmit a GROUPKEY-PUSH ACK, and whether a GCKS should accept a 495 GROUPKEY-PUSH ACK. These are addressed in the following subsections. 497 The construction of the HASH defined in this memo uses PRF-HMAC- 498 SHA-256 or PRF-HMAC-SHA-512. The strength of these PRFs were 499 unquestioned at the time this memo was developed. When a HASH 500 construction is necessary using a different prf, a new 501 KEK_ACK_REQUESTED value will be defined in a new specification. 503 7.1. Protection of the GROUPKEY-PUSH ACK 505 The GROUPKEY-PUSH ACK message is an ISAKMP [RFC2408] message. 506 Message authentication and Man-in-the-Middle Attack Protection is 507 provided by the inclusion of a HASH payload, which includes the 508 output of an HMAC computation over the bytes of the message. 510 When the value of REKEY_ACK_KEK is specified, because the KEK is a 511 group secret impersonation of a victim GM by another authorized GM is 512 possible. However, security considerations of the impersonation are 513 limited to a false claim that a victim GM has received a GROUPKEY- 514 PUSH when the victim GM has in fact not received it (e.g., because an 515 active attacker has discarded the GROUPKEY-PUSH). If a GCKS policy 516 includes sending retransmissions of the GROUPKEY-PUSH message to that 517 victim GM, then the victim GM might not receive replacement security 518 associations. However, this adds no additional threats over a use 519 case where the GROUPKEY-PUSH ACK is not deployed and GROUPKEY-PUSH 520 messages are withheld from a victim GM by an active attacker. These 521 threats can be mitigated by using a value of REKEY_ACK_LKH, due to 522 the use of a secret pairwise key shared between the GCKS and 523 individual GM. 525 Confidentiality is not provided for the GROUPKEY-PUSH ACK message. 526 The contents of the message can be observed by a passive attacker, 527 which includes the hash value, the sequence number of in the 528 GROUPKEY-PUSH message to which it is acknowledging receipt, and the 529 identity of the GM. Observation of a hash value or set of hash 530 values will not compromise the hash key. The identity of the GM is 531 also available to the passive attacker as the source IP address of 532 the packet. The sequence number does reveal the sequence number that 533 was included in the GROUPKEY-PUSH, which was previously not available 534 to the attacker. However, the attacker is assumed to not be in 535 possession of the key used to encrypt the message, and thus cannot 536 create a spoofed GROUPKEY-PUSH message. Therefore, there is no 537 direct value that the attacker derives from the knowledge of the 538 sequence number. 540 7.2. Transmitting a GROUPKEY-PUSH ACK 542 A GM transmits an ACK only when the policy of the most recently 543 received SA KEK includes a request by the GCKS for ACKs, and only is 544 returned after processing the GROUPKEY-PUSH message according to 545 Section 4.4 of [RFC6407]. In other words, the form of the GROUPKEY- 546 PUSH message will have been validated, replay protection completed, 547 and the digital signature verified as being genuine. Therefore, the 548 threats of a GM responding to a spoofed or resent GROUPKEY-PUSH 549 message, and the possibility of the GM being used to propagate a 550 Distributed Denial of Service (DDoS) attack on a GCKS are mitigated. 551 For more information, see the security considerations of a GROUPKEY- 552 PUSH message described in Section 7.3 of [RFC6407]. 554 7.3. Receiving a GROUPKEY-PUSH ACK 556 A GCKS receiving ACK messages will follow the validation steps 557 described in Section 5 before interpreting the contents of the 558 message. The GCKS will then be sure to operate only on messages that 559 have been sent by an authorized GM. 561 A GCKS SHOULD be prepared to receive GROUPKEY-PUSH ACK messages from 562 each GM to which it was sent. That is, needs to ensure it has 563 sufficient resources (e.g., receive queue size) so that it does not 564 unnecessarily drop ACK messages. An GCKS should be aware that a 565 large number of replayed or invalid GROUPKEY-PUSH messages could be 566 addressed to it. However, this is no worse a threat than if it 567 received a large number of other types of replayed or invalid GDOI or 568 other messages containing a HASH payload. 570 How a GCKS processes the serial number and identity included in an 571 ACK message is a matter of local policy and is outside the scope of 572 this memo. 574 8. IANA Considerations 576 The following additions are made to the GDOI Payloads [GDOI-REG] 577 registry. 579 A new attribute is added to the SA KEK Payload Values - KEK 580 Attributes registry. The ID Class name is KEK_ACK_REQUESTED with a 581 value of TBD-1, and is a Basic attribute. 583 A new registry defining values for KEK_ACK_REQUESTED is needed, and 584 these values are shown in the following table. The terms Reserved, 585 Unassigned, and Private Use are to be applied as defined in 586 [RFC8126]. The registration procedure is Specification Required. 588 Value Type 589 ------- ---- 590 0 Reserved 591 1 REKEY_ACK_KEK_SHA256 592 2 REKEY_ACK_LKH_SHA256 593 3 REKEY_ACK_KEK_SHA512 594 4 REKEY_ACK_LKH_SHA512 595 5-128 Unassigned 596 129-255 Private Use 598 A new registry describing ISAKMP Exchange Types for GDOI is added to 599 GDOI Payloads [GDOI-REG]. This registry defines DOI Specific Use 600 values [ISAKMP-EXCH], which are Exchange type values used with the 601 ISAKMP GDOI DOI. Its name is "GDOI DOI Exchange Types". The 602 registration procedure is Specification Required. The terms Known 603 Unregistered Use and Unassigned are to be applied as defined in 604 [RFC8126]. 606 Value Phase Reference 607 ---- ----- --------- 608 GROUPKEY-PULL 32 RFC 6407 609 GROUPKEY-PUSH 33 RFC 6407 610 Known Unregistered Use 34 611 GROUPKEY-PUSH-ACK 35 RFC XXXX 612 Unassigned 36-239 614 [Note to RFC Editor: Please replace XXXX with the number of the RFC 615 resulting from this memo, and delete this note.] 617 9. Acknowledgements 619 Mike Hamada, Adrian Farrel, and Yaron Sheffer provided many useful 620 technical and editorial comments and suggestions for improvement. 622 10. References 624 10.1. Normative References 626 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 627 Requirement Levels", BCP 14, RFC 2119, 628 DOI 10.17487/RFC2119, March 1997, . 631 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 632 384, and HMAC-SHA-512 with IPsec", RFC 4868, 633 DOI 10.17487/RFC4868, May 2007, . 636 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 637 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 638 October 2011, . 640 [RFC8052] Weis, B., Seewald, M., and H. Falk, "Group Domain of 641 Interpretation (GDOI) Protocol Support for IEC 62351 642 Security Services", RFC 8052, DOI 10.17487/RFC8052, June 643 2017, . 645 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 646 Writing an IANA Considerations Section in RFCs", BCP 26, 647 RFC 8126, DOI 10.17487/RFC8126, June 2017, 648 . 650 10.2. Informative References 652 [GDOI-REG] 653 Internet Assigned Numbers Authority, "Group Domain of 654 Interpretation (GDOI) Payload Type Values", IANA Registry, 655 November 2016, . 658 [ISAKMP-EXCH] 659 Internet Assigned Numbers Authority, "Internet Key 660 Exchange (IKE) Attributes Exchange Type Values", 661 IANA Registry, May 2013, . 664 [ISAKMP-NP] 665 Internet Assigned Numbers Authority, "Internet Key 666 Exchange (IKE) Attributes Next Protocol Types", 667 IANA Registry, May 2013, . 670 [RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, 671 "Internet Security Association and Key Management Protocol 672 (ISAKMP)", RFC 2408, DOI 10.17487/RFC2408, November 1998, 673 . 675 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 676 "Multicast Security (MSEC) Group Key Management 677 Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005, 678 . 680 [SP800-108] 681 Chen, L., "Recommendation for Key Derivation Using 682 Pseudorandom Functions", United States of America, 683 National Institute of Science and Technology, NIST Special 684 Publication 800-108, October 2009, 685 . 687 Authors' Addresses 689 Brian Weis 690 Cisco Systems 691 170 W. Tasman Drive 692 San Jose, California 95134-1706 693 USA 695 Phone: +1-408-526-4796 696 Email: bew@cisco.com 698 Umesh Mangla 699 Juniper Networks Inc. 700 1133 Innovation Way 701 Sunnyvale, California 94089 702 USA 704 Phone: +1-408-936-1022 705 Email: umangla@juniper.net 707 Thomas Karl 708 Deutsche Telekom 709 Landgrabenweg 151 710 Bonn 53227 711 Germany 713 Phone: +49 228 18138122 714 Email: thomas.karl@telekom.de 715 Nilesh Maheshwari 717 Email: nileshm@gmail.com