idnits 2.17.1 draft-ietf-msec-gkmarch-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1755. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1775. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1781. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 762 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 09, 2004) is 7262 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'PAGE 2' on line 95 looks like a reference -- Missing reference section? 'TAXONOMY' on line 1683 looks like a reference -- Missing reference section? 'RFC3711' on line 1660 looks like a reference -- Missing reference section? 'RFC2401' on line 1625 looks like a reference -- Missing reference section? 'RFC2094' on line 1613 looks like a reference -- Missing reference section? 'RFC2627' on line 1647 looks like a reference -- Missing reference section? 'OFT' on line 1605 looks like a reference -- Missing reference section? 'MARKS' on line 1587 looks like a reference -- Missing reference section? 'CLIQUES' on line 1562 looks like a reference -- Missing reference section? 'FN93' on line 1565 looks like a reference -- Missing reference section? 'Wool' on line 1709 looks like a reference -- Missing reference section? 'GKMBB' on line 134 looks like a reference -- Missing reference section? 'MSEC-Arch' on line 1597 looks like a reference -- Missing reference section? 'PAGE 3' on line 146 looks like a reference -- Missing reference section? 'PAGE 4' on line 197 looks like a reference -- Missing reference section? 'PAGE 5' on line 248 looks like a reference -- Missing reference section? 'TPM' on line 1700 looks like a reference -- Missing reference section? 'JKKV94' on line 1582 looks like a reference -- Missing reference section? 'PAGE 6' on line 299 looks like a reference -- Missing reference section? 'PAGE 7' on line 350 looks like a reference -- Missing reference section? 'PAGE 8' on line 398 looks like a reference -- Missing reference section? 'PAGE 9' on line 448 looks like a reference -- Missing reference section? 'PAGE 10' on line 498 looks like a reference -- Missing reference section? 'SDR' on line 1236 looks like a reference -- Missing reference section? 'PAGE 11' on line 550 looks like a reference -- Missing reference section? 'RFC2367' on line 1622 looks like a reference -- Missing reference section? 'GSPT' on line 1574 looks like a reference -- Missing reference section? 'RFC2327' on line 1619 looks like a reference -- Missing reference section? 'PAGE 12' on line 601 looks like a reference -- Missing reference section? 'RFC3547' on line 1651 looks like a reference -- Missing reference section? 'PAGE 13' on line 650 looks like a reference -- Missing reference section? 'RFC2409' on line 1635 looks like a reference -- Missing reference section? 'MVV' on line 1600 looks like a reference -- Missing reference section? 'PAGE 14' on line 701 looks like a reference -- Missing reference section? 'RFC2326' on line 1616 looks like a reference -- Missing reference section? 'RFC2543' on line 1644 looks like a reference -- Missing reference section? 'PAGE 15' on line 752 looks like a reference -- Missing reference section? 'PAGE 16' on line 801 looks like a reference -- Missing reference section? 'PAGE 17' on line 851 looks like a reference -- Missing reference section? 'SD' on line 864 looks like a reference -- Missing reference section? 'BatchRekey' on line 1558 looks like a reference -- Missing reference section? 'PAGE 18' on line 903 looks like a reference -- Missing reference section? 'PAGE 19' on line 953 looks like a reference -- Missing reference section? 'PAGE 20' on line 1004 looks like a reference -- Missing reference section? 'PAGE 21' on line 1055 looks like a reference -- Missing reference section? 'SD1' on line 1663 looks like a reference -- Missing reference section? 'SD2' on line 1667 looks like a reference -- Missing reference section? 'Self-healing' on line 1102 looks like a reference -- Missing reference section? 'PAGE 22' on line 1106 looks like a reference -- Missing reference section? 'PAGE 23' on line 1156 looks like a reference -- Missing reference section? 'TLS' on line 1184 looks like a reference -- Missing reference section? 'PAGE 24' on line 1207 looks like a reference -- Missing reference section? 'RFC 2459' on line 1212 looks like a reference -- Missing reference section? 'RFC 2693' on line 1212 looks like a reference -- Missing reference section? 'PAGE 25' on line 1258 looks like a reference -- Missing reference section? 'PAGE 26' on line 1308 looks like a reference -- Missing reference section? 'RFC 2401' on line 1316 looks like a reference -- Missing reference section? 'TESLA' on line 1344 looks like a reference -- Missing reference section? 'PAGE 27' on line 1358 looks like a reference -- Missing reference section? 'RFC3550' on line 1656 looks like a reference -- Missing reference section? 'PAGE 28' on line 1401 looks like a reference -- Missing reference section? 'PAGE 29' on line 1453 looks like a reference -- Missing reference section? 'GSAKMP' on line 1569 looks like a reference -- Missing reference section? 'STS' on line 1679 looks like a reference -- Missing reference section? 'SKEME' on line 1675 looks like a reference -- Missing reference section? 'RFC2408' on line 1631 looks like a reference -- Missing reference section? 'RFC2412' on line 1638 looks like a reference -- Missing reference section? 'RFC2522' on line 1641 looks like a reference -- Missing reference section? 'PAGE 30' on line 1504 looks like a reference -- Missing reference section? 'PAGE 31' on line 1555 looks like a reference -- Missing reference section? 'MIKEY' on line 1592 looks like a reference -- Missing reference section? 'PAGE 32' on line 1603 looks like a reference -- Missing reference section? 'RFC2093' on line 1610 looks like a reference -- Missing reference section? 'RFC2406' on line 1628 looks like a reference -- Missing reference section? 'PAGE 33' on line 1654 looks like a reference -- Missing reference section? 'Self-Healing' on line 1671 looks like a reference -- Missing reference section? 'TESLA-INFO' on line 1686 looks like a reference -- Missing reference section? 'TESLA-SPEC' on line 1691 looks like a reference -- Missing reference section? 'PAGE 34' on line 1707 looks like a reference -- Missing reference section? 'PAGE 35' on line 1713 looks like a reference -- Missing reference section? 'PAGE 36' on line 1763 looks like a reference -- Missing reference section? 'PAGE 37' on line 1788 looks like a reference -- Missing reference section? 'PAGE 38' on line 1789 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 88 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Mark Baugher (Cisco) 3 IETF MSEC WG Ran Canetti (IBM) 4 Expires: December 08, 2004 Lakshminath Dondeti (Nortel) 5 Category: Informational Fredrik Lindholm (Ericsson) 6 June 09, 2004 8 MSEC Group Key Management Architecture 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as work in progress. 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document defines the common architecture for Multicast Security 35 (MSEC) key management protocols that support a variety of 36 application, transport, and network layer security protocols. It 37 also defines the group security association (GSA), and describes the 38 key management protocols that help establish a GSA. The framework 39 and guidelines described in this document allow for a modular and 40 flexible design of group key management protocols for a variety of 41 different settings that are specialized to applications needs. MSEC 42 key management protocols may be used to facilitate secure one-to- 43 many, many-to-many, or one-to-one communication. 45 Comments on this document should be sent to msec@securemulticast.org. 47 Table of Contents 49 Status of this Memo................................................1 50 Abstract...........................................................1 51 1.0 Introduction: Purpose of this Document.........................3 52 2.0 Requirements of a Group Key Management Protocol................4 53 3.0 Overall Design of the Group Key Management Architecture........6 54 3.1 Overview.......................................................6 55 3.2 Detailed Description of the GKM Architecture...................8 56 3.3 Properties of the Design .....................................11 57 3.4 Group Key Management Block Diagram............................11 58 4.0 Registration protocol.........................................13 59 4.1 Registration protocol via Piggybacking or Protocol Reuse......13 60 4.2 Properties of Alternative registration Exchange Types.........14 61 4.3 Infrastructure for Alternative registration Exchange Types....15 62 4.4 De-registration Exchange......................................15 63 5.0 Rekey protocol................................................16 64 5.1 Goals of the rekey protocol...................................16 65 5.2 Rekey message Transport and Protection........................17 66 5.3 Reliable Transport of rekey messages..........................18 67 5.4 State-of-the-art on Reliable Multicast Infrastructure.........20 68 5.5 Implosion.....................................................20 69 5.6 Issues in Incorporating Group Key Management Algorithms.......22 70 5.7 Stateless, Stateful, and Self-healing Rekeying Algorithms.....22 71 5.8 Interoperability of a GKMA....................................23 72 6.0 Group Security Association....................................23 73 6.1 Group policy..................................................24 74 6.2 Contents of the Rekey SA......................................25 75 6.2.1 Rekey SA Policy.............................................25 76 6.2.2 Group Identity..............................................26 77 6.2.3 KEKs........................................................26 78 6.2.4 Authentication Key..........................................26 79 6.2.5 Replay Protection...........................................26 80 6.2.6 Security Parameter Index (SPI)..............................26 81 6.3 Contents of the Data SA.......................................27 82 6.3.1 Group Identity..............................................27 83 6.3.2 Source Identity.............................................27 84 6.3.3 Traffic Protection Keys.....................................27 85 6.3.4 Data Authentication Keys....................................27 86 6.3.5 Sequence Numbers............................................27 87 6.3.6 Security Parameter Index (SPI)..............................27 88 6.3.7 Data SA policy..............................................28 89 7.0 Scalability Considerations....................................28 90 8.0 Security Considerations.......................................30 91 9.0 Acknowledgments...............................................31 92 10.0 References and Bibliography..................................32 93 11.0 Authors' Addresses...........................................36 95 Internet Draft Group Key Management Architecture [PAGE 2] 96 1.0 Introduction: Purpose of this Document 98 Group and multicast applications have diverse requirements in IP 99 networks [TAXONOMY]. Their key management requirements - briefly 100 reviewed in Section 2.0 - include support for internetwork, 101 transport, and application-layer protocols. Some applications may 102 achieve simpler operation by running key-management messaging over a 103 pre-established secure channel (e.g., TLS, IPsec). Other security 104 protocols may benefit from a key management protocol that can run 105 over already deployed session initiation or management protocol 106 (e.g., SIP or RTSP). Finally, some may benefit from a light-weight 107 key management protocol that finishes in fewest round trips. For 108 these reasons, different application, transport, and internetwork- 109 layer data security protocols (e.g., SRTP [RFC3711] and IPsec 110 [RFC2401]) may benefit from using different group key management 111 systems. The purpose of this document is to define a common 112 architecture and design for group key-management protocols for 113 internet, transport, and application services. 115 The common architecture for group key management is called the MSEC 116 key management architecture and is based on the group control or key 117 server model developed in GKMP [RFC2094] and assumed by group key 118 management algorithms such as LKH [RFC2627], OFT [OFT], and MARKS 119 [MARKS]. There are other approaches that are not considered in this 120 architecture such as the highly distributed Cliques group key 121 management protocol [CLIQUES] and broadcast key management schemes 122 [FN93, Wool]. MSEC (Multicast Security) key management may in fact 123 be complementary to other group key management designs, but these 124 are not considered in this document. The integration of MSEC group 125 key management with Cliques, broadcast key management and other 126 group key systems is not considered in this document. 128 Indeed, key-management protocols are difficult to design and 129 validate. The common architecture described in this document eases 130 this burden by defining common abstractions and overall design that 131 can be specialized for different uses. 133 This document builds on and extends the Group Key Management Building 134 Block document of the IRTF SMuG research group [GKMBB] and is part of 135 the MSEC document roadmap. The MSEC architecture [MSEC-Arch] is a 136 reference for a complete multicast or group security architecture, of 137 which key management is a component. 139 The rest of this document is organized as follows. Section 2 140 discusses the security, performance and architectural requirements 141 for a group key management protocol. Section 3 presents the overall 142 architectural design principles. Section 4 describes the registration 143 protocol in detail and Section 5 does the same for rekey protocol. 144 Section 6 considers the interface to the Group Security Association 146 Internet Draft Group Key Management Architecture [PAGE 3] 147 (GSA). Section 7 reviews the scalability issues for group key 148 management protocols and Section 8 discusses security considerations. 150 2.0 Requirements of a Group Key Management Protocol 152 A group key management protocol supports protected communication 153 between members of a secure group. A secure group is a collection of 154 principals, called members, who may be senders, receivers or both 155 receivers and senders to other members of the group. (Note that group 156 membership may vary over time.) A group key management protocol 157 helps to ensure that only members of a secure group gain access to 158 group data (by gaining access to group keys) and can authenticate 159 group data. The goal of a group key management protocol is to 160 provide legitimate group members with the up-to-date cryptographic 161 state they need for their secrecy and authenticity requirements. 163 Multicast applications, such as video broadcast and multicast file 164 transfer, typically have the following key-management requirements 165 (see also [TAXONOMY]). Note that the list is neither applicable to 166 all applications, nor exhaustive. 168 1. The group members receive security associations including 169 encryption keys, authentication/integrity keys, cryptographic 170 policy that describes the keys, and attributes such as an index 171 for referencing the security association (SA) or particular 172 objects contained in the SA. 174 2. In addition to the policy associated with group keys, the group 175 owner or the Group Controller and Key Server (GCKS) may define 176 and enforce group membership, key management, data security and 177 other policies that may or may not be communicated to the 178 membership-at-large. 180 3. Keys will have a predetermined lifetime and may be periodically 181 refreshed. 183 4. Key material should be delivered securely to members of the 184 group so that they are secret, integrity-protected and can be 185 verified as coming from an authorized source. 187 5. The key-management protocol should be secure against replay 188 attacks and Denial of Service(DoS) attacks (see the Security 189 Considerations section of this memo). 191 6. The protocol should facilitate addition and removal of group 192 members so that members who are added may optionally be denied 193 access to the key material used before they joined the group, 194 and that removed members lose access to the key material 195 following their departure. 197 Internet Draft Group Key Management Architecture [PAGE 4] 198 7. The protocol should support a scalable group rekey operation 199 without unicast exchanges between members and a group 200 controller/key server, to avoid overwhelming a GCKS managing a 201 large group. 203 8. The protocol should be compatible with the infrastructure and 204 performance needs of the data-security application, such as 205 IPsec security protocols, AH and ESP, and/or application-layer 206 security protocols, such as SRTP. 208 9. The key management protocol should offer a framework for 209 replacing or renewing transforms, authorization infrastructure 210 and authentication systems. 212 10. The key management protocol should be secure against collusion 213 among excluded members and non-members. Specifically, 214 collusion must not result in attackers gaining any additional 215 group secrets than each of them individually are privy to. In 216 other words, combining the knowledge of the colluding entities 217 must not result in revealing additional group secrets. 219 12. The key management protocol should provide a mechanism to 220 securely recover from a compromise of some or all of the key 221 material. 223 13. Key management protocols may need to address real-world 224 deployment issues such as NAT-traversal and may need to 225 interface with legacy authentication mechanisms already 226 deployed. 228 In contrast to typical unicast key and SA negotiation protocols such 229 as TLS and IKE, group key management protocols provide SA and key 230 download capability. This feature may be useful for point-to-point 231 communication as well. Thus, a group key management protocol may 232 also be useful to unicast applications. In other words, group key 233 management protocols may be used for protecting multicast 234 communications, or unicast communications between members of a secure 235 group. Secure sub-group communication is also plausible using the 236 group SA. 238 There are other requirements for small group operation where there 239 will be many senders or in which all members may potentially be 240 senders. In this case, the group setup time may need to be optimized 241 to support a small, highly interactive group environment [RFC2627]. 243 The current key management architecture covers secure communication 244 in large single-sender groups, such as source-specific multicast 245 groups. Scalable operation to a range of group sizes is also a 246 desirable feature, and a better group key management protocol will 248 Internet Draft Group Key Management Architecture [PAGE 5] 249 support large, single-sender groups as well as groups that have many 250 senders. It may be that no single key management protocol can satisfy 251 the scalability requirements of all group-security applications. 253 In addition to these requirements, it is useful to emphasize two non- 254 requirements, namely, technical protection measures (TPM) [TPM] and 255 broadcast key management. TPM are used for such things as copy 256 protection by preventing the user of a device to get easy access to 257 the group keys. There is no reason why a group key management 258 protocol cannot be used in an environment where the keys are kept in 259 a tamper-resistant store using various types of hardware or software 260 to implement TPM. However, for simplicity, the MSEC key management 261 architecture described in this document considers design for 262 technical protection measures out of scope. 264 The second non-requirement is broadcast key management where there is 265 no back channel [FN93, JKKV94] or where the device is not on a 266 network, such as a digital videodisk player. We assume IP network 267 operation where there is two-way communication, however asymmetric, 268 and that authenticated key-exchange procedures can be used for member 269 registration. It is possible that broadcast applications can make 270 use of a one-way Internet group key management protocol message, and 271 a one-way rekey message as described below. 273 3.0 Overall Design of the Group Key Management Architecture 275 This section describes the overall structure of a group key 276 management protocol. The design is based upon a group controller 277 model [RFC2093, RFC2094, RFC2627, OFT, GSAKMP, and RFC3547] with a 278 single group owner as the root-of-trust. The group owner designates 279 a group controller for member registration and GSA rekeying. 281 3.1 Overview 283 The main goal of a group key management protocol is to securely 284 provide the group members with an up-to-date security association 285 (SA), which contains the needed information for securing group 286 communication (i.e., the group data). We call this SA the Data SA. 287 In order to obtain this goal, the Group Key Management Architecture 288 defines the following protocols. 290 (1) Registration protocol. 291 ===================== 292 This is a unicast protocol between the group controller/key server 293 (GCKS) and a joining group member. In this protocol, the GCKS and 294 joining member mutually authenticate each other. If the 295 authentication succeeds and the GCKS finds that the joining member is 296 authorized, then the GCKS supplies the joining member with the 297 following information: 299 Internet Draft Group Key Management Architecture [PAGE 6] 300 (a) Sufficient information to initialize the Data SA within the 301 joining member. This information is given only in the case that the 302 group security policy calls for initializing the Data SA at 303 registration, instead of or in addition to as part of the rekey 304 protocol. 306 (b) Sufficient information to initialize a Rekey SA within the 307 joining member (see more details about this SA below). This 308 information is given only in case that the group security policy 309 calls for using a rekey protocol. 311 The registration protocol must ensure that the transfer of 312 information from GCKS to member is done in an authenticated and 313 confidential manner over a security association. We call this SA the 314 Registration SA. A complementary de-registration protocol serves to 315 explicitly remove Registration SA state. Members may choose to 316 delete Registration SA state on their own volition. 318 (2) Rekey protocol. 319 ============== 320 A GCKS may periodically update or change the Data SA, by sending 321 rekey information to the group members. Rekey messages may result 322 from group membership changes, change in group security policy, the 323 creation of new traffic-protection keys (TPKs, see next section) for 324 the particular group, or from key expiration. Rekey messages are 325 protected by the Rekey SA, which is initialized in the registration 326 protocol. They contain information for updating the Rekey SA and/or 327 the Data SA. Rekey messages can be sent via multicast to group 328 members or unicast from the GCKS to a particular group member. 330 Note that there are other means for managing (e.g. expiring or 331 refreshing) the Data SA without interaction between the GCKS and the 332 members. For example in MARKS [MARKS], the GCKS pre-determines TPKs 333 for different periods in the lifetime of the secure group and 334 distributes keys to members based on their membership periods. 335 Alternative schemes such as the GCKS disbanding the secure group and 336 starting a new group with a new Data SA are also possible, although 337 this type of operation is typically limited to small groups. 339 Rekey messages are authenticated using one of the two following 340 options: 342 o The first option is to use source authentication [TAXONOMY], that 343 is to enable each group member to verify that a rekey message 344 originates with the GCKS and none other. 346 o The second option is to use only group-based authentication 347 using a symmetric key. Members can only be assured that the 348 rekey messages originated within the group. Therefore, this is 350 Internet Draft Group Key Management Architecture [PAGE 7] 351 applicable only when all members of the group are trusted not 352 to impersonate the GCKS. Group authentication for rekey 353 messages is typically used when public-key cryptography is not 354 suitable for the particular group. 356 The rekey protocol ensures that all members receive the rekey 357 information in a timely manner. In addition, the rekey protocol 358 specifies mechanisms for the parties to contact the GCKS and re-synch 359 in case that their keys expired and an updated key has not yet been 360 received. The rekey protocol for large-scale groups offers 361 mechanisms to avoid implosion problems and ensure the needed 362 reliability in its delivery of keying material. 364 Rekey messages are protected by a Rekey SA, which is established by 365 the registration protocol, and updated using rekey protocol. When a 366 member leaves the group, it destroys its local copy of the GSA. Use 367 of a de-registration message may be an efficient mechanisms for a 368 member to inform the GCKS that it has destroyed the SAs, or is about 369 to destroy them. Such a message may prompt the GCKS to 370 cryptographically remove the member from the group (i.e., to prevent 371 the member from having access to future group communication). In 372 large-scale multicast applications, however, de-registration has the 373 potential to cause implosion at the GCKS. 375 3.2 Detailed Description of the GKM Architecture 377 Figure 1 depicts the overall design of a GKM protocol. Each group 378 member, sender or receiver, uses the registration protocol to get 379 authorized, authenticated access to a particular Group, its policies, 380 and its keys. The two types of group keys are the key encryption keys 381 (KEKs) and the traffic encryption keys (TEKs). For group 382 authentication of rekey messages or data, key integrity keys or 383 traffic integrity keys may be used as well. We use the term 384 protection keys to refer to both integrity keys and the encryption 385 keys. For example, the term traffic protection key (TPK) is used to 386 denote the combination of a TEK and a traffic integrity key, or key 387 material used to generate them. 389 The KEK may be a single key that protects the rekey message, 390 typically containing a new Rekey SA (containing a KEK) and/or Data SA 391 (containing a TEK). A Rekey SA may also contain a vector of keys 392 that are part of a group key membership algorithm [RFC2627, OFT, 393 TAXONOMY, SD1, SD2]. The TPKs are used by the data security protocol 394 to protect streams, files, or other data sent and received by the 395 data security protocol. Thus the registration protocol and/or the 396 rekey protocol establish the KEK(s) and/or the TPKs. 398 Internet Draft Group Key Management Architecture [PAGE 8] 399 +------------------------------------------------------------------+ 400 | +-----------------+ +-----------------+ | 401 | | POLICY | | AUTHORIZATION | | 402 | | INFRASTRUCTURE | | INFRASTRUCTURE | | 403 | +-----------------+ +-----------------+ | 404 | ^ ^ | 405 | | | | 406 | v v | 407 | +--------------------------------------------------------------+ | 408 | | | | 409 | | +--------------------+ | | 410 | | +------>| GCKS |<------+ | | 411 | | | +--------------------+ | | | 412 | | REGISTRATION or | REGISTRATION or | | 413 | | DE-REGISTRATION | DE-REGISTRATION | | 414 | | PROTOCOL | PROTOCOL | | 415 | | | | | | | 416 | | v REKEY v | | 417 | | +-----------------+ PROTOCOL +-----------------+ | | 418 | | | | (OPTIONAL) | | | | 419 | | | SENDER(S) |<-------+-------->| RECEIVER(S) | | | 420 | | | | | | | | 421 | | +-----------------+ +-----------------+ | | 422 | | | ^ | | 423 | | v | | | 424 | | +-------DATA SECURITY PROTOCOL-------+ | | 425 | | | | 426 | +--------------------------------------------------------------+ | 427 | | 428 +------------------------------------------------------------------+ 429 FIGURE 1: Group Security Association Model 431 There are a few, distinct outcomes to a successful registration 432 Protocol exchange. 434 o If the GCKS uses rekey messages, then the admitted member 435 receives the Rekey SA. The Rekey SA contains the groups 436 rekey policy (note that not all of the policy need to be 437 revealed to members), and at least a group KEK. In 438 addition, the GCKS may send a group key integrity key, and 439 if the group uses a group key management algorithm, a set 440 of KEKs (or key material used to derive the KEKs) according 441 to the particular algorithm. 443 o If rekey messages are not used for the Group, then the 444 admitted member will receive TPKs (as part of the Data 445 Security SAs) that are passed to the members Data Security 446 Protocol (as IKE does for IPsec). 448 Internet Draft Group Key Management Architecture [PAGE 9] 449 o The GCKS may pass one or more TPKs to the member even if 450 rekey messages are used, for efficiency reasons according 451 to group policy. 453 The GCKS creates the KEK and TPKs and downloads them to each member - 454 as the KEK and TPKs are common to the entire group. The GCKS is a 455 separate, logical entity that performs member authentication and 456 authorization according to the group policy that is set by the group 457 owner. The GCKS may present a credential to the group member that is 458 signed by the group owner so the member can check the GCKSs 459 authorization. The GCKS, which may be co-located with a member or be 460 a separate physical entity, runs the rekey protocol to push rekey 461 messages containing refreshed KEKs, new TPKs, and/or refreshed TPKs 462 to members. Note that some group key management algorithms refresh 463 any of the KEKs (potentially), whereas others only refresh the group 464 KEK. 466 Alternatively, the sender may forward rekey messages on behalf of the 467 GCKS when it uses a credential mechanism that supports delegation. 468 Thus, it is possible for the sender (or other members) to source 469 keying material - TPKs encrypted in the Group KEK - as it sources 470 multicast or unicast data. As mentioned above, the rekey message can 471 be sent using unicast or multicast delivery. Upon receipt of a TPK 472 (as part of a Data SA) from a rekey message or a registration 473 protocol exchange, the members group key management functional block 474 will provide the new or updated security association (SA) to the data 475 security protocol to protect the data sent from sender to receiver. 477 The Data SA protects the data sent on the arc labeled DATA SECURITY 478 PROTOCOL shown in Figure 1. A second SA, the Rekey SA, is optionally 479 established by the key-management protocol for rekey messages as 480 shown in Figure 1 by the arc labeled REKEY PROTOCOL. The rekey 481 message is optional because all keys, KEKs and TPKs, can be delivered 482 by the registration protocol exchanges shown in Figure 1, and those 483 keys may not need to be updated. The registration protocol is 484 protected by a third, unicast, SA between the GCKS and each member; 485 this is called the Registration SA. There may be no need for the 486 Registration SA to remain in place after the completion of the 487 registration protocol exchanges. The de-registration protocol may be 488 used when explicit teardown of the SA is desirable (such as when a 489 phone call or conference terminates). The three SAs compose the GSA. 490 Only one SA is optional and that is the Rekey SA. 492 Figure 1 shows two blocks that are external to the group key 493 management protocol: The policy and authorization infrastructures 494 are discussed in Section 6.1. The Multicast Security Architecture 495 document further clarifies the SAs and their use as part of the 496 complete architecture of a multicast security solution [MSEC-Arch]. 498 Internet Draft Group Key Management Architecture [PAGE 10] 499 3.3 Properties of the Design 501 The design of Section 3.2 achieves scalable operation by (1) allowing 502 the de-coupling of authenticated key exchange in a registration 503 protocol from a rekey protocol, (2) allowing the rekey protocol to 504 use unicast push or multicast distribution of group and data keys as 505 an option, (3) allowing all keys to be obtained by the unicast 506 registration protocol, and (4) delegating the functionality of the 507 GCKS among multiple entities, i.e., to permit distributed operation 508 of the GCKS. 510 High-capacity operation is obtained by (1) amortizing 511 computationally-expensive asymmetric cryptography over multiple data 512 keys used by data security protocols, (2) supporting multicast 513 distribution of symmetric group and data keys, and (3) supporting key 514 revocation algorithms such as LKH [RFC2627, OFT, SDR] that allow 515 members to be added or removed at logarithmic rather than linear 516 space/time complexity. The registration protocol may use asymmetric 517 cryptography to authenticate joining members and optionally establish 518 the group KEK. Asymmetric cryptography such as Diffie-Hellman key 519 agreement and/or digital signatures are amortized over the life of 520 the group KEK: A Data SA can be established without the use of 521 asymmetric cryptography - the TPKs are simply encrypted in the 522 symmetric KEK and sent unicast or multicast in the rekey protocol. 524 The design of the registration and rekey protocols is flexible. The 525 registration protocol establishes either a Rekey SA or one or more 526 Data SAs or both types of SAs. At least one of the SAs is present 527 (otherwise, there is no purpose to the Registration SA). The Rekey 528 SA may update the Rekey SA, or establish or update one or more Data 529 SAs. Individual protocols or configurations may take advantage of 530 this flexibility for efficient operation. 532 3.4 Group Key Management Block Diagram 534 In the block diagram of Figure 2, group key management protocols run 535 between a GCKS and member principal to establish a Group Security 536 Association (GSA). The GSA consists of a Data SA, an optional Rekey 537 SA, and a Registration SA. The GCKS may use a delegated principal, 538 such as the sender, which has a delegation credential signed by the 539 GCKS. The Member of Figure 2 may be a sender or receiver of 540 multicast or unicast data. There are two functional blocks in Figure 541 2 labeled GKM, and there are two arcs between them depicting the 542 group key-management registration (reg) and rekey (rek) protocols. 543 The message exchanges are the GSA establishment protocols, which are 544 the registration protocol and the rekey protocol described above. 546 Figure 2 shows that a complete group-key management functional 547 specification includes much more than the message exchange. Some of 548 these functional blocks and the arcs between them are peculiar to an 550 Internet Draft Group Key Management Architecture [PAGE 11] 551 operating system (OS) or vendor product, such as vendor 552 specifications for products that support updates to the IPsec 553 Security Association Database (SAD) and Security Policy Database 554 (SPD) [RFC2367]. Various vendors also define the functions and 555 interface of credential stores, CRED in Figure 2. 557 +----------------------------------------------------------+ 558 | | 559 | +-------------+ +------------+ | 560 | | CONTROL | | CONTROL | | 561 | +------^------+ +------|-----+ +--------+ | 562 | | | +-----| CRED | | 563 | | | | +--------+ | 564 | +----v----+ +----v--v-+ +--------+ | 565 | | <-----Reg-----> |<->| SAD | | 566 | | GKM -----Rek-----> GKM | +--------+ | 567 | | | | | +--------+ | 568 | | ------+ | |<->| SPD | | 569 | +---------+ | +-^-------+ +--------+ | 570 | +--------+ | | | | | 571 | | CRED |----->+ | | +-------------------+ | 572 | +--------+ | | +--------------------+ | | 573 | +--------+ | +-V-------+ +--------+ | | | 574 | | SAD <----->+ | |<->| SAD <-+ | | 575 | +--------+ | |SECURITY | +--------+ | | 576 | +--------+ | |PROTOCOL | +--------+ | | 577 | | SPD <----->+ | |<->| SPD <----+ | 578 | +--------+ +---------+ +--------+ | 579 | | 580 | (A) GCKS (B) MEMBER | 581 +----------------------------------------------------------+ 582 Figure 2: Group key management block diagram for a host computer 584 The CONTROL function directs the GCKS to establish a group, admit a 585 member, or remove a member, or it directs a member to join or leave a 586 group. CONTROL includes authorization, which is subject to group 587 policy [GSPT], but how this is done is specific to the GCKS 588 implementation. For large-scale multicast sessions, CONTROL could 589 perform session announcement functions to inform a potential group 590 member that it may join a group or receive group data (e.g. a stream 591 of file transfer protected by a data security protocol). 592 Announcements notify group members to establish multicast SAs in 593 advance of secure multicast data transmission. Session Description 594 Protocol (SDP) is one form that the announcements might take 595 [RFC2327]. The announcement function may be implemented in a 596 session-directory tool, an electronic program guide (EPG), or by 597 other means. The Data Security or the announcement function directs 598 group key management using an application-programming interface 599 (API), which is peculiar to the host OS in its specifics. A generic 601 Internet Draft Group Key Management Architecture [PAGE 12] 602 API for group key management is for further study, but this function 603 is necessary to allow Group (KEK) and Data (TPKs) key establishment 604 to be done in a way that is scalable to the particular application. 605 A GCKS application program will use the API to initiate the 606 procedures to establish SAs on behalf of a Security Protocol in which 607 members join secure groups and receive keys for streams, files or 608 other data. 610 The goal of the exchanges is to establish a GSA through updates to 611 the SAD of a key-management implementation and particular Security 612 Protocol. The data security protocol of Figure 2 may span 613 internetwork and application layers or operate at the internetwork 614 layer, such as AH and ESP. 616 4.0 Registration protocol 618 The design of the registration protocol is flexible, and can support 619 different application scenarios. The chosen registration protocol 620 solution reflects the specific requirements of specific scenarios. 621 In principle, it is possible to base a registration protocol on any 622 secure-channel protocol, such as IPsec and TLS, which is the case in 623 tunneled GSAKMP [tGSAKMP]. GDOI [RFC3547] reuses IKE Phase 1 as the 624 secure channel to download Rekey and/or Data SAs. Other protocols, 625 such as MIKEY and GSAKMP, use authenticated Diffie-Hellman exchanges 626 similar to IKE Phase 1, but specifically tailored for key download 627 to achieve efficient operation. We discuss the design of a 628 registration protocol in detail in the rest of this section. 630 4.1 Registration protocol via Piggybacking or Protocol Reuse 632 Some registration protocols need to tunnel through a data-signaling 633 protocol to take advantage of already existing security 634 functionality, and/or to optimize the total session setup time. For 635 example, a telephone call has strict bounds for delay in setup time. 636 It is not feasible to run security exchanges in parallel with call 637 setup since the latter often resolves the address: Call setup must 638 complete before the caller knows the address of the callee. In this 639 case, it may be advantageous to tunnel the key exchange procedures 640 inside call establishment [H.235, MIKEY] so both can complete (or 641 fail, see below) at the same time. 643 The registration protocol has different requirements depending on 644 the particular integration/tunneling approach. These requirements 645 are not necessarily security requirements, but will have an impact 646 on the chosen security solution. For example, the security 647 association will certainly fail if the call setup fails in the case 648 of IP telephony. 650 Internet Draft Group Key Management Architecture [PAGE 13] 651 Conversely, the registration protocol imposes requirements on the 652 protocol that tunnels it. In the case of IP telephony, the call 653 setup usually will fail when the security association is not 654 successfully established. In the case of video-on-demand, protocols 655 such as RTSP that convey key management data will fail when a needed 656 security association cannot be established. 658 Both GDOI and MIKEY use this approach, but in different ways. MIKEY 659 can be tunneled in SIP and RTSP. It takes advantage of the session 660 information contained in these protocols and the possibility to 661 optimize the setup time for the registration procedure. SIP 662 requires that a tunneled protocol must use at most one roundtrip 663 (i.e. two messages). This is also desirable requirement from RTSP 664 as well. 666 The GDOI approach takes advantage of the already defined ISAKMP 667 phase 1 exchange [RFC2409], and extends the phase 2 exchange for the 668 registration. The advantage here is the reuse of a successfully 669 deployed protocol and the code base, where the defined phase 2 670 exchange is protected by the SA created by phase 1. GDOI also 671 inherits other functionality of the ISAKMP, and thus it is readily 672 suitable for running IPsec protocols over IP multicast services. 674 4.2 Properties of Alternative registration Exchange Types 676 The required design properties of a registration protocol have 677 different tradeoffs. A protocol that provides perfect forward 678 secrecy and identity protection trades performance or efficiency for 679 better security, while a protocol that completes in one or two 680 messages may trade security functionality (e.g. identity protection) 681 for efficiency. 683 Replay protection generally uses either a timestamp or a sequence 684 number. The first requires synchronized clocks, while the latter 685 requires that it is possible to keep state. In a timestamp-based 686 protocol, a replay cache is needed to store the authenticated 687 messages (or the hashes of the messages) received within the 688 allowable clock skew. The size of the replay cache depends on the 689 number of authenticated messages received during the allowable clock 690 skew. During a DoS attack, the replay cache might become 691 overloaded. One solution is to over-provision the replay cache. 692 However, this may lead to a large replay cache. Another solution is 693 to let the allowable clock skew be changed dynamically during 694 runtime. During a suspected DoS attack, the allowable clock skew is 695 decreased so that the replay cache becomes manageable. 697 A challenge-response mechanism (using Nonces) obviates the need for 698 synchronized clocks for replay protection when the exchange uses 699 three or more messages [MVV]. 701 Internet Draft Group Key Management Architecture [PAGE 14] 702 Additional security functions become possible as the number of 703 allowable messages in the registration protocol increase. ISAKMP 704 offers identity protection, for example, as part of a six-message 705 exchange. With additional security features, however, comes added 706 complexity: Identity protection, for example, not only requires 707 additional messages, but may result in DoS vulnerabilities since 708 authentication is performed in a late stage of the exchange after 709 resources already have been devoted. 711 In all cases, there are tradeoffs with the number of message 712 exchanged, the desired security services, and the amount of 713 infrastructure that is needed to support the group key management 714 service. Whereas protocols that use two or even one-message setup 715 have low latency and computation requirements, they may require more 716 infrastructure such as secure time or offer less security such as 717 the absence of identity protection. What tradeoffs are acceptable 718 and what are not is very much dictated by the application and 719 application environment. 721 4.3 Infrastructure for Alternative registration Exchange Types 723 The registration protocol may need external infrastructures to be 724 able to handle authentication and authorization, replay protection, 725 protocol-run integrity, and potentially other security services such 726 as secure, synchronized clocks. For example, authentication and 727 authorization may need a PKI deployment (with either authorization- 728 based certificates or a separate management for this) or may be 729 handled by using AAA infrastructure. Replay protection using 730 timestamps requires an external infrastructure or protocol for clock 731 synchronization. 733 However, external infrastructures may not always be needed, if for 734 example pre-shared keys are used for authentication and 735 authorization; this may be the case if the subscription base is 736 relatively small. In a conversational multimedia scenario (e.g., a 737 VoIP call between two or more people), it may very well be the end 738 user who handles the authorization by manually accepting/rejecting 739 the incoming calls. Thus, infrastructure support may not be 740 required in that case. 742 4.4 De-registration Exchange 744 The session-establishment protocol (e.g., SIP, RTSP) that conveys a 745 registration exchange often has a session-disestablishment protocol 746 such as RTSP TEARDOWN [RFC2326] or SIP BYE [RFC2543]. The session- 747 disestablishment exchange between endpoints offers an opportunity to 748 signal the end of the GSA state at the endpoints. This exchange 749 need only be a uni-directional notification by one side that the GSA 750 is to be destroyed. For authentication of this notification, we may 752 Internet Draft Group Key Management Architecture [PAGE 15] 753 use a proof-of-possession of the group key(s) by one side to the 754 other. Some applications benefit from acknowledgement in a mutual, 755 two-message exchange signaling disestablishment of the GSA 756 concomitant with disestablishment of the session, e.g., RTSP or SIP 757 session. In this case, a two-way proof-of-possession might serve 758 for mutual acknowledgement of the GSA disestablishment. 760 5.0 Rekey protocol 762 The group rekey protocol is for transport of keys and SAs between a 763 GCKS and the members of a secure communications group. The GCKS 764 sends rekey messages to update a Rekey SA, or initialize/update a 765 Data SA or both. Rekey messages are protected by a Rekey SA. The 766 GCKS may update the Rekey SA when group membership changes or when 767 KEKs or TPKs expire. Recall that KEKs correspond to a Rekey SA and 768 TPKs correspond to a Data SA. 770 The following are some desirable properties of the rekey protocol: 772 o Rekey protocol ensures that all members receive the rekey 773 information in a timely manner. 775 o Rekey protocol specifies mechanisms for the parties 776 involved, to contact the GCKS and re-sync when their keys expire 777 and no updates have been received. 779 o Rekey protocol avoids implosion problems and ensures the 780 needed reliability in delivering Rekey information. 782 We further note that the rekey protocol is primarily responsible for 783 scalability of the group key management architecture. Hence it is 784 imperative that we provide the above listed properties in a scalable 785 manner. Note that solutions exist in the literature (both IETF 786 standards and research articles) for parts of the problem. For 787 instance, the rekey protocol may use a scalable group key management 788 algorithm (GKMA) to reduce the number of keys sent in a rekey 789 message. Examples of a GKMA include LKH, OFT, Subset difference 790 based schemes etc. 792 5.1 Goals of the rekey protocol 794 The goals of the rekey protocol are: 796 o to synchronize a GSA 798 o to provide privacy and (symmetric or asymmetric) 799 authentication, replay protection and DoS protection 801 Internet Draft Group Key Management Architecture [PAGE 16] 802 o efficient rekeying after changes in group membership, or when 803 keys (KEKs) expire, 805 o reliable delivery of rekey messages, 807 o provide methods for members to recover from an out-of-sync 808 GSA, 810 o high throughput and low latency, and 812 o to use IP Multicast or multi-unicast. 814 We identify several major issues in the design of a rekey protocol: 816 1. rekey message format 818 2. reliable transport of rekey messages 820 3. implosion 822 4. recovery from out-of-sync GSA 824 5. incorporating GKMAs in rekey messages 826 6. interoperability of GKMAs 828 Note that for a GCKS to successfully rekey a group, it is not 829 sufficient that rekey protocol implementations interoperate. We also 830 need to ensure that the GKMA also interoperates, i.e., standards 831 versions of group key management algorithms, such as LKH, OFT, subset 832 difference and others need to be used. 834 In the rest of this section we discuss these topics in detail. 836 5.2 Rekey message Transport and Protection 838 Rekey messages contain Rekey and/or Data SAs along with KEKs and 839 TPKs. These messages need to be confidential, authenticated, and 840 protected against replay and DoS attacks. They are sent via 841 multicast or multi-unicast from the GCKS to the members. 843 Rekey messages are encrypted with the Group KEK for confidentiality. 844 When used in conjunction with a GKMA, portions of the rekey message 845 are first encrypted with the appropriate KEKs as specified by the 846 GKMA. The GCKS authenticates rekey messages using either a MAC - 847 computed using the group Authentication key - or a digital signature. 848 In both cases, a sequence number is included in computation of the 849 MAC or the signature to protect against replay attacks. 851 Internet Draft Group Key Management Architecture [PAGE 17] 852 When group authentication is provided - with a symmetric key - rekey 853 messages are vulnerable to attacks by other members of the group. 854 Rekey messages are digitally signed when group members do not trust 855 each other. When asymmetric authentication is used, members 856 receiving rekey messages are vulnerable to DoS attacks. An external 857 adversary may send a bogus rekey message, which a member cannot 858 identify until after it performs an expensive digital signature 859 operation. To protect against such an attack, a MAC may be sent as 860 part of the rekey message. Members verify the signature only upon 861 successful verification of the MAC. 863 Rekey messages contain group key updates corresponding to a single 864 [RFC2627, OFT] or multiple membership changes [SD, BatchRekey] and 865 may contain group key initialization messages [OFT]. 867 5.3 Reliable Transport of rekey messages 869 The GCKS needs to ensure that all members have the current Data 870 Security and Rekey SAs. Otherwise, authorized members may be 871 inadvertently excluded from receiving group communications. Thus, 872 the GCKS needs to use a rekey algorithm that is inherently reliable 873 or employ some reliable transport mechanism to send rekey messages. 875 There are two dimensions to the problem: Messages that update group 876 keys may be lost in transit or may be missed by a host when it is 877 offline. LKH and OFT group key management algorithms rely on past 878 history of updates being received by the host. If the host goes 879 offline, it will need to resynchronize its group-key state when it 880 comes online; this may require a unicast exchange with the GCKS. 881 The Subset Difference algorithm, however, conveys all the needed 882 state in its rekey messages and does not need members to be always 883 online, nor keeping state. Subset difference algorithm does not 884 require a backchannel and can operate on a broadcast network. If a 885 rekey message is lost in transmission, subset difference algorithm 886 cannot decrypt messages encrypted with the TPK sent via the lost 887 rekey message. There are self-healing GKMAs proposed in the 888 literature that allow a member to recover lost rekey messages, as 889 long as rekey messages before and after the lost rekey message are 890 received. 892 Rekey messages are typically short (for single membership change as 893 well as for small groups) which makes it easy to design a reliable 894 delivery protocol. On the other hand, the security requirements may 895 add an additional dimension to address. Also there are some special 896 cases where membership changes are processed as a batch, which 897 reduces the frequency of rekey messages, but increases their size. 898 Furthermore, among all the KEKs sent in a rekey message, as many as 899 half the members need only a single KEK. We may take 900 advantage of these properties in designing a rekey message(s) and a 901 protocol for their reliable delivery. 903 Internet Draft Group Key Management Architecture [PAGE 18] 904 Three categories of solutions have been proposed: 906 1. Repeatedly transmit the rekey message: Recall that in many 907 cases rekey messages translate to only one or two IP packets. 909 2. Use an existing reliable multicast protocol/infrastructure 911 3. Use FEC for encoding rekey packets (with NACKs as feedback) 912 [BatchRekey] 914 Note that for small messages, category 3 is essentially the same as 915 category 1. 917 The group member might be out of synchrony with the GCKS if it 918 receives a rekey message having a sequence number that is more than 919 one greater than the last sequence number processed. This is one 920 means by which the GCKS member detects that it has missed a rekey 921 message. Alternatively, the data-security application might detect 922 that it is using an out-of-date key and notifies the group key 923 management module of this condition. What action the GCKS member 924 takes is a matter of group policy: The GCKS member should log the 925 condition and may contact the GCKS to re-run the re-registration 926 protocol to obtain a fresh group key. The group policy needs to 927 take into account boundary conditions, such as re-ordered rekey 928 messages when rekeying is so frequent that two messages might get 929 reordered in an IP network. The group key policy also needs to 930 take into account the potential for denial of service attacks where 931 an attacker delays or deletes a rekey message in order to force a 932 subnetwork or subset of the members to synchronously contact the 933 GCKS. 935 If a group member becomes out-of-synch with the GSA then it should 936 re-register with the GCKS. However, in many cases there are other, 937 simpler methods for re-synching with the group: 939 o The member can open a simple, unprotected connection (say, TCP) 940 with the GCKS and obtain the current (or several recent) rekey 941 messages. Note that there is no need for authentication or 942 encryption here, since the rekey message is already signed and 943 is anyway multicasted in the clear. One may think that this 944 opens the GCKS to DoS attacks by many bogus such requests. But 945 this does not seem to worsen the situation: in fact, bombarding 946 the GCKS with bogus resynch requests would be much more 947 problematic. 949 o The GCKS can post the rekey messages on some public site (say, 950 web site) and the out-of-synch memeber can obtain the rekey 951 messages from that site. 953 Internet Draft Group Key Management Architecture [PAGE 19] 954 It is suggested that the GCKS always provide all three ways of 955 resynching (i.e., re-registration, simple TCP, and public posting). 956 This way, it is up to the member to choose how to resynch; it also 957 avoids adding yet another field to the policy token [GSPT]. 958 Alternatively, a policy token may contain a field specifying one or 959 more methods supported for resynchronization of a GSA. 961 5.4 State-of-the-art on Reliable Multicast Infrastructure 963 The rekey message may be sent using reliable multicast. There are 964 multiple types of reliable multicast protocols and products, which 965 have different properties. However, there are no standard reliable 966 multicast protocols at the present time. Thus, this document makes 967 no recommendation for use of a particular reliable multicast 968 protocol or set of protocols for the purposes group key management. 969 The suitability of NAK-based, ACK-based or other reliable multicast 970 methods are determined by the particular needs of the group key 971 management application and environment. In the future, group key 972 management protocols may choose to use particular standards-based 973 approaches that meet the needs of the particular application. A 974 secure announcement facility is needed to signal the use of a 975 reliable multicast protocol, which must be specified as part of 976 group policy. The reliable multicast announcement and policy 977 specification, however, can only follow the establishment of 978 reliable multicast standards and are not considered further in this 979 document. 981 Today, the several MSEC group key management protocols support 982 sequencing of the rekey messages through a sequence number, which is 983 authenticated along with the rekey message. A sender of rekey 984 messages may re-transmit multiple copies of the message provided 985 that they have the same sequence number. Thus, re-sending the 986 message is a rudimentary means of overcoming loss along the network 987 path. A member who receives the rekey message will check the 988 sequence number to detect duplicate and missing rekey messages. The 989 member receiver will discard duplicate messages that it receives. 990 Large rekey messages, such as those that contain LKH or OFT tree 991 structures, might benefit from transport-layer FEC when standard 992 methods are available in the future. It is unlikely that forward 993 error correction (FEC) methods will benefit rekey messages that are 994 short and fit within a single message. In this case, FEC 995 degenerates to simple retransmission of the message. 997 5.5 Implosion 999 Implosion may occur due to one of two reasons. First, recall that 1000 one of the goals of the rekey protocol is to synchronize a GSA. When 1001 a rekey or Data SA expires, members may contact the GCKS for an 1002 update. If all or even many members contact the GCKS at about the 1004 Internet Draft Group Key Management Architecture [PAGE 20] 1005 same time, the GCKS cannot handle all those messages. We refer to 1006 this as an out-of-sync implosion. 1008 The second case is in the reliable delivery of rekey messages. 1009 Reliable multicast protocols use feedback (NACK or ACK) to determine 1010 which packets must be retransmitted. Packet losses may result in 1011 many members sending NACKs to the GCKS. We refer to this as feedback 1012 implosion. 1014 The implosion problem has been studied extensively in the context of 1015 reliable multicasting. Some of the proposed solutions viz., feedback 1016 suppression and aggregation, might be useful in the GKM context as 1017 well. 1019 Members may wait for a random time before sending an out-of-sync or 1020 feedback message. Meanwhile, members might receive the key updates 1021 they need and therefore will not send a feedback message. 1023 An alternative solution is to have the members contact one of several 1024 registration servers when they are out-of-sync. This requires GSA 1025 synchronization between the multiple registration servers. 1027 Feedback aggregation and local recovery employed by some reliable 1028 multicast protocols are not easily adaptable to transport of rekey 1029 messages. There are authentication issues to address in aggregation. 1030 Local recovery is more complex in that members need to establish SAs 1031 with the local repair server (Any member of the group or a 1032 subordinate GCKS might serve as a repair server. Repair servers may 1033 be responsible for resending rekey messages). 1035 Members may use the group SA, more specifically the Rekey SA, to 1036 authenticate requests sent to the repair server; however, replay 1037 protection requires maintaining state at members as well as repair 1038 servers. Authentication of repair requests is to protect against DoS 1039 attacks. Note also that an out-of-sync member may use an expired 1040 Rekey SA to authenticate repair requests, which requires repair 1041 servers to accept messages protected by old SAs. 1043 Alternatively, a simple mechanism may be employed to achieve local 1044 repair efficiently. Each member receives a set of local repair 1045 server addresses as part of group operation policy information. When 1046 a member does not receive a rekey message, it can send a "retransmit 1047 replay message(s) with sequence number n and higher" to one of the 1048 local repair servers. The repair server can do one of two things: 1049 ignore the request if it is busy, or retransmit the requested rekey 1050 messages as received from the GCKS. The repair server, which is also 1051 another member may choose to serve only m requests in a given time 1052 period (i.e., rate limits responses) or per a given rekey message. 1053 Rate limiting the requests and responses protects the repair servers 1055 Internet Draft Group Key Management Architecture [PAGE 21] 1056 as well other members of the group from being vulnerable to DoS 1057 attacks. 1059 5.6 Issues in Incorporating Group Key Management Algorithms 1061 Group key management algorithms make Rekeying scalable. Large group 1062 Rekeying without employing GKMAs is prohibitively expensive. 1064 First we list some requirements to consider in selecting a GKMA: 1066 o Protection against Collusion: Members (or non members) should 1067 not be able to collaborate to deduce keys that they are not 1068 privileged to (following the GKMA key distribution rules). 1070 o Forward access control: Ensure that departing members cannot get 1071 access to future group data. 1073 o Backward access control: Ensure that joining members cannot 1074 decrypt past data. 1076 5.7 Stateless, Stateful, and Self-healing Rekeying Algorithms 1078 We classify group key management algorithms into three categories, 1079 viz., stateful, stateless, and self-healing algorithms. 1081 Stateful algorithms [RFC2627, OFT] use KEKs from past rekeying 1082 instances to encrypt (protect) KEKS corresponding to the current and 1083 future rekeying instances. The main disadvantage in these schemes is 1084 that if a member were offline or otherwise fails to receive KEKs from 1085 a past rekeying instance, it may no longer be able to synchronize its 1086 GSA even though it can receive KEKs from all future rekeying 1087 instances. The only solution is to contact the GCKS explicitly for 1088 resynchronization. Note that the KEKs for the first rekeying 1089 instance are protected by the Registration SA. Recall that 1090 communication in that phase is one to one, and therefore it is easy 1091 to ensure reliable delivery. 1093 Stateless GKMAs [SD1, SD2] encrypt rekey messages with KEKs sent 1094 during the registration protocol. Since rekey messages are 1095 independent of any past rekey messages (i.e. not protected by KEKs 1096 therein), a member may go offline, but continue to be able to 1097 decipher future communications. However, they offer no mechanisms to 1098 recover past rekeying messages. Stateless rekeying may be relatively 1099 inefficient, particularly for immediate (in contrast to batch) 1100 rekeying in highly dynamic groups. 1102 In self-healing schemes [Self-healing], a member can reconstruct a 1103 lost rekey message, as long as it receives some past rekey messages 1104 and some future rekey messages. 1106 Internet Draft Group Key Management Architecture [PAGE 22] 1107 5.8 Interoperability of a GKMA 1109 Most GKMA specifications do not specify packet formats although any 1110 group key management algorithms need to, for the purposes of 1111 interoperability. In particular there are several alternative ways 1112 to managing key trees and numbering nodes within key trees. The 1113 following information is generally needed during initialization of a 1114 Rekey SA or included with each GKMA packet. 1116 o GKMA name (e.g. LKH, OFT, Subset difference) 1118 o GKMA version number (implementation specific). Version may imply 1119 several things such as the degree of a key tree, proprietary 1120 enhancements, and qualify another field such as a key id. 1122 o Number of keys or Largest ID 1124 o Version specific data 1126 o Per key information 1128 - Key ID 1130 - Key lifetime (creation/expiration data) 1132 - Encrypted key 1134 - Encryption key's ID (optional) 1136 Key IDs may change in some implementations in which case we need to 1137 send: 1139 o List of 1141 6.0 Group Security Association 1143 The GKM Architecture defines the interfaces between the registration, 1144 Rekey, and data security protocols in terms of the Security 1145 Associations (SAs) of those protocols. By isolating these protocols 1146 behind a uniform interface, the architecture allows implementations 1147 to use protocols best suited to their needs. For example, a rekey 1148 protocol for a small group could use multiple unicast transmissions 1149 with symmetric authentication, while that for a large group could use 1150 IP Multicast with packet-level Forward Error Correction and source 1151 authentication. 1153 The Group Key Management Architecture provides an interface between 1154 the security protocols and the group SA (GSA), which consists of 1156 Internet Draft Group Key Management Architecture [PAGE 23] 1157 three SAs, viz., Registration SA, Rekey SA and Data SA. The Rekey SA 1158 is optional. There are two cases in defining the relationships 1159 between the three SAs. In both cases, the Registration SA protects 1160 the registration protocol. 1162 In Case 1, group key management is done WITHOUT using a Rekey SA. The 1163 registration protocol initializes and updates one or more Data SAs 1164 (having TPKs to protect files or streams). Each Data SA corresponds 1165 to a single group - and a group may have more than one Data SA. 1167 In Case 2, group key management is done WITH a Rekey SA to protect 1168 the rekey protocol. The registration protocol initializes the Rekey 1169 SAs (one or more) as well as zero or more Data SAs upon successful 1170 completion. When a Data SA is not initialized in the registration 1171 protocol, this is done in the rekey protocol. The rekey protocol 1172 updates Rekey SA(s) AND establishes Data SA(s). 1174 6.1 Group policy 1176 Group policy is described in detail in the Group Security Policy 1177 Token document [GSPT]. Group policy can be distributed through group 1178 announcements, key management protocols, and other out-of-band means 1179 (e.g., via a web page). The group key management protocol carries 1180 cryptographic policies of the SAs and keys it establishes as well as 1181 additional policies for the secure operation of the group. 1183 The acceptable cryptographic policies for the registration protocol, 1184 which may run over TLS [TLS], IPsec, or IKE, are not conveyed in the 1185 group key-management protocol since they precede any of the key 1186 management exchanges. Thus, a security policy repository having some 1187 access protocol may need to be queried prior to key-management 1188 session establishment to determine the initial cryptographic policies 1189 for that establishment. This document assumes the existence of such 1190 a repository and protocol for GCKS and member policy queries. 1191 Thus group security policy will be represented in a policy repository 1192 and accessible using a policy protocol. Policy distribution may be a 1193 push or a pull operation. 1195 The group key management architecture assumes that the following 1196 group-policy information may be externally managed, e.g., by the 1197 content owner, group conference administrator or group owner. 1199 o Identity of the Group owner, and authentication method, and 1200 delegation method for identifying a GCKS for the group 1202 o Group GCKS, authentication method, and delegation method for any 1203 subordinate GCKSs for the group 1205 o Group membership rules or list and authentication method 1207 Internet Draft Group Key Management Architecture [PAGE 24] 1208 There are also two additional policy-related requirements external to 1209 group key management. 1211 o There is an authentication and authorization infrastructure such 1212 as X.509 [RFC 2459], SPKI [RFC 2693], or a pre-shared key scheme 1213 in accordance with the group policy for a particular group. 1215 o There is an announcement mechanism for secure groups and events 1216 that operates according to group policy for a particular group. 1218 Group policy determines how the registration and rekey protocols 1219 initialize or update Rekey and Data SAs. The following sections 1220 describe potential information sent by the GCKS for the Rekey and 1221 Data SAs. A member needs to have the information specified in the 1222 next sections to establish Rekey and Data SAs. 1224 6.2 Contents of the Rekey SA 1226 The Rekey SA protects the rekey protocol. It contains cryptographic 1227 policy, Group Identity and Security Parameter Index (SPI) [RFC2401] 1228 to uniquely identify an SA, replay protection information, and key 1229 protection keys. 1231 6.2.1 Rekey SA Policy 1233 The GROUP KEY MANAGEMENT ALGORITHM represents the group key 1234 revocation algorithm that enforces forward and backward access 1235 control. Examples of key revocation algorithms include LKH, LKH+, 1236 OFT, OFC and Subset Difference [RFC2627, OFT, TAXONOMY, SDR]. The 1237 key revocation algorithm could also be NULL. In that case, the Rekey 1238 SA contains only one KEK, which serves as the group KEK. The rekey 1239 messages initialize or update Data SAs as usual. But, the Rekey SA 1240 itself can be updated (group KEK can be Rekeyed) when members join or 1241 the KEK is about to expire. Leave Rekeying is done by re- 1242 initializing the Rekey SA through the rekey protocol. 1244 The KEK ENCRYPTION ALGORITHM uses a standard encryption algorithm 1245 such as 3DES or AES. The KEK KEY LENGTH is also specified. 1247 The AUTHENTICATION ALGORITHM uses digital signatures for GCKS 1248 authentication (since all shared secrets are known to some or all 1249 members of the group), or some symmetric secret in computing MACs for 1250 group authentication. Symmetric authentication provides weaker 1251 authentication in that any group member can impersonate a particular 1252 source. The AUTHENTICATION KEY LENGTH is also be specified. 1254 The CONTROL GROUP ADDRESS is used for multicast transmission of rekey 1255 messages. This information is sent over the control channel such as 1256 in an ANNOUNCEMENT protocol or call setup message. The degree to 1258 Internet Draft Group Key Management Architecture [PAGE 25] 1259 which the control group address is protected is a matter of group 1260 policy. 1262 The REKEY SERVER ADDRESS allows the registration server to be a 1263 different entity from the server used for Rekey, such as for future 1264 invocations of the registration and rekey protocols. If the 1265 registration server and the Rekey server are two different entities, 1266 the registration server sends the Rekey servers address as part of 1267 the Rekey SA. 1269 6.2.2 Group Identity 1271 The Group identity accompanies the SA (payload) information as an 1272 identifier if the specific group key management protocol allows 1273 multiple groups to be initialized in a single invocation of the 1274 registration protocol or multiple groups to be updated in a single 1275 rekey message. It is often much simpler to restrict each 1276 registration invocation to a single group; no such restriction is 1277 necessary. There is always a need to identify the group when 1278 establishing a Rekey SA either implicitly through an SPI or 1279 explicitly as an SA parameter. 1281 6.2.3 KEKs 1283 Corresponding to the key management algorithm, the Rekey SA contains 1284 one or more KEKs. The GCKS holds the key encrypting keys of the 1285 group, while the members receive keys following the specification of 1286 the key-management algorithm. When there are multiple KEKs for a 1287 group (as in an LKH tree), each KEK needs to be associated with a Key 1288 ID, which is used to identify the key needed to decrypt it. Each KEK 1289 has a LIFETIME associated with it, after which the KEK expires. 1291 6.2.4 Authentication Key 1293 The GCKS provides a symmetric or public key for authentication of its 1294 rekey messages. Symmetric-key authentication is appropriate only 1295 when all group members can be trusted not to impersonate the GCKS. 1296 The architecture does not rule out methods for deriving symmetric 1297 authentication keys at the member [RFC2409] rather than being pushed 1298 from the GCKS. 1300 6.2.5 Replay Protection 1302 Rekey messages need to be protected from replay/reflection attacks. 1303 Sequence numbers are used for this purpose and the Rekey SA (or 1304 protocol) contains this information. 1306 6.2.6 Security Parameter Index (SPI) 1308 Internet Draft Group Key Management Architecture [PAGE 26] 1309 The tuple uniquely identifies a Rekey SA. The 1310 SPI changes each time the KEKs change. 1312 6.3 Contents of the Data SA 1314 The GCKS specifies the data security protocol used for secure 1315 transmission of data from sender(s) to receiving members. Examples 1316 of data security protocols include IPsec ESP [RFC 2401] and SRTP [RFC 1317 3711]. While the content of each of these protocols is out of the 1318 scope of this document, we list the information sent by the 1319 registration protocol (or the rekey protocol) to initialize or update 1320 the Data SA. 1322 6.3.1 Group Identity 1324 The Group identity accompanies SA information when Data SAs are 1325 initialized or Rekeyed for multiple groups in a single invocation of 1326 the registration protocol or in a single rekey message. 1328 6.3.2 Source Identity 1330 The SA includes source identity information when the group owner 1331 chooses to reveal Source identity to authorized members only. A 1332 public channel such as announcement protocol is only appropriate when 1333 there is no need to protect source or group identities. 1335 6.3.3 Traffic Protection Keys 1337 Irrespective of the data security protocol used, the GCKS supplies 1338 the TEKs or information to derive TEKs, used for data encryption. 1340 6.3.4 Data Authentication Keys 1342 Depending on the data-authentication method used by the data security 1343 protocol, group key management may pass one or more keys, functions 1344 (e.g., TESLA [TESLA]), or other parameters used for authenticating 1345 streams or files. 1347 6.3.5 Sequence Numbers 1349 The GCKS passes sequence numbers when needed by the data security 1350 protocol, for SA synchronization and replay protection. 1352 6.3.6 Security Parameter Index (SPI) 1354 The GCKS may provide an identifier as part of the Data SA contents 1355 for data security protocols that use an SPI or similar mechanism to 1356 identify an SA or keys within an SA. 1358 Internet Draft Group Key Management Architecture [PAGE 27] 1359 6.3.7 Data SA policy 1361 The Data SA parameters are specific to the data security protocol but 1362 generally include encryption algorithm and parameters, the source 1363 authentication algorithm and parameters, the group authentication 1364 algorithm and parameters, and/or replay protection information. 1366 7.0 Scalability Considerations 1368 The area of group communications is quite diverse. In 1369 teleconferencing, a multipoint control unit (MCU) may be used to 1370 aggregate a number of teleconferencing members into a single session; 1371 MCUs may be hierarchically organized as well. A loosely coupled 1372 teleconferencing session [RFC3550] has no central controller but is 1373 fully distributed and end-to-end. Teleconferencing sessions tend to 1374 have at most dozens of participants whereas video broadcast, which 1375 uses multicast communications, and media on demand, which uses 1376 unicast, are large-scale groups numbering hundreds to millions of 1377 participants. 1379 As described in the Requirements section above, the group key 1380 management architecture supports multicast applications with a single 1381 sender. The architecture described in this paper supports large- 1382 scale operation through the following features. 1384 1. There is no need for a unicast exchange to provide data keys to a 1385 security protocol for members who have previously-registered in the 1386 particular group; data keys can be pushed in the rekey protocol. 1388 2. The registration and rekey protocols are separable to allow 1389 flexibility in how members receive group secrets. A group can use a 1390 smart-card based system in place of the registration protocol, for 1391 example, to allow the rekey protocol to be used with no back channel 1392 for broadcast applications such as television conditional access 1393 systems. 1395 3. The registration and rekey protocols support new keys, algorithms, 1396 authentication mechanisms and authorization infrastructures in the 1397 architecture. When the authorization infrastructure supports 1398 delegation, as in X.509 and SPKI, the GCKS function can be 1399 distributed as shown in Figure 3. 1401 Internet Draft Group Key Management Architecture [PAGE 28] 1402 +----------------------------------------+ 1403 | +-------+ | 1404 | | GCKS | | 1405 | +-------+ | 1406 | | ^ | 1407 | | | | 1408 | | +---------------+ | 1409 | | ^ ^ | 1410 | | | ... | | 1411 | | +--------+ +--------+ | 1412 | | | MEMBER | | MEMBER | | 1413 | | +--------+ +--------+ | 1414 | v | 1415 | +-------------+ | 1416 | | | | 1417 | v ... v | 1418 | +-------+ +-------+ | 1419 | | GCKS | | GCKS | | 1420 | +-------+ +-------+ | 1421 | | ^ | 1422 | | | | 1423 | | +---------------+ | 1424 | | ^ ^ | 1425 | | | ... | | 1426 | | +--------+ +--------+ | 1427 | | | MEMBER | | MEMBER | | 1428 | | +--------+ +--------+ | 1429 | v | 1430 | ... | 1431 +----------------------------------------+ 1432 Figure 3: Hierarchically-organized Key Distribution 1434 The first feature in the list allows fast keying of data security 1435 protocols when the member already belongs to the group. While this 1436 is realistic for subscriber groups and customers of service providers 1437 who offer content events, it may be too restrictive for applications 1438 that allow member enrollment at the time of the event. The MSEC 1439 group key management architecture suggests hierarchically organized 1440 key distribution to handle potential mass simultaneous registration 1441 requests. The Figure 3 configuration may be needed when conventional 1442 clustering and load-balancing solutions of a central GCKS site cannot 1443 meet customer requirements. Unlike conventional caching and content- 1444 distribution networks, however, the configuration shown in Figure 3 1445 has additional security ramifications for physical security of a 1446 GCKS. 1448 More analysis and work needs to be done on the protocol 1449 instantiations of the group key management architecture to determine 1450 how effectively and securely the architecture can support large- 1451 scale multicast applications. In addition to being as secure as 1453 Internet Draft Group Key Management Architecture [PAGE 29] 1454 pairwise key management against man-in-the-middle, replay, and 1455 reflection attacks, group key management protocols have additional 1456 security needs. Unlike pairwise key management, group key 1457 management needs to be secure against attacks not only by non- 1458 members but by members who may attempt to impersonate a GCKS or 1459 disrupt the operation of a GCKS. Thus, secure groups need to 1460 converge to a common group key under the conditions of members 1461 attacking the group, joining and leaving the group, and being 1462 evicted from the group. Group key management protocols also need to 1463 be robust when denial of service attacks or network partitions lead 1464 to large numbers of synchronized requests. An instantiation of 1465 group key management, therefore, needs to consider how GCKS 1466 operation might be distributed across multiple GCKS as designated by 1467 the group owner to serve keys on behalf of a designated GCKS. 1468 GSAKMP [GSAKMP] protocol uses the policy token and allows 1469 designating some of the members as subordinate GCKSs to address this 1470 scalability issue. 1472 8.0 Security Considerations 1474 This memo describes MSEC key management architecture. This 1475 architecture will be instantiated in one or more group key management 1476 protocols, which must be protected against man-in-the-middle, 1477 connection hijacking, replay or reflection of past messages, and 1478 denial of service attacks. 1480 Authenticated key exchange [STS, SKEME, RFC2408, RFC2412, RFC2409] 1481 techniques limit the effects of man-in-the-middle and connection- 1482 hijacking attacks. Sequence numbers and low-computation message 1483 authentication techniques can be effective against replay and 1484 reflection attacks. Cookies [RFC2522], when properly implemented, 1485 provide an efficient means to reduce the effects of denial of service 1486 attacks. 1488 This memo does not address attacks against key management or security 1489 protocol implementations such as so-called type attacks that aim to 1490 disrupt an implementation by such means as buffer overflow. The 1491 focus of this memo is on securing the protocol, not an implementation 1492 of the protocol. 1494 While classical techniques of authenticated key exchange can be 1495 applied to group key management, new problems arise with the sharing 1496 of secrets among a group of members: Group secrets may be disclosed 1497 by a member of the group and group senders may be impersonated by 1498 other members of the group. Key management messages from the GCKS 1499 should not be authenticated using shared symmetric secrets unless all 1500 members of the group can be trusted not to impersonate the GCKS or 1501 each other. Similarly, members who disclose group secrets undermine 1502 the security of the entire group. group owners and GCKS 1504 Internet Draft Group Key Management Architecture [PAGE 30] 1505 administrators must be aware of these inherent limitations of group 1506 key management. 1508 Another limitation of group key management is policy complexity: 1509 Whereas peer-to-peer security policy is an intersection of the policy 1510 of the individual peers, a group owner sets group security policy 1511 externally in secure groups. This document assumes there is no 1512 negotiation of cryptographic or other security parameters in group 1513 key management. Group security policy, therefore, poses new risks to 1514 members who send and receive data from secure groups. Security 1515 administrators, GCKS operators, and users need to determine minimal 1516 acceptable levels of security (e.g., authentication and admission 1517 policy of the group, key lengths, cryptographic algorithms and 1518 protocols used etc.) when joining secure groups. 1520 Given the limitations and risks of group security, the security of 1521 the group key management registration protocol should be as good as 1522 the base protocols on which it is developed such as IKE, IPsec, TLS, 1523 or SSL. The particular instantiations of this Group Key Management 1524 architecture must ensure that the high standards for authenticated 1525 key exchange are preserved in their protocol specifications, which 1526 will be Internet standards-track documents that are subject to 1527 review, analysis and testing. 1529 The second protocol, the group key management rekey protocol, is new 1530 and has unknown risks associated with it. The source-authentication 1531 risks described above are obviated by the use of public-key 1532 cryptography. The use of multicast delivery may raise additional 1533 security issues such as reliability, implosion, and denial of service 1534 attacks based upon the use of multicast. The rekey protocol 1535 specification needs to offer secure solutions to these problems. 1536 Each instantiation of the rekey protocol, such as the GSAKMP Rekey or 1537 the GDOI Groupkey-push operations, need to validate the security of 1538 their Rekey specifications. 1540 Novelty and complexity are the biggest risks to group key management 1541 protocols. Much more analysis and experience are needed to ensure 1542 that the architecture described in this document can provide a well- 1543 articulate standard for security and risks of group key management. 1545 9.0 Acknowledgments 1547 The GKM Building Block [GKMBB) I-D by SMuG was a precursor to this 1548 document; thanks to Thomas Hardjono and Hugh Harney for their 1549 efforts. During the course of preparing this document, Andrea 1550 Colegrove, Brian Weis, George Gross and several others in MSEC WG 1551 and GSEC and SMuG research groups provided valuable comments that 1552 helped improve this document. The authors appreciate their 1553 contributions to this document. 1555 Internet Draft Group Key Management Architecture [PAGE 31] 1556 10.0 References and Bibliography 1558 [BatchRekey] Yang, Y. R., et al., Reliable Group Rekeying: Design and 1559 Performance Analysis, in Proc. of ACM SIGCOMM, San Diego, CA, August 1560 2001. 1562 [CLIQUES] M. Steiner, G. Tsudik and M. Waidner, CLIQUES: A New 1563 Approach to Group Key Agreement, IEEE ICDCS 97, May 1997 1565 [FN93] A. Fiat, M. Naor, Broadcast Encryption, Advances in 1566 Cryptology - CRYPTO 93 Proceedings, Lecture Notes in Computer 1567 Science, Vol. 773, 1994, pp. 480 -- 491. 1569 [GSAKMP] H.Harney, A.Colegrove, E.Harder, U.Meth, R.Fleischer, Group 1570 Secure Association Key Management Protocol, 1571 http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-msec-gsakmp-sec- 1572 01.txt, February 2003, Work in Progress. 1574 [GSPT] Hardjono, T., H. Harney, P. McDaniel, A. Colegrove, and P. 1575 Dinsmore, The MSEC Group Security Policy Token, draft-ietf-msec-gspt- 1576 02.txt, August 2003, Work in Progress. 1578 [H.235] ITU, Security and encryption for H-Series (H.323 and other 1579 H.245-based) multimedia terminals, ITU-T Recommendation H.235 Version 1580 3, 2001, Work in progress. 1582 [JKKV94] M. Just, E. Kranakis, D. Krizanc, P. van Oorschot, On Key 1583 Distribution via True Broadcasting. In Proceedings of 2nd ACM 1584 Conference on Computer and Communications Security, November 1994, 1585 pp. 81--88. 1587 [MARKS] Briscoe, B., MARKS: Zero Side Effect Multicast Key 1588 Management Using Arbitrarily Revealed Key Sequences, in Proc. of 1589 First International Workshop on Networked Group Communication (NGC), 1590 Pisa, Italy, November 1999. 1592 [MIKEY] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. 1593 Norrman, MIKEY: Multimedia Internet KEYing, Internet Draft, 1594 http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-msec-mikey- 1595 06.txt, February 2003, Work in progress. 1597 [MSEC-Arch] Hardjono, T., and B. Weis, The Multicast Group Security 1598 Architecture, RFC 3740 (Informational), March 2004. 1600 [MVV] A.J.Menzes, P.C.van Oorschot, S.A. Vanstone, Handbook of 1601 Applied Cryptography, CRC Press, 1996. 1603 Internet Draft Group Key Management Architecture [PAGE 32] 1605 [OFT] Balenson, D., D. McGrew, and A. Sherman, Key Management for 1606 Large Dynamic Groups: One-Way Function Trees and Amortized 1607 Initialization, draft-irtf-smug-groupkeymgmt-oft-00.txt, IRTF, August 1608 2000, Work in progress. 1610 [RFC2093] Harney, H., and C. Muckenhirn, Group Key Management 1611 Protocol (GKMP) Specification, RFC 2093 (experimental), July 1997. 1613 [RFC2094] Harney, H., and C. Muckenhirn, Group Key Management 1614 Protocol (GKMP) Architecture, RFC 2094 (experimental), July 1997. 1616 [RFC2326] Schulzrinee, H., A. Rao, and R. Lanphier, Real Time 1617 Streaming Protocol (RTSP), RFC 2326 (Proposed Standard), April 1998. 1619 [RFC2327] Handley, M., and V. Jacobson, SDP: Session Description 1620 Protocol, RFC 2327 (Proposed Standard), April 1998. 1622 [RFC2367] McDonald, D., C. Metz, and B. Phan, PF_KEY Key Management 1623 API, Version 2, RFC 2367 (Informational), July 1998. 1625 [RFC2401] Kent, S., and R. Atkinson, Security Architecture for the 1626 Internet Protocol, RFC 2401 (proposed standard), November 1998. 1628 [RFC2406] Kent, S., and R. Atkinson, IP Encapsulating Security 1629 Payload (ESP), RFC 2406 (proposed standard), November 1998. 1631 [RFC2408] Maughan, D., et al., Internet Security Association and Key 1632 Management Protocol (ISAKMP), RFC 2408 (proposed standard), November 1633 1998. 1635 [RFC2409] Harkins, D., and D. Carrel, The Internet Key Exchange 1636 (IKE), RFC 2409 (proposed standard), November 1998. 1638 [RFC2412] H. Orman, The OAKLEY Key Determination Protocol, RFC 2412 1639 (Informational), November 1998. 1641 [RFC2522] Karn, P., and W. Simpson, Photuris: Session-Key Management 1642 Protocol, RFC 2522 (Informational), March 1999. 1644 [RFC2543] Handley, M., et. al., SIP: Session Initiation Protocol, 1645 RFC 2543 (Proposed Standard), March 1999. 1647 [RFC2627] Wallner, D., E. Harder, and R. Agee, Key Management for 1648 Multicast: Issues and Architectures, RFC 2627(informational), IETF, 1649 June 1999. 1651 [RFC3547] M. Baugher, T. Hardjono, H. Harney, B. Weis, The Group 1652 Domain of Interpretation, RFC 3547 (Proposed Standard), July 2003. 1654 Internet Draft Group Key Management Architecture [PAGE 33] 1656 [RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: 1657 A Transport Protocol for Real-Time Applications, RFC 3550 (Proposed 1658 Standard), July 2003. 1660 [RFC3711] Baugher, M., et. al., The Secure Real Time Transport 1661 Protocol, RFC 3711 (Proposed Standard), March 2004. 1663 [SD1] Naor, D., M. Naor, and J. Lotspiech, Revocation and Tracing 1664 Schemes for Stateless Receivers, in Advances in Cryptology - CRYPTO, 1665 Santa Barbara, CA: Springer-Verlag Inc., LNCS 2139, August 2001. 1667 [SD2] Moni Naor and Benny Pinkas, Efficient Trace and Revoke 1668 Schemes, In Proceedings of Financial Cryptography 2000, Anguilla, 1669 British West Indies, February 2000. 1671 [Self-Healing] Staddon, J., et. al., Self-healing Key Distribution 1672 with Revocation, In proceedings of the 2002 IEEE Symposium on 1673 Security and Privacy, Oakland, CA, May 2002. 1675 [SKEME] H. Krawczyk, SKEME: A Versatile Secure Key Exchange 1676 Mechanism for Internet, ISOC Secure Networks and Distributed Systems 1677 Symposium, San Diego, 1996. 1679 [STS] Diffie, P. van Oorschot, M. J. Wiener, Authentication and 1680 Authenticated Key Exchanges, Designs, Codes and Cryptography, 2, 1681 107-125 (1992), Kluwer Academic Publishers. 1683 [TAXONOMY] R. Canetti et al, Multicast Security: A taxonomy and some 1684 Efficient Constructions, IEEE INFOCOM, 1999. 1686 [TESLA-INFO] Perrig, A., R. Canetti, D. Song, D. Tygar, and B. 1687 Briscoe, TESLA: Multicast Source Authentication Transform 1688 Introduction, http://www.ietf.org/proceedings/03mar/I-D/draft-ietf- 1689 msec-tesla-intro-01.txt, October 2002, Work in Progress. 1691 [TESLA-SPEC] Perrig, A., R. Canetti, and Whillock, TESLA: Multicast 1692 Source Authentication Transform Specification, 1693 http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-msec-tesla-spec- 1694 00.txt, April 2002, Work in Progress. 1696 [tGSAKMP] Harney, H., et. al., Tunneled Group Secure Association Key 1697 Management Protocol, http://www.ietf.org/internet-drafts/draft-ietf- 1698 msec-tgsakmp-00.txt, May 2003, Work in Progress. 1700 [TPM] D.S. Marks, B.H. Turnbull, Technical protection measures: The 1701 intersection of technology, law, and commercial licenses, Workshop 1702 on Implementation Issues of the WIPO Copyright Treaty (WCT) and the 1703 WIPO Performances and Phonograms Treaty (WPPT), World Intellectual 1704 Property Organization, Geneva, December 6 and 7, 1999 1705 (http://www.wipo.org/eng/meetings/1999/wct_wppt/pdf/imp99_3.pdf). 1707 Internet Draft Group Key Management Architecture [PAGE 34] 1709 [Wool] Wool. A., Key Management for Encrypted broadcast, 5th ACM 1710 Conference on Computer and Communications Security, San Francisco, 1711 CA, Nov. 1998. 1713 Internet Draft Group Key Management Architecture [PAGE 35] 1714 11.0 Authors' Addresses 1716 Mark Baugher 1717 Cisco Systems 1718 5510 SW Orchid St. 1719 Portland, OR 97219, USA 1720 +1 408-853-4418 1721 mbaugher@cisco.com 1723 Ran Canetti 1724 IBM Research 1725 30 Saw Mill River Road 1726 Hawthorne, NY 10532, USA 1727 +1 914-784-7076 1728 canetti@watson.ibm.com 1730 Lakshminath R. Dondeti 1731 Nortel Networks 1732 600 Technology Park Drive 1733 Billerica, MA 01821, USA 1734 +1 978-288-6406 1735 ldondeti@nortelnetworks.com 1737 Fredrik Lindholm 1738 Ericsson Research 1739 SE-16480 Stockholm, Sweden 1740 +46 8 58531705 1741 fredrik.lindholm@ericsson.com 1743 Full Copyright Statement 1745 Copyright (C) The Internet Society (2004). This document is subject 1746 to the rights, licenses and restrictions contained in BCP 78 and 1747 except as set forth therein, the authors retain all their rights. 1749 This document and the information contained herein are provided on an 1750 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1751 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1752 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1753 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1754 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1755 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1757 Intellectual Property 1759 The IETF takes no position regarding the validity or scope of any 1760 Intellectual Property Rights or other rights that might be claimed to 1761 pertain to the implementation or use of the technology described in 1763 Internet Draft Group Key Management Architecture [PAGE 36] 1764 this document or the extent to which any license under such rights 1765 might or might not be available; nor does it represent that it has 1766 made any independent effort to identify any such rights. Information 1767 on the procedures with respect to rights in RFC documents can be 1768 found in BCP 78 and BCP 79. 1770 Copies of IPR disclosures made to the IETF Secretariat and any 1771 assurances of licenses to be made available, or the result of an 1772 attempt made to obtain a general license or permission for the use of 1773 such proprietary rights by implementers or users of this 1774 specification can be obtained from the IETF on-line IPR repository at 1775 http://www.ietf.org/ipr. 1777 The IETF invites any interested party to bring to its attention any 1778 copyrights, patents or patent applications, or other proprietary 1779 rights that may cover technology that may be required to implement 1780 this standard. Please address the information to the IETF at ietf- 1781 ipr@ietf.org. 1783 Additional Acknowledgements 1785 Funding for the RFC Editor function is currently provided by the 1786 Internet Society. 1788 Internet Draft Group Key Management Architecture [PAGE 37] 1789 Internet Draft Group Key Management Architecture [PAGE 38]