idnits 2.17.1 draft-ietf-msec-gdoi-update-11.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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 12, 2011) is 4634 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 normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2627 ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Downref: Normative reference to an Informational RFC: RFC 5903 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Obsoletes: 3547 (once approved) B. Weis 3 Internet-Draft S. Rowles 4 Intended status: Standards Track Cisco Systems 5 Expires: February 13, 2012 T. Hardjono 6 MIT 7 August 12, 2011 9 The Group Domain of Interpretation 10 draft-ietf-msec-gdoi-update-11 12 Abstract 14 This document describes the Group Domain of Interpretation (GDOI) 15 protocol specified in RFC 3547. The GDOI provides group key 16 management to support secure group communications according to the 17 architecture specified in RFC 4046. The GDOI manages group security 18 associations, which are used by IPsec and potentially other data 19 security protocols. This document replaces RFC 3547. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 13, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 6 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 70 1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 7 72 2. GDOI Phase 1 protocol . . . . . . . . . . . . . . . . . . . . 9 73 2.1. DOI value . . . . . . . . . . . . . . . . . . . . . . . . 9 74 2.2. UDP port . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . . . 10 77 3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 10 78 3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.3. Group Member Operations . . . . . . . . . . . . . . . . . 13 80 3.4. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 14 81 3.5. Counter-modes of operation . . . . . . . . . . . . . . . . 15 83 4. GROUPKEY-PUSH Message . . . . . . . . . . . . . . . . . . . . 18 84 4.1. Use of signature keys . . . . . . . . . . . . . . . . . . 19 85 4.2. ISAKMP Header Initialization . . . . . . . . . . . . . . . 19 86 4.3. GCKS Operations . . . . . . . . . . . . . . . . . . . . . 19 87 4.4. Group Member Operations . . . . . . . . . . . . . . . . . 20 89 5. Payloads and Defined Values . . . . . . . . . . . . . . . . . 22 90 5.1. Identification Payload . . . . . . . . . . . . . . . . . . 22 91 5.2. Security Association Payload . . . . . . . . . . . . . . . 23 92 5.3. SA KEK payload . . . . . . . . . . . . . . . . . . . . . . 24 93 5.4. Group Associated Policy . . . . . . . . . . . . . . . . . 31 94 5.5. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 33 95 5.6. Key Download Payload . . . . . . . . . . . . . . . . . . . 38 96 5.7. Sequence Number Payload . . . . . . . . . . . . . . . . . 47 97 5.8. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 48 98 5.9. Delete . . . . . . . . . . . . . . . . . . . . . . . . . . 48 100 6. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 50 101 6.1. KEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 102 6.2. TEK . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 104 7. Security Considerations . . . . . . . . . . . . . . . . . . . 52 105 7.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . . 52 106 7.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . 53 107 7.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . . 55 108 7.4. Forward and Backward Access Control . . . . . . . . . . . 56 109 7.5. Derivation of keying material . . . . . . . . . . . . . . 58 111 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 112 8.1. Additions to current registries . . . . . . . . . . . . . 59 113 8.2. New registries . . . . . . . . . . . . . . . . . . . . . . 59 114 8.3. Cleanup of existing registries . . . . . . . . . . . . . . 61 116 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63 118 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 119 10.1. Normative References . . . . . . . . . . . . . . . . . . . 64 120 10.2. Informative References . . . . . . . . . . . . . . . . . . 65 122 Appendix A. GDOI Applications . . . . . . . . . . . . . . . . . . 68 124 Appendix B. Significant Changes from RFC 3547 . . . . . . . . . . 69 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70 128 1. Introduction 130 Secure group and multicast applications require a method by which 131 each group member shares common security policy and keying material. 132 This document describes the Group Domain of Interpretation (GDOI), 133 which is an ISAMKP [RFC2408] Domain of Interpretation (DOI), a group 134 key management system. The GDOI distributes security associations 135 (SAs) for IPsec AH [RFC4302] and ESP [RFC4303] protocols and 136 potentially other data security protocols used in group applications. 137 The GDOI uses the group key management model defined in [RFC4046], 138 and described more generally by "The Multicast Group Security 139 Architecture" [RFC3740]. 141 In this group key management model, the GDOI protocol participants 142 are a "group controller/key server" (GCKS) and a group member (GM). 143 A group member contacts ("registers with") a GCKS to join the group. 144 During the registration mutual authentication and authorization are 145 achieved, after which the GCKS distributes current group policy and 146 keying material to the group member over an authenticated and 147 encrypted session. The GCKS may also initiate contact ("rekeys") 148 with group members to provide updates to group policy. 150 ISAKMP defines two "phases" of negotiation (p.16 of [RFC2408]). A 151 Phase 1 security association provides mutual authentication and 152 authorization, and a security association that is used by the 153 protocol participants to execute a phase 2 exchange. This document 154 incorporates (i.e., uses but does not re-define) the Phase 1 security 155 association definition from the Internet DOI [RFC2407], [RFC2409]. 156 The GDOI includes two new phase 2 ISAKMP exchanges (protocols), as 157 well as necessary new payload definitions to the ISAKMP standard (p. 158 14 of [RFC2408]). These two new protocols are: 160 1. The GROUPKEY-PULL registration protocol exchange. This exchange 161 uses "pull" behavior since the member initiates the retrieval of 162 these SAs from a GCKS. It is protected by an ISAKMP phase 1 163 protocol, as described above. At the culmination of a GROUPKEY- 164 PULL exchange, an authorized group member has received and 165 installed a set of SAs that represent group policy, and it is 166 ready to participate in secure group communications. 168 2. The GROUPKEY-PUSH rekey protocol exchange. The rekey protocol is 169 a datagram initiated ("pushed") by the GCKS, usually delivered to 170 group members using a IP multicast address. The rekey protocol 171 is an ISAKMP protocol, where cryptographic policy and keying 172 material ("Re-key SA") is included in the group policy 173 distributed by the GCKS in the GROUPKEY-PULL exchange. At the 174 culmination of a GROUPKEY-PUSH exchange the key server has sent 175 group policy to all authorized group members, allowing receiving 176 group members to participate in secure group communications. If 177 a group management method is included in group policy (as 178 described in Section 7.4), at the conclusion of the GROUPKEY-PUSH 179 exchange some members of the group may have been de-authorized 180 and no longer able to participate in the secure group 181 communications. 183 +--------------------------------------------------------------+ 184 | | 185 | +--------------------+ | 186 | +------>| GDOI GCKS |<------+ | 187 | | +--------------------+ | | 188 | | | | | 189 | GROUPKEY-PULL | GROUPKEY-PULL | 190 | PROTOCOL | PROTOCOL | 191 | | | | | 192 | v GROUPKEY-PUSH v | 193 | +-----------------+ PROTOCOL +-----------------+ | 194 | | | | | | | 195 | | GDOI GM(s) |<-------+-------->| GDOI GM(S) | | 196 | | | | | | 197 | +-----------------+ +-----------------+ | 198 | | ^ | 199 | v | | 200 | +-Data Security Protocol (e.g., ESP)-+ | 201 | | 202 +--------------------------------------------------------------+ 204 Figure 1. Group Key Management Model 206 Although the GROUPKEY-PUSH protocol specified by this document can be 207 used to refresh the Re-key SA protecting the GROUPKEY-PUSH protocol, 208 the most common use of GROUPKEY-PUSH is to establish keying material 209 and policy for a data security protocol. 211 GDOI defines several payload types used to distribute policy and 212 keying material within the GROUPKEY-PULL and GROUPKEY-PUSH protocols: 213 Security Association (SA), SA KEK, SA TEK, Group Associated Policy 214 (GAP) , Sequence Number (SEQ), and Key Download (KD). Format and 215 usage of these payloads are defined in later sections of this memo. 217 In summary, GDOI is a group security association management protocol: 218 all GDOI messages are used to create, maintain, or delete security 219 associations for a group. As described above, these security 220 associations protect one or more data security protocol SAs, a Re-key 221 SA, and/or other data shared by group members for multicast and 222 groups security applications. 224 1.1. Requirements notation 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 227 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 228 document are to be interpreted as described in [RFC2119]. 230 1.2. Terminology 232 The following key terms are used throughout this document. 234 Data-Security SA. The security policy distributed by a GDOI GCKS 235 describing traffic that is expected to be protected by group 236 members. This document described the distribution of IPsec AH 237 and ESP Data-Security SAs. 239 Group Controller/Key Server A device that defines group policy and 240 distributes keys for that policy.[RFC3740] 242 Group Member. An authorized member of a secure group, sending and/or 243 receiving IP packets related to the group. 245 GROUPKEY-PULL. A protocol used by a GDOI Group Member to request 246 group policy and keying material. 248 GROUPKEY-PUSH. A protocol used by a GDOI GCKS to distribute updates 249 of group policy and keying material to authorized group 250 members. 252 Key Encrypting Key. The symmetric cipher key used to protect the 253 GROUPKEY-PUSH message. 255 Logical Key Hierarchy. A group management method defined in Section 256 5.4 of [RFC2627]. 258 Re-key SA. The security policy protecting a GROUPKEY-PUSH protocol. 260 SA Attribute Payload A payload that follows the Security Association 261 payload that describe group security attributes associated with 262 the security association. SA Attribute Payloads include the 263 SAK, SAT and GAP payloads. 265 Security Parameter Index An arbitrary value that is used by a 266 receiver to identify a Security Association such as IPsec ESP 267 Security Association or a Re-key SA. 269 Traffic Encryption Key. The symmetric cipher key used to protect a 270 data security protocol (e.g., IPsec ESP). 272 1.3. Acronyms and Abbreviations 274 The following acronyms and abbreviations are used throughout this 275 document. 277 AH IP Authentication Header 279 ATD Activation Time Delay 281 DOI Domain of Interpretation 283 DTD Deactivation Time Delay 285 ESP IP Encapsulating Security Payload 287 GCKS Group Controller/Key Server 289 GDOI Group Domain of Interpretation 291 GAP Group Associated Policy Payload 293 GM Group Member 295 GSPD Group Security Policy Database 297 IV Initialization Vector 299 KD Key Download Payload 301 KEK Key Encryption Key 303 LKH Logical Key Hierarchy 305 SA Security Association 307 SAK SA KEK Payload 309 SEQ Sequence Number Payload 311 SAT SA TEK Payload 313 SID Sender-ID 314 SPI Security Parameter Index 316 SSIV Sender-Specific ID 318 TEK Traffic Encryption Key 320 TLV Type/Length/Value 322 TV Type/Value 324 2. GDOI Phase 1 protocol 326 The GDOI GROUPKEY-PULL exchange is a "phase 2" protocol which MUST be 327 protected by a "phase 1" protocol. The "phase 1" protocol can be any 328 protocol which provides for the following protections: 330 o Peer Authentication 332 o Confidentiality 334 o Message Integrity 336 The following sections describe one such "phase 1" protocol. Other 337 protocols which may be potential "phase 1" protocols are described in 338 Appendix A. However, the use of the protocols listed there are not 339 considered part of this document. 341 This document defines how the ISAKMP phase 1 exchanges as defined in 342 [RFC2409] can be used a "phase 1" protocol for GDOI. The following 343 sections define characteristics of the ISAKMP phase 1 protocols that 344 are unique for these exchanges when used for GDOI. 346 Section 7.1 describes how the ISAKMP Phase 1 protocols meet the 347 requirements of a GDOI "phase 1" protocol. 349 2.1. DOI value 351 The Phase 1 SA payload has a DOI value. That value MUST be the GDOI 352 DOI value as defined later in this document. 354 2.2. UDP port 356 IANA has assigned port 848 for the use of GDOI, which allows for an 357 implementation to use separate ISAKMP implementations to service GDOI 358 and IKE [RFC5996]. A GCKS SHOULD listen on this port for GROUPKEY- 359 PULL exchanges, and the GCKS MAY use this port to distribute 360 GROUPKEY-PUSH messages. An ISAKMP phase 1 exchange implementation 361 supporting NAT Traversal [RFC3947] MAY move to port 4500 to process 362 the GROUPKEY-PULL exchange. 364 3. GROUPKEY-PULL Exchange 366 The goal of the GROUPKEY-PULL exchange is to establish a Re-key 367 and/or Data-security SAs at the member for a particular group. A 368 Phase 1 SA protects the GROUPKEY-PULL; there MAY be multiple 369 GROUPKEY-PULL exchanges for a given Phase 1 SA. The GROUPKEY-PULL 370 exchange downloads the data security keys (TEKs) and/or group key 371 encrypting key (KEK) or KEK array under the protection of the Phase 1 372 SA. 374 3.1. Authorization 376 It is important that a group member explicitly trust entities that it 377 expects to act as a GCKS for a particular group. When no 378 authorization is performed, it is possible for a rogue GDOI 379 participant to perpetrate a man-in-the-middle attack between a group 380 member and a GCKS [MP04]. Group members MUST specifically list each 381 authorized GCKS in its Group Peer Authorization Database (GPAD) 382 [RFC5374]. A group member MUST ensure that the Phase 1 identity of 383 the GCKS is an authorized GCKS. 385 It is important that a GCKS explicitly authorize group members before 386 providing them with group policy and keying material. A GCKS 387 implementation SHOULD have a method of authorizing group members 388 (e.g., by maintaining an authorization list). When the GCKS performs 389 authorization, it MUST use the Phase 1 identity to authorize the 390 GROUPKEY-PULL request for group policy and keying material. 392 3.2. Messages 394 The GROUPKEY-PULL is a Phase 2 exchange. Phase 1 computes SKEYID_a 395 which is the "key" in the keyed hash used in the ISAKMP HASH payloads 396 [RFC2408] included in GROUPKEY-PULL messages. When using the Phase 1 397 defined in this document, SKEYID_a is derived according to [RFC2409]. 398 Each GROUPKEY-PULL message hashes a uniquely defined set of values 399 (described below) and includes the result in the HASH payload. 400 Nonces permute the HASH and provide some protection against replay 401 attacks. Replay protection is important to protect the GCKS from 402 attacks that a key management server will attract. 404 The GROUPKEY-PULL uses nonces to guarantee "liveness" as well as 405 against replay of a recent GROUPKEY-PULL message. The replay attack 406 is only possible in the context of the current Phase 1. If a 407 GROUPKEY-PULL message is replayed based on a previous Phase 1, the 408 HASH calculation will fail due to a wrong SKEYID_a. The message will 409 fail processing before the nonce is ever evaluated. 411 In order for either peer to get the benefit of the replay protection, 412 it must postpone as much processing as possible until it receives the 413 message in the protocol that proves the peer is live. For example, 414 the GCKS MUST NOT adjust its internal state (e.g., keeping a record 415 of the GM) until it receives a message with Nr included properly in 416 the HASH payload. This requirement ensures that replays of GDOI 417 messages will not cause the GCKS to change the state of the group 418 until it has confirmation that the initiating group member is live. 420 Group Member GCKS 421 ------------ ---- 422 (1) HDR*, HASH(1), Ni, ID --> 423 (2) <-- HDR*, HASH(2), Nr, SA 424 (3) HDR*, HASH(3) [,GAP] --> 425 (4) <-- HDR*, HASH(4), [SEQ,] KD 427 * Protected by the Phase 1 SA, encryption occurs after HDR 429 Figure 2. GROUPKEY-PULL Exchange 431 Figure 2 demonstrates the four messages that are part of a GROUPKEY- 432 PULL exchange. HDR is an ISAKMP header payload that uses the Phase 1 433 cookies and a message identifier (M-ID) as in ISAKMP. Following each 434 HDR is a set of payloads conveying requests (messages one and three 435 originated by the group member, or group policy and/or keying 436 material (messages two and four originated by the GCKS). 438 Hashes are computed in the manner described within [RFC2409]. The 439 HASH computation for each message is unique, shown in Figure 2 and 440 below as HASH(n) where (n) represents the GROUPKEY-PULL message 441 number. Each HASH calculation is a pseudo-random function ("prf") 442 over the message id (M-ID) from the ISAKMP header concatenated with 443 the entire message that follows the hash including all payload 444 headers, but excluding any padding added for encryption. The GM 445 expects to find its nonce, Ni, in the HASH of a returned message. 446 And the GCKS expects to see its nonce, Nr, in the HASH of a returned 447 message. HASH(2), HASH(3), and HASH(4) also include nonce values 448 previously passed in the protocol (i.e., Ni or Nr minus the payload 449 header). The nonce passed in Ni is represented as Ni_b, and the 450 nonce passed in Nr is represented as Nr_b. The HASH payloads prove 451 that the peer has the Phase 1 secret (SKEYID_a) and the nonce for the 452 exchange identified by message id, M-ID. 454 HASH(1) = prf(SKEYID_a, M-ID | Ni | ID) 455 HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA) 456 HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | GAP ]) 457 HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | SEQ ] | KD) 459 In addition to the Nonce and HASH payloads, the GM identifies the 460 group it wishes to join through the ISAKMP ID payload. 462 The GCKS informs the member of the cryptographic policies of the 463 group in the SA payload, which describes the DOI, KEK and/or TEK 464 keying material, authentication transforms, and other group policy. 465 Each SPI is also determined by the GCKS and downloaded in the SA 466 payload chain (see Section 5.2). The SA KEK attribute contains the 467 ISAKMP cookie pair for the Re-key SA, which is not negotiated but 468 downloaded. Each SA TEK attribute contains a SPI as defined in 469 Section 5.5 of this document. 471 After receiving and parsing the SA payload, the GM responds with an 472 acknowledgement message proving its liveness. It optionally includes 473 a GAP payload requesting resources. 475 The GCKS informs the GM of the value of the sequence number in the 476 SEQ payload. This sequence number provides anti-replay state 477 associated with a KEK, and its knowledge ensures that the GM will not 478 accept GROUPKEY-PUSH messages sent prior to the GM joining the group. 479 The SEQ payload has no other use, and is omitted from the GROUPKEY- 480 PULL exchange when a KEK attribute is not included in the SA payload. 481 When a SEQ payload is included in the GROUPKEY-PULL exchange, it 482 includes the most recently used sequence number for the group. At 483 the conclusion of a GROUPKEY-PULL exchange, the initiating group 484 member MUST NOT accept any rekey message with both the KEK attribute 485 SPI value and a sequence number less than or equal to the one 486 received during the GROUPKEY-PULL exchange. When the first group 487 member initiates a GROUPKEY-PULL exchange, the GCKS provides a 488 Sequence Number of zero, since no GROUPKEY-PUSH messages have yet 489 been sent. Note the sequence number increments only with GROUPKEY- 490 PUSH messages. The GROUPKEY-PULL exchange distributes the current 491 sequence number to the group member. The sequence number resets to a 492 value of one with the usage of a new KEK attribute. Thus the first 493 packet sent for a given Rekey SA will have a Sequence Number of 1. 494 The sequence number increments with each successive rekey. 496 The GCKS always returns a KD payload containing keying material to 497 the GM. If a Re-key SA is defined in the SA payload, then KD will 498 contain the KEK; if one or more Data-security SAs are defined in the 499 SA payload, KD will contain the TEKs. 501 3.2.1. ISAKMP Header Initialization 503 Cookies are used in the ISAKMP header to identify a particular GDOI 504 session. The GDOI GROUPKEY-PULL exchange uses cookies according to 505 ISAKMP [RFC2408]. 507 Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0). 509 Major Version is 1 and Minor Version is 0 according to ISAKMP 510 (Section 3.1 of [RFC2408]). 512 The Exchange Type has value 32 for the GDOI GROUPKEY-PULL exchange. 514 Flags, Message ID, and Length are according to ISAKMP (Section 3.1 of 515 [RFC2408]). The Commit flag is not useful because there is no 516 synchronization between the GROUPKEY-PULL exchange and the data 517 traffic protected by the policy distributed by the GROUPKEY-PULL 518 exchange. 520 3.3. Group Member Operations 522 Before a GM contacts the GCKS, it needs to determine the group 523 identifier and acceptable Phase 1 policy via an out-of-band method. 524 Phase 1 is initiated using the GDOI DOI in the SA payload. Once 525 Phase 1 is complete, the GM state machine moves to the GDOI protocol. 527 To construct the first GDOI message the GM chooses Ni and creates a 528 nonce payload, builds an identity payload including the group 529 identifier, and generates HASH(1). 531 Upon receipt of the second GDOI message, the GM validates HASH(2), 532 extracts the nonce Nr, and interprets the SA payload (including its 533 SA Attribute Payloads) . The SA payload contains policy describing 534 the security protocol and cryptographic protocols used by the group. 535 This policy describes the Re-key SA (if present), Data-security SAs, 536 and other group policy. If the policy in the SA payload is 537 acceptable to the GM, it continues the protocol. Otherwise, the GM 538 SHOULD tear down the Phase 1 session after notifying the GCKS with an 539 ISAKMP Informational Exchange containing a Delete payload. 541 When constructing the third GDOI message, it first reviews each Data- 542 security SA given to it. If any describe the use of a counter mode 543 cipher, the GM determines whether it requires more than one Sender-ID 544 (SID) (see Section 3.5). If so, it requests the required number of 545 Sender-IDs for its exclusive use within the counter mode nonce as 546 described in the Section 5.4 section of this document. The GM the 547 completes construction of the third GDOI message by creating HASH(3). 549 Upon receipt of the fourth GDOI message, the GM validates HASH(4). 551 If the SEQ payload is present, the sequence number included in the 552 SEQ payload asserts the lowest acceptable sequence number present in 553 a future GROUPKEY-PUSH message. But if the the KEK associated with 554 this sequence number had been previously installed, due to the 555 asynchronous processing of GROUPKEY-PULL and GROUPKEY-PUSH messages 556 this sequence number may be lower than the sequence number contained 557 in the most recently received GROUPKEY-PUSH message. In this case, 558 the sequence number value in the SEQ payload MUST be considered stale 559 and ignored. 561 The GM interprets the KD key packets, where each key packet includes 562 the keying material for SAs distributed in the SA payload. Keying 563 material is matched by comparing the SPI in each key packet to SPI 564 values previously sent in the SA payloads. Once TEK keys and policy 565 are matched, the GM provides them to the data security subsystem, and 566 it is ready to send or receive packets matching the TEK policy. If 567 this group has a KEK, the KEK policy and keys are marked as ready for 568 use and the GM knows to expect a sequence number not less than the 569 one distributed in the SEQ payload. The GM is now ready to receive 570 GROUPKEY-PUSH messages. 572 If the KD payload included an LKH array of keys, the GM takes the 573 last key in the array as the group KEK. The array is then stored 574 without further processing. 576 3.4. GCKS Operations 578 The GCKS passively listens for incoming requests from group members. 579 The Phase 1 authenticates the group member and sets up the secure 580 session with them. 582 Upon receipt of the first GDOI message the GCKS validates HASH(1), 583 extracts the Ni and group identifier in the ID payload. It verifies 584 that its database contains the group information for the group 585 identifier, and that the GM is authorized to participate in the 586 group. 588 The GCKS constructs the second GDOI message, including a nonce Nr, 589 and the policy for the group in an SA payload, followed by SA 590 Attribute Payloads (i.e, SA KEK, GAP, and/or SA TEK payloads) 591 according to the GCKS policy. (See Section 5.2.1 for details on how 592 the GCKS chooses which payloads to send.) 594 Upon receipt of the third GDOI message the GCKS validates HASH(3). 595 If the message includes a GAP payload, it caches the requests 596 included in that payload for use of constructing the fourth GDOI 597 message. 599 The GCKS constructs the fourth GDOI message, including the SEQ 600 payload (if the GCKS sends rekey messages), and the KD payload 601 containing keys corresponding to policy previously sent in the SA TEK 602 and SA KEK payloads. If a group management algorithm is defined as 603 part of group policy, the GCKS will first insert the group member 604 into the group management structure (e.g., a leaf in the LKH tree), 605 and then create an LKH array of keys and include it in the KD 606 payload. The first key in the array is associated with the group 607 member leaf node, followed by each LKH node above it in the tree, 608 culminating with the root node (which is also the KEK). If one or 609 more Data-Security SAs distributed in the SA payload included a 610 counter mode of operation, the GCKS includes at least one SID value 611 in the KD payload, and possibly more depending on a request received 612 in the third GDOI message. 614 3.5. Counter-modes of operation 616 Several new counter-based modes of operation have been specified for 617 ESP (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES-CCM [RFC4309], 618 AES-GMAC [RFC4543]) and AH (e.g., AES-GMAC [RFC4543]). These 619 counter-based modes require that no two senders in the group ever 620 send a packet with the same Initialization Vector (IV) using the same 621 cipher key and mode. This requirement is met in GDOI when the 622 following requirements are met: 624 o The GCKS distributes a unique key for each Data-Security SA. 626 o The GCKS uses the method described in [RFC6054], which assigns 627 each sender a portion of the IV space by provisioning each sender 628 with one or more unique SID values. 630 When at least one Data-Security SA included in the group policy 631 includes a counter-mode, the GCKS automatically allocates and 632 distributes one SID to each group member acting in the role of sender 633 on the Data-Security SA. The SID value is used exclusively by the 634 group member to which it was allocated. The group member uses the 635 same SID for each Data-Security SA specifying the use of a counter- 636 based mode of operation. A GCKS MUST distribute unique keys for each 637 Data-Security SA including a counter-based mode of operation in order 638 to maintain a unique key and nonce usage. 640 When a group member receives a Data-Security SA in a SA TEK payload 641 for which it is a sender, it can choose to request one or more SID 642 values. Requesting a value of 1 is not necessary since the GCKS will 643 automatically allocate exactly one to the sending group member. A 644 group member MUST request as many SIDs matching the number of 645 encryption modules in which it will be installing the TEKs in the 646 outbound direction. Alternatively, a group member MAY request more 647 than one SID and use them serially. This could be useful when it is 648 anticipated that the group member will exhaust their range of Data- 649 Security SA nonces using a single SID too quickly (e.g., before the 650 time-based policy in the TEK expires). 652 When group policy includes a counter-based mode of operation, a GCKS 653 SHOULD use the following method to allocate SID values, which ensures 654 that each SID will be allocated to just one group member. 656 1. A GCKS maintains an SID-counter, which records which SIDs have 657 been allocated. SIDs are allocated sequentially, with the first 658 SID allocated to be zero. 660 2. Each time an SID is allocated, the current value of the counter 661 is saved and allocated to the group member. The SID-counter is 662 then incremented in preparation for the next allocation. 664 3. When the GCKS distributes a Data-Security SA specifying a 665 counter-based mode of operation, and a group member is a sender, 666 a group member may request a count of SIDs in a GAP payload. 667 When the GCKS receives this request, it increments the SID- 668 counter once for each requested SID, and distributes each SID 669 value to the group member. 671 4. A GCKS allocates new SID values for each GROUPKEY-PULL exchange 672 originated by a sender, regardless of whether a group member had 673 previously contacted the GCKS. In this way, the GCKS does not 674 have a requirement of maintaining a record of which SID values it 675 had previously allocated to each group member. More importantly, 676 since the GCKS cannot reliably detect whether the group member 677 had sent data on the current group Data-Security SAs it does not 678 know what Data-Security counter-mode nonce values that a group 679 member has used. By distributing new SID values, the key server 680 ensures that each time a conforming group member installs a Data- 681 Security SA it will use a unique set of counter-based mode 682 nonces. 684 5. When the SID-counter maintained by the GCKS reaches its final SID 685 value, no more SID values can be distributed. Before 686 distributing any new SID values, the GCKS MUST delete the Data- 687 Security SAs for the group, followed by creation of new Data- 688 Security SAs, and resetting the SID-counter to its initial value. 690 6. The GCKS SHOULD send a GROUPKEY-PUSH message deleting all Data- 691 Security SAs and the Rekey SA for the group. This will result in 692 the group members initiating a new GROUPKEY-PULL exchange, in 693 which they will receive both new SID values and new Data-Security 694 SAs. The new SID values can safely be used because they are only 695 used with the new Data-Security SAs. Note that deletion of the 696 Rekey SA is necessary to ensure that group members receiving a 697 GROUPKEY-PUSH exchange before the re-register do not 698 inadvertently use their old SIDs with the new Data-Security SAs. 700 Using the method above, at no time can two group members use the same 701 IV values with the same Data-Security SA key. 703 4. GROUPKEY-PUSH Message 705 GDOI sends control information securely using group communications. 706 Typically this will be using IP multicast distribution of a GROUPKEY- 707 PUSH message but it can also be "pushed" using unicast delivery if IP 708 multicast is not possible. The GROUPKEY-PUSH message replaces a Re- 709 key SA KEK or KEK array, and/or creates a new Data-security SA. 711 GM GCKS 712 -- ---- 713 <---- HDR*, SEQ, [D,] SA, KD, SIG 715 * Protected by the Re-key SA KEK; encryption occurs after HDR 717 Figure 3. GROUPKEY-PUSH Message 719 HDR is defined below. The SEQ payload is defined in the Payloads 720 section. One or more D (Delete) payloads (further described in 721 Section 5.9) optionally specify the deletion of existing group 722 policy. The SA defines the group policy for replacement Re-key SA 723 and/or Data-security SAs as described in the Payloads section, with 724 the KD providing keying material for those SAs. 726 The SIG payload includes a signature of a hash of the entire 727 GROUPKEY-PUSH message (excepting the SIG payload octets) before it 728 has been encrypted. The HASH is taken over the string 'rekey', the 729 GROUPKEY-PUSH HDR, followed by all payloads preceding the SIG 730 payload. The prefixed string ensures that the signature of the Rekey 731 datagram cannot be used for any other purpose in the GDOI protocol. 732 The SIG payload is created using the signature of the above hash, 733 with the receiver verifying the signature using a public key 734 retrieved in a previous GDOI exchange. The current KEK encryption 735 key (also previously distributed in a GROUPKEY-PULL exchange or 736 GROUPKEY-PUSH message) encrypts all the payloads following the 737 GROUPKEY-PUSH HDR. Note: The rationale for this order of operations 738 is given in Section 7.3.5. 740 If the SA defines the use of a single KEK or an LKH KEK array, KD 741 MUST contain a corresponding KEK or KEK array for a new Re-key SA, 742 which has a new cookie pair. When the KD payload carries a new SA 743 KEK attribute (section 5.3), a Re-key SA is replaced with a new SA 744 having the same group identifier (ID specified in message 1 of 745 section 3.2) and incrementing the same sequence counter, which is 746 initialized in message 4 of section 3.2. Note the first packet for 747 the given Rekey SA encrypted with the new KEK attribute will have a 748 Sequence number of 1. If the SA defines an SA TEK payload, this 749 informs the member that a new Data-security SA has been created, with 750 keying material carried in KD (Section 5.6). 752 If the SA defines a large LKH KEK array (e.g., during group 753 initialization and batched rekeying), parts of the array MAY be sent 754 in different unique GROUPKEY-PUSH datagrams. However, each of the 755 GROUPKEY-PUSH datagrams MUST be a fully formed GROUPKEY-PUSH 756 datagram. This results in each datagram containing a sequence number 757 and the policy in the SA payload, which corresponds to the KEK array 758 portion sent in the KD payload. 760 4.1. Use of signature keys 762 A signing key should not be used in more than one context (e.g., used 763 for host authentication and also for message authentication). Thus, 764 the GCKS SHOULD NOT use the same key to sign the SIG payload in the 765 GROUPKEY-PUSH message as was used for authentication in the GROUPKEY- 766 PULL exchange. 768 4.2. ISAKMP Header Initialization 770 Unlike ISAKMP, the cookie pair is completely determined by the GCKS. 771 The cookie pair in the GDOI ISAKMP header identifies the Re-key SA to 772 differentiate the secure groups managed by a GCKS. Thus, GDOI uses 773 the cookie fields as an SPI. 775 Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0). 777 Major Version is 1 and Minor Version is 0 according to ISAKMP 778 (Section 3.1 of [RFC2408]). 780 The Exchange Type has value 33 for the GDOI GROUPKEY-PUSH message. 782 Flags MUST have the Encryption bit set according to Section 3.1 of 783 [RFC2408]. All other bits MUST be set to zero. 785 Message ID MUST be set to zero. 787 Length is according to ISAKMP (Section 3.1 of [RFC2408]). 789 4.3. GCKS Operations 791 GCKS may initiate a Rekey message for one of several reasons, e.g., 792 the group membership has changed or keys are due to expire. 794 To begin the rekey datagram the GCKS builds an ISAKMP HDR with the 795 correct cookie pair, and a SEQ payload that includes a sequence 796 number which is one greater than the previous rekey datagram. If the 797 message is using the new KEK attribute for the first time, the SEQ is 798 reset to 1 in this message. 800 An SA payload is then added. This is identical in structure and 801 meaning to a SA payload sent in a GROUPKEY-PULL exchange. If there 802 are changes to the KEK (including due to group members being 803 excluded, in the case of LKH), an SA_KEK attribute is added to the 804 SA. If there are one or more new TEKs then SA_TEK attributes are 805 added to describe that policy. 807 A KD payload is then added. This is identical in structure and 808 meaning to a KD payload sent in a GROUPKEY-PULL exchange. If an 809 SA_KEK attribute was included in the SA payload then corresponding 810 KEK keys (or a KEK update array) is included. A KEK update array is 811 created by first determining which group members have been excluded, 812 generating new keys as necessary, and then distributing LKH update 813 arrays sufficient to provide the new KEK to remaining group members 814 (see Section 5.4.1 of [RFC2627] for details). TEK keys are also sent 815 for each SA_TEK attribute included in the SA payload. 817 In the penultimate step, the GCKS creates the SIG payload and adds it 818 to the datagram. 820 Lastly, the payloads following the HDR are encrypted using the 821 current KEK encryption key. The datagram can now be sent. 823 4.4. Group Member Operations 825 A group member receiving the GROUPKEY-PUSH datagram matches the 826 cookie pair in the ISAKMP HDR to an existing SA. The message is 827 decrypted, and the form of the datagram is validated. This weeds out 828 obvious ill-formed messages (which may be sent as part of a Denial of 829 Service attack on the group). 831 The sequence number in the SEQ payload is validated to ensure that it 832 is greater than the previously received sequence number. The SIG 833 payload is then validated. If the signature fails, the message is 834 discarded. 836 The SA and KD payloads are processed which results in a new GDOI 837 Rekey-SA (if the SA payload included an SA_KEK attribute) and/or new 838 Data-security SAs being added to the system. If the KD payload 839 includes an LKH update array, the group member compares the LKH ID in 840 each key update packet to the LKH IDs that it holds. If it finds a 841 match, it decrypts the key using the key prior to it in the key array 842 and stores the new key in the LKH key array that it holds. The final 843 decryption yields the new group KEK. 845 If the SA payload includes one or more Data-Security SA including a 846 counter-modes of operation and the receiving group member is a sender 847 for that SA, the group member uses its current SID value with the 848 Data-Security SAs to create counter-mode nonces. If it is a sender 849 and does not hold a current SID value, it MUST NOT install the Data- 850 Security SAs. It MAY initiate a GROUPKEY-PULL exchange to the GCKS 851 in order to obtain an SID value (along with current group policy). 853 5. Payloads and Defined Values 855 This document specifies use of several ISAKMP payloads, which are 856 defined in accordance with [RFC2408]. The following payloads are 857 used as defined in [RFC2408]. 859 Next Payload Type Value 860 ----------------- ----- 861 Hash Payload (HASH) 8 862 Signature (SIG) 9 864 The following payloads are extended or further specified. 866 Next Payload Type Value 867 ----------------- ----- 868 Security Association (SA) 1 869 Identification (ID) 5 870 Nonce (N) 10 871 Delete (D) 12 873 Several payload formats specific to the group security exchanges are 874 required. 876 Next Payload Type Value 877 ----------------- ----- 878 SA KEK Payload (SAK) 15 879 SA TEK Payload (SAT) 16 880 Key Download (KD) 17 881 Sequence Number (SEQ) 18 882 Group Associated Policy (GAP) TBD-1 884 All multi-octet fields in GDOI payloads representing integers are 885 laid out in big endian order (also known as "most significant byte 886 first", or "network byte order"). 888 All payloads including an ISAKMP Generic Payload Header create a 889 Payload Length field that includes the length of the generic payload 890 header (Section 3.2 of [RFC2408]). 892 5.1. Identification Payload 894 The Identification Payload is defined in [RFC2408]. For the GDOI, it 895 is used to identify a group identity that will later be associated 896 with Security Associations for the group. A group identity may map 897 to a specific IPv4 or IPv6 multicast address, or may specify a more 898 general identifier, such as one that represents a set of related 899 multicast streams. 901 When used with the GDOI, the DOI Specific ID Data field MUST be set 902 to 0. 904 When used with the GDOI, the ID_KEY_ID ID Type MUST be supported by a 905 conforming implementation, and MUST specify a four (4)-octet group 906 identifier as its value. Implementations MAY also support other ID 907 Types. 909 5.2. Security Association Payload 911 The Security Association payload is defined in [RFC2408]. For the 912 GDOI, it is used by the GCKS to assert security attributes for both 913 Re-key and Data-security SAs. 915 0 1 2 3 916 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 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 918 ! Next Payload ! RESERVED ! Payload Length ! 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 ! DOI ! 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 922 ! Situation ! 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 924 ! SA Attribute Next Payload ! RESERVED2 ! 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 927 Figure 4. Security Association Payload 929 The Security Association Payload fields are defined as follows: 931 o Next Payload (1 octet) -- Identifies the next payload for the 932 GROUPKEY-PULL or the GROUPKEY-PUSH message as defined above. The 933 next payload MUST NOT be a SA Attribute Payload; it MUST be the next 934 payload following the Security Association type payload. 936 o RESERVED (1 octet) -- MUST be zero. 938 o Payload Length (2 octets) -- Is the octet length of the current 939 payload including the generic header and all TEK and KEK payloads. 941 o DOI (4 octets) -- Is the GDOI, which is value 2. 943 o Situation (4 octets) -- MUST be zero. 945 o SA Attribute Next Payload (2 octets) -- MUST be the code for an SA 946 Attribute Payload type. See Section 5.2.1 for a description of which 947 circumstances are required for each payload type to be present. 949 o RESERVED (2 octets) -- MUST be zero. 951 5.2.1. SA Attribute Payloads 953 Payloads that define specific security association attributes for the 954 KEK and/or TEKs used by the group MUST follow the SA payload. How 955 many of each payload is dependent upon the group policy. There may 956 be zero or one SAK Payload, zero or one GAP Payload, and zero or more 957 SAT Payloads, where either one SAK or SAT payload MUST be present. 958 When present, the order of the SA Attributes payloads MUST be: SAK, 959 GAP, and SATs. 961 This latitude regarding SA Attributes payloads allows various group 962 policies to be accommodated. For example if the group policy does 963 not require the use of a Re-key SA, the GCKS would not need to send 964 an SA KEK attribute to the group member since all SA updates would be 965 performed using the Registration SA. Alternatively, group policy 966 might use a Re-key SA but choose to download a KEK to the group 967 member only as part of the Registration SA. Therefore, the KEK 968 policy (in the SA KEK attribute) would not be necessary as part of 969 the Re-key SA message SA payload. 971 Specifying multiple SATs allows multiple sessions to be part of the 972 same group and multiple streams to be associated with a session 973 (e.g., video, audio, and text) but each with individual security 974 association policy. 976 A GAP payload allows for the distribution of groupwide policy, such 977 as instructions as to when to activate and de-activate SAs. 979 5.3. SA KEK payload 981 The SA KEK (SAK) payload contains security attributes for the KEK 982 method for a group and parameters specific to the GROUPKEY-PULL 983 operation. The source and destination identities describe the 984 identities used for the GROUPKEY-PULL datagram. 986 0 1 2 3 987 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 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 989 ! Next Payload ! RESERVED ! Payload Length ! 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 991 ! Protocol ! SRC ID Type ! SRC ID Port ! 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 993 !SRC ID Data Len! SRC Identification Data ~ 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 995 ! DST ID Type ! DST ID Port !DST ID Data Len! 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 997 ! DST Identification Data ~ 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 999 ! ! 1000 ~ SPI ~ 1001 ! ! 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1003 ! RESERVED2 ! 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1005 ~ KEK Attributes ~ 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1008 Figure 5. SA KEK Payload 1010 The SAK Payload fields are defined as follows: 1012 o Next Payload (1 octet) -- Identifies the next payload for the 1013 GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid next 1014 payload types for this message are a GAP Payload, SAT Payload or zero 1015 to indicate that no SA Attribute payloads follow. 1017 o RESERVED (1 octet) -- MUST be zero. 1019 o Payload Length (2 octets) -- Length of this payload, including the 1020 KEK attributes. 1022 o Protocol (1 octet) -- Value describing an IP protocol ID (e.g., 1023 UDP/TCP) [PROTOCOL-REG] for the GROUPKEY-PUSH datagram. 1025 o SRC ID Type (1 octet) -- Value describing the identity information 1026 found in the SRC Identification Data field. Defined values are 1027 specified by the IPsec Identification Type section in the IANA 1028 isakmpd-registry [ISAKMP-REG]. 1030 o SRC ID Port (2 octets) -- Value specifying a port associated with 1031 the source Id. A value of zero means that the SRC ID Port field MUST 1032 be ignored. 1034 o SRC ID Data Len (1 octet) -- Value specifying the length (in 1035 octets) of the SRC Identification Data field. 1037 o SRC Identification Data (variable length) -- Value, as indicated by 1038 the SRC ID Type. 1040 o DST ID Type (1 octet) -- Value describing the identity information 1041 found in the DST Identification Data field. Defined values are 1042 specified by the IPsec Identification Type section in the IANA 1043 isakmpd-registry [ISAKMP-REG]. 1045 o DST ID Prot (1 octet) -- Value describing an IP protocol ID (e.g., 1046 UDP/TCP) [PROTOCOL-REG]. 1048 o DST ID Port (2 octets) -- Value specifying a port associated with 1049 the source Id. 1051 o DST ID Data Len (1 octet) -- Value specifying the length (in 1052 octets) of the DST Identification Data field. 1054 o DST Identification Data (variable length) -- Value, as indicated by 1055 the DST ID Type. 1057 o SPI (16 octets) -- Security Parameter Index for the KEK. The SPI 1058 is the ISAKMP Header cookie pair where the first 8 octets become the 1059 "Initiator Cookie" field of the GROUPKEY-PUSH message ISAKMP HDR, and 1060 the second 8 octets become the "Responder Cookie" in the same HDR. 1061 As described above, these cookies are assigned by the GCKS. 1063 o RESERVED2 (4 octets) -- MUST be zero. These octets represent 1064 fields previously defined but no longer used by GDOI. 1066 o KEK Attributes -- Contains KEK policy attributes associated with 1067 the group. The following attributes may be present in a SAK Payload. 1068 The attributes must follow the format defined in ISAKMP (Section 3.3 1069 of [RFC2408]). In the table, attributes that are defined as TV are 1070 marked as Basic (B); attributes that are defined as TLV are marked as 1071 Variable (V). 1073 ID Class Value Type 1074 -------- ----- ---- 1075 RESERVED 0 1076 KEK_MANAGEMENT_ALGORITHM 1 B 1077 KEK_ALGORITHM 2 B 1078 KEK_KEY_LENGTH 3 B 1079 KEK_KEY_LIFETIME 4 V 1080 SIG_HASH_ALGORITHM 5 B 1081 SIG_ALGORITHM 6 B 1082 SIG_KEY_LENGTH 7 B 1083 RESERVED 8 B 1084 Standards Action 9-127 1085 Private Use 128-255 1086 Unassigned 256-32767 1088 The KEK_ALGORITHM, SIG_ALGORITHM attributes MUST be included; others 1089 are OPTIONAL, and included depending on group policy. The 1090 KEK_MANAGEMENT_ALGORITHM attribute MUST NOT be included in a 1091 GROUPKEY-PULL message, and MUST be ignored if present. 1093 5.3.1. KEK_MANAGEMENT_ALGORITHM 1095 The KEK_MANAGEMENT_ALGORITHM class specifies the group KEK management 1096 algorithm used to provide forward or backward access control (i.e., 1097 used to exclude group members). Defined values are specified in the 1098 following table. 1100 KEK Management Type Value 1101 ------------------- ----- 1102 RESERVED 0 1103 LKH 1 1104 Standards Action 2-127 1105 Private Use 128-255 1107 5.3.1.1. LKH 1109 This type indicates the group management method described in Section 1110 5.4 of [RFC2627]. A general discussion of LKH operations can also be 1111 found in Section 6.3 of Multicast and Group Security [HD03] 1113 5.3.2. KEK_ALGORITHM 1115 The KEK_ALGORITHM class specifies the encryption algorithm in which 1116 the KEK is used to provide confidentiality for the GROUPKEY-PUSH 1117 message. Defined values are specified in the following table. A 1118 GDOI implementation MUST abort if it encounters an attribute or 1119 capability that it does not understand. 1121 Algorithm Type Value 1122 -------------- ----- 1123 RESERVED 0 1124 KEK_ALG_DES 1 1125 KEK_ALG_3DES 2 1126 KEK_ALG_AES 3 1127 Standards Action 4-127 1128 Private Use 128-255 1129 Unassigned 256-32767 1131 If a KEK_MANAGEMENT_ALGORITHM is defined which defines multiple keys 1132 (e.g., LKH), and if the management algorithm does not specify the 1133 algorithm for those keys, then the algorithm defined by the 1134 KEK_ALGORITHM attribute MUST be used for all keys which are included 1135 as part of the management. 1137 5.3.2.1. KEK_ALG_DES 1139 This type specifies DES using the Cipher Block Chaining (CBC) mode as 1140 described in [FIPS81]. 1142 5.3.2.2. KEK_ALG_3DES 1144 This type specifies 3DES using three independent keys as described in 1145 "Keying Option 1" in [FIPS46-3]. 1147 5.3.2.3. KEK_ALG_AES 1149 This type specifies AES as described in [FIPS197]. The mode of 1150 operation for AES is Cipher Block Chaining (CBC) as defined in 1151 [SP.800-38A]. 1153 5.3.3. KEK_KEY_LENGTH 1155 The KEK_KEY_LENGTH class specifies the KEK Algorithm key length (in 1156 bits). The Group Controller/Key Server (GCKS) adds the 1157 KEK_KEY_LENGTH attribute to the SA payload when distributing KEK 1158 policy to group members. The group member verifies whether or not it 1159 has the capability of using a cipher key of that size. If the cipher 1160 definition includes a fixed key length (e.g., KEK_ALG_3DES), the 1161 group member can make its decision solely using the KEK_ALGORITHM 1162 attribute and does not need the KEK_KEY_LENGTH attribute. Sending 1163 the KEK_KEY_LENGTH attribute in the SA payload is OPTIONAL if the KEK 1164 cipher has a fixed key length. Also, note that the KEK_KEY_LEN 1165 includes only the actual length of the cipher key (the IV length is 1166 not included in this attribute). 1168 5.3.4. KEK_KEY_LIFETIME 1170 The KEK_KEY_LIFETIME class specifies the maximum time for which the 1171 KEK is valid. The GCKS may refresh the KEK at any time before the 1172 end of the valid period. The value is a four (4) octet number 1173 defining a valid time period in seconds. 1175 5.3.5. SIG_HASH_ALGORITHM 1177 SIG_HASH_ALGORITHM specifies the SIG payload hash algorithm. The 1178 following table defines the algorithms for SIG_HASH_ALGORITHM. 1180 Algorithm Type Value 1181 -------------- ----- 1182 RESERVED 0 1183 SIG_HASH_MD5 1 1184 SIG_HASH_SHA1 2 1185 SIG_HASH_SHA256 TBD-2 1186 SIG_HASH_SHA384 TBD-3 1187 SIG_HASH_SHA512 TBD-4 1188 Standards Action 3-127 1189 Private Use 128-255 1190 Unassigned 256-32767 1191 The SHA hash algorithms are defined in the Secure Hash 1192 Standard[FIPS180-3.2008]. 1194 If the SIG_ALGORITHM is SIG_ALG_ECDSA-256, SIG_ALG_ECDSA-384, or 1195 SIG_ALG_ECDSA-521 the hash algorithm is implicit in the definition, 1196 and SIG_HASH_ALGORITHM is OPTIONAL in a SAK Payload. 1198 5.3.6. SIG_ALGORITHM 1200 The SIG_ALGORITHM class specifies the SIG payload signature 1201 algorithm. Defined values are specified in the following table. 1203 Algorithm Type Value 1204 -------------- ----- 1205 RESERVED 0 1206 SIG_ALG_RSA 1 1207 SIG_ALG_DSS 2 1208 SIG_ALG_ECDSS 3 1209 SIG_ALG_ECDSA-256 TBD-7 1210 SIG_ALG_ECDSA-384 TBD-8 1211 SIG_ALG_ECDSA-521 TBD-9 1212 Standards Action 4-127 1213 Private Use 128-255 1214 Unassigned 256-32767 1216 5.3.6.1. SIG_ALG_RSA 1218 This algorithm specifies the RSA digital signature algorithm using 1219 the EMSA-PKCS1-v1_5 encoding method, as described in [RFC3447]. 1221 5.3.6.2. SIG_ALG_DSS 1223 This algorithm specifies the DSS digital signature algorithm as 1224 described in Section 4 of [FIPS186-3]. 1226 5.3.6.3. SIG_ALG_ECDSS 1228 This algorithm specifies the Elliptic Curve digital signature 1229 algorithm as described in Section 5 of [FIPS186-3]. This definition 1230 is deprecated in favor of the SIG_ALG_ECDSA family of algorithms. 1232 5.3.6.4. SIG_ALG_ECDSA-256 1234 This algorithm specifies the 256-bit Random ECP Group, as described 1235 in [RFC5903]. The format of the signature in the SIG payload MUST be 1236 as specified in [RFC4754]. 1238 5.3.6.5. SIG_ALG_ECDSA-384 1240 This algorithm specifies the 384-bit Random ECP Group, as described 1241 in [RFC5903]. The format of the signature in the SIG payload MUST be 1242 as specified in [RFC4754]. 1244 5.3.6.6. SIG_ALG_ECDSA-521 1246 This algorithm specifies the 521-bit Random ECP Group, as described 1247 in [RFC5903]. The format of the signature in the SIG payload MUST be 1248 as specified in [RFC4754]. 1250 5.3.7. SIG_KEY_LENGTH 1252 The SIG_KEY_LENGTH class specifies the length of the SIG payload key 1253 in bits. 1255 5.4. Group Associated Policy 1257 A GCKS may have group-specific policy that is not distributed in an 1258 SA TEK or SA KEK. Some of this policy is relevant to all group 1259 members, and some is sender-specific policy for a particular group 1260 member. The former can be distributed in either a GROUPKEY-PULL or 1261 GROUPKEY-PUSH exchange, whereas the latter MUST only be sent in a 1262 GROUPKEY-PULL exchange. Additionally, a group member sometimes has 1263 the need to make policy requests for resources of the GCKS in a 1264 GROUPKEY-PULL exchange. GDOI distributes this associated group 1265 policy and policy requests in the Group Associated Policy (GAP) 1266 payload. 1268 The GAP payload can be distributed by the GCKS as part of the SA 1269 payload. It follows any SA KEK payload, and is placed before any SA 1270 TEK payloads. In the case that group policy does not include an SA 1271 KEK, the SA Attribute Next Payload field in the SA payload MAY 1272 indicate the GAP payload. 1274 The GAP payload can be optionally included by a group member in 1275 message 3 of the GROUPKEY-PULL exchange in order to make policy 1276 requests. 1278 The GAP payload is defined as follows: 1280 0 1 2 3 1281 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 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1283 ! Next Payload ! RESERVED ! Payload Length ! 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1285 ! Group Associated Policy Attributes ~ 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1288 Figure 6. GAP Payload 1290 The GAP payload fields are defined as follows: 1292 o Next Payload (1 octet) -- Identifies the next payload present in 1293 the GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid 1294 next payload type for this message is an SA TEK or zero to 1295 indicate there are no more security association attributes. 1297 o RESERVED (1 octet) -- MUST be zero. 1299 o Payload Length (2 octets) -- Length of this payload, including the 1300 GAP header and Attributes. 1302 o Group Associated Policy Attributes (variable) -- Contains 1303 attributes following the format defined in Section 3.3 of 1304 [RFC2408]. In the table, attributes that are defined as TV are 1305 marked as Basic (B); attributes that are defined as TLV are marked 1306 as Variable (V). 1308 Attribute Type Value Type 1309 -------------- ----- ---- 1310 RESERVED 0 1311 ACTIVATION_TIME_DELAY 1 B 1312 DEACTIVATION_TIME_DELAY 2 B 1313 SENDER_ID_REQUEST 3 B 1314 Standards Action 4-127 1315 Private Use 128-255 1316 Unassigned 256-32767 1318 Several group associated policy attributes are defined in this memo. 1319 An GDOI implementation MUST abort if it encounters an attribute or 1320 capability that it does not understand. The values for these 1321 attributes are included in the IANA Considerations section of this 1322 memo. 1324 5.4.1. ACTIVATION_TIME_DELAY/DEACTIVATION_TIME_DELAY 1326 Section 4.2.1 of [RFC5374] specifies a key rollover method that 1327 requires two values be given it from the group key management 1328 protocol. The ACTIVATION_TIME_DELAY attribute allows a GCKS to set 1329 the Activation Time Delay (ATD) for SAs generated from TEKs. The ATD 1330 defines how long after receiving new SAs that they are to be 1331 activated by the GM. The ATD value is in seconds. 1333 The DEACTIVATION_TIME_DELAY allows the GCKS to set the Deactivation 1334 Time Delay (DTD) for previously distributed SAs. The DTD defines how 1335 long after receiving new SAs that it SHOULD deactivate SAs that are 1336 destroyed by the re-key event. The value is in seconds. 1338 The values of ATD and DTD are independent. However, the most 1339 effective policy will have the DTD value to be the larger value as 1340 this allows new SAs to be activated before older SAs are deactivated. 1341 Such a policy ensures that protected group traffic will always flow 1342 without interruption. 1344 5.4.2. SENDER_ID_REQUEST 1346 The SENDER_ID_REQUEST attribute is used by a group member to request 1347 SIDs during the GROUPKEY-PULL message, and includes a count of how 1348 many SID values it desires. 1350 5.5. SA TEK Payload 1352 The SA TEK (SAT) payload contains security attributes for a single 1353 TEK associated with a group. 1355 0 1 2 3 1356 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 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1358 ! Next Payload ! RESERVED ! Payload Length ! 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1360 ! Protocol-ID ! TEK Protocol-Specific Payload ~ 1361 +-+-+-+-+-+-+-+-+ ~ 1362 ~ ~ 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1365 Figure 7. SA TEK Payload 1367 The SAT Payload fields are defined as follows: 1369 o Next Payload (1 octet) -- Identifies the next payload for the 1370 GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid next 1371 payload types for this message are another SAT Payload or zero to 1372 indicate there are no more security association attributes. 1374 o RESERVED (1 octet) -- MUST be zero. 1376 o Payload Length (2 octets) -- Length of this payload, including the 1377 TEK Protocol-Specific Payload. 1379 o Protocol-ID (1 octet) -- Value specifying the Security Protocol. 1380 The following table defines values for the Security Protocol 1381 Protocol ID Value 1382 ----------- ----- 1383 RESERVED 0 1384 GDOI_PROTO_IPSEC_ESP 1 1385 GDOI_PROTO_IPSEC_AH TBD-5 1386 Standards Action 3-127 1387 Private Use 128-255 1389 o TEK Protocol-Specific Payload (variable) -- Payload which describes 1390 the attributes specific for the Protocol-ID. 1392 5.5.1. GDOI_PROTO_IPSEC_ESP/GDOI_PROTO_IPSEC_AH 1394 The TEK Protocol-Specific payload for ESP and AH is as follows: 1396 0 1 2 3 1397 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 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1399 ! Protocol ! SRC ID Type ! SRC ID Port ! 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1401 !SRC ID Data Len! SRC Identification Data ~ 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1403 ! DST ID Type ! DST ID Port !DST ID Data Len! 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1405 ! DST Identification Data ~ 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1407 ! Transform ID ! SPI ! 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1409 ! SPI ! RFC 2407 SA Attributes ~ 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1412 Figure 8. ESP/AH TEK Payload 1414 The SAT Payload fields are defined as follows: 1416 o Protocol (1 octet) -- Value describing an IP protocol ID (e.g., 1417 UDP/TCP) [PROTOCOL-REG]. A value of zero means that the Protocol 1418 field MUST be ignored. 1420 o SRC ID Type (1 octet) -- Value describing the identity information 1421 found in the SRC Identification Data field. Defined values are 1422 specified by the IPsec Identification Type section in the IANA 1423 isakmpd-registry [ISAKMP-REG]. 1425 o SRC ID Port (2 octets) -- Value specifying a port associated with 1426 the source Id. A value of zero means that the SRC ID Port field MUST 1427 be ignored. 1429 o SRC ID Data Len (1 octet) -- Value specifying the length (in 1430 octets) of the SRC Identification Data field. 1432 o SRC Identification Data (variable length) -- Value, as indicated by 1433 the SRC ID Type. Set to three octets of zero for multiple-source 1434 multicast groups that use a common TEK for all senders. 1436 o DST ID Type (1 octet) -- Value describing the identity information 1437 found in the DST Identification Data field. Defined values are 1438 specified by the IPsec Identification Type section in the IANA 1439 isakmpd-registry [ISAKMP-REG]. 1441 o DST ID Prot (1 octet) -- Value describing an IP protocol ID (e.g., 1442 UDP/TCP) [PROTOCOL-REG]. A value of zero means that the DST Id Prot 1443 field MUST be ignored. 1445 o DST ID Port (2 octets) -- Value specifying a port associated with 1446 the source Id. A value of zero means that the DST ID Port field MUST 1447 be ignored. 1449 o DST ID Data Len (1 octet) -- Value specifying the length (in 1450 octets) of the DST Identification Data field. 1452 o DST Identification Data (variable length) -- Value, as indicated by 1453 the DST ID Type. 1455 o Transform ID (1 octet) -- Value specifying which ESP or AH 1456 transform is to be used. The list of valid values is defined in the 1457 IPsec ESP or IPsec AH Transform Identifiers section of the IANA 1458 isakmpd-registry [ISAKMP-REG]. 1460 o SPI (4 octets) -- Security Parameter Index for ESP. 1462 o RFC 2407 Attributes -- ESP and AH Attributes from Section 4.5 of 1463 [RFC2407]. The GDOI supports all IPsec DOI SA Attributes for 1464 GDOI_PROTO_IPSEC_ESP and GDOI_PROTO_IPSEC_AH excluding the Group 1465 Description (section 4.5 of [RFC2407]), which MUST NOT be sent by a 1466 GDOI implementation and is ignored by a GDOI implementation if 1467 received. The following attributes MUST be supported by an 1468 implementation supporting ESP and AH: SA Life Type, SA Life Duration, 1469 Encapsulation Mode. An implementation supporting ESP MUST also 1470 support the Authentication Algorithm attribute if the ESP transform 1471 includes authentication. The Authentication Algorithm attribute of 1472 the IPsec DOI is group authentication in GDOI. 1474 5.5.1.1. New IPsec Security Association Attributes 1476 The Multicast Extensions to the Security Architecture for the 1477 Internet Protocol (RFC 5374) introduces new requirements for a group 1478 key management system distributing IPsec policy. It also defines new 1479 attributes as part of the Group Security Policy Database (GSPD). 1480 These attributes describe policy that a group key management system 1481 must convey to a group member in order to support those extensions. 1482 The GDOI SA TEK payload distributes IPsec policy using IPsec security 1483 association attributes defined in [ISAKMP-REG]. This section defines 1484 how GDOI can convey the new attributes as IPsec Security Association 1485 Attributes. 1487 5.5.1.1.1. Address Preservation 1489 Applications use the extensions in [RFC5374] to copy the IP addresses 1490 into the outer IP header when encapsulating an IP packet as an IPsec 1491 tunnel mode packet. This allows an IP multicast packet to continue 1492 to be routed as a IP multicast packet. This attribute also provides 1493 the necessary policy so that the GDOI group member can appropriately 1494 set up the GSPD. The following table defines values for the Address 1495 Preservation attribute. 1497 Address Preservation Type Value 1498 ------------------------- ----- 1499 Reserved 0 1500 None 1 1501 Source-Only 2 1502 Destination-Only 3 1503 Source-And-Destination 4 1504 Standards Action 5-61439 1505 Private Use 61440-65535 1507 Depending on group policy, several address preservation methods are 1508 possible: no address preservation ("None"), preservation of the 1509 original source address ("Source-Only"), preservation of the original 1510 destination address ("Destination-Only"), or both addresses ("Source- 1511 And-Destination"). If this attribute is not included in a GDOI SA 1512 TEK payload provided by a GCKS, then Source-And-Destination address 1513 preservation has been defined for the SA TEK. 1515 5.5.1.1.2. SA Direction 1517 Depending on group policy, an IPsec SA created from an SA TEK payload 1518 is defined to be in the sending and/or receiving direction. The 1519 following table defines values for the SA Direction attribute. 1521 Name Value 1522 ---- ----- 1523 Reserved 0 1524 Sender-Only 1 1525 Receiver-Only 2 1526 Symmetric 3 1527 Standards Action 4-61439 1528 Private Use 61440-65535 1530 SA TEK policy used by multiple senders MUST be installed in both the 1531 sending and receiving direction ("Symmetric"), whereas SA TEK for a 1532 single sender SHOULD be installed in the receiving direction by 1533 receivers ("Receiver-Only") and in the sending direction by the 1534 sender ("Sender-Only"). 1536 An SA TEK payload that does not include the SA Direction attribute is 1537 treated as a Symmetric IPsec SA. Note that Symmetric is the only 1538 value that can be meaningfully described for an SA TEK distributed in 1539 an GROUPKEY-PUSH message. Alternatively, Receiver-Only could be 1540 distributed, but group senders would need to be configured to not 1541 receive GROUPKEY-PUSH messages in order to retain their role. 1543 5.5.2. Other Security Protocols 1545 Besides ESP and AH, GDOI should serve to establish SAs for secure 1546 groups needed by other Security Protocols that operate at the 1547 transport, application, and internetwork layers. These other 1548 Security Protocols, however, are in the process of being developed or 1549 do not yet exist. 1551 The following information needs to be provided for a Security 1552 Protocol to the GDOI. 1554 o The Protocol-ID for the particular Security Protocol 1556 o The SPI Size 1558 o The method of SPI generation 1560 o The transforms, attributes and keys needed by the Security 1561 Protocol 1563 All Security Protocols MUST provide the information in the bulleted 1564 list above to guide the GDOI specification for that protocol. 1565 Definitions for the support of those Security Protocols in GDOI will 1566 be specified in separate documents. 1568 A Security Protocol MAY protect traffic at any level of the network 1569 stack. However, in all cases applications of the Security Protocol 1570 MUST protect traffic which MAY be shared by more than two entities. 1572 5.6. Key Download Payload 1574 The Key Download Payload contains group keys for the group specified 1575 in the SA Payload. These key download payloads can have several 1576 security attributes applied to them based upon the security policy of 1577 the group as defined by the associated SA Payload. 1579 0 1 2 3 1580 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 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1582 ! Next Payload ! RESERVED ! Payload Length ! 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1584 ! Number of Key Packets ! RESERVED2 ! 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1586 ~ Key Packets ~ 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1589 Figure 9. Key Download Payload 1591 The Key Download Payload fields are defined as follows: 1593 o Next Payload (1 octet) -- Identifier for the payload type of the 1594 next payload in the message. If the current payload is the last in 1595 the message, then this field will be zero. 1597 o RESERVED (1 octet) -- Unused, set to zero. 1599 o Payload Length (2 octets) -- Length in octets of the current 1600 payload, including the generic payload header. 1602 o Number of Key Packets (2 octets) -- Contains the total number of 1603 key packets being passed in this data block. 1605 o Key Packets (variable) -- Several types of key packets are defined. 1606 Each Key Packet has the following format. 1608 0 1 2 3 1609 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 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1611 ! KD Type ! RESERVED ! KD Length ! 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1613 ! SPI Size ! SPI (variable) ~ 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1615 ~ Key Packet Attributes ~ 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1618 Figure 10. Key Packet 1620 o Key Download (KD) Type (1 octet) -- Identifier for the Key Data 1621 field of this Key Packet. 1623 Key Download Type Value 1624 ----------------- ----- 1625 RESERVED 0 1626 TEK 1 1627 KEK 2 1628 LKH 3 1629 SID TBD-6 1630 Standards Action 4-127 1631 Private Use 128-255 1633 "KEK" is a single key whereas LKH is an array of key-encrypting keys. 1635 o RESERVED (1 octet) -- Unused, set to zero. 1637 o Key Download Length (2 octets) -- Length in octets of the Key 1638 Packet data, including the Key Packet header. 1640 o SPI Size (1 octet) -- Value specifying the length in octets of the 1641 SPI as defined by the Protocol-Id. 1643 o SPI (variable length) -- Security Parameter Index which matches a 1644 SPI previously sent in an SAK or SAT Payload. 1646 o Key Packet Attributes (variable length) -- Contains Key 1647 information. The format of this field is specific to the value of 1648 the KD Type field. The following sections describe the format of 1649 each KD Type. 1651 5.6.1. TEK Download Type 1653 The following attributes may be present in a TEK Download Type. 1654 Exactly one attribute matching each type sent in the SAT payload MUST 1655 be present. The attributes must follow the format defined in ISAKMP 1656 (Section 3.3 of [RFC2408]). In the table, attributes defined as TV 1657 are marked as Basic (B); attributes defined as TLV are marked as 1658 Variable (V). 1660 TEK Class Value Type 1661 --------- ----- ---- 1662 RESERVED 0 1663 TEK_ALGORITHM_KEY 1 V 1664 TEK_INTEGRITY_KEY 2 V 1665 TEK_SOURCE_AUTH_KEY 3 V 1666 Standards Action 4-127 1667 Private Use 128-255 1668 Unassigned 256-32767 1670 If no TEK key packets are included in a Registration KD payload, the 1671 group member can expect to receive the TEK as part of a Re-key SA. 1672 At least one TEK must be included in each Re-key KD payload. 1673 Multiple TEKs may be included if multiple streams associated with the 1674 SA are to be rekeyed. 1676 When an algorithm specification specifies the format of the keying 1677 material, the value transported in the KD payload for that key is 1678 passed according to that specification. The keying material may 1679 contain information besides a key. For example, The Use of Galois/ 1680 Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) 1681 [RFC4106] defines a salt value as part of KEYMAT. 1683 5.6.1.1. TEK_ALGORITHM_KEY 1685 The TEK_ALGORITHM_KEY class declares that the encryption key for this 1686 SPI is contained as the Key Packet Attribute. The encryption 1687 algorithm that will use this key was specified in the SAT payload. 1689 In the case that the algorithm requires multiple keys (e.g., 3DES), 1690 all keys will be included in one attribute. 1692 DES keys will consist of 64 bits (the 56 key bits with parity bit). 1693 Triple DES keys will be specified as a single 192 bit attribute 1694 (including parity bits) in the order that the keys are to be used for 1695 encryption (e.g., DES_KEY1, DES_KEY2, DES_KEY3). 1697 5.6.1.2. TEK_INTEGRITY_KEY 1699 The TEK_INTEGRITY_KEY class declares that the integrity key for this 1700 SPI is contained as the Key Packet Attribute. The integrity 1701 algorithm that will use this key was specified in the SAT payload. 1703 Thus, GDOI assumes that both the symmetric encryption and integrity 1704 keys are pushed to the GM. HMAC-SHA1 keys will consist of 160 bits 1705 [RFC2404], HMAC-MD5 keys will consist of 128 bits [RFC2403]. HMAC- 1706 SHA2 and AES-GMAC keys will have a key length equal to the output 1707 length of the hash functions [RFC4868][RFC4543]. 1709 5.6.1.3. TEK_SOURCE_AUTH_KEY 1711 The TEK_SOURCE_AUTH_KEY class declares that the source authentication 1712 key for this SPI is contained in the Key Packet Attribute. The 1713 source authentication algorithm that will use this key was specified 1714 in the SAT payload. 1716 5.6.2. KEK Download Type 1718 The following attributes may be present in a KEK Download Type. 1719 Exactly one attribute matching each type sent in the SAK payload MUST 1720 be present. The attributes MUST follow the format defined in ISAKMP 1721 (Section 3.3 of [RFC2408]). In the table, attributes defined as TV 1722 are marked as Basic (B); attributes defined as TLV are marked as 1723 Variable (V). 1725 KEK Class Value Type 1726 --------- ----- ---- 1727 RESERVED 0 1728 KEK_ALGORITHM_KEY 1 V 1729 SIG_ALGORITHM_KEY 2 V 1730 Standards Action 3-127 1731 Private Use 128-255 1732 Unassigned 256-32767 1734 If the KEK key packet is included, there MUST be only one present in 1735 the KD payload. 1737 5.6.2.1. KEK_ALGORITHM_KEY 1739 The KEK_ALGORITHM_KEY class declares the encryption key for this SPI 1740 is contained in the Key Packet Attribute. The encryption algorithm 1741 that will use this key was specified in the SAK payload. 1743 If the mode of operation for the algorithm requires an IV, an 1744 explicit IV MUST be included in the KEK_ALGORITHM_KEY before the 1745 actual key. 1747 5.6.2.2. SIG_ALGORITHM_KEY 1749 The SIG_ALGORITHM_KEY class declares that the public key for this SPI 1750 is contained in the Key Packet Attribute, which may be useful when no 1751 public key infrastructure is available. The signature algorithm that 1752 will use this key was specified in the SAK payload. 1754 5.6.3. LKH Download Type 1756 The LKH key packet is comprised of attributes representing different 1757 nodes in the LKH key tree. 1759 The following attributes are used to pass an LKH KEK array in the KD 1760 payload. The attributes MUST follow the format defined in ISAKMP 1761 (Section 3.3 of [RFC2408]). In the table, attributes defined as TV 1762 are marked as Basic (B); attributes defined as TLV are marked as 1763 Variable (V). 1765 KEK Class Value Type 1766 --------- ----- ---- 1767 RESERVED 0 1768 LKH_DOWNLOAD_ARRAY 1 V 1769 LKH_UPDATE_ARRAY 2 V 1770 SIG_ALGORITHM_KEY 3 V 1771 Standards Action 4-127 1772 Private Use 128-255 1773 Unassigned 256-32767 1775 If an LKH key packet is included in the KD payload, there MUST be 1776 only one present. 1778 5.6.3.1. LKH_DOWNLOAD_ARRAY 1780 This attribute is used to download a set of keys to a group member. 1781 It MUST NOT be included in a GROUPKEY-PUSH message KD payload if the 1782 GROUPKEY-PUSH is sent to more than the group member. If an 1783 LKH_DOWNLOAD_ARRAY attribute is included in a KD payload, there MUST 1784 be only one present. 1786 This attribute consists of a header block, followed by one or more 1787 LKH keys. 1789 0 1 2 3 1790 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 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 ! LKH Version ! # of LKH Keys ! RESERVED ! 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 ! LKH Keys ! 1795 ~ ~ 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 Figure 11. LKH Download Array 1800 The KEK_LKH attribute fields are defined as follows: 1802 o LKH version (1 octet) -- Version of the LKH data format. Must be 1803 one. 1805 o Number of LKH Keys (2 octets) -- This value is the number of 1806 distinct LKH keys in this sequence. 1808 o RESERVED (1 octet) -- Unused, set to zero. Each LKH Key is defined 1809 as follows: 1811 0 1 2 3 1812 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 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 ! LKH ID ! Key Type ! RESERVED ! 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1816 ! Key Creation Date ! 1817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1818 ! Key expiration Date ! 1819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1820 ! Key Handle ! 1821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1822 ! ! 1823 ~ Key Data ~ 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1826 Figure 12. LKH Key 1828 o LKH ID (2 octets) -- Identity of the LKH node. A GCKS is free to 1829 choose the ID in an implementation-specific manner (e.g., the 1830 position of this key in a binary tree structure used by LKH). 1832 o Key Type (1 octet) -- Encryption algorithm for which this key data 1833 is to be used. This value is specified in Section 5.3.3. 1835 o RESERVED (1 octet) -- Unused, set to zero. 1837 o Key Creation Date (4 octets) -- Unsigned time value defining a 1838 valid time period in seconds representing the number of seconds since 1839 0 hours, 0 minutes, 0 seconds, January 1, 1970, Coordinated Universal 1840 Time (UTC), without including leap seconds. [RFC5905]. This is the 1841 time when this key data was originally generated. A time value of 1842 zero indicates that there is no time before which this key is not 1843 valid. 1845 o Key Expiration Date (4 octets) -- Unsigned time value defining a 1846 valid time period in seconds representing the number of seconds since 1847 0 hours, 0 minutes, 0 seconds, January 1, 1970, Coordinated Universal 1848 Time (UTC), without including leap seconds. [RFC5905]. This is the 1849 time when this key is no longer valid for use. A time value of zero 1850 indicates that this key does not have an expiration time. 1852 o Key Handle (4 octets) -- Value assigned by the GCKS to uniquely 1853 identify a key within an LKH ID. Each new key distributed by the 1854 GCKS for this node will have a key handle identity distinct from 1855 previous or successive key handles specified for this node. 1857 o Key Data (variable length) -- Key data, which is dependent on the 1858 Key Type algorithm for its format. If the mode of operation for the 1859 algorithm requires an IV, an explicit IV MUST be included in the Key 1860 Data field prepended to the actual key. 1862 The Key Creation Date and Key expiration Dates MAY be zero. This is 1863 necessary in the case where time synchronization within the group is 1864 not possible. 1866 The first LKH Key structure in an LKH_DOWNLOAD_ARRAY attribute 1867 contains the Leaf identifier and key for the group member. The rest 1868 of the LKH Key structures contain keys along the path of the key tree 1869 in order from the leaf, culminating in the group KEK. 1871 5.6.3.2. LKH_UPDATE_ARRAY 1873 This attribute is used to update the keys for a group. It is most 1874 likely to be included in a GROUPKEY-PUSH message KD payload to rekey 1875 the entire group. This attribute consists of a header block, 1876 followed by one or more LKH keys, as defined in the previous section. 1878 There may be any number of UPDATE_ARRAY attributes included in a KD 1879 payload. 1881 0 1 2 3 1882 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 1883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1884 ! LKH Version ! # of LKH Keys ! RESERVED ! 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1886 ! LKH ID ! RESERVED2 ! 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 ! Key Handle ! 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 ! LKH Keys ! 1891 ~ ~ 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 Figure 13. LKH Update Array 1896 o LKH version (1 octet) -- Version of the LKH data format. Must be 1897 one. 1899 o Number of LKH Keys (2 octets) -- Number of distinct LKH keys in 1900 this sequence. 1902 o RESERVED (1 octet) -- Unused, set to zero. 1904 o LKH ID (2 octets) -- Node identifier associated with the key used 1905 to encrypt the first LKH Key. 1907 o RESERVED2 (2 octets) -- Unused, set to zero. 1909 o Key Handle (4 octets) -- Value assigned by the GCKS to uniquely 1910 identify the key within the LKH ID used to encrypt the first LKH Key. 1912 The LKH Keys are as defined in the previous section. The LKH Key 1913 structures contain keys along the path of the key tree in order from 1914 the LKH ID found in the LKH_UPDATE_ARRAY header, culminating in the 1915 group KEK. The Key Data field of each LKH Key is encrypted with the 1916 LKH key preceding it in the LKH_UPDATE_ARRAY attribute. The first 1917 LKH Key is encrypted under the key defined by the LKH ID and Key 1918 Handle found in the LKH_UPDATE_ARRAY header. 1920 5.6.3.3. SIG_ALGORITHM_KEY 1922 The SIG_ALGORITHM_KEY class declares that the public key for this SPI 1923 is contained in the Key Packet Attribute, which may be useful when no 1924 public key infrastructure is available. The signature algorithm that 1925 will use this key was specified in the SAK payload. 1927 5.6.4. SID Download Type 1929 This attribute is used to download one or more Sender-ID (SID) values 1930 for the exclusive use of a group member. 1932 The SID Download Type does not require a SPI. When the KD Type is 1933 SID, the SPI Size field MUST be zero, and the SPI field is omitted. 1935 SID Class Value Type 1936 --------- ----- ---- 1937 RESERVED 0 1938 NUMBER_OF_SID_BITS 1 B 1939 SID_VALUE 2 V 1940 Standards Action 3-128 1941 Private Use 129-255 1942 Unassigned 256-32767 1944 Because a SID value is intended for a single group member, the SID 1945 Download type MUST NOT be distributed in a GROUPKEY-PUSH message 1946 distributed to multiple group members. 1948 5.6.4.1. NUMBER_OF_SID_BITS 1950 The NUMBER_OF_SID_BITS class declares how many bits of the cipher 1951 nonce in which to represent a SID value. This value is applied to 1952 each SID value distributed in the SID Download. 1954 5.6.4.2. SID_VALUE 1956 The SID_VALUE class declares a single SID value for the exclusive use 1957 of the a group member. Multiple SID_VALUE attributes MAY be included 1958 in a SID Download. 1960 5.6.4.3. Group Member Semantics 1962 The SID_VALUE attribute value distributed to the group member MUST be 1963 used by that group member as the SID field portion of the IV for all 1964 Data-Security SAs including a counter-based mode of operation 1965 distributed by the GCKS as a part of this group. 1967 When the Sender-Specific IV (SSIV) field for any Data-Security SA is 1968 exhausted, the group member MUST no longer act as a sender on that SA 1969 using its active SID. The group member SHOULD re-register, at which 1970 time the GCKS will issue a new SID to the group member, along with 1971 either the same Data-Security SAs or replacement ones. The new SID 1972 replaces the existing SID used by this group member, and also resets 1973 the SSIV value to its starting value. A group member MAY re-register 1974 prior to the actual exhaustion of the SSIV field to avoid dropping 1975 data packets due to the exhaustion of available SSIV values combined 1976 with a particular SID value. 1978 GROUPKEY-PUSH message may include Data-Security SAs that are 1979 distributed to the group member for the first time. An SID 1980 previously issued to the receiving group member is used with counter- 1981 based mode of operation Data-Security SAs on which the group member 1982 acts as a sender. Because this Data-Security SA has not previously 1983 been used for transmission, the SSIV field should be set to its 1984 starting value. 1986 5.6.4.4. GCKS Semantics 1988 If any KD payload includes keying material that is associated with a 1989 counter-mode of operation, an SID Download Type KD payload containing 1990 at least one SID_VALUE attribute MUST be included. 1992 The GCKS MUST NOT send the SID Download Type KD payload as part of a 1993 GROUPKEY-PUSH message, because distributing the same sender-specific 1994 policy to more than one group member will reduce the security of the 1995 group. 1997 5.7. Sequence Number Payload 1999 The Sequence Number Payload (SEQ) provides an anti-replay protection 2000 for GROUPKEY-PUSH messages. Its use is similar to the Sequence 2001 Number field defined in the IPsec ESP protocol [RFC4303]. 2003 0 1 2 3 2004 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 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2006 ! Next Payload ! RESERVED ! Payload Length ! 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2008 ! Sequence Number ! 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2011 Figure 14. Sequence Number Payload 2013 The Sequence Number Payload fields are defined as follows: 2015 o Next Payload (1 octet) -- Identifier for the payload type of the 2016 next payload in the message. If the current payload is the last in 2017 the message, then this field will be zero. 2019 o RESERVED (1 octet) -- Unused, set to zero. 2021 o Payload Length (2 octets) -- Length in octets of the current 2022 payload, including the generic payload header. MUST be a value of 8. 2024 o Sequence Number (4 octets) -- This field contains a monotonically 2025 increasing counter value for the group. It is initialized to zero by 2026 the GCKS, and incremented in each subsequently-transmitted message. 2027 Thus the first packet sent for a given Rekey SA will have a Sequence 2028 Number of 1. The GDOI implementation keeps a sequence counter as an 2029 attribute for the Rekey SA and increments the counter upon receipt of 2030 a GROUPKEY-PUSH message. The current value of the sequence number 2031 MUST be transmitted to group members as a part of the Registration SA 2032 payload. 2034 5.8. Nonce 2036 The data portion of the Nonce payload (i.e., Ni_b and Nr_b included 2037 in the HASHs) MUST be a value between 8 and 128 octets. 2039 5.9. Delete 2041 There are times the GCKS may want to signal to receivers to delete 2042 SAs, for example at the end of a broadcast. Deletion of keys may be 2043 accomplished by sending an ISAKMP Delete payload (Section 3.15 of 2044 [RFC2408]) as part of a GDOI GROUPKEY-PUSH message. 2046 One or more Delete payloads MAY be placed following the SEQ payload 2047 in a GROUPKEY-PUSH message. If a GCKS has no further SAs to send to 2048 group members, the SA and KD payloads MUST be omitted from the 2049 message. 2051 The following fields of the Delete Payload are further defined as 2052 follows: 2054 o The Domain of Interpretation field contains the GDOI DOI. 2056 o The Protocol-Id field contains TEK protocol id values defined in 2057 Section 5.5 of this document. To delete a KEK SA, the value of zero 2058 MUST be used as the protocol id. Note that only one protocol id 2059 value can be defined in a Delete payload. Thus, if a TEK SA and a 2060 KEK SA are to be deleted, their SPI values MUST be sent in different 2061 Delete payloads. 2063 There may be circumstances where the GCKS may want to start over with 2064 a clean slate. If the administrator is no longer confident in the 2065 integrity of the group, the GCKS can signal deletion of all policy of 2066 a particular TEK protocol by sending a TEK with a SPI value equal to 2067 zero in the delete payload. For example, if the GCKS wishes to 2068 remove all the KEKs and all the TEKs in the group, the GCKS SHOULD 2069 send a delete payload with a spi of zero and a protocol_id of a TEK 2070 protocol_id value, followed by another delete payload with a SPI 2071 value of zero and protocol_id of zero, indicating that the KEK SA 2072 should be deleted. 2074 6. Algorithm Selection 2076 For GDOI implementations to interoperate, they must support one or 2077 more security algorithms in common. This section specifies the 2078 security algorithm implementation requirements for standards- 2079 conformant GDOI implementations. In all cases the choices are 2080 intended to maintain at least 112 bits of security [SP.800-131]. 2082 Algorithms not referenced in this section MAY be used. 2084 6.1. KEK 2086 These tables list the algorithm selections for values related to the 2087 KEK. 2088 Requirement KEK Management Algorithm 2089 ----------- --------------------- 2090 SHOULD LKH 2092 Requirement KEK Algorithm (notes) 2093 ----------- --------------------- 2094 MUST KEK_ALG_AES with 128-bit keys 2095 SHOULD NOT KEK_ALG_DES (1) 2097 Requirement KEK Signature Hash Algorithm (notes) 2098 ----------- ------------------------------------ 2099 MUST SIG_HASH_SHA256 2100 SHOULD SIG_HASH_SHA1 (2) 2101 SHOULD NOT SIG_HASH_MD5 (3) 2103 Requirement KEK Signature Algorithm (notes) 2104 ----------- ------------------------------- 2105 MUST SIG_ALG_RSA with 2048-bit keys 2107 Notes: 2109 (1) DES, with its small key size and corresponding security strength 2110 is of questionable security for general use 2112 (2) The use of SIG_HASH_SHA1 as a signature hash algorithm used with 2113 GROUPKEY-PUSH messages remains safe at the time of this writing, 2114 and is a widely deployed signature hash algorithm. 2116 (3) Although a real weakness with second preimage resistance with 2117 MD5 has not been found at the time of this writing, the security 2118 strength of MD5 has been shown to be rapidly declining over time 2119 and it's use should be understood and carefully weighed. 2121 6.2. TEK 2123 The following table lists the requirements for Security Protocol 2124 support for an implementation. 2126 Requirement KEK Management Algorithm 2127 ----------- --------------------- 2128 MUST GDOI_PROTO_IPSEC_ESP 2130 7. Security Considerations 2132 GDOI is a security association (SA) management protocol for groups of 2133 senders and receivers. This protocol performs authentication of 2134 communicating protocol participants (Group Member, Group Controller/ 2135 Key Server). It provides confidentiality of key management messages, 2136 and it provides source authentication of those messages. GDOI 2137 includes defenses against man-in-middle, connection hijacking, 2138 replay, reflection, and denial-of-service (DOS) attacks on unsecured 2139 networks. GDOI assumes the network is not secure and may be under 2140 the complete control of an attacker. 2142 GDOI assumes that the group members and GCKS are secure even though 2143 the network is insecure. GDOI ultimately establishes keys among 2144 members of a group, which MUST be trusted to use those keys in an 2145 authorized manner according to group policy. An GDOI entity 2146 compromised by an attacker may reveal the secrets necessary to 2147 eavesdrop on group traffic and/or take the identity of a group 2148 sender, so host security measures mitigating unauthorized access is 2149 of the utmost importance. The latter threat could be mitigated by 2150 using source origin authentication in the Data-Security SAs (e.g., 2151 the use of RSA signatures [RFC4359] or TESLA [RFC4082]). The choice 2152 of Data-Security SAs is a matter of group policy and is not within 2153 the scope of this memo. 2155 There are three phases of GDOI as described in this document: an 2156 ISAKMP Phase 1 protocol, the GROUPKEY-PULL exchange protected by the 2157 ISAKMP Phase 1 protocol, and the GROUPKEY-PUSH message. Each phase 2158 is considered separately below. 2160 7.1. ISAKMP Phase 1 2162 GDOI uses the Phase 1 exchanges defined in [RFC2409] to protect the 2163 GROUPKEY-PULL exchange. Therefore all security properties and 2164 considerations of those exchanges (as noted in [RFC2409]) are 2165 relevant for GDOI. 2167 GDOI may inherit the problems of its ancestor protocols [FS00], such 2168 as identity exposure, absence of unidirectional authentication, or 2169 stateful cookies [PK01]. 2171 7.1.1. Authentication 2173 Authentication is provided via the mechanisms defined in [RFC2409], 2174 namely Pre-Shared Keys or Public Key encryption. 2176 7.1.2. Confidentiality 2178 Confidentiality is achieved in Phase 1 through a Diffie-Hellman 2179 exchange that provides keying material, and through negotiation of 2180 encryption transforms. 2182 The Phase 1 protocol will be protecting encryption and integrity keys 2183 sent in the GROUPKEY-PULL protocol. The strength of the encryption 2184 used for Phase 1 SHOULD exceed that of the keys send in the GROUPKEY- 2185 PULL protocol. 2187 7.1.3. Man-in-the-Middle Attack Protection 2189 A successful man-in-the-middle or connection-hijacking attack foils 2190 entity authentication of one or more of the communicating entities 2191 during key establishment. GDOI relies on Phase 1 authentication to 2192 defeat man-in-the-middle attacks. 2194 7.1.4. Replay/Reflection Attack Protection 2196 In a replay/reflection attack, an attacker captures messages between 2197 GDOI entities and subsequently forwards them to a GDOI entity. 2198 Replay and reflection attacks seek to gain information from a 2199 subsequent GDOI message response or seek to disrupt the operation of 2200 a GDOI member or GCKS entity. GDOI relies on the Phase 1 nonce 2201 mechanism in combination with a hash-based message authentication 2202 code to protect against the replay or reflection of previous key 2203 management messages. 2205 7.1.5. Denial of Service Protection 2207 A denial of service attacker sends messages to a GDOI entity to cause 2208 that entity to perform unneeded message authentication operations. 2209 GDOI uses the Phase 1 cookie mechanism to identify spurious messages 2210 prior to cryptographic hash processing. This is a "weak" form of 2211 denial of service protection in that the GDOI entity must check for 2212 good cookies, which can be successfully imitated by a sophisticated 2213 attacker. The Phase 1 cookie mechanism is stateful, and commits 2214 memory resources for cookies. 2216 7.2. GROUPKEY-PULL Exchange 2218 The GROUPKEY-PULL exchange allows a group member to request SAs and 2219 keys from a GCKS. It runs as a "phase 2" protocol under protection 2220 of the Phase 1 security association. 2222 7.2.1. Authentication 2224 Peer authentication is not required in the GROUPKEY-PULL protocol. 2225 It is running in the context of the Phase 1 protocol, which has 2226 previously authenticated the identity of the peer. 2228 Message authentication is provided by HASH payloads in each message, 2229 where the HASH is defined to be over SKEYID_a (derived in the Phase 1 2230 exchange), the ISAKMP Message-ID, and all payloads in the message. 2231 Because only the two endpoints of the exchange know the SKEYID_a 2232 value, this provides confidence that the peer sent the message. 2234 7.2.2. Confidentiality 2236 Confidentiality is provided by the Phase 1 security association, 2237 after the manner described in [RFC2409]. 2239 7.2.3. Man-in-the-Middle Attack Protection 2241 Message authentication (described above) includes a secret known only 2242 to the group member and GCKS when constructing a HASH payload. This 2243 prevents man-in-the-middle and connection-hijacking attacks because 2244 an attacker would not be able to change the message undetected. 2246 7.2.4. Replay Protection 2248 A GROUPKEY-PULL message identifies its messages using a cookie pair 2249 from the Phase 1 exchange that precedes it. A GROUPKEY-PULL message 2250 with invalid cookies will be discarded. Therefore, GDOI messages 2251 that are not associated with a current GDOI session will be discarded 2252 without further processing. 2254 Replayed GDOI messages that are associated with a current GDOI 2255 session will be decrypted and authenticated. The M-ID in the HDR 2256 identifies a session. Replayed packets will be processed according 2257 to the state machine of that session. Packets not matching that 2258 state machine will be discarded without processing. 2260 7.2.5. Denial of Service Protection 2262 GCKS implementations SHOULD keep a record of recently received 2263 GROUPKEY-PULL messages (e.g., a hash of the packet) and reject 2264 messages that have already been processed. This provides Denial of 2265 Service and Replay Protection of previously sent messages. An 2266 implementation MAY choose to rate-limit the receipt of GDOI messages 2267 in order to mitigate overloading its computational resources. 2269 The GCKS SHOULD NOT perform any computationally expensive tasks 2270 before receiving a HASH with its own nonce included. The GCKS MUST 2271 NOT update the group management state (e.g., LKH key tree, SID- 2272 counter) until it receives the third message in the exchange with a 2273 valid HASH payload including its own nonce. 2275 7.2.6. Authorization 2277 A GCKS implementation SHOULD maintain an authorization list of 2278 authorized group members. Group members MUST specifically list each 2279 authorized GCKS in its Group Peer Authorization Database (GPAD) 2280 [RFC5374]. 2282 7.3. GROUPKEY-PUSH Exchange 2284 The GROUPKEY-PUSH exchange is a single message that allows a GCKS to 2285 send SAs and keys to group members. This is likely to be sent to all 2286 members using an IP multicast group. This message provides an 2287 efficient rekey and group membership adjustment capability. 2289 7.3.1. Authentication 2291 The GROUPKEY-PULL exchange distributes a public key that is used for 2292 message authentication. The GROUPKEY-PUSH message is digitally 2293 signed using the corresponding private key held by the GCKS. This 2294 digital signature provides source authentication for the message. 2295 Thus, GDOI protects the GCKS from impersonation in group 2296 environments. 2298 7.3.2. Confidentiality 2300 The GCKS encrypts the GROUPKEY-PUSH message with an encryption key 2301 that was distributed in the GROUPKEY-PULL exchange or a previous 2302 GROUPKEY-PUSH exchange. The encryption key may be a simple KEK, or 2303 the result of a group management method (e.g., LKH) calculation. 2305 7.3.3. Man-in-the-Middle Attack Protection 2307 This combination of confidentiality and message authentication 2308 services protects the GROUPKEY-PUSH message from man-in-middle and 2309 connection-hijacking attacks. 2311 7.3.4. Replay/Reflection Attack Protection 2313 The GROUPKEY-PUSH message includes a monotonically increasing 2314 sequence number to protect against replay and reflection attacks. A 2315 group member will discard sequence numbers associated with the 2316 current KEK SPI that have the same or lower value as the most 2317 recently received replay number. 2319 Implementations SHOULD keep a record (e.g., a hash value) of recently 2320 received GROUPKEY-PUSH messages and reject duplicate messages prior 2321 to performing cryptographic operations. This enables an early 2322 discard of the replayed messages. 2324 7.3.5. Denial of Service Protection 2326 A cookie pair identifies the security association for the GROUPKEY- 2327 PUSH message. The cookies thus serve as a weak form of denial-of- 2328 service protection for the GROUPKEY-PUSH message. 2330 The digital signature used for message authentication has a much 2331 greater computational cost than a message authentication code and 2332 could amplify the effects of a denial of service attack on GDOI 2333 members who process GROUPKEY-PUSH messages. The added cost of 2334 digital signatures is justified by the need to prevent GCKS 2335 impersonation: If a shared symmetric key were used for GROUPKEY-PUSH 2336 message authentication, then GCKS source authentication would be 2337 impossible and any member would be capable of GCKS impersonation. 2339 The potential of the digital signature amplifying a denial of service 2340 attack is mitigated by the order of operations a group member takes, 2341 where the least expensive cryptographic operation is performed first. 2342 The group member first decrypts the message using a symmetric cipher. 2343 If it is a validly formed message then the sequence number is checked 2344 against the most recently received sequence number. Only when the 2345 sequence number is valid (i.e., it is a larger value than previously 2346 received) is the digital signature verified and the message further 2347 processed. Thus in order for a denial of service attack to be 2348 mounted, an attacker would need to know both the symmetric encryption 2349 key used for confidentiality, and a valid sequence number. Generally 2350 speaking this means only current group members can effectively deploy 2351 a denial of service attack. 2353 7.4. Forward and Backward Access Control 2355 Through GROUPKEY-PUSH, the GDOI supports group management methods 2356 such as LKH (section 5.4 of [RFC2627]) that have the property of 2357 denying access to a new group key by a member removed from the group 2358 (forward access control) and to an old group key by a member added to 2359 the group (backward access control). The concepts "forward access 2360 control" and "backward access control" have also been described as 2361 "perfect forward security" and "perfect backward security" 2362 respectively in the literature [RFC2627]. 2364 Group management algorithms providing forward and backward access 2365 control other than LKH have been proposed in the literature, 2366 including OFT [OFT] and Subset Difference [NNL]. These algorithms 2367 could be used with GDOI, but are not specified as a part of this 2368 document. 2370 7.4.1. Forward Access Control Requirements 2372 When group membership is altered using a group management algorithm 2373 new Data-security SAs are usually also needed. New SAs ensure that 2374 members who were denied access can no longer participate in the 2375 group. 2377 If forward access control is a desired property of the group, new 2378 Data-security SAs MUST NOT be included in a GROUPKEY-PUSH message 2379 which changes group membership. This is required because the new 2380 Data-security SAs are not protected with the new KEK. Instead, two 2381 sequential GROUPKEY-PUSH messages must be sent by the GCKS; the first 2382 changing the KEK, and the second (protected with the new KEK) 2383 distributing the new Data-security SAs. 2385 Note that in the above sequence, although the new KEK can effectively 2386 deny access to the group to some group members they will be able to 2387 view the new KEK policy. If forward access control policy for the 2388 group includes keeping the KEK policy secret as well as the KEK 2389 itself secret, then two GROUPKEY-PUSH messages changing the KEK must 2390 occur before the new Data-security SAs are transmitted. 2392 If other methods of using LKH or other group management algorithms 2393 are added to GDOI, those methods MAY remove the above restrictions 2394 requiring multiple GROUPKEY-PUSH messages, providing those methods 2395 specify how forward access control policy is maintained within a 2396 single GROUPKEY-PUSH message. 2398 7.4.2. Backward Access Control Requirements 2400 If backward access control is a desired property of the group, a new 2401 member MUST NOT be given Data-security SAs that were used prior to it 2402 joining the group. This can be accomplished if the GCKS provides 2403 only the Rekey SA to the new member in a GROUPKEY-PULL exchange, 2404 followed by a GROUPKEY-PUSH message that both deletes current Data- 2405 security SAs, and provides new replacement Data-security SAs. The 2406 new group member will effectively join the group at such time as the 2407 existing members begin sending on the Data-security SAs. 2409 If there is a possibility that the new group member has stored 2410 GROUPKEY-PUSH messages delivered prior to joining the group, then the 2411 above procedure is not sufficient. In this case, to achieve backward 2412 access control the GCKS needs to return a new Rekey SA to the group 2413 member in a GROUPKEY-PULL exchange rather than the existing one. The 2414 GCKS would subsequently deliver two GROUPKEY-PUSH messages. The 2415 first, intended for existing group members, distributes the new 2416 Rekey-SA to existing members. The GCKS would then deliver the second 2417 GROUPKEY-PUSH message using the new Rekey-SA that both deletes 2418 current Data-security SAs, and provides new replacement Data-security 2419 SAs. Both preexisting and new members would process the second 2420 GROUPKEY-PUSH message, and all would be able to communicate using the 2421 new Data-security SAs. 2423 7.5. Derivation of keying material 2425 A GCKS distributes keying material associated with Data-Security SAs 2426 and the Rekey SA. Because these security associations are used by a 2427 set of group members, this keying material is not related to any pair 2428 wise connection, and there is no requirement in The Multicast Group 2429 Security Architecture [RFC3740] for group members to permute group 2430 keying material. Because the GCKS is solely responsible for the 2431 generation of the keying material, the GCKS MUST derive the keying 2432 material using a strong random number generator. Because there are 2433 no interoperability concerns with key generation, no method is 2434 prescribed in GDOI. 2436 8. IANA Considerations 2438 8.1. Additions to current registries 2440 The GDOI KEK Attribute named SIG_HASH_ALGORITHM [GDOI-REG] should be 2441 assigned several new Algorithm Type values from the RESERVED space to 2442 represent the SHA-256, SHA-384, and SHA-512 hash algorithms as 2443 defined in [FIPS180-3.2008]. The new algorithm names should be 2444 SIG_HASH_SHA256, SIG_HASH_SHA384, and SIG_HASH_SHA512 respectively 2445 and have the values of TBD-2, TBD-3, and TBD-4 respectively. 2447 The GDOI KEK Attributed named SIG_ALGORITHM [GDOI-REG] should be 2448 assigned several new Algorithm Type values from the RESERVED space to 2449 represent the SIG_ALG_ECDSA-256, SIG_ALG_ECDSA-384, and 2450 SIG_ALG_ECDSA-521 signature algorithms. The Algorithm Types values 2451 should be TBD-7, TBD-8, and TBD-9 respectively. 2453 A new GDOI SA TEK type Protocol-ID type [GDOI-REG] should be assigned 2454 from the RESERVED space. The new algorithm id should be called 2455 GDOI_PROTO_IPSEC_AH, refers to the IPsec AH encapsulation, and has a 2456 value of TBD-5. 2458 A new Next Payload Type [ISAKMP-REG] should be assigned. The new 2459 type is called "SA Group Associated Policy (GAP)", and has a value of 2460 TBD-1. 2462 A new Key Download Type Section 5.6 should be assigned. The new type 2463 is called "SID", and has a value of TBD-6. 2465 8.2. New registries 2467 A new registry identifying the possible values of GAP Payload Policy 2468 Attributes (of the form described in Section 3.3 of [RFC2408]) should 2469 be created in the GDOI Payloads [GDOI-REG]. This memo defines the 2470 following values for this registry: 2472 Attribute Type Value Type 2473 ---- ----- ---- 2474 RESERVED 0 2475 ACTIVATION_TIME_DELAY 1 B 2476 DEACTIVATION_TIME_DELAY 2 B 2477 SENDER_ID_REQUEST 3 B 2478 Standards Action 4-127 2479 Private Use 128-255 2480 Unassigned 256-32767 2482 The terms Standards Action and Private Use are to be applied as 2483 defined in [RFC5226]. 2485 A new IPsec Security Association Attribute [ISAKMP-REG] defining the 2486 preservation of IP addresses is needed. The attribute class is 2487 called "Address Preservation", and it is a Basic type. The following 2488 rules apply to define the values of the attribute: 2490 Name Value 2491 ---- ----- 2492 Reserved 0 2493 None 1 2494 Source-Only 2 2495 Destination-Only 3 2496 Source-And-Destination 4 2497 Standards Action 5-61439 2498 Private Use 61440-65535 2500 The terms Standards Action and Private Use are to be applied as 2501 defined in [RFC5226]. 2503 A new IPsec Security Association Attribute [ISAKMP-REG] defining the 2504 SA direction is needed. The attribute class is called "SA 2505 Direction", and it is a Basic type. The following rules apply to 2506 define the values of the attribute: 2508 Name Value 2509 ---- ----- 2510 Reserved 0 2511 Sender-Only 1 2512 Receiver-Only 2 2513 Symmetric 3 2514 Standards Action 4-61439 2515 Private Use 61440-65535 2517 The terms Standards Action and Private Use are to be applied as 2518 defined in [RFC5226]. 2520 When the SID "Key Download Type" (described in the previous section) 2521 has a set of attributes. The attributes must follow the format 2522 defined in ISAKMP (Section 3.3 of [RFC2408]). In the table, 2523 attributes defined as TV are marked as Basic (B); attributes defined 2524 as TLV are marked as Variable (V). 2526 SID Class Value Type 2527 --------- ----- ---- 2528 RESERVED 0 2529 NUMBER_OF_SID_BITS 1 B 2530 SID_VALUE 2 V 2531 Standards Action 3-128 2532 Private Use 129-255 2533 Unassigned 256-32767 2535 The terms Standards Action and Private Use are to be applied as 2536 defined in [RFC5226]. 2538 8.3. Cleanup of existing registries 2540 Several existing GDOI Payloads registries do not use the terms in RFC 2541 5226 and/or do not describe the entire range of possible values. The 2542 following sections correct these registries. The terms Standards 2543 Action, Unassigned, and Private Use are to be applied as defined in 2544 [RFC5226]. 2546 8.3.1. Pop Algorithm 2548 Values 4-127 are to be designated Standards Action. Values 256-32767 2549 are to be added and designated Unassigned. 2551 8.3.2. KEK Attributes 2553 Values 9-127 are to added and designated Standards Action. Values 2554 128-255 are to be added and designated Private Use. Values 256-32767 2555 are to be added and designated Unassigned. 2557 8.3.3. KEK_MANAGEMENT_ALGORITHM 2559 Values 2-127 are to be designated Standards Action. Values 256-65535 2560 are to be added and designated Unassigned. 2562 8.3.4. KEK_ALGORITHM 2564 Values 4-127 are to be designated Standards Action. Values 256-65535 2565 are to be added and designated Unassigned. 2567 8.3.5. SIG_HASH_ALGORITHM 2569 Values 3-127 are to be designated Standards Action. Values 256-65535 2570 are to be added and designated Unassigned. 2572 8.3.6. SIG_ALGORITHM 2574 Values 4-127 are to be designated Standards Action. Values 256-65535 2575 are to be added and designated Unassigned. 2577 8.3.7. SA TEK Payload Values 2579 Values 2-127 are to be designated Standards Action. 2581 8.3.8. Key Download Types 2583 Values 4-127 are to be designated Standards Action. 2585 8.3.9. TEK Download Type 2587 Values 4-127 are to be added and designated Standards Action. Values 2588 128-255 are to be added and designated Private Use. Values 256-32767 2589 are to be added and designated Unassigned. 2591 8.3.10. KEK Download Type 2593 Values 3-127 are to be designated Standards Action. Values 128-255 2594 are to be added and designated Private Use. Values 256-32767 are to 2595 be added and designated Unassigned. 2597 8.3.11. LKH Download Type 2599 Values 4-127 are to be designated Standards Action. Values 256-32767 2600 are to be added and designated Unassigned. 2602 9. Acknowledgements 2604 This memo replaces RFC 3547, and the authors wish to thank Mark 2605 Baugher and Hugh Harney for their extensive contributions that led to 2606 this newer specification of GDOI. 2608 The authors are grateful to Catherine Meadows for her careful review 2609 and suggestions for mitigating the man-in-the-middle attack she had 2610 previously identified. Yoav Nir, Vincent Roca, Sean Turner, and 2611 Elwyn Davies provided many useful technical and editorial comments 2612 and suggestions for improvement. 2614 10. References 2616 10.1. Normative References 2618 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2619 Requirement Levels", BCP 14, RFC 2119, March 1997. 2621 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 2622 ESP and AH", RFC 2403, November 1998. 2624 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 2625 ESP and AH", RFC 2404, November 1998. 2627 [RFC2407] Piper, D., "The Internet IP Security Domain of 2628 Interpretation for ISAKMP", RFC 2407, November 1998. 2630 [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet 2631 Security Association and Key Management Protocol 2632 (ISAKMP)", RFC 2408, November 1998. 2634 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2635 (IKE)", RFC 2409, November 1998. 2637 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 2638 Multicast: Issues and Architectures", RFC 2627, June 1999. 2640 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 2641 Standards (PKCS) #1: RSA Cryptography Specifications 2642 Version 2.1", RFC 3447, February 2003. 2644 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 2645 December 2005. 2647 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2648 RFC 4303, December 2005. 2650 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 2651 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 2652 RFC 4754, January 2007. 2654 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 2655 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 2657 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 2658 Extensions to the Security Architecture for the Internet 2659 Protocol", RFC 5374, November 2008. 2661 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 2662 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 2663 June 2010. 2665 [RFC6054] McGrew, D. and B. Weis, "Using Counter Modes with 2666 Encapsulating Security Payload (ESP) and Authentication 2667 Header (AH) to Protect Group Traffic", RFC 6054, 2668 November 2010. 2670 10.2. Informative References 2672 [FIPS180-3.2008] 2673 National Institute of Standards and Technology, "Secure 2674 Hash Standard", FIPS PUB 180-3, October 2008, . 2678 [FIPS186-3] 2679 "Digital Signature Standard (DSS)", United States of 2680 America, National Institute of Science and 2681 Technology Federal Information Processing Standard (FIPS) 2682 186-2, June 2009. 2684 [FIPS197] "Advanced Encryption Standard (AES)", United States of 2685 America, National Institute of Science and 2686 Technology Federal Information Processing Standard (FIPS) 2687 197, November 2001. 2689 [FIPS46-3] 2690 "Data Encryption Standard (DES)", United States of 2691 America, National Institute of Science and 2692 Technology Federal Information Processing Standard (FIPS) 2693 46-3, October 1999. 2695 [FIPS81] "DES Modes of Operation", United States of America, 2696 National Institute of Science and Technology Federal 2697 Information Processing Standard (FIPS) 81, December 1980. 2699 [FS00] Ferguson, N. and B. Schneier, Counterpane, "A 2700 Cryptographic Evaluation of IPsec", 2701 . 2703 [GDOI-REG] 2704 Internet Assigned Numbers Authority, "Group Domain of 2705 Interpretation (GDOI) Payload Type Values", IANA Registry, 2706 December 2004, 2707 . 2709 [HD03] Hardjono, T. and L. Dondeti, "Multicast and Group 2710 Security", Artech House Computer Security Series, ISBN 2711 1-58053-342-6, 2003. 2713 [ISAKMP-REG] 2714 "'Magic Numbers' for ISAKMP Protocol", 2715 . 2717 [MP04] Meadows, C. and D. Pavlovic, "Deriving, Attacking, and 2718 Defending the GDOI Protocol", ESORICS 2004 pp. 53-72, 2719 September 2004. 2721 [NNL] Naor, D., Noal, M., and J. Lotspiech, "Revocation and 2722 Tracing Schemes for Stateless Receivers", Advances in 2723 Cryptology, Crypto '01, Springer-Verlag LNCS 2139, 2001, 2724 pp. 41-62, 2001, 2725 . 2727 [OFT] McGrew, D. and A. Sherman, "Key Establishment in Large 2728 Dynamic Groups Using One-Way Function Trees", Manuscript, 2729 submitted to IEEE Transactions on Software Engineering, 2730 1998, . 2733 [PK01] Perlman, R. and C. Kaufman, "Analysis of the IPsec Key 2734 Exchange Standard", WET-ICE conference , 2001, 2735 . 2737 [PROTOCOL-REG] 2738 "Assigned Internet Protocol Numbers", . 2742 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 2743 Counter Mode With IPsec Encapsulating Security Payload 2744 (ESP)", RFC 3686, January 2004. 2746 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 2747 Architecture", RFC 3740, March 2004. 2749 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 2750 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 2751 January 2005. 2753 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 2754 "Multicast Security (MSEC) Group Key Management 2755 Architecture", RFC 4046, April 2005. 2757 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 2759 Briscoe, "Timed Efficient Stream Loss-Tolerant 2760 Authentication (TESLA): Multicast Source Authentication 2761 Transform Introduction", RFC 4082, June 2005. 2763 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 2764 (GCM) in IPsec Encapsulating Security Payload (ESP)", 2765 RFC 4106, June 2005. 2767 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2768 Internet Protocol", RFC 4301, December 2005. 2770 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 2771 Mode with IPsec Encapsulating Security Payload (ESP)", 2772 RFC 4309, December 2005. 2774 [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within 2775 Encapsulating Security Payload (ESP) and Authentication 2776 Header (AH)", RFC 4359, January 2006. 2778 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 2779 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 2780 May 2006. 2782 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2783 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2784 May 2008. 2786 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 2787 Time Protocol Version 4: Protocol and Algorithms 2788 Specification", RFC 5905, June 2010. 2790 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 2791 "Internet Key Exchange Protocol Version 2 (IKEv2)", 2792 RFC 5996, September 2010. 2794 [SP.800-131] 2795 Barker, E. and A. Roginsky, "Recommendation for the 2796 Transitioning of Cryptographic Algorithms and Key 2797 Lengths", United States of America, National Institute of 2798 Science and Technology DRAFT NIST Special Publication 800- 2799 131, June 2010. 2801 [SP.800-38A] 2802 Dworkin, M., "Recommendation for Block Cipher Modes of 2803 Operation", United States of America, National Institute 2804 of Science and Technology NIST Special Publication 800-38A 2805 2001 Edition, December 2001. 2807 Appendix A. GDOI Applications 2809 GDOI can be used to distribute keys for several secure multicast 2810 applications, where different applications have different key 2811 management requirements. This section outlines two example ways that 2812 GDOI can be used. Other examples can be found in Section 10 of 2813 [HD03]. 2815 A simple application is secure delivery of periodic multicast content 2816 over an organization's IP network, perhaps a multicast video 2817 broadcast. Assuming the content delivery time frame is bounded and 2818 the group membership is not expected to change over time, there is no 2819 need for group policy to include a GROUPKEY-PUSH exchange, and 2820 there's no need for the GCKS to distribute a Re-key SA. Thus, the 2821 GDOI GCKS may only need to distribute a single set of Data-Security 2822 SAs to protect the time-bounded broadcast. 2824 In contrast, a persistent IP multicast application (e.g., stock- 2825 ticker delivery service) may have many group members, where the group 2826 membership changes over time. A periodic change of Data-security SAs 2827 may be desirable, and the potential for change in group membership 2828 requires the use of a group management method enabling de- 2829 authorization of group members. The GDOI GCKS will distribute the 2830 current set of Data-Security SAs and a Re-key SA to registering group 2831 members. It will then deliver regularly-scheduled GROUPKEY-PUSH 2832 protocol delivering the new SAs for the group. Additionally, the 2833 group membership on the GCKS may be frequently adjusted, which will 2834 result in GROUPKEY-PUSH exchange delivering a new Rekey SAs protected 2835 by a group management method. Each GROUPKEY-PUSH may include Data- 2836 security SAs and/or a Rekey SA. 2838 In each example the relevant policy is defined on the GCKS and 2839 relayed to group members using the GROUPKEY-PULL and/or GROUPKEY-PUSH 2840 protocols. Specific policy choices configured by the GCKS 2841 administrator depends on each application. 2843 Appendix B. Significant Changes from RFC 3547 2845 The following significant changes have been made from RFC 3547. 2847 o The Proof of Possession (POP) payload was removed from the 2848 GROUPKEY-PULL exchange. It provided an alternate form of 2849 authorization, but its use was underspecified. Furthermore, 2850 Meadows and Pavlovic [MP04] discussed a man-in-the-middle attack 2851 on the POP authorization method, which would require changes to 2852 its semantics. No known implementation of RFC 3547 supported the 2853 POP payload, so it was removed. Removal of the POP payload 2854 obviated the need for the CERT payload in that exchange and it was 2855 removed as well. 2857 o The Key Exchange Payloads (KE_I, KE_R) payloads were removed from 2858 the GROUPKEY-PULL exchange. However, the specification for 2859 computing keying material for the additional encryption function 2860 in RFC 3547 is faulty. Furthermore, it has been observed that 2861 because the GDOI registration message uses strong ciphers and 2862 provides authenticated encryption, additional encryption of the 2863 keying material in a GDOI registration message provides negligible 2864 value. Therefore, the use of KE payloads is deprecated in this 2865 memo. 2867 o The Certificate Payload (CERT) was removed from the GROUPKEY-PUSH 2868 exchange. The use of this payload was underspecified. In all 2869 known use cases, the public key of used to verify the GROUPKEY- 2870 PUSH payload is distributed directly from the key server as part 2871 of the GROUPKEY-PULL exchange. 2873 o Supported cryptographic algorithms were changed to meet current 2874 guidance. Implementations are required to support AES with 128- 2875 bit keys to encrypt the rekey message, and SHA-256 for 2876 cryptographic signatures. The use of DES is deprecated. 2878 o New protocol support for AH. 2880 o New protocol definitions were added to conform to the most recent 2881 Security Architecture for the Internet Protocol [RFC4301] and the 2882 Multicast Extensions to the Security Architecture for the Internet 2883 Protocol[RFC5374]. This includes addition of the GAP payload. 2885 o New protocol definitions and semantics were added to support Using 2886 Counter Modes with ESP and AH to Protect Group Traffic[RFC6054]. 2888 o Specification to IANA to better clarify the use of the GDOI 2889 Payloads registry. 2891 Authors' Addresses 2893 Brian Weis 2894 Cisco Systems 2895 170 W. Tasman Drive 2896 San Jose, California 95134-1706 2897 USA 2899 Phone: +1-408-526-4796 2900 Email: bew@cisco.com 2902 Sheela Rowles 2903 Cisco Systems 2904 170 W. Tasman Drive 2905 San Jose, California 95134-1706 2906 USA 2908 Phone: +1-408-527-7677 2909 Email: sheela@cisco.com 2911 Thomas Hardjono 2912 MIT 2913 77 Massachusetts Ave. 2914 Cambridge, Massachusets 02139 2915 USA 2917 Phone: +1-781-729-9559 2918 Email: hardjono@mit.edu