idnits 2.17.1 draft-canetti-secure-multicast-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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 0) being 61 lines 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 26 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([Wallner], [FN], [FN1,Dyer], [HMAC], [FN1], [Mittra], [Ballardie], [Gennaro], [GKMPA,GKMPS], [CEKPS], [GKMPS], [Dyer], [GKMPA,SMKD,MKMP], [CGIMNP], [GMKPA], [Even], [MKMP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 51 has weird spacing: '...ormance param...' == Line 66 has weird spacing: '...itional unica...' == Line 113 has weird spacing: '...ect the draft...' == Line 162 has weird spacing: '...re that the d...' == Line 179 has weird spacing: '...o it is suffi...' == (12 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 (May 1998) is 9478 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? 'GKMPA' on line 481 looks like a reference -- Missing reference section? 'GKMPS' on line 594 looks like a reference -- Missing reference section? 'Ballardie' on line 560 looks like a reference -- Missing reference section? 'Mittra' on line 600 looks like a reference -- Missing reference section? 'MKMP' on line 588 looks like a reference -- Missing reference section? 'HMAC' on line 597 looks like a reference -- Missing reference section? 'Even' on line 573 looks like a reference -- Missing reference section? 'Gennaro' on line 584 looks like a reference -- Missing reference section? 'FN1' on line 580 looks like a reference -- Missing reference section? 'Dyer' on line 570 looks like a reference -- Missing reference section? 'CGIMNP' on line 566 looks like a reference -- Missing reference section? 'SMKD' on line 481 looks like a reference -- Missing reference section? 'FN' on line 577 looks like a reference -- Missing reference section? 'Wallner' on line 604 looks like a reference -- Missing reference section? 'CEKPS' on line 563 looks like a reference -- Missing reference section? 'GMKPA' on line 591 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Canetti, B. Pinkas 3 draft-canetti-secure-multicast-taxonomy-00.txt IBM Research and 4 Expire in two months the Weizmann Institute 5 May 1998 7 A taxonomy of multicast security issues 8 (temporary version) 9 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and working groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet Drafts as reference 21 material or to cite them other than as "work in progress." 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 1. Abstract 32 With the growth and commercialization of the Internet, the need for 33 secure IP multicast is growing. In this draft we present a taxonomy of 34 multicast security issues. We first sketch some multicast group 35 parameters that are relevant to security, and outline the basic 36 security issues concerning multicast in general, with emphasis on IP 37 multicast. Next we suggest two `benchmark' scenarios for secure 38 multicast solutions. Lastly we review some previous works. 40 This is a temporary version of the document. The authors will be 41 grateful for remarks, and will update and revise this document 42 accordingly. 44 Table of Contents: 46 1. Abstract ................................................. i 47 2. Introduction ............................................. 1 48 3. A Taxonomy of multicast security issues................... 2 49 3.1 Multicast group characteristics....................... 2 50 3.2 Security requirements and trust issues................ 3 51 3.3 Performance parameters............................... 5 52 4. Benchmark Scenarios....................................... 5 53 4.1 Single source broadcast............................... 6 54 4.2 Virtual Conferences................................... 7 55 5. A mini-survey of related work............................. 7 56 5.1 Works on group key management......................... 8 57 5.2 Works on individual authentication.................... 9 58 5.3 Works on membership revocation........................10 59 5.4 Working prototypes....................................11 60 Acknowledgments.... .........................................12 61 References...................................................12 62 Authors address..............................................13 64 2. Introduction 66 In addition to traditional unicast communication, the Internet 67 Protocol supports a multicast mode where a packet is addressed to 68 a group of recipients. The main motivation behind this mode is 69 efficiency, both in sender resources (one transmission serves all 70 recipients) and in network resources (far less traffic). The main 71 challenge in efficient multicast transmission is routing: how to get 72 a packet to its intended recipients with minimal latency and 73 bandwidth consumption. See work done at the MBONED and IDMR working 74 groups. Reliable multicast is being studied in the IRTF Reliable 75 Multicast working group. 77 The growth and commercialization of the Internet offers a large 78 variety of scenarios where multicast transmission will greatly save 79 in bandwidth and sender resources. Immediate examples include news 80 feeds and stock quotes, video transmissions, teleconferencing, 81 software updates, and more. 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 84 authentication and secrecy becomes much more complex; in addition 85 other concerns arise, such as access control, trust in group 86 centers, trust in routers, dynamic group membership, and others. 88 We are looking for solutions that mesh well with current multicast 89 routing protocols, and that have as small overhead as possible. 90 In particular, a realistic solution must maintain the current way by 91 which {\em data packets} are being routed; yet additional control 92 messages may be introduced, for key exchange and access control. 93 These messages need not necessarily be sent via multicast. 95 As a first step towards a workable solution, we present a taxonomy 96 of multicast security concerns and scenarios, with a strong emphasis 97 on IP multicast. First we list multicast group characteristics 98 that are relevant to security. Next we list security concerns and some 99 trust issues. We also discuss important performance parameters. 101 It soon becomes clear that the scenarios are so diverse that there 102 is little hope for a single security solution that accommodates all 103 scenarios. Thus we suggest two `benchmark' scenarios for 104 multicast security solutions. One scenario involves a single sender 105 (say, an on-line stock-quotes distributor) and a large number of 106 passive recipients (say, hundreds of thousands). The second scenario 107 depicts relatively small interactive groups of up to few thousands 108 of participants. 110 Lastly we present a brief survey of existing work on multicast 111 security. (The authors apologize in advance for any 112 misinterpretations and omissions. Please write and complain. They 113 will be happy to update and correct the draft.) Two main issues 114 emerge, where the performance of current solutions leaves much to be 115 desired. One is individual authentication, where it is required to 116 make sure that information is arriving from a particular group member 117 (as opposed to information coming from "one of the group members"). 118 The other is membership revocation: here it is required to prevent 119 a leaving member from future access to the group resources. 121 3. A Taxonomy of multicast security issues 123 3.1 Multicast group characteristics 125 We list salient parameters of multicast groups. These parameters 126 affect in a crucial way on the security architecture that should be 127 used. 129 Group size: Can vary from several tens of participants in small 130 discussion groups, through thousands in virtual conferences 131 and classes, and up to several millions in large broadcasts. 133 Member characteristics: These include computing power (do all members 134 have similar computing power or can some members be loaded more 135 than others?) and attention (are members on-line at all times?). 137 Membership dynamics: Is the group membership static and known in 138 advance? Otherwise, do members only join, or do members also 139 leave? how frequently does membership change and how fast should 140 changes be updated? Are membership changes bursty? 142 Expected life time: Is the group expected to last several minutes? 143 days? unbounded amount of time? 145 Number and type of senders: Is there a single party that sends data? 146 several such parties? all parties? Does few senders generate most 147 of the traffic? Is the identity of the senders known in advance? 148 Are non-members expected to send data? 150 Volume and type of traffic: Is there heavy volume of communication? 151 Must the communication arrive in real-time? what is the allowed 152 latency? For instance, is it data communication (less stringent 153 real-time requirements, low volume), audio (must be real-time, 154 low volume), or video (real-time, high volume)? 156 3.2 Security requirements and trust issues 158 We list several security requirements and trust issues. Not all 159 issues are relevant to all multicast applications; yet they should 160 be kept in mind when designing a system. 162 Long-term secrecy: Making sure that the data remains secret to 163 non-group members, for a substantial amount of time after 164 transmission. This may often not be a requirement for multicast 165 traffic. In particular, the larger the multicast group the 166 weaker the secrecy assurance is (even if the cryptography 167 is perfect.) 169 Perfect Forward Secrecy: Making sure that encrypted data remains 170 secret even if the key is compromised (either by cryptanalysis or 171 by break-in) at a later date. This requirement is needed only for 172 applications that require long-term secrecy. Thus in many 173 multicast applications it is not necessary. 175 Ephemeral secrecy: Preventing non group-members from easy access 176 to the transmitted data. Here a mechanism that delays access, 177 or prevents access only to crucial parts of the data is sufficient. 178 (For instance, to maintain ephemeral secrecy when transmitting 179 a video it is sufficient to encrypt only the low-order Fourier 180 coefficients in an MPEG encoding.) 182 Sender and data authenticity: Making sure that the received data 183 originates with the claimed sender and was not modified on 184 the way. Authenticity takes two flavors: Group authenticity 185 means that a group member can recognize whether a message 186 was sent by a group member. Individual authenticity means that 187 it is possible to identify the particular sender within the group. 188 It may also be desirable to verify the origin of messages 189 even if the originator is not a group member. 191 Anonymity: Several flavors are possible. One is keeping the identity 192 of group members secret from outsiders or from other group members. 193 Another is keeping the identity of the sender of a message secret. 194 A related concern is protection from traffic analysis. 196 Non-repudiability: The ability of receivers of data to prove to third 197 parties that the data has been transmitted, together with the 198 source. Non-repudiability is somewhat contradictory to anonymity, 199 and it is not clear whether it should be implemented in an IP-layer 200 protocol. 202 Key refreshment: The need to refresh (change) the key during a 203 lengthy multicast session, in order to foil cryptanalysis and 204 other methods for compromising the key. It should be remembered 205 that key refreshment in a multicast setting is more complex 206 than for unicast. 208 Service availability: Maintaining service availability against 209 malicious attack is ever more relevant in a multicast setting, 210 since clogging attacks are easier to mount and are much more 211 harmful. 213 Group management and ownership: Several tasks related to 214 a secure multicast group need handling. We list these tasks 215 below. These tasks can be handled either by a centralized 216 entity or in a distributed way (and then it should be decided which 217 entities or coalitions of entities can perform each security 218 critical operation) . It should be remembered that putting trust 219 in centralized centers is a security Achilles-heel (although it 220 usually makes solutions much simpler). 221 Group management tasks include: 222 * Key management 223 * Logging/Audit 224 * Error and exception handling 225 * Access control (see below) 227 Access control: Controlling group membership, and perhaps keeping 228 reliable records of the amount of usage of each member. The problem 229 becomes more complex if members may join with time, and even more 230 complex if members may leave the group (and then the group has to 231 make sure that the leaving members lose the cryptographic abilities 232 reserved to members). 234 3.3 Performance parameters 236 We list relevant performance parameters. Relative importance of 237 these parameters may vary from application to application. These 238 parameters should always be measured against the degree of security 239 achieved. 241 Latency, bandwidth and work overhead per data packets. These are 242 the most immediate costs and should definitely be minimized. 243 Here distinction should be made between the load on strong server 244 machines and on weak end-users. 246 Group initialization, and member addition and deletion overheads. 247 Group initialization occurs once. In groups with highly dynamic 248 membership, efficient addition (and especially deletion) of 249 members may be an important concern. 251 Sender initialization, the overhead of a sender when it starts 252 transmitting to the group. 254 Key generation and distribution overhead. 256 Congestion, especially around centralized control services 257 at peak sign-on and sign-off times. (A quintessential scenario 258 is a real-time broadcast where many people join right before the 259 broadcast begins and leave right after it ends.) 261 Resume overhead: The work incurred when a group member becomes 262 active after being dormant (say, off-line) for a while. 264 4. Benchmark Scenarios 266 As seen above, it takes many parameters to characterize a multicast 267 security scenario, and a large number of potential scenarios exist. 268 Different scenarios call for different solutions; it seems unlikely 269 that a single solution will accommodate all scenarios. 271 We present two very different scenarios for secure multicast, 272 and sketch possible solutions and challenges. These scenarios seem 273 to be the ones that require most urgent solutions; in addition, they 274 span a large fraction of the concerns described above, and solutions 275 here may well be useful in other scenarios as well. Thus we suggest 276 these scenarios as benchmarks for evaluating security solutions. 278 4.1 Single source broadcast 280 Here a single source wishes to continuously broadcast data to a large 281 number of passive recipients. The source can be a news agency that 282 broadcasts stock-quotes and news-feeds to paying customers, or a 283 Pay-TV station. We list a number of characteristics: 285 The number of recipients can be up to hundreds of thousands or even 286 several millions. The source is typically a top-end machine with 287 ample resources. It can also be parallelized or even split to several 288 sources in different locations. The recipients are typically 289 lower-end machines with limited resources. Consequently, and security 290 solution must optimize for efficiency at the recipient side. 292 Although the life-time of the group is usually long, the group 293 membership is dynamic: members join and leave at a relatively high 294 rate. In addition, at peak times (say, before and after important 295 broadcasts) a high volume of sign-on/sign-off requests are expected. 296 In addition, it can be assumed that members have a long-term 297 relationship with the group; this may facilitate processing of 298 sign-on/sign-off requests. 300 The volume of transmitted data may vary considerably: if only 301 text is being transmitted then the volume is relatively low (and 302 the latency requirements are quite relaxed); if audio/video is 303 transmitted (say, in on-line pay-TV) then the volume can be very 304 high and very little latency is allowed. 306 Authenticity of the transmitted data is a crucial concern and 307 should be strictly maintained: a client must never accept a forged 308 stock-quote as authentic. Another important concern is preventing 309 non-members from using the service. This can be achieved by 310 encrypting the data; yet the encryption may be weak since there 311 is no real secrecy requirement - only prevention from easy 312 unauthorized use. 314 The required latency of the communication varies from application 315 to application. Member revocation should be performed within minutes 316 or seconds from the time it is requested (but it is typically not 317 required to remove members within fractions of a second) 319 There is usually a natural group owner that manages access-control as 320 well as key management. However, the sender of data may be a 321 different entity (say, Yahoo broadcasting Reuters stock-quotes in its 322 home-page). 324 4.2 Virtual Conferences 326 Typical virtual conference scenarios may include on-line meetings 327 of corporate executives or committees, town-hall type meetings, 328 interactive lectures and classes, and multiparty video games. 329 A virtual conference involves several tens to hundreds of peers, 330 often with roughly similar computational resources. Usually most, 331 or all, group members may a-priori wish to transmit data 332 (although often there is a small set of members that generate 333 most of the bandwidth). 335 The group is often formed per event and is relatively short-lived 336 (say, few minutes or hours). Membership is often static: members 337 join at start-up, and remain signed on throughout. Furthermore, 338 even if a member leaves it is often not crucial to 339 cryptographically revoke their group membership. 340 Bandwidth and latency requirements vary from application to 341 application, similarly to the case of single source 342 broadcast. However, latency (and especially sender initialization) 343 should typically be very small in order to facilitate the 344 simultaneity and interactivity of virtual conferences. 346 Authenticity of data {\em and sender} is the most crucial 347 security concern. In some scenarios maintaining secrecy of data and 348 anonymity of members may be crucial as well; in many other 349 scenarios secrecy of data is not a concern at all. There is often a 350 natural group owner that may serve as a trusted center. Yet, 351 it is always beneficial to distribute trust as much as possible. 353 5. A mini-survey of known related work 355 Following is a short survey of multicast security related work. The 356 authors apologize in advance for any misinterpretations and 357 omissions. Please write and complain. They will be happy to update 358 and correct the draft. 359 The first three sections of the survey describe work on three main 360 issues described above: group key management, individual 361 authentication, and membership revocation. The last section describes 362 work on prototypes which implement various elements of multicast 363 security. 365 5.1 Works on group key management 367 The works below concentrate on establishing and managing a common key 368 among all group members. This key can be used for encryption 369 and group authentication, but is not sufficient for individual 370 authentication. 372 The GKMP protocol [GKMPA,GKMPS] generates and maintains symmetric 373 keys for the members of a multicast group. In this protocol each 374 multicast group has a dedicated Group Controller (GC) which is 375 responsible for managing the group keys. The GC generates the 376 group keys in a joint operation with a selected group 377 member. Afterwards it contacts each group member validates its 378 permissions and sends it the group keys encrypted by a key mutually 379 shared between the GC and that member. This approach is non-scalable 380 since a single entity, the GC, is responsible for sending the keys to 381 all group members. 383 The Scalable Multicast Key Distribution scheme (SMKD) [Ballardie] is 384 based on the Core-Based Tree (CBT) routing protocol and provides 385 secure joining of a CBT group tree in a scalable approach. 386 It utilizes the hard-state approach of CBT in which routers on the 387 delivery tree know the identities of their tree-neighbors. When a CBT 388 group is initiated in this scheme the core of the tree operates 389 as the group controller and generates the group session keys and key 390 distribution keys. As routers join the delivery tree they are 391 delegated the ability to authenticate joining members and provide 392 them with the group key. This approach is highly scalable. Yet, since 393 every router in the delivery tree obtains the same keys as the group 394 controller the scheme does not provide a high level of security against 395 corrupt routers in the group tree. 397 The Iolus scheme [Mittra] handles the scalability problem 398 by introducing a "secure distribution tree". The multicast group is 399 divided into subgroups which are arranged hierarchically. There is a 400 Group Security Controller (GSC) managing the top-level group, and 401 Group Security Intermediaries (GSIs) for managing the different 402 subgroups. Each subgroup has its own subkey which is chosen by its 403 manager. A GSI knows the keys of its subgroup and of a higher level 404 subgroup, so it can "translate" messages to/from higher levels. 405 A disadvantage of this approach is the latency incurred by GSIs 406 decrypting and re-encrypting each data packet (although the use of 407 encryption indirection enables this latency to be constant and 408 independent of the packets length). The removal of an untrusted GSI is 409 also complex. 411 The MKMP [MKMP] key management protocol enables the initial Group Key 412 Manager to delegate the key distribution authority to other 413 parties in a dynamic way. It first generates the group key (the 414 method which is used for key generation is left outside the scope of 415 the MKMP draft). Then it delegates the key distribution authority to 416 selected parties by sending a message to the multicast group 417 soliciting these parties. This message contains keys and access 418 lists which can only be decrypted by the solicited parties. After 419 they obtain this material they can operate as Group Key Managers. 420 This dynamic approach has the advantage that the group topology can be 421 adapted to changes occurring on-line. MKMP uses a single key for the 422 entire group and thus does not require hop-by-hop 423 decryption/re-encryption of the payload. 425 5.2 Works on individual authentication 427 In order to authenticate that a message was sent by a group member it 428 is enough to use Message Authentication Codes (MACs, see e.g. [HMAC]) 429 with a single shared key known to all group members. However, this 430 method does not suffice to enable individual authentication, 431 i.e. to authenticate a message as being from a specific party. 433 Individual authentication can be achieved if the sender of the message 434 signs it using a digital signature scheme. However, the computational 435 complexity of computing and verifying digital signatures, as well as the 436 length of the signature, may be significant. RSA signatures might be 437 an appealing choice of a signature scheme since it is possible to use 438 them in a mode which considerably reduces the running time of the 439 verifier. 441 It is also possible to use signature schemes based on elliptic curves, 442 which are very efficient in both the computation and the communication 443 requirements. Another interesting approach is to use on-line/off-line 444 signatures schemes [Even]. These enable the signer to perform most of 445 its computation off-line, even before it learns the message that it 446 should sign. When this message becomes known the signer only has to 447 perform a very efficient computation in order to complete the signature. 449 The schemes of Gennaro and Rohatgi [Gennaro] enable to efficiently 450 sign streams of data. Basically, the idea is to partition the data 451 packets into chains; each data packet will include a hash of the 452 next packets in the chain; now only the first packet in the chain 453 needs to be signed. However, these schemes do not deal well with 454 unreliable communication channels, and might not be efficient enough 455 for on-line data which should be transmitted "on-the-fly". 457 Building on previous work [FN1,Dyer], Canetti et al [CGIMNP] 458 suggest individual authentication schemes which are based on 459 efficient MACs rather than on public key signatures. These schemes are 460 designed to be secure against coalitions of up to k of group members, 461 where k is a parameter which affects the overhead. To explain the 462 approach, let us present a simplified example: The idea is to 463 use some number, n, of MAC keys. The pre-designated sender has all 464 keys, where each one of the receivers has n/2 keys, chosen at random 465 from the n keys. Now, each message is MACed with each one of the n 466 keys, and a recipient verifies the MACs whose keys it knows. 467 A coalition of bad parties can make some `victim' accept forge messages 468 only it the coalition knows all the MAC keys that the victim 469 knows. The parameters are set so that the probability that such a 470 bad event occurs is small. 472 5.3 Works on membership revocation 474 In order to prevent newly joined members (respectively, leaving members) 475 from accessing data sent before they joined (respectively, after they 476 leave), one needs to change a multicast group key whenever membership 477 in the group changes. It is particularly difficult to make sure that a 478 leaving member does NOT know the newly distributed key. 480 The approach taken when removing untrusted members in most existing 481 group key management protocols [GKMPA,SMKD,MKMP] is to generate a new 482 group key and distribute it to all the remaining group members, thus 483 essentially creating a new multicast group without the untrusted member. 484 This approach is highly non-scalable. The same approach is also taken 485 by the Iolus protocol [Mittra] for the subgroup which contained the 486 removed member, but since this subgroup is smaller than the entire group 487 this solution is more scalable. However, if a Group Security 488 Intermediary becomes untrusted then a more complex operation (which is 489 not described in [Mittra]) should be performed. 491 Broadcast encryption is a scheme designed in [FN] to encrypt messages 492 from a single source to a dynamically changing group of recipients. 493 When a member is leaving, the scheme can be used to send the new group 494 key to the remaining members. The scheme uses a parameter k which is 495 the maximum tolerable size of a corrupt coalition of former group 496 members that might try to learn a key they should not get. The 497 overhead of the scheme is large for small numbers of leaving members, 498 but becomes more attractive when the number of leaving/joining members 499 is large. The scheme is based on using a set of keys 500 and applying a clever method of assigning subsets of these keys to 501 group members. This assignment makes sure that for every corrupt 502 coalition of k users it is possible to encrypt a message such that the 503 keys known to the corrupt coalition members do not suffice for 504 decryption, whereas the keys of any other member do. 506 The scheme of Wallner et al [Wallner] for user revocation is highly 507 scalable. For a group of n members there is a total of 2n keys but 508 each member is only required to store log(n) keys. When a group 509 member is removed, the group controller should send a single message 510 of size 2log(n) to all members, and each member should perform log(n) 511 (rather efficient) computations in order to generate the new group 512 key. The removed member cannot compute the new group key even if it 513 receives this message. The basic idea of the scheme is to arrange the 514 users as leaves of a binary tree, assign a key to each node, give 515 each user the keys in the path from its leaf to the root and use the 516 root key as the group key. When a user is removed, all the keys it 517 holds are replaced. The main drawbacks of this scheme are that it 518 requires the center to keep track of about 2n keys, and requires 519 each member to receive and process all member-revocation 520 messages in order to learn the current group key. In contrast, it may 521 be good to design mechanisms that enable members which have been 522 off-line to receive and process all member-revocation messages that 523 they have not received, in a reasonable amount of work. 525 5.4 Working prototypes 527 A prototype of the Iolus system has been implemented [Mittra]. It 528 uses a client application which interfaces between applications and 529 the Iolus GSC/GSIs. It is claimed there that the basic prototype is 530 rather a simple to implement and to use. There is only small 531 penalty for the decryption/encryption process of a GSI, and 532 this penalty does not depend on the size of the payload. Note however 533 that the Iolus system does not provide any individual authentication 534 mechanism. 536 A toolkit for secure internet multicast is described in [CEKPS]. It 537 emphasizes a separation between control and data functions. This 538 enables applications to have fine grain control over the data path, 539 while keeping the control plain transparent to the applications. The 540 toolkit can operate without end-to-end support for multicast, using 541 data reflectors connected via unicast tunnels. It is written in 542 Java. Similar to Iolus, a multicast group is divided to subgroups 543 (domains), however the toolkit offers better flexibility, supports 544 individual authentication (by using digital signatures), and operates 545 over non-multicast enabled backbones. 547 Acknowledgments 548 ================ 550 Much of this text is reproduced from [CGIMNP], written 551 with Juan Garay, Gene Itkis, Daniele Micciancio and Moni Naor. 552 The authors are grateful to the people with whom they interacted 553 on this topic, including all the above and in addition Naganand 554 Doraswamy, Rosario Gennaro, Dan Harkins, Shai Halevi, Dimitris 555 Pendarakis, Tal Rabin, Pankaj Rohargi and Debanjan Saha. 557 References 558 ========== 560 [Ballardie] Ballardie A., "Scalable Multicast Key Distribution", RFC 561 1949, May 1996. 563 [CEKPS] Chang I., R. Engel, D. Kandlur, D. Pendarakis, D. Sala, "A 564 Toolkit for Secure Iternet Multicast", manuscript, 1998. 566 [CGIMNP] Canetti R., J. Garay, G. Itkis, D. Micciancio, M. Naor, 567 B. Pinkas, "Multicast Security: A Taxonomy and Efficient 568 Authentication", manuscript, 1998. 570 [Dyer] Dyer M., T. Fenner, A. Frieze, A. Thomason, "On Key Storage 571 in Secure Networks", J. of Cryptology, Vol. 8, 1995, 189--200. 573 [Even] Even S., O. Goldreich, S. Micali, "On-line/off-line digital 574 signatures", Advances in Cryptology - Crypto '89, Springer-Verlag 575 LNCS 435, pp. 263-277, 1990. 577 [FN] Fiat A., M. Naor, "Broadcast Encryption", Advances in Cryptology 578 - Crypto '92, Springer-Verlag LNCS 839, pp. 257-270, 1994. 580 [FN1] Fiat A., M. Naor, Unpublished work. Appears in Alon N., 581 "Probabilistic Methods in Extremal Finite Set Theory", in 582 "Extremal Problems for Finite Sets", 1991, 39--57. 584 [Gennaro] Gennaro R., P. Rohatgi, "How to Sign Digital Streams", 585 Advances in Cryptology - Crypto '97, Springer-Verlag LNCS 1294, 586 pp. 180-197, 1997. 588 [MKMP] Harkins D., N. Doraswamy, "A Secure, Scalable Multicast Key 589 Management Protocol (MKMP)". 591 [GMKPA] Harney, H., C. Muckenhirn, "Group Key Management Protocol 592 (GKMP) Architecture", RFC 2094, July 1997. 594 [GKMPS] Harney, H., C. Muckenhirn, "Group Key Management Protocol 595 (GKMP) Specification". RFC 2093, July 1997. 597 [HMAC] Krawczyk H., M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for 598 Message Authentication", RFC 2104, February 1997. 600 [Mittra] Mittra S., "Iolus: A Framework for Scalable Secure 601 Multicast". In Proceedings of ACM SIGCOMM '97, Cannes, France, 602 September 1997. 604 [Wallner] Wallner D. M., E. G. Harder, R. C. Agee, "Key Management 605 for Multicast: Issues and Architecture", internet draft 606 draft-wallner-key-arch-00.txt, June 1997. 608 Authors' Addresses: 609 ==================== 611 Ran Canetti Benny Pinkas 612 IBM TJ Watson Research Center Weizmann Inst. of Science 613 POB. 704, Yorktown Heights, Rehovot, Israel 614 Tel. 1-914-784-7076 Tel. +972-8-9344310 615 canetti@watson.ibm.com bennyp@wisdom.weizmann.ac.il