idnits 2.17.1 draft-irtf-smug-taxonomy-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == Mismatching filename: the document gives the document name as 'draft-irtf-smug-taxonomy-01', but the file name used is 'draft-irtf-smug-taxonomy-00' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Abstract' ) ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Introduction' ) ** The document seems to lack a Security Considerations section. ** 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 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([CCPRRS], [WGL], [FN], [HMAC], [FN1], [Ken98], [MS], [Mittra,PACB,HCD,HCM], [EGM], [FN1,DFFT], [Mittra], [Ballardie], [NP], [CKLS], [GKMPA,GKMPS], [C], [Kruus], [HCM], [DFFT], [WL], [CFN], [CEKPS], [GKMPS], [CFN,NP], [WHA], [PACB], [Quinn], [HCD], [GKMPA,SMKD,MKMP], [CGIMNP], [GR], [GMKPA], [BS], [Merkle], [DLN], [MKMP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 48 has weird spacing: '...ormance param...' == Line 65 has weird spacing: '...itional unica...' == Line 114 has weird spacing: '...ect the draft...' == Line 185 has weird spacing: '...o it is suffi...' == Line 186 has weird spacing: '...Fourier coeff...' == (15 more instances...) -- 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 (April 1999) is 9114 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Quinn' on line 839 looks like a reference -- Missing reference section? 'GKMPA' on line 543 looks like a reference -- Missing reference section? 'GKMPS' on line 806 looks like a reference -- Missing reference section? 'Ballardie' on line 742 looks like a reference -- Missing reference section? 'MKMP' on line 800 looks like a reference -- Missing reference section? 'Mittra' on line 827 looks like a reference -- Missing reference section? 'PACB' on line 834 looks like a reference -- Missing reference section? 'HCD' on line 791 looks like a reference -- Missing reference section? 'HCM' on line 795 looks like a reference -- Missing reference section? 'Kruus' on line 816 looks like a reference -- Missing reference section? 'HMAC' on line 813 looks like a reference -- Missing reference section? 'EGM' on line 776 looks like a reference -- Missing reference section? 'GR' on line 787 looks like a reference -- Missing reference section? 'WL' on line 850 looks like a reference -- Missing reference section? 'Merkle' on line 824 looks like a reference -- Missing reference section? 'FN1' on line 783 looks like a reference -- Missing reference section? 'DFFT' on line 773 looks like a reference -- Missing reference section? 'CGIMNP' on line 757 looks like a reference -- Missing reference section? 'SMKD' on line 543 looks like a reference -- Missing reference section? 'FN' on line 780 looks like a reference -- Missing reference section? 'WHA' on line 842 looks like a reference -- Missing reference section? 'WGL' on line 846 looks like a reference -- Missing reference section? 'MS' on line 820 looks like a reference -- Missing reference section? 'CEKPS' on line 751 looks like a reference -- Missing reference section? 'CCPRRS' on line 754 looks like a reference -- Missing reference section? 'Ken98' on line 809 looks like a reference -- Missing reference section? 'C' on line 749 looks like a reference -- Missing reference section? 'CFN' on line 761 looks like a reference -- Missing reference section? 'NP' on line 831 looks like a reference -- Missing reference section? 'CKLS' on line 765 looks like a reference -- Missing reference section? 'BS' on line 745 looks like a reference -- Missing reference section? 'DLN' on line 769 looks like a reference -- Missing reference section? 'GMKPA' on line 803 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 35 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Canetti, B. Pinkas 2 draft-irtf-smug-taxonomy-01.txt IBM Research and the Weizmann Institute 3 Expire in six months April 1999 5 A taxonomy of multicast security issues 6 (updated version) 7 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. Internet Drafts are 12 working documents of the Internet Engineering Task Force (IETF), its 13 areas, and working groups. Note that other groups may also 14 distribute working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 1. Abstract 29 With the growth and commercialization of the Internet, the need for 30 secure IP multicast is growing. In this draft we present a taxonomy 31 of multicast security issues. We first sketch some multicast group 32 parameters that are relevant to security, and outline the basic 33 security issues concerning multicast in general, with emphasis on IP 34 multicast. Next we suggest two `benchmark' scenarios for secure 35 multicast solutions. Lastly we review some previous works. 37 This is an updated version of the document. The authors will be 38 grateful for remarks, and will continue to update and revise this 39 document accordingly. 41 Table of Contents: 43 1. Abstract ................................................. i 44 2. Introduction ............................................. 1 45 3. A Taxonomy of multicast security issues................... 2 46 3.1 Multicast group characteristics....................... 2 47 3.2 Security requirements and trust issues................ 3 48 3.3 Performance parameters............................... 5 49 4. Benchmark Scenarios....................................... 5 50 4.1 Single source broadcast............................... 6 51 4.2 Virtual Conferences................................... 7 52 5. A mini-survey of related work............................. 7 53 5.1 Works on group key management......................... 8 54 5.2 Works on individual authentication....................10 55 5.3 Works on membership revocation........................11 56 5.4 Working prototypes....................................13 57 5.5 Architectures.........................................13 58 5.6 Fighting piracy.......................................14 59 Acknowledgments..............................................15 60 References...................................................16 61 Authors address..............................................18 63 2. Introduction 65 In addition to traditional unicast communication, the Internet 66 Protocol supports a multicast mode where a packet is addressed to 67 a group of recipients. The main motivation behind this mode is 68 efficiency, both in sender resources (one transmission serves all 69 recipients) and in network resources (far less traffic). The main 70 challenge in efficient multicast transmission is routing: how to get 71 a packet to its intended recipients with minimal latency and 72 bandwidth consumption. See work done at the MBONED and IDMR working 73 groups. Reliable multicast is being studied in the IRTF Reliable 74 Multicast working group. 76 The growth and commercialization of the Internet offers a large 77 variety of scenarios where multicast transmission will greatly save 78 in bandwidth and sender resources. Immediate examples include news 79 feeds and stock quotes, video transmissions, teleconferencing, 80 software updates, and more. (See [Quinn] for a more complete survey 81 on multicast applications.) Yet, multicast transmission introduces 82 security concerns that are far more complex than those of simple 83 unicast. Even dealing with the `standard' issues of message and 84 source authentication and secrecy becomes much more complex; in 85 addition other concerns arise, such as access control, trust in 86 group centers, trust in routers, dynamic group membership, and 87 others. 89 We are looking for solutions that mesh well with current multicast 90 routing protocols, and that have as small overhead as possible. 91 In particular, a realistic solution must maintain the current way by 92 which {\em data packets} are being routed; yet additional control 93 messages may be introduced, for key exchange and access control. 94 These messages need not necessarily be sent via multicast. 96 As a first step towards a workable solution, we present a taxonomy 97 of multicast security concerns and scenarios, with a strong emphasis 98 on IP multicast. First we list multicast group characteristics 99 that are relevant to security. Next we list security concerns and 100 some trust issues. We also discuss important performance parameters. 102 It soon becomes clear that the scenarios are so diverse that there 103 is little hope for a single security solution that accommodates all 104 scenarios. Thus we suggest two `benchmark' scenarios for 105 multicast security solutions. One scenario involves a single sender 106 (say, an on-line stock-quotes distributor) and a large number of 107 passive recipients (say, hundreds of thousands). The second scenario 108 depicts relatively small interactive groups of up to few thousands 109 of participants. 111 Lastly we present a brief survey of existing work on multicast 112 security. (The authors apologize in advance for any 113 misinterpretations and omissions. Please write and complain. They 114 will be happy to update and correct the draft.) Two main issues 115 emerge, where the performance of current solutions leaves much to be 116 desired: 118 - Individual authentication: How to make sure that information 119 is arriving unmodified from a particular group member 120 (as opposed to information coming from "one of the group members"). 122 - Membership revocation: How to prevent a leaving member from 123 future access to the group resources. 125 3. A Taxonomy of multicast security issues 127 3.1 Multicast group characteristics 129 We list salient parameters of multicast groups. These parameters 130 affect in a crucial way on the security architecture that should be 131 used. 133 Group size: Can vary from several tens of participants in small 134 discussion groups, through thousands in virtual conferences 135 and classes, and up to several millions in large broadcasts. 137 Member characteristics: These include computing power (do all members 138 have similar computing power or can some members be loaded more 139 than others?) and attention (are members on-line at all times?). 141 Membership dynamics: Is the group membership static and known in 142 advance? Otherwise, do members only join, or do members also 143 leave? how frequently does membership change and how fast should 144 changes be updated? Are membership changes bursty? 146 Expected life time: Is the group expected to last several minutes? 147 days? an unbounded amount of time? 149 Number and type of senders: Is there a single party that sends data? 150 several such parties? all parties? Do few senders generate most 151 of the traffic? Is the identity of the senders known in advance? 152 Are non-members expected to send data to the group? 154 Volume and type of traffic: Is there heavy volume of communication? 155 Must the communication arrive in real-time? what is the allowed 156 latency? For instance, is it data communication (less stringent 157 real-time requirements, low volume), audio (must be real-time, 158 low volume), or video (real-time, high volume)? 160 3.2 Security requirements and trust issues 162 We list several security requirements and trust-related concerns. Not 163 all issues are relevant to all multicast applications; yet they 164 should be kept in mind when designing a system. 166 Group management and access control: Making sure that only registered 167 and legitimate parties have access to the communication addressed 168 to the group. (Sometimes it may be necessary also to allow only 169 group member to send data to the group.) Sometimes this is enforced 170 by having a group key that is known only to group members; other, 171 more hierarchical solutions exist as well. Here several security 172 concerns are involved: 173 * How to authenticate potential group members 174 * How to securely distribute the group key(s). 175 * How to revoke membership of leaving members 176 * How to prevent joining members from access to past group 177 communication. 178 * How to periodically refresh the group key(s). 179 * How to log information and allow for external auditing. 181 Ephemeral secrecy: Preventing non group-members from easy access 182 to the transmitted data. Here a mechanism that only delays access, 183 or prevents access only to crucial parts of the data may be 184 sufficient. (For instance, to maintain ephemeral secrecy when 185 transmitting a video it is sufficient to encrypt only the 186 low-order Fourier coefficients in an MPEG encoding.) 188 Long-term secrecy: Making sure that the data remains secret to 189 non-group members, for a substantial amount of time after 190 transmission. This may often not be a requirement for multicast 191 traffic. In particular, the larger the multicast group the 192 weaker the secrecy assurance is (even if the cryptography 193 is perfect.) 195 Perfect Forward Secrecy: Making sure that encrypted data remains 196 secret even if the key is compromised (either by cryptanalysis or 197 by break-in) at a later date. This requirement is needed only for 198 applications that require long-term secrecy. Thus in many 199 multicast applications it is not necessary. 201 Sender and data authenticity: Making sure that the received data 202 originates with the claimed sender and was not modified on 203 the way. Authenticity takes two flavors: Group authenticity 204 means that a group member can recognize whether a message 205 was sent by a group member. Individual authenticity means that 206 it is possible to identify the particular sender within the group. 207 It may also be desirable to verify the origin of messages 208 even if the originator is not a group member. 210 Anonymity: Several flavors are possible. One is keeping the identity 211 of group members secret from outsiders or from other group members. 212 Another is keeping the identity of the sender of a message secret. 213 A related concern is protection from traffic analysis. 215 Non-repudiability: The ability of receivers of data to prove to third 216 parties that the data has been transmitted, together with the 217 source. Non-repudiability is somewhat contradictory to anonymity, 218 and it is not clear whether it should be implemented in an IP-layer 219 protocol. 221 Service availability: Maintaining service availability against 222 malicious attack is ever more challenging in a multicast setting, 223 since clogging attacks are easier to mount and are much more 224 harmful. 226 3.3 Performance parameters 228 We list relevant performance parameters. Relative importance of 229 these parameters may vary from application to application. These 230 parameters should always be measured against the degree of security 231 achieved. 233 Latency, bandwidth and work overhead per data packets. These are 234 the most immediate costs and should typically be minimized at the 235 highest priority. Here distinction should be made between the load 236 on strong server machines and on weak end-users. 238 Latency, bandwidth and work overhead per control packets. These are 239 typically less frequent, thus efficiency here is somewhat less 240 crucial. The control messages usually deal with key distribution 241 and refreshment. 243 Group initialization, and member addition and deletion overheads. 244 Group initialization occurs once. In groups with highly dynamic 245 membership, efficient addition (and especially deletion) of 246 members may be an important concern. 248 Sender initialization, the overhead of a sender when it starts 249 transmitting to the group. 251 Congestion control, especially around centralized control services 252 at peak sign-on and sign-off times. (A quintessential scenario 253 is a real-time broadcast where many people join right before the 254 broadcast begins and leave right after it ends.) 256 Resume overhead: The work incurred when a group member becomes 257 active after being dormant (say, off-line) for a while. 259 4. Benchmark Scenarios 261 As seen above, it takes many parameters to characterize a multicast 262 security scenario, and a large number of potential scenarios exist. 263 Different scenarios call for different solutions; it seems unlikely 264 that a single solution will accommodate all scenarios. 266 We present two very different scenarios for secure multicast, 267 and sketch possible solutions and challenges. These scenarios seem 268 to be the ones that require most urgent solutions; in addition, they 269 span a large fraction of the concerns described above, and solutions 270 here may well be useful in other scenarios as well. Thus we suggest 271 these scenarios as benchmarks for evaluating security solutions. 273 4.1 Single source broadcast 275 Here a single source wishes to continuously broadcast data to a large 276 number of passive recipients. The source can be a news agency that 277 broadcasts stock-quotes and news-feeds to paying customers, or a 278 Pay-TV station. We list a number of characteristics: 280 The number of recipients can be up to hundreds of thousands and more. 281 The source is typically a top-end machine with ample resources. 282 It can also be parallelized or split to several sources in different 283 locations. The recipients are typically lower-end machines 284 with limited resources. Consequently, the security solution must 285 optimize for efficiency at the recipient side. 287 The life-time of the group is usually long. Yet, the group 288 membership is dynamic: members join and leave at a relatively high 289 rate. In addition, at peak times (say, before and after important 290 broadcasts) a high volume of sign-on/sign-off requests are expected. 291 It can be assumed that members have a long-term relationship with the 292 group; this may facilitate processing of sign-on/sign-off requests. 294 The volume of transmitted data may vary considerably: if only 295 text is being transmitted then the volume is relatively low (and 296 the latency requirements are quite relaxed); if audio/video is 297 transmitted (say, in on-line pay-TV) then the volume can be very 298 high and very little latency is allowed. 300 Authenticity of the transmitted data is a crucial concern and 301 should be strictly maintained: a client must never accept a forged 302 stock-quote as authentic. In particular, it should it accept a stock 303 quote that originated with any other group member than the specified 304 sender. Another important concern is preventing 305 non-members from using the service. This can be achieved by 306 encrypting the data; yet the encryption may be relatively 307 weak/ephemeral since there is no real secrecy requirement - only 308 prevention from easy unauthorized use. 310 The required latency of the communication varies from application 311 to application. Member revocation would would be performed within 312 minutes or seconds from the time it is requested (but it is typically 313 not required to remove members within fractions of a second) 315 There is typically a natural group owner that manages access-control 316 as well as key management. However, the sender of data may be a 317 different entity (say, Yahoo broadcasting Reuters stock-quotes in its 318 home-page). 320 4.2 Virtual Conferences 322 Typical virtual conference scenarios may include on-line meetings 323 of corporate executives or committees, town-hall type meetings, 324 interactive lectures and classes, and multiparty video games. 325 A virtual conference involves several tens to hundreds of peers, 326 often with roughly similar computational resources. Usually most, 327 or all, group members may a-priori wish to transmit data 328 (although often there is a small set of members that generate 329 most of the bandwidth). 331 The group is often formed per event and is relatively short-lived 332 (say, few minutes or hours). Membership is often static: members 333 join at start-up, and remain signed on throughout. Furthermore, 334 even if a member leaves it is often not crucial to 335 cryptographically revoke their group membership. 336 Bandwidth and latency requirements vary from application to 337 application, similarly to the case of single source 338 broadcast. However, latency (and especially sender initialization) 339 should typically be very small in order to facilitate the 340 simultaneity and interactivity of virtual conferences. 342 Authenticity of data {\em and sender} may be the most crucial 343 security concern. In some scenarios maintaining secrecy of data and 344 anonymity of members may be important as well; in other 345 scenarios secrecy of data is not a concern at all. There is often a 346 natural group owner that may serve as a trusted center. Yet, 347 it is always beneficial to distribute trust as much as possible. 349 5. A mini-survey of known related work 351 Following is a short survey of multicast security related work. The 352 authors apologize in advance for any misinterpretations and 353 omissions. Please write and complain. They will be happy to update 354 and correct the draft. 355 The first three sections of the survey describe work on three main 356 issues described above: group key management, individual 357 authentication, and membership revocation. The last section describes 358 work on prototypes which implement various elements of multicast 359 security. 361 5.1 Works on group key management 363 The works below concentrate on establishing and managing a common 364 key among all group members. This key can be used for encryption 365 and group authentication, but is insufficient for individual 366 authentication. Group management is closely related to user 367 revocation methods (see Section 5.3) since it should enable to 368 prevent a leaving group member from further decrypting the group 369 communication. 371 The GKMP protocol [GKMPA,GKMPS] generates and maintains symmetric 372 keys for the members of a multicast group. In this protocol a 373 multicast group has a dedicated Group Controller (GC) which is 374 responsible for managing the group keys. The GC generates the 375 group keys in a joint operation with a selected group 376 member. Afterwards it contacts each group member validates its 377 permissions, and sends it the group keys (encrypted using a key which 378 is mutually shared between the GC and that member). This approach may 379 have scalability problems since a single entity, the GC, is 380 responsible for sending the keys to all group members. 382 The Scalable Multicast Key Distribution scheme (SMKD) [Ballardie] is 383 based on the Core-Based Tree (CBT) routing protocol and provides 384 secure join to a CBT group tree in a scalable approach. It utilizes 385 the hard-state approach of CBT in which routers on the delivery tree 386 know the identities of their tree-neighbors. When a CBT group is 387 initiated in this scheme the core of the tree operates as the group 388 controller and generates the group session keys and key distribution 389 keys. As routers join the delivery tree they are delegated the 390 ability to authenticate joining members and provide them with the 391 group key. This approach is highly scalable. However, it is tied to a 392 specific routing protocol, and does not provide a separation between 393 the routing and the security mechanism. (In particular, it puts hight 394 trust in the routers, since each router in the delivery tree obtains 395 the same keys as the group controller.) 396 The MKMP [MKMP] key management protocol enables the initial Group Key 397 Manager to delegate the key distribution authority to other 398 parties in a dynamic way. It first generates the group key. 399 Then it delegates the key distribution ability to 400 selected parties by sending a message to the multicast group 401 soliciting these parties. This message contains keys and access 402 lists which can only be decrypted by the solicited parties. After 403 they obtain this material they can operate as Group Key Managers. 404 This dynamic approach has the advantage that the group topology can 405 be adapted on-line. MKMP uses a single key for the entire group and 406 thus does not require hop-by-hop decryption/re-encryption of the 407 payload. 409 The Iolus scheme [Mittra] handles the scalability problem 410 by introducing a "secure distribution tree". The multicast group is 411 divided into subgroups which are arranged hierarchically. There is a 412 Group Security Controller (GSC) managing the top-level group, and 413 Group Security Intermediaries (GSIs) for managing the different 414 subgroups. Each subgroup has its own sub-key which is chosen by its 415 manager. A GSI knows the keys of its subgroup and of a higher level 416 subgroup, so it can "translate" messages to/from higher levels. 417 A disadvantage of this approach is the latency incurred by GSIs 418 decrypting and re-encrypting each data packet (although the use of 419 encryption indirection enables this latency to be constant and 420 independent of the packets length). The removal of an untrusted GSI 421 is also complex. 423 The work of Poovendran et al [PACB] identifies two major drawbacks of 424 the GKMP protocol which result from the use of a single group 425 controller: the group controller is a single point of failure, and 426 its heavy load might affect scalability. It is suggested to use a 427 panel of three controllers, where every two panel members can operate 428 as a group controller. It is furthermore proposed to improve 429 scalability by segmenting the group into clusters, which are each 430 managed by a sub-controller panel. 432 The internet draft of Hardjono et al [HCD] suggests a hierarchical 433 framework for group key management, similar to that of Iolus. The 434 network is divided into regions: many "leaf regions" and a single 435 "trunk region" which which is used to connect leaf regions and does 436 not contain any member hosts. Each region can have a different key 437 management protocol. In particular, different leaf regions can have 438 different intra-region group key management protocols, and the trunk 439 region operates an inter-region group key management protocol. 441 In [HCM] an intra-region group key management protocol is presented 442 in detail. To enable scalability a domain is further divided into 443 areas, where each host belongs to a single area. There is a single 444 Domain-Key-Distributor and many Area-Key-Distributors which are 445 responsible for each area. A host only communicates with the AKD of 446 its area. A key for the members of a multicast group in a domain is 447 generated by the DKD and is propagated to the hosts through the 448 AKD's. This scheme presents an interesting new concept: the group key 449 is common to members in the the entire domain, while the control 450 messages for key updates are transferred via the 451 Area-Key-Distributors, using two levels of keys. This method enjoys 452 "the best of two worlds": First, the data packets need not be 453 re-encrypted en-route and can be routed using any multicast routing 454 protocol. Second, the group (or domain) controller need not keep 455 track of all group members; instead, it can keep track only of the 456 AKDs. This facilitates scalability while maintaining independence 457 from the data routing mechanism. Note that this protocol is for 458 managing an multicast group inside a domain (a "leaf" in the terms of 459 [HCD]) whereas a different protocol can be used for inter-domain 460 ("trunk") key management of the group. 462 Kruus [Kruus] focuses on identifying and surveying security related 463 issues for multicast group key management. The paper describes 464 several approaches for group key management and for user revocation. 466 5.2 Works on individual authentication 468 In order to authenticate that a message was sent by one of the group 469 members it is sufficient to use Message Authentication Codes (MACs, 470 see e.g. [HMAC]) with a single shared key known to all group 471 members. However, this method does not suffice to enable individual 472 authentication, i.e. it cannot be used to authenticate a message as 473 originating from a specific party. 475 Individual authentication can be achieved if the sender of the 476 message signs it using a digital signature scheme. However, the 477 computational complexity of computing and verifying digital 478 signatures, as well as the length of the signature, may be 479 significant. RSA signatures might be an appealing choice of a 480 signature scheme since it is possible to use them in a mode which 481 considerably reduces the running time of the verification algorithm. 483 It is possible to use signature schemes based on elliptic curves, 484 which are very efficient in both the computation and the 485 communication requirements. Another interesting approach is to use 486 on-line/off-line signature schemes [EGM]. These enable the signer to 487 perform most of its computation off-line, even before it learns the 488 message that it should sign. When this message becomes known the 489 signer only has to perform a very efficient computation in order to 490 complete the signature. 492 The schemes of Gennaro and Rohatgi [GR] enable to efficiently sign 493 streams of data. Basically, the idea is to partition data packets 494 into chains. Each data packet includes a hash of the next packets in 495 the chain, and then only the first packet in the chain needs to be 496 signed. There are two types of schemes, for data streams which are 497 available off-line (and so the whole stream can be examined by 498 the source before it sends the first packet), and for real-time data. 499 A major drawback of the suggested schemes is that they do not deal 500 well with unreliable communication channels and might therefore not 501 be suitable for large scale multicast groups. Furthermore, the scheme 502 for real-time data introduces a considerable communication overhead 503 per packet. 505 Digital signatures for streams are also discussed in [WL], their 506 design goal is to enable efficient and delay bounded signatures, and 507 efficient verification for individual packets (thus solving the 508 problem of unreliable communication). They suggest that the source 509 will sign a digest of several packets. Each packet is sent with this 510 signature and with additional information that enables the receiver 511 to compute the digest. The preferred method for computing the digest 512 is using Merkle's hash trees [Merkle]. It is also suggested that 513 signatures will be performed using a variant of Fiat-Shamir 514 signatures, which (using some heuristics) are more efficient than 515 other common signature schemes. 517 Building on previous work [FN1,DFFT], Canetti et al [CGIMNP] 518 suggest individual authentication schemes which are based on 519 efficient MACs rather than on public key signatures. These schemes 520 are designed to be secure against coalitions of up to k of group 521 members, where k is a parameter which affects the overhead. To 522 explain the approach, let us present a simplified example: The idea 523 is to use some number, n, of MAC keys. The pre-designated sender has 524 all keys, where each one of the receivers has n/2 keys, chosen at 525 random from the n keys. Now, each message is MACed with each one of 526 the n keys, and a recipient verifies the MACs whose keys it knows. 527 A coalition of bad parties can make some `victim' accept forge 528 messages only it the coalition knows all the MAC keys that the victim 529 knows. The parameters are set so that the probability that such a 530 bad event occurs is small. 532 5.3 Works on membership revocation 534 In order to prevent new group members (respectively, leaving members) 535 from accessing data sent before they joined (respectively, after they 536 leave), the group controller needs to change a multicast group key 537 whenever membership in the group changes. While it is rather 538 straightforward to efficiently update the group key when a new member 539 joins the group, this is not the case when a member is removed from 540 the group since this member already knows the group key. 542 The approach taken in many group key management protocols 543 [GKMPA,SMKD,MKMP] to remove untrusted members is to generate a new 544 group key and send it to all the remaining group members (using 545 secret keys which are shared between each of the members and the 546 group controller), thus essentially creating a new multicast group 547 without the untrusted member. This approach is non-scalable. 549 As discussed in Section 5.1, an alternative approach is to divide the 550 multicast group to subgroups with independent subgroup keys. When a 551 member is removed it is only required to send individually encrypted 552 messages to members of the subgroup of the removed member. This 553 approach, taken in [Mittra,PACB,HCD,HCM], is more scalable. It 554 requires that each subgroup contains a trusted controller (e.g. the 555 Group Security Intermediary in the Iolus system of [Mittra]). If this 556 party becomes untrusted then a more complex revocation procedure 557 (which is not described in these drafts) should be run. (Note 558 that the scheme of [HCM] suggests that subgroups (domains) are 559 further partitioned to smaller subgroups (areas) with their own 560 controllers, to provide better scalability). 562 Broadcast encryption [FN] is a scheme to encrypt messages from a 563 single source to a dynamically changing group of recipients. When a 564 member is leaving the scheme can be used to send the new group 565 key to the remaining members. The scheme uses a parameter k which is 566 the maximum tolerable size of a corrupt coalition of former group 567 members that might try to learn a key they should not get. The 568 overhead of the scheme depends on the maximum number of potential 569 members in the group, and the maximum size of the corrupt coalition, 570 but not on the number of members which are removed. Therefore 571 overhead is better than in other user revocation methods if the 572 number of leaving/joining members is large. The scheme is based on 573 using a set of keys and applying a clever method of assigning subsets 574 of these keys to group members. This assignment makes sure that for 575 every corrupt coalition of k users it is possible to encrypt a 576 message such that the keys known to its coalition members do not 577 suffice for decryption, whereas the keys of any other member do. 579 Wallner et al [WHA] (and, independently, [WGL]) introduce a scalable, 580 tree based user revocation scheme. For a group of n members there is 581 a total of 2n keys but each member is only required to store log(n) 582 keys. When a group member is removed the group controller sends a 583 single message of size 2log(n) to all members, and each member 584 performs log(n) (rather efficient) computations in order to generate 585 the new group key. The removed member cannot compute the new group 586 key even if it receives this message. The basic idea of the scheme is 587 to imagine the users as the leaves of a binary tree, assign a key to 588 each node, give each user the keys in the path from its leaf to the 589 root and use the root key as the group key. When a user is removed all 590 the keys it holds are replaced. Two drawbacks of the scheme are that 591 it requires the center to keep track of 2n keys, and requires each 592 member to receive and process each member-revocation message in order 593 to learn the current group key. 595 The scheme of [WHA] was generalized by [WGL] for trees of arbitrary 596 degree (although binary trees achieve the best communication 597 overhead). It is possible to reduce the length of the member 598 revocation message that the controller broadcasts to only log(n) 599 encryptions (instead of 2log(n) in [WHA]). Different schemes that 600 achieve this property are presented in [CGIMNP] and in [MS]. 601 The scheme of [MS] affects the broadcast overhead of the user 602 addition operation, it increases it from O(1) in the scheme of [WHA] 603 to log(n). The scheme of [CGIMNP] does not increase the overhead of 604 user addition. The security of the scheme of [CGIMNP] can be 605 rigorously proven based on the security (i.e. pseudorandomness) of 606 the cryptographic function that is used. 608 5.4 Working prototypes 610 A prototype of the Iolus system has been implemented [Mittra]. It 611 uses a client application which interfaces between applications and 612 the Iolus GSC/GSIs. It is claimed there that the basic prototype is 613 rather a simple to implement and to use. There is only small 614 penalty for the decryption/encryption process of a GSI, and 615 this penalty does not depend on the size of the payload. Note however 616 that the Iolus system does not provide any individual authentication 617 mechanism. 619 A toolkit for secure internet multicast is described in [CEKPS]. It 620 emphasizes a separation between control and data functions. This 621 enables applications to have fine grain control over the data path, 622 while keeping the control plain transparent to the applications. The 623 toolkit can operate without end-to-end support for multicast, using 624 data reflectors connected via unicast tunnels. It is written in 625 Java. Similar to Iolus, a multicast group is divided to subgroups 626 (domains), however the toolkit offers better flexibility, supports 627 individual authentication (by using digital signatures), and operates 628 over non-multicast enabled backbones. 630 5.5 Architectures 632 Several works address the architectural issues involved in the key 633 management aspect of secure multicast [HCD,GMKPA.GMKPS,WHA,WGL]. 634 These works have been described above. 636 In [CCPRRS] a host architecture for secure IP multicast protocols is 637 suggested. The architecture is based on the IPSEC architecture [Ken98] 638 and tries to use IPSEC components (IKE, AH, ESP) as much as possible. 639 As in IPSEC, the architecture calls for separation of the key 640 management (to take place in the application layer) from the data 641 trandformations (to take place mostly in the IP layer). Yet, an 642 additional data-processing module is added in the application/UDP 643 layer. This module is responsible for source authentication, which is 644 not taken care of by the IPSEC trandformations. The suggested 645 architecture is flexible and can adopt many of the key management 646 protocols described above. 648 5.6 Fighting piracy 650 Secure multicast is used to ensure the secrecy of the 651 communication inside the multicast group. However nothing 652 prevents one of the legitimate members of the group from helping 653 other, illegitimate parties to receive the messages that are 654 sent to the group. This problem is well known in the context of 655 television broadcasting, and is commonly referred to as 656 "piracy". There has been a considerable amount of work on this 657 subject, motivated by the pay-TV industry. It is mostly relevant 658 to the one-to-many multicast scenario. 660 The fight against piracy consists of two stages: (1) tracing the 661 pirates, and (2) taking action to prevent them from further 662 operation. We describe below some methods which can be used for 663 tracing. Once the source of piracy is detected it is possible to 664 prevent it from further decryption using the user revocation 665 schemes we discussed above. It might be also desirable to take 666 legal actions against the pirates. 668 There are two methods by which pirates can operate. They can either 670 (1) distribute decryption keys that enable to decrypt the group 671 communication, i.e. perform illegal "key distribution", or 672 (2) decrypt the communication themselves and distribute the 673 decrypted content, i.e. perform illegal "contect distribution". 675 The content distribution attack is harder for large scale 676 implementation and easier to detect, since the pirates should 677 essentially operate their own broadcast station. The key 678 distribution attack is therefore preferable to the pirates. 680 In order to prevent illegal key distribution pay-TV providers 681 provide decryption keys in smartcards which are supposed to 682 be "tamper proof". That is, it should be hard to extract from a 683 key from a smartcard. However, most smartcards have weaknesses 684 which enable to extract the keys they contain (see e.g. [C]). 686 It is easier to trace the source of a key distribution attack 687 than that of a content distribution attack. The reason being that 688 it is possible to give each user a somewhat different key (and 689 then, given a pirate decoder, recognize which keys were used to 690 construct it). It is a much harder task to distribute to each 691 user a different copy of the data such that each copy would seem 692 to have the same content, but a pirate copy would identify its 693 source (even if the content was passed through different 694 trasnformations, e.g. lossy compression, and was generated from 695 several legal copies). This task is known as watermarking, and 696 is discussed below. 698 Fighting illegal key distribution: 700 A obvious method to trace the source of keys is to give each 701 user a personal key. The content should be encrypted with a 702 random key, which is itself ecnrypted with each of the personal 703 keys. The drawback of this scheme is that it sends an additional 704 encryption per user, and this overhead is only reasonable for 705 small groups. There are more advanced methods whose ovehead is 706 much smaller [CFN,NP]. These methods are secure as long as the 707 pirates use less than k keys, where k is a parameter. 709 Fighting illegal content distribution: 711 In order to trace the source of the content it is essential to 712 insert in it "watermarks" which the pirates cannot remove. See 713 [CKLS] for a discussion of marking methods. An additional 714 issue is the distribution of marks into the copies that are 715 delivered to users, i.e the problem of efficiently generating 716 unique fingerprints. An efficient fingerprinting method is 717 suggested in [BS] (however, fingerprinting schemes are less 718 efficient than schemes for tracing illegal key distribution). 720 Self enforcement is an interesting concept: it intends to 721 prevent piracy (rather than trace its source) by discouraging 722 legitimate users from giving their keys to others. In order to 723 achieve this property each user's key contains some information 724 which is private to the user (for example, his credit card 725 number). It is hoped for that users would be discouraged from 726 providing keys which contain this information to others. 727 Efficient tracing schemes are described in [DLN]. 729 Acknowledgments 730 ================ 732 Much of this text is reproduced from [CGIMNP], written 733 with Juan Garay, Gene Itkis, Daniele Micciancio and Moni Naor. 734 The authors are grateful to the people with whom they interacted 735 on this topic, including all the above and in addition Naganand 736 Doraswamy, Rosario Gennaro, Dan Harkins, Shai Halevi, Dimitris 737 Pendarakis, Tal Rabin, Pankaj Rohargi and Debanjan Saha. 739 References 740 ========== 742 [Ballardie] Ballardie A., "Scalable Multicast Key Distribution", RFC 743 1949, May 1996. 745 [BS] Boneh D., Shaw D., "Collusion-Secure Fingerprinting 746 for Digital date", IEEE Tran. on Information Theory, Vol 44, 747 No. 5, pp. 1897-1905, 1998. 749 [C] http://www.cryptography.com/dpa/qa/index.html 751 [CEKPS] Chang I., R. Engel, D. Kandlur, D. Pendarakis, D. Saha, "A 752 Toolkit for Secure Internet Multicast", manuscript, 1998. 754 [CCPRRS] Canetti R., Cheng P. C., Pendarakis D., Rao, J., Rohatgi P., 755 Saha D., "An architecture for secure IP multicast", manuscript. 757 [CGIMNP] Canetti R., J. Garay, G. Itkis, D. Micciancio, M. Naor, 758 B. Pinkas, "Multicast Security: A Taxonomy and Efficient 759 Authentication", to be presented at INFOCOM '99. 761 [CFN] Chor B., Fiat A., Naor M., "Tracing Traitors", Proc. 762 Advances in Cryptology - Crypto '94, Springr-Verlag LNCS 839 763 (1994), 257--270. 765 [CKLS] Cox I., Kilian J., Leighton T., Shamoon T., "A Secure, 766 Robust Watermark for Multimedia", Information Hiding Workshop, 767 Cambridge, UK, Springer-Verlag LNCS 1174, (1996), 185--206. 769 [DLN] Dwork C., Lotspiech J., Naor M., "Digital Signets: 770 Self-Enforcing Protection of Digital Information", 28th 771 Symposium on the Theory of Computation (1996), 489--498. 773 [DFFT] Dyer M., T. Fenner, A. Frieze, A. Thomason, "On Key Storage 774 in Secure Networks", J. of Cryptology, Vol. 8, 1995, 189-200. 776 [EGM] Even S., O. Goldreich, S. Micali, "On-line/off-line digital 777 signatures", Advances in Cryptology - Crypto '89, Springer-Verlag 778 LNCS 435, pp. 263-277, 1990. 780 [FN] Fiat A., M. Naor, "Broadcast Encryption", Adv. in Cryptology 781 - Crypto '92, Springer-Verlag LNCS 839, pp. 257-270, 1994. 783 [FN1] Fiat A., M. Naor, unpublished work. Appears in Alon N., 784 "Probabilistic Methods in Extremal Finite Set Theory", in 785 "Extremal Problems for Finite Sets", 1991, 39-57. 787 [GR] Gennaro R., P. Rohatgi, "How to Sign Digital Streams", 788 Advances in Cryptology - Crypto '97, Springer-Verlag LNCS 1294, 789 pp. 180-197, 1997. 791 [HCD] Hardjono T., Cain B., Doraswamy N., "A Framework for Group Key 792 Management for Multicast Security", internet draft 793 draft-ietf-ipsec-gkmframework-00.txt, July 1998. 795 [HCM] Hardjono T., Cain B., Monga I., "Intra-Domain Group Key 796 Management Protocol", internet draft, 797 draft-ietf-ipsec-intragkm-00.txt, 798 November 1998. 800 [MKMP] Harkins D., N. Doraswamy, "A Secure, Scalable Multicast Key 801 Management Protocol (MKMP)". 803 [GMKPA] Harney, H., C. Muckenhirn, "Group Key Management Protocol 804 (GKMP) Architecture", RFC 2094, July 1997. 806 [GKMPS] Harney, H., C. Muckenhirn, "Group Key Management Protocol 807 (GKMP) Specification". RFC 2093, July 1997. 809 [Ken98] Stephen Kent, Randall Atkinson, "Security Architecture for 810 the Internet Protocol", 811 Internet Draft draft-ietf-ipsec-arch-sec-07.txt, July 1998. 813 [HMAC] Krawczyk H., M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for 814 Message Authentication", RFC 2104, April 1997. 816 [Kruus] Kruus P., "A Survey of Multicast Security Issues and 817 Architectures," 21st National Information Systems Security Conf., 818 Arlington, VA, October 5-8, 1998. 820 [MS] McGrew D. A., and Sherman A. T., "Key Establishment in Large 821 Dynamic Groups using One-way Function Trees", submitted to IEEE 822 Trans. on Software Engineering. 1998. 824 [Merkle] Merkle R. C., "A Digital Signature based on a Conventional 825 Encryption Function", Crypto '87. 827 [Mittra] Mittra S., "Iolus: A Framework for Scalable Secure 828 Multicast". In Proceedings of ACM SIGCOMM '97, Cannes, France, 829 September 1997. 831 [NP] Naor M., Pinkas B., "Threshold Traitor Tracing", Crypto '98. 832 http://www.wisdom.weizmann.ac.il/~bennyp/PAPERS/ttt.ps 834 [PACB] Poovendran R., Ahmed S., Corson S., Baras J., "A Scalable 835 Extension of Group Key Management Protocol", Proceedings of the 2nd 836 ATIRP Conference, University of Maryland, College Park, MD, Feb. 2-6, 837 1998. 839 [Quinn] Bob Quinn, "IP Multicast Applications: Challenges and 840 Solutions", draft-quinn-multicast-apps-00.txt, Nov 1998. 842 [WHA] Wallner D. M., E. G. Harder, R. C. Agee, "Key Management 843 for Multicast: Issues and Architecture", internet draft 844 draft-wallner-key-arch-01.txt, September 1998. 846 [WGL] Wong C. K., Gouda M., Lam S. S., "Secure Group Communication 847 Using Key Graphs", SIGCOMM '98. Also, University of Texas at Austin, 848 Computer Science Technical report TR 97-23. 850 [WL] Wong C. K., Lam S. S., "Digital Signatures for Flows and 851 Multicasts", IEEE ICNP '98. Also, University of Texas at Austin, 852 Computer Science Technical report TR 98-15. 854 Authors' Addresses: 855 ==================== 857 Ran Canetti Benny Pinkas 858 IBM TJ Watson Research Center Weizmann Inst. of Science 859 POB. 704, Yorktown Heights, Rehovot, Israel 860 Tel. 1-914-784-7076 Tel. +972-8-9344310 861 canetti@watson.ibm.com bennyp@wisdom.weizmann.ac.il