idnits 2.17.1 draft-irtf-smug-data-transforms-00.txt: 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. == 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 Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. 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 76 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 10 instances of lines with control characters in the document. ** The abstract seems to contain references ([CP], [M], [Ch,PCTS], [HCBD], [WL], [R], [CGIMNP], [GR], [KA]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 40 has weird spacing: '... in the commu...' == Line 185 has weird spacing: '...otocols based...' == Line 213 has weird spacing: '...er, the flexi...' == Line 255 has weird spacing: '...f legal restr...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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? 'HCBD' on line 511 looks like a reference -- Missing reference section? 'KA' on line 515 looks like a reference -- Missing reference section? 'CP' on line 500 looks like a reference -- Missing reference section? 'GR' on line 507 looks like a reference -- Missing reference section? 'WL' on line 527 looks like a reference -- Missing reference section? 'R' on line 523 looks like a reference -- Missing reference section? 'Ch' on line 503 looks like a reference -- Missing reference section? 'PCTS' on line 519 looks like a reference -- Missing reference section? 'CGIMNP' on line 496 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Research Task Force Ran Canetti (IBM Watson) 2 INTERNET-DRAFT Pankaj Rohatgi (IBM Watson) 3 June 2000 Pau-Chen Cheng (IBM Watson) 5 Multicast Data Security Transformations: 6 Requirements, Considerations, and Proposed Design 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 In the framework document , 34 the Secure Multicast Group (SMuG) has identified three functionalities 35 that deal with security transformations for the multicasted 36 data. These are data encryption, source authentication, and group 37 authentication. This document expands on the issues to be taken 38 into consideration when designing transforms that realize these 39 functionalities. These issues include the order of applying the 40 transforms, their placement in the communication layers, possible 41 aggregation of several functionalities in a single transform, and 42 the relationships with other protocols (such as reliable multicast 43 protocols). Next a specific design is proposed, that attempts to meet 44 the requirements of prominent application in a simple yet flexible way. 46 Canetti Rohatgi Cheng 1 47 Contents: 49 1. Introduction.................................................. 3 50 2. Data security transforms...................................... 4 51 2.1 The functionalities ....................................... 4 52 2.2 Considerations ............................................ 5 53 3. The proposed design .......................................... 7 54 4. Possible usage patterns ...................................... 10 55 5. References.................................................... 12 57 Canetti Rohatgi Cheng 2 58 1. Introduction 60 A security solution for IP multicast consists of three main components: 61 a component that sets the security policy of the group (typically set by 62 the group controller), a component that handles the interaction between 63 group members and the group controller(s) (and in particular guarantees 64 secure dissemination and update of policy and cryptographic keys to the 65 group members), and a component that applies actual cryptographic 66 transforms to the data in order to implement the security policy. 67 See more details in the SMuG framework document [HCBD]. 69 This document concentrates on the design and placement of the 70 cryptographic transforms applied to the multicasted data. It starts 71 with a short review of the functionalities for multicast security data 72 transforms. Next it reviews the issues related to the ordering, placement 73 and aggregation of these functionalities. 74 This includes integration of the transforms with each other, 75 with the current IP multicast model, with reliable multicast protocols, 76 and with the secure multicast framework. 78 Next a specific design for the security data transforms is proposed. 79 The design emphasizes flexibility, simplicity and maximal reuse of 80 IPSec protocols (in particular, ESP [KA]). It allows providing security 81 either in the IP layer or in the application/transport layer. 82 It also allows for easy incorporation within the reliable multicast 83 protocols that are being designed in the Reliable Multicast Transport 84 (RMT) working group. 86 The design is quite simple. It consists of two ESP-like transforms, 87 MESP (for Multicast ESP) which is an IP layer transform and AMESP 88 which is an application/transport layer transform: 90 * MESP is an extension of ESP, 91 in a sense that for certain choice of parameters, MESP is identical 92 to ESP. In particular, MESP can keep the same IANA protocol number as 93 ESP (namely, protocol 50). This also means that the existing ESP 94 transform can be used to provide limited support for secure multicast. 96 * AMESP is similar to MESP, but works in the application/transport layer. 98 Each one of these transforms is capable of providing full security 99 for the data (encryption, group and source authentication) 100 independently of the other. Furthermore, in general a secure 101 multicast protocol-suite will apply *both* transforms to the 102 data. It is up to the security policy (set by the application) to 103 specify which cryptographic algorithms, if any, are invoked in each 104 transform. 106 Canetti Rohatgi Cheng 3 107 This design allows for increased flexibility in the ordering and 108 layer placement of the three basic functionalities. Using different 109 sets of policy parameters, a system can do all the cryptographic 110 transforms in the application layer, all in the network layer, or 111 some in the application and some in the network layer. In addition, 112 AMESP can be used in conjunction with a transport-layer reliable 113 multicast transform, to obtain a single transform that guarantees 114 both reliability and security. See more details in Section 4. 116 A remark on terminology: we make a distinction between the term 117 functionality (or, "functional building block" in the terminology of 118 [HCBD]) and the term "security transform". The former refers to a 119 cryptographic functionality (e.g., encryption, source authentication, 120 or group authentication). The latter refers to an actual transform 121 that is being carried out on the data (e.g., ESP or AH). In particular, 122 a single transform can provide more than one functionality. 124 2. Data security transforms: Issues and considerations. 126 2.1 The functionalities 128 The security requirements for multicast have been discussed and 129 enumerated in the SMuG Framework document [HCBD] and also in 130 [CP]. In particular, these reference documents identify three 131 different functionalities that must be part of any complete solution. 133 The functionalities for multicast security data transforms 134 are: 136 a) Group Secrecy (GS). 138 The group secrecy functionality ensures that the transmitted data 139 is accessible only to group members. This can also be viewed as a 140 way to enforce access control. A typical realization is to encrypt 141 data using a key known only to group members. Essentially, the 142 solution for multicast is the same as the solution for 143 confidentiality in unicast. 145 b) Group Authentication (GA). 147 This functionality ensures that any group member can verify that 148 the received data originated from someone in the group. Note that 149 group authentication by itself does not identify the source of the 150 data; for example the data could have been forged by any malicious 151 group member. It can be efficiently realized using standard shared 152 key authentication mechanisms such as Message Authentication Codes 153 (MACs), e.g., CBC-MAC or HMAC. 155 Canetti Rohatgi Cheng 4 156 c) Source and Data Authentication (SrA). This functionality ensures that 157 any group member can verify that the received data originated from 158 the claimed source and was not modified en-route by anyone 159 (including other malicious group members). Source and Data 160 Authentication provides a much stronger security guarantee than the 161 Group authentication functionality. Realizing source authentication 162 requires stronger cryptographic techniques such as digital 163 signatures, stream signatures [GR], flow signatures [WL], hybrid 164 signatures [R], timed MACs [Ch,PCTS], asymmetric MACs [CGIMNP], etc. 166 2.2 Considerations regarding ordering, layer placement and aggregation 167 of the functionalities. 169 A secure multicast solution is likely to utilize all three of the 170 basic functionalities. Due to the diversity of the various application 171 and deployment scenarios for multicast, several issues arise with respect 172 to the layering of these functionalities (i.e., in which layer of the 173 networking stack each functionality should be applied to the data), 174 ordering of application of the functionalities and use of composite 175 transforms that aggregate more than one functionality. These issues 176 are listed below. 178 1. Should transforms include only a single functionality or should 179 transforms combine several functionalities for common usage scenarios? 180 For example ESP provides both encryption and group authentication. 182 2. Potential for interactions between security transforms and Reliable 183 Multicast protocols: 185 A. Reliable multicast protocols based on Forward Error Correction 186 (FEC) techniques require source authentication to be done below or 187 together with the reliability transform. This is because these 188 reliability solutions are very susceptible to denial-of-service 189 attacks based on a small number of forged packets. 191 B. Other multicast reliability mechanisms are based on 192 having intermediary network entities (e.g., "repair nodes") 193 retransmit lost packets. Since the reliability mechanism resides 194 above the network layer, a network layer encryption 195 transform would interfere with the retransmission mechanism unless 196 the intermediary entities have access to the group key and decrypt 197 and re-encrypt data. 199 C. On the other hand, the Source Authentication functionality 200 can be realized much more efficiently over Reliable Multicast than 201 over plain IP-Multicast. This means that the choice of a data 202 transform could depend on whether reliable multicast is provided. 204 Canetti Rohatgi Cheng 5 205 3. Should all transforms be applied at the same level in the networking 206 stack, either application or network layer or should there be 207 flexibility in applying different transforms at different layers? 209 The main advantage of a flexible approach is that it may allow the 210 re-use of existing IPSec components directly, and may facilitate 211 the transition from application-layer transforms to 212 network-layer transforms without changing the overall design. 213 However, the flexibility to apply different transforms in different 214 layers would complicate both the design and the security analysis. 215 For example, the end-points of the connections in different layers 216 are different entities (e.g., host vs. application). 218 4. More considerations regarding placing transforms at different 219 layers of the stack. 221 Arguments in favor of application level transforms: 222 - Supports application -level group membership granularity. 223 - Faster to implement and deploy, requires no kernel modifications. 224 - Less efficient, especially in multiple group members per host 225 scenarios. 226 - some source authentication transforms are more efficient when 227 applied at the application layer above some form of reliable 228 multicast transport. 230 Arguments in favor of network level transforms: 231 - Supports host-level group membership granularity. 232 - more efficient, especially in multiple group members/host 233 scenarios. 234 - Does not require modification of current multicast applications; 235 if done right, secure multicast should be transparent to 236 current multicast applications. 238 5. In scenarios where more than one functionality is used, 239 the order of application of the functionalities could be important. 241 - Source authentication should ideally be done before encryption. 242 Two reasons are: 244 -- For the purpose of non-repudiation, it is a good cryptographic 245 practice to apply source authentication before any encryption. 246 If a source authenticates encrypted data, then for non-repudiation 247 purposes there may be ambiguity regarding the cleartext, since 248 every different key potentially yields a different cleartext. 249 ( To mitigate this problem the source could also authenticate the 250 key. This may not be trivial since one has to make sure that 251 authenticating the key does not leak any information on the key.) 253 -- Encrypted data may get decrypted and re-encrypted by a different 254 key at gateways between different domains, e.g., in Iolus or 255 because of legal restrictions on permissible encryption 256 schemes. Therefore in this scenario source authentication 257 information should be applied before encryption. 259 Canetti Rohatgi Cheng 6 260 - To minimize impact of denial-of-service attacks, it is usually 261 best to have group authentication transformation performed last, 262 i.e., checked first. 264 In summary, it seems best not to mandate an order. For example, 265 GA[GS[SrA[M]]] may be preferable in some scenarios, and SrA[GS[M]] 266 may be more appropriate in other scenarios. 268 REMARK: Order of transform application and the level (in the network 269 stack) they are applied are related. Order of application can only 270 move down the stack. 272 3. The proposed design 274 3.1 Network layer transform: MESP 276 The Network layer transform (MESP) is intended to be an extension of 277 the ESP transform in IPSec, in that the encryption algorithm of the 278 ESP is overloaded to perform both encryption and source 279 authentication. Also, the authentication algorithm of ESP can be 280 replaced by algorithms that guarantee source authentication (such 281 as timed MACs algorithms). Thus the MESP packet is identical to an 282 ESP packet in situations where no source authentication is done in 283 the network layer. 285 Canetti Rohatgi Cheng 7 286 Figure 1: MESP Format. 288 0 1 2 3 289 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- 291 | Security Parameters Index (SPI) | Ext. 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth 293 | Sequence Number | cov. 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | 295 | IV (if any) | | | 296 ~ ~ | | 297 | | | | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | --- | --- 299 | Source ID | | ^ | ^ 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | 301 | Multicast Session ID | | | | | 302 ~ ~ | I | | 303 | | | n | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | t. | | 305 | Internal Authentication SEQ # | | A | | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | u | | 307 | Reserved | Data and Option Length | | t | | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | h. | | 309 | Transform-specific options (variable) | P co | | 310 | + | a ve | | 311 ~ Data (variable) ~ y ra | | 312 | | l ge | | 313 | | o v | | 314 |...............................................................| a --- | | 315 | Internal Authentication Tag (variable) | d | | 316 | | | |Conf 317 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |Cov. 318 | | Padding (0-255 bytes) | | | | 319 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 320 | | Pad Length | Next Header | v v v 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- --- 322 | External Authentication Data (variable) | 323 ~ ~ 324 | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Canetti Rohatgi Cheng 8 328 The MESP Packet format is illustrated in Figure 1. As in the ESP 329 packet format, the MESP packet starts with a 32-bit Security 330 Parameter Index (SPI) field followed by a 32-bit sequence number 331 field. As in IPSec, the SPI together with the destination address 332 uniquely identify a Security Association (SA) and associated 333 keying material. The main difference between the unicast and 334 multicast case is that the destination address in this case is a 335 multicast address. It is also expected that each sender in a 336 multicast group would be assigned a different SPI, so that each 337 source can manage its own sequence number. 339 As in an ESP packet, the sequence number field is followed by an 340 optional IV field, plus a variable-length field of encrypted data. In 341 cases where the MESP does not involve any internal authentication, the 342 structure of the encrypted data field is identical to that of the ESP 343 packet. In case that the MESP involves internal authentication, 344 the encrypted data consists of the following fields: 345 * Internal Authentication Sequence Number (4 bytes). 346 This sequence number is potentially different than the ESP sequence 347 number. (In particular, it can be source-specific.) Note that 348 the Internal Authentication Sequence Number authenticated both by 349 the internal authentication and by the external authentication 350 transforms, whereas the ESP sequence number is authenticated only 351 by the external authentication transform. 352 * Reserved (2 Bytes) 353 * Data and Options Length (2 Bytes) 354 This field contains the combined length of the transform-specific 355 options and of the data. It does NOT contain the length of the 356 Internal Authentication Tag. 357 * Transform-specific Options and Data (Variable) 358 This field contains optional parameters that may be required by 359 specific transforms, together with the data payload. For maximum 360 flexibility, this document does not mandate any particular structure 361 for this field; it is left to the designers of specific internal 362 authentication transforms to come up with the most appropriate 363 structure for this field. 364 * Internal Authentication Tag (Variable) 365 As in an ESP packet, the encrypted payload ends with variable amount 366 (0-255 bytes) of padding followed by the pad length and next header 367 fields. The next header field still refers to the next protocol 368 header in the actual data. The format of the internal authenticating 369 data will be described in greater detail later. 371 As in ESP, the encrypted data is followed by the external 372 authentication data or tag, which provides either group or source 373 authentication (depending on the algorithm used) for the SPI, SEQ 374 Number and encrypted data. If the current authentication 375 algorithms of ESP are used then the the external authentication 376 data provides only group authentication. If appropriate algorithms 377 are used (such as timed MACs) then the external authentication may 378 provide also source authentication. 380 Canetti Rohatgi Cheng 9 381 3.1.1 Internal Authentication transform format. 383 We now describe the internal authentication transform format in 384 greater detail. The internal authentication transform prepends a 385 fixed size internal authentication header together with transform 386 specific options, to the data to be authenticated and appends a 387 variable sized internal authentication tag at the end of the 388 data. The internal authentication tag authenticates both the 389 header, options and the data. The internal authentication header 390 consists of of a 32-bit Source ID field, followed by a TBD sized 391 Multicast Session ID field, followed by a 32-bit Internal 392 Authentication Sequence Number field followed by a 16-bit reserved 393 field (currently mandated to be all 0 bits) followed by a 16 bit 394 Data and Options Length field. The function of each of these fields 395 is as follows. 397 Source ID: This is a 32 bit quantity which identifies the source. The 398 source identifier could be independent of the particular SPI that is 399 assigned to the source for the particular multicast session. 401 Multicast Session ID: This identifier uniquely specifies the 402 current multicast session in which the source is 403 participating. This field is intended to prevent out-of-context 404 substitution attacks wherein source authenticated data from a 405 particular source in one multicast session is replayed by an 406 attacker in another session. The size of this field is TBD. 408 Internal Authentication SEQ number: This sequence number is with 409 respect to the stream/flow of internal authenticated data from the 410 source in the current multicast session. In general this may not 411 be related to the ESP sequence number which may be only group 412 authenticated. 414 Reserved field. This 16-bit field which is currently set to 0's is 415 reserved for future extensions. 417 Data and Options Length field. This 16-bit field must contain the 418 length of the data (in bytes) that is authenticated using the internal 419 authentication algorithm. Since both the length of the 420 authenticated data and the internal authentication tag are 421 variable sized this field is to be used to determine the beginning 422 of the internal authentication tag. 424 3.2 Application layer transform: AMESP 426 The structure of the AMESP mimics the structure of MESP. The only 427 difference is that the next header field in not meaningful and is 428 mandated to be set to all 0's. Other fields are meant to be 429 functionally equivalent. 431 Canetti Rohatgi Cheng 10 432 4. Possible usage patterns 434 To exemplify the usability of the above design, we briefly mention 435 some potential usage patterns. 437 (1) AMESP with encryption, source and group authentication, null 438 MESP. 440 Here all the security is applied in the transport/application layer, 441 and no network layer mechanisms are deployed. This mode requires no 442 kernel modifications and can be used even in groups where hosts do not 443 have IPSec deployed. 445 (2) AMESP with source authentication, MESP with encryption and group 446 authentication. 448 Here source authentication is applied in the transport/application 449 layer, and encryption and group authentication are applied in the 450 network layer. This mode requires no kernel modifications and can be 451 used wherever IPSec is deployed. 453 (3) Null AMESP, MESP with encryption, source and group authentication. 455 Here all the security is applied in the network layer. This mode 456 requires some kernel changes (adding a transform in the ESP format), 457 but has the advantage that security is transparent to 458 applications. However, this mode is incompatible with 459 retransmission-based reliable multicast, unless all the 460 retransmission points become group members. 462 (4) AMESP used in conjunction with a reliable multicast transform. 464 When a secure multicast protocol is used in conjunction with a 465 transport-layer reliable multicast protocol, it is possible to use 466 AMESP to obtain reliable multicast transport-layer transform that 467 provides both security and reliability. Such a transform would have 468 a dedicated security field, and its processing can proceed roughly 469 as follows. (The description corresponds to the processing of an 470 outgoing packet. Processing of an incoming packet is analogous.) 472 a. Apply a first-pass of the reliability transform, with the security 473 field "zeroed out". Obtain a packet (or frame) denoted P. 475 b. Feed P (as data) to AMESP. 477 c. Use the fields of the generated packet (in AMESP format) to 478 modify P as follows: - Replace the data field of P with the 479 encrypted payload of AMESP. - Fill the security field in the 480 header of P with: -- The header information of AMESP, including 481 the SPI, the sequence number and IV. -- The external 482 authentication tag of AMESP. The obtained modified packet, P', is 483 the result of the combined transform. 485 Canetti Rohatgi Cheng 11 486 The combined transform has the advantage that the security 487 algorithms are applied to the data *after* the reliability 488 algorithms, and are still done at the transport layer (and 489 potentially outside of the kernel). Furthermore, there is only one 490 transport-layer multicast header. This can potentially be useful 491 when one needs to provide, at the transport layer, source 492 authentication of individual data packets. 494 5. References: 496 [CGIMNP] Canetti R., J. Garay, G. Itkis, D. Micciancio, M. Naor, 497 B. Pinkas, "Multicast Security: A Taxonomy and Efficient 498 Authentication", INFOCOM '99. 500 [CP] R. Canetti, B. Pinkas, "A taxonomy of multicast security issues", 501 draft-canetti-secure-multicast-taxonomy-01.txt, Nov. 1998. 503 [Ch] S. Cheung, "An Efficient Message Authentication Scheme for 504 Link State Routing". Proceedings of the 13th Annual Computer Security 505 Applications Conference, San Diego, December 8-12, 1997, pp.90-98. 507 [GR] R. Gennaro, P. Rohatgi, "How to Sign Digital Streams", 508 Advances in Cryptology - Crypto '97, Springer-Verlag LNCS 1294, 509 pp. 180-197, 1997. 511 [HCBD] T. Hardjono, R. Canetti, M. Baugher, P. Dinsmore, 512 "Secure IP Multicast: Problem areas, Framework, and Building Blocks", 513 Internet Draft draft-irtf-smug-framework-00.txt, October 1999. 515 [KA] Stephen Kent, Randall Atkinson, "IP Encapsulating Security 516 Payload (ESP)", Internet Draft draft-ietf-ipsec-esp-v2-06.txt, July 517 1998. 519 [PCTS] A. Perrig, R. Canetti, D. Tygar, D. Song, "Efficient 520 Authentication and Signature of Multicast Streams over Lossy 521 Channels" IEEE Symposium on Security and Privacy, Oakland, CA, May 2000. 523 [R] P. Rohatgi, "A Compact and Fast Signature Scheme for Multicast 524 Packet Authenticatio". In 6th ACM Computer and Communications Security 525 Conference (CCS) , Nov 1999. 527 [WL] C. K. Wong and S. S. Lam, "Digital Signatures for Flows and 528 Multicasts", IEEE ICNP '98. See also University of Texas at Austin, 529 Computer Science Technical report TR 98-15. 531 Canetti Rohatgi Cheng 12 532 Authors Addresses 534 Ran Canetti 535 EMail: canetti@watson.ibm.com 537 Pau-Chen Cheng 538 EMail: pau@watson.ibm.com 540 Pankaj Rohatgi 541 EMail: rohatgi@watson.ibm.com 543 IBM T.J. Watson Research Center 544 30 Saw Mill River Road 545 Hawthorne, NY 10598, USA 546 Tel: +1-914-784-6692 548 Canetti Rohatgi Cheng 13