Internet Engineering Task Force Mark Baugher (Cisco Systems) MSEC Working Group Ran Canetti (IBM Watson) INTERNET-DRAFT Pau-Chen Cheng (IBM Watson) Pankaj Rohatgi (IBM Watson) EXPIRES: September 2003 March 2003 MESP: A Multicast Framework for the IPsec ESP Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Multicast ESP (MESP) is a framework for multicast data-origin authentication using the IPsec Encapsulating Security Payload (ESP) protocol. The MESP framework combines group-secrecy, group- authentication, and source-authentication transforms in an ESP packet. MESP uses a message authentication code for group authentication to protect a digital signature, TESLA timed MAC, or other multicast source-authentication transform. INTERNET-DRAFT Multicast ESP March 2003 TABLE OF CONTENTS 1.0 Notational Conventions..........................................2 2.0 Introduction....................................................2 2.1 Changes from the Previous Version..............................3 2.2 Overview.......................................................3 3.0 IP Multicast Security Functionalities...........................3 3.1 Composition of the Functionalities.............................4 3.2 MESP Security Association Database.............................5 4.0 MESP Packet Format.............................................5 4.1 MESP Transforms................................................7 4.1.1 Group Secrecy..............................................7 4.1.2 Internal Authentication....................................7 4.1.3 External Authentication....................................7 4.2 MESP Signaling.................................................7 4.2.1 GDOI.......................................................7 4.2.2 GSAKMP.....................................................8 4.2.3 MIKEY......................................................8 5.0 Security Considerations.........................................8 5.1 MESP Authentication............................................8 5.2 MESP Denial-of-Service Protection..............................9 5.3 MESP Encryption................................................9 6.0 IANA Considerations............................................10 7.0 Acknowledgements...............................................11 8.0 Author's Address...............................................11 9.0 References.....................................................11 9.1 Normative References..........................................11 9.2 Informative References........................................12 1.0 Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terminology conforms to [RFC2828]. 2.0 Introduction The IPsec Encapsulation Security Payload (ESP) provides a set of security services that include data origin authentication, which enables an IPsec receiver to validate that a received packet originated from a peer-sender in a pairwise security association [Section 3.1, RFC2401]. A Message Authentication Code (MAC), such as the hash-based message authentication code [RFC2104, RFC2404] (HMAC), is the common means to provide data-origin authentication for pairwise IPsec security associations. For secure groups such as IP multicast groups, however, a MAC supports only "group authentication" and not data-origin authentication [CP]. This Internet-Draft document (I-D) defines a framework for ESP data- Baugher, Canetti, Cheng, Rohatgi [Page 2] INTERNET-DRAFT Multicast ESP March 2003 origin authentication that is suitable for IP multicast groups of ESP receivers. 2.1 Changes from the Previous Version This version is not a protocol, unlike the previous version, but is a transform framework for ESP and realizes all of its functions within the ESP protocol. MESP now imposes an additional structure and usage on IPsec ESP Initialization Vector (IV) and Integrity Check Value (ICV) fields [ESPbis]. A smaller change that appears in this version of MESP is the requirement that TESLA authentication be protected by external authentication transform such as a MAC. 2.2 Overview This I-D assumes that the reader is familiar with the "Security Architecture for Internet Protocol" [RFC2401] and the "IP Encapsulating Security Payload (ESP)" [ESPBIS] RFCs. Section 3 reviews the functionalities of group data-security transforms for applications such as media streaming, process control, and reliable multicast applications. Section 3 describes the problem of authenticating the source when the data-authentication key is shared by more than two IPsec endpoints. Section 4 describes the MESP framework in terms of the extensions and use of the ESP IV and integrity-check-value fields. The three functionalities of the MESP framework are realized in cryptographic transforms that are secure for various uses, and Section 5 recites the security considerations for each MESP transform. Section 5 considers IP multicast risks, the transforms that address a particular risk, and the suitability of a transform for various applications and environments. 3.0 IP Multicast Security Functionalities The security requirements for multicast have been discussed in [CP]. In general, group security has different requirements and characteristics than pairwise security. In particular, data-origin authentication using a MAC will not prevent one member from impersonating another when a group of three or more members share the symmetric authentication key. There are three new functionalities needed to add data-origin authentication to ESP. a) Group Secrecy (GS) The GS functionality is ESP confidentiality applied to a group . It ensures that transmitted data are accessible only to group members (i.e. two or more hosts in possession of a shared symmetric key). This can also be viewed as a way to enforce access control. A typical realization of GS is to encrypt data using a key known only to group members. Essentially, the solution for multicast is the Baugher, Canetti, Cheng, Rohatgi [Page 3] INTERNET-DRAFT Multicast ESP March 2003 same as the solution for unicast confidentiality. It is important to note, however, that some encryption transforms have special considerations when a key is shared among multiple senders. An MESP encryption or authentication transform SHOULD describe any potential risks of multicast operation and how those risks are averted. b) Group Authentication (GA) The GA functionality enables a group member to verify that the received data originated from someone in the group and was not modified en-route by a non-group member. Note that group authentication by itself does not identify the source of the data. For example, the data might have been forged by any malicious group member. GA can be efficiently realized using standard shared key authentication mechanisms such as Message Authentication Codes (MACs), e.g., CBC-MAC, HMAC, or UMAC. c) Source and Data Authentication (SrA) The SrA functionality enables a group member to verify that the received data originated from the claimed source and was not modified en-route by anyone (including other malicious group members). Unlike Group Authentication, SrA provides the IPsec data- origin authentication function [RFC2401, ESPbis]. Source and Data Authentication provides a much stronger security guarantee than Group Authentication in that a particular group member can be identified as a source of a packet. Group and multicast source authentication requires stronger cryptographic techniques such as digital signatures, stream signatures [GR], flow signatures [WL], hybrid signatures [R], timed MACs, e.g. TESLA [TESLA, Ch,PCTS],asymmetric MACs [CGIMNP], etc. 3.1 Composition of the Functionalities A secure multicast solution is likely to utilize all three of the basic functionalities. Due to the diversity of the various application and deployment scenarios for multicast, several issues arise with respect to the composition and ordering of these functionalities. In ESP, encryption precedes authentication when both are applied and a "combined-mode" confidentiality/integrity operation is not used [Section 3.3.2 of ESPBIS]. Combined modes of encryption and authentication are supported in ESP [ESPbis] but are not considered in this version of MESP. Encryption first is an efficient ordering that allows the receiver to apply a message authentication code (MAC) before it runs a more computationally-intensive decryption; fast authentication before decryption offers a better defense against bogus packets from a denial of service attack. In MESP, therefore, the group secrecy (GS) transform MUST precede group authentication (GA) when GS is used. In other words, the sender Baugher, Canetti, Cheng, Rohatgi [Page 4] INTERNET-DRAFT Multicast ESP March 2003 applies GS prior to GA and the receiver applies GA prior to GS. Krawczyk has shown that it is more secure to authenticate encrypted data rather than encrypt authenticated data [K], but this ordering does not provide non-repudiation. The latter is usually not needed or even desirable for IPsec applications. MESP uses the same ordering for SrA: SrA MUST follow GS. Digital signatures offer the simplest method for multicast source authentication (SrA) but are computationally expensive, greatly expand the packet size and impractical for many, if not most, packet flows. Given the relatively high cost of signature verification, a digital signature leaves the receiver vulnerable to denial of service attack when an attacker succeeds in getting the receiver to perform signature validation of bad packets. MESP partially protects the receiver from denial-of-service attacks from bogus digitally-signed packets by applying a MAC to the packet after signing it. MESP calls this MAC "external authentication" and applies it in an identical fashion to ESP. The digital signature is called "internal authentication," which the sender applies to the packet payload before the MAC. MAC authentication, therefore, is applied first by the receiver. If the attacker is not a member of the group, or otherwise has not obtained the group key, the MAC will fail before the receiver incurs the burden of a signature validation. SrA transforms such as TESLA timed-MAC can be more efficient than digital signatures for many applications. But like a digital signature, it is REQUIRED that TESLA and other SrA transforms use internal authentication in MESP and be protected by an external- authentication MAC. Thus, a digital signature or TESLA MAC MUST be applied prior to GA at the sender and after GA at the receiver. MAC-based GA is an external-authentication transform that MUST be applied last at the sender and first at the receiver. As in ESP, encryption (GS) is applied before any authentication and is optional. 3.2 MESP Security Association Database The MESP framework applies up to three transforms to a multicast ESP packet in the order described above: Group Secrecy (GS) is OPTIONAL, Source Authentication (SrA) SHOULD be applied next, and Group Authentication (GA) SHOULD be applied last. The IPsec SAD MUST be extended to store the additional transform information if MESP is to be supported. There are no changes to ESP SA lookup beyond what is specified for multicast SAs in the IPsec specifications [AHbis, ESPbis]. 4.0 MESP Packet Format Baugher, Canetti, Cheng, Rohatgi [Page 5] INTERNET-DRAFT Multicast ESP March 2003 The ESP Packet format is illustrated in Figure 4-1: * Internal Authentication Parameters (variable). The length and contents of this field are defined by the SrA transform. Certain internal authentication transforms have a zero length SrA Transform Parameters fields (Section 5.1). * Internal Authentication Tag (Variable). The length and contents of this field are defined by the internal authentication transform. Certain SrA transforms have a zero length Internal Authentication Tag field. Figure 4-1: MESP Transforms in an ESP Packet 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Sequence Number | ^ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ IV (variable & optional) ~ | | +---------------------------------------------------------------+ | | ~ Internal Authentication Parameters (variable & optional) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Data (variable) ~^ I E + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E N X ~ ~ Padding (0-255 bytes) |N T T +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+C | | | | Pad Length | Next Header |v v | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ Internal Authentication Tag (variable) ~ v +---------------------------------------------------------------+ ~ Integrity Check Value (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Encryption (ENC), when applied, covers the ESP data, padding and next header fields. Internal Authentication (INT) covers the ESP sequence number through the next header field, inclusive. External authentication (EXT) covers the entire ESP packet except for the Integrity Check Value (ICV) field. A sender MAY use an encryption-transform (ENC) as done in any other ESP packet. When INT is applied to the packet, its output (if any) is placed in the Internal Authentication Tag. Section 4.1 identifies the INT transforms, which the sender MUST perform prior to the encryption transform. Baugher, Canetti, Cheng, Rohatgi [Page 6] INTERNET-DRAFT Multicast ESP March 2003 A sender of an MESP packet SHOULD use an external-authentication transform (EXT). Section 4.1 identifies the EXT transforms, which the sender MUST perform last (and the receiver performs first). The sender MUST perform the MESP transforms in the order of ENC, INT, and EXT while the receiver MUST perform them in the order of EXT, INT and ENC. 4.1 MESP Transforms This version of MESP defines a minimal number of transforms. In the future, new transforms MAY be added through the publication of an Internet RFC. The transforms of the MESP framework are listed below and classified according to MESP type. 4.1.1 Group Secrecy MESP supports 3DES, AES-CBC, and AES-CTR. 4.1.2 Internal Authentication MESP internal authentication is either RSA-SHA1 or TESLA. 4.1.3 External Authentication MESP external authentication uses HMAC-SHA1. 4.2 MESP Signaling MESP parameters are signaled through a key management protocol or interface such as GDOI, GSAKMP, GKMP, or SDP. 4.2.1 GDOI GDOI MUST signal use of the MESP framework using PROTO_ESP_MESP with the TRANSFORM ID set to the MESP transform ID value (see IANA Section below). MESP extends the RFC 2407 attributes ["IPsec Security Association Attributes," IANA] with the three new classes, "ENC_Transform, "INT_Transform," and "EXT_Transform" (see IANA Section below). The ENC Transform MUST be one of the transforms from 4.1.1. Additional ENC transforms MAY be added to this suite through the publication of an Internet RFC. The INT Transform MUST be non-null and MUST be one of the values from 4.1.2. Additional INT transforms MAY be added to this suite through the publication of an Internet RFC. Baugher, Canetti, Cheng, Rohatgi [Page 7] INTERNET-DRAFT Multicast ESP March 2003 The EXT Transform MUST be one of the transforms from 4.1.3. Additional EXT transforms MAY be added to this suite through the publication of an Internet RFC. The IANA Considerations section of this document describes value assignments for the EXT, INT and ENC attributes. The SA Life Type and Life Duration as defined in RFC 2407 [RFC2407, IANA] apply to all keys used for the session, including the Signature PubKey, which MUST NOT be sent if the INT Transform is not a digital signature algorithm. The length of the encoding is determined by INT. {Editor: Need to define the Signature PubKey format and should make it a GDOI KD payload item instead.} 4.2.2 GSAKMP TBD 4.2.3 MIKEY TBD 5.0 Security Considerations MESP is a framework for IPsec ESP authentication and encryption transforms to support IP multicast delivery. IPsec ESP provides access control, rejection of replayed packets, confidentiality (encryption), limited traffic-flow confidentiality and connectionless integrity. ESP supports a datagram environment where each IP packet is cryptographically independent of other IP packets and can be decrypted, authenticated, and integrity checked when delayed, reordered, or when other packets from the flow are lost. ESP provides rejection of replayed packets for pairwise security associations and for multicast security associations under certain circumstances [ESPbis]. MESP has the same replay mechanism for the single-sender case; the multi-sender case is for further study. ESP provides data origin authentication for pairwise security associations using symmetric message authentication codes, which are not sufficient for group security applications where more than two members share a symmetric key. 5.1 MESP Authentication The MESP framework for ESP provides data-origin authentication services to multicast ESP packets. Secure groups, such as secure multicast groups, cannot use a symmetric-key MAC to uniquely identify the sender; any group member that is in possession of the group authentication key is capable of replacing the source address of the packet with that of another group member and applying the symmetric key to authenticate the packet. To uniquely identify a sender among a group of members, digital signature, public key Baugher, Canetti, Cheng, Rohatgi [Page 8] INTERNET-DRAFT Multicast ESP March 2003 encryption, or specialized source-authentication techniques such as timed MACs are needed. This version of MESP defines a general ESP packet structure for accommodating a digital signature or TESLA timed MAC. 5.2 MESP Denial-of-Service Protection As discussed above, a group member cannot authenticate the source of the packet for a multicast group where multiple members share the MAC key. Thus, a rogue member of the group has all the keying material needed to impersonate a sender of the group if that attacker is able to inject packets into the network using that sender's IP address. The MESP framework addresses this problem by augmenting the MAC with an "internal authentication" transform, which MAY be an RSA-SHA1 digital signature or a TESLA timed MAC. Digital signatures leave multicast receivers vulnerable to denial- of-service attack if the receiver is duped into performing computationally-expensive signature validation of bogus packets. An external message authentication SHOULD accompany a digital signature so as to limit the effectiveness of bogus digitally signed packets by non-group members. TESLA is also vulnerable to a denial of service attack if the receiver is duped into storing bogus packets awaiting MAC verification. An external message authentication transform SHOULD accompany a TESLA authentication transform so as to limit the effectiveness of bogus TESLA packets by non-group members. Unfortunately, group members are still capable of sending packets with a valid external-authenticating MAC and invalid digital signature, i.e. a group member can launch a DoS attack on the group using invalid digital signatures. And group members are still capable of sending packets with a valid external-authentication MAC but an invalid TESLA MAC. In both the TESLA and digital-signature cases, the external authentication will succeed only to have the internal authentication fail. MESP includes the ESP sequence number in the internal authentication to protect against a replay attack by a group member. When the RECOMMENDED external authentication code is use, however, the ESP receiver MUST validate both the internal authentication as well as the external authentication before updating the ESP replay window. The value of MESP authentication transforms is to enable the receiver to greatly reduce the effect of an attack by non-group members, to reduce the effects of a denial of service attack by a group member, to detect an attack by a group member, and to support the integration of multicast source-authentication transforms into IPsec ESP for data-origin authentication. 5.3 MESP Encryption The value of MESP encryption is to validate individual encryption transforms for multicast operation. It is possible that a Baugher, Canetti, Cheng, Rohatgi [Page 9] INTERNET-DRAFT Multicast ESP March 2003 particular cipher and mode are suitable for pairwise security associations but not for multicast security associations, such as one where multiple senders share the key. For example, a stream or hybrid stream/block cipher has special risks of keystream reuse when its key is shared by multiple senders. Although IPsec encryption transforms are generally suitable for multicast operation, many have not been evaluated, tested or used in IP multicast environments. This I-D has considered the suitability of several IPsec ESP encryption transforms for inclusion in the MESP framework. It is RECOMMENDED that all future IPsec encryption transforms be analyzed as to their security for multicast and group security as well as for pairwise security. 6.0 IANA Considerations This I-D extends the RFC 2407 attributes for IPsec ESP, PROTO_IPSEC_ESP [RFC2407]. Within PROTO_IPSEC_ESP, MESP reserves the transform identifier value 13 [See IANA, "IPSEC ESP Transform Identifiers"]. MESP also adds new type/length/value attributes to RFC 2407. For the MESP transform ID security association attributes, the ENC Transform has type number 11, the INT transform has type number 12, and the EXT transform has type number 13 [see IANA, "Security Association Attributes"]. class value type ----------------------------------------- ENC-Transform 11 B INT-Transform 12 B EXT-Transform 13 B The ENC-Transform has the following values. name value ---- ----- Reserved 0 3DES 1 AES-CBC 2 AES-CTR 3 The INT-Transform has the following values. name value ---- ----- Reserved 0 RSA-SHA 1 TESLA 2 The EXT-Transform has the following values. name value ---- ----- Reserved 0 HMAC-SHA1 1 Baugher, Canetti, Cheng, Rohatgi [Page 10] INTERNET-DRAFT Multicast ESP March 2003 7.0 Acknowledgements The authors wish to thank Scott Fluhrer, Thomas Hardjono, Steve Kent and Brian Weis for their thoughtful comments and suggestions. 8.0 Author's Address Mark Baugher Cisco Systems, Inc. 5510 SW Orchid Street Portland, Oregon mbaugher@cisco.com +1-503-245-4543 Ran Canetti IBM T.J. Watson Research Center 30 Saw Mill River Road Hawthorne, NY 10598, USA canetti@watson.ibm.com Tel: +1-914-784-6692 Pau-Chen Cheng IBM T.J. Watson Research Center 30 Saw Mill River Road Hawthorne, NY 10598, USA pau@watson.ibm.com Tel: +1-914-784-6692 Pankaj Rohatgi IBM T.J. Watson Research Center 30 Saw Mill River Road Hawthorne, NY 10598, USA rohatgi@watson.ibm.com Tel: +1-914-784-6692 9.0 References 9.1 Normative References [AHBIS] S. Kent, IP Authentication Header (AH), IETF, Work in Progress, March 2003, http://www.ietf.org/internet-drafts/draft- ietf-ipsec-rfc2402bis-02.txt [ESPBIS] S. Kent, IP Encapsulated Security Payload (ESP), IETF, Work in Progress, March 2003, http://www.ietf.org/internet-drafts/draft- ietf-ipsec-esp-v3-04.txt. [GDOI] M. Baugher, H. Harjono, H. Harney, B. Weis, The Group Domain of Interpretation, IETF, Work in Progress, October 2002, http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-06.txt. Baugher, Canetti, Cheng, Rohatgi [Page 11] INTERNET-DRAFT Multicast ESP March 2003 [GSAKMP] H. Harney, A. Schuett, A. Colegrove, GSAKMP Light, IETF, Work in Progress, July 2002, http://www.ietf.org/internet- drafts/draft-ietf-msec-gsakmp-light-sec-01.txt [IANA] http://www.iana.org/assignments/isakmp-registry [MIKEY] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Normann, MIKEY: Multimedia Internet KEYing, IETF, Work in Progress, September 2002, http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey- 04.txt [PKCS1] PKCS #1 v2.1: RSA Cryptography Standard, RSA Laboratories, ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf, June 2002. [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, HMAC: Keyed-Hashing for Message Authentication, Internet Request for Comments 2104, IETF, November 1997, ftp://ftp.rfc-editor.org/in-notes/rfc2104.txt. [RFC2401] S.Kent, R.Atkinson, Security Architecture for the Internet Protocol, Internet Request for Comments 2401, IETF, November 1998, http://www.ietf.org/rfc/tfc2401.txt. [RFC2404] C. Madson, R. Glenn, The Use of HMAC-SHA-1-96 within ESP and AH, Internet Request for Comments 2404, IETF, November 1998, http://www.ietf.org/rfc/rfc2404.txt. [RFC2407] D. Piper, The Internet IP Security Domain of Interpretation for ISAKMP, Internet Request for Comments 2407, IETF, November 1998, http://www.ietf.org/rfc/rfc2407.txt. [RFC2451] Pereira, R., and R. Adams, "The ESP CBC-Mode Cipher Algorithms", Internet Request For Comments 2451, IETF, November 1998, ftp://ftp.rfc-editor.org/in-notes/rfc2451.txt. [RFC3376] B.Cain, S.Deering, B.Fenner, I. Kouvelas, A. Thyagarajan, Internet Group Management Protocol, Version 3, Internet Request for Comments 3376, IETF, October 2002, http://www.ietf.org/rfc/rfc3376.txt. [SSM]H.Holbrook, B.Cain, Source Specific Multicast for IP, http://www.ietf.org/internet-drafts/draft-ietf-ssm-arch-00.txt, Work in Progress [TESLA] 9.2 Informative References [CGIMNP] Canetti R., J. Garay, G. Itkis, D. Micciancio, M. Naor, B. Pinkas, "Multicast Security: A Taxonomy and Efficient Authentication", INFOCOM '99. Baugher, Canetti, Cheng, Rohatgi [Page 12] INTERNET-DRAFT Multicast ESP March 2003 [CP] R. Canetti, B. Pinkas, "A taxonomy of multicast security issues",draft-canetti-secure-multicast-taxonomy-01.txt, Nov. 1998. [Ch] S. Cheung, An Efficient Message Authentication Scheme for Link State Routing, Proceedings of the 13th Annual Computer Security Applications Conference, San Diego, December 8-12, 1997, pp.90-98. [GR] R. Gennaro, P. Rohatgi, "How to Sign Digital Streams", Advances in Cryptology - Crypto '97, Springer-Verlag LNCS 1294, pp. 180-197, 1997. [K] H. Krawczyk, The order of encryption and authentication for protecting communications (or: How secure is SSL?). In J. Kilian, editor, CRYPTO 2001. [PCTS] A. Perrig, R. Canetti, D. Tygar, D. Song, Efficient Authentication and Signature of Multicast Streams over Lossy Channels, IEEE Symposium on Security and Privacy, Oakland, CA, May 2000. [R] P. Rohatgi, A Compact and Fast Signature Scheme for Multicast Packet Authentication, In 6th ACM Computer and Communications Security Conference (CCS) , Nov 1999. [WL] C. K. Wong and S. S. Lam, Digital Signatures for Flows and Multicasts, IEEE ICNP '98. See also University of Texas at Austin, Computer Science Technical report TR 98-15. Baugher, Canetti, Cheng, Rohatgi [Page 13]