Internet Engineering Task Force Mark Baugher (Cisco Systems) MSEC Working Group Ran Canetti (IBM Watson) INTERNET-DRAFT Pau-Chen Cheng (IBM Watson) EXPIRES: April 25, 2003 Pankaj Rohatgi (IBM Watson) October 25, 2002 MESP: Multicast Encapsulating Security Payload 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 security protocol for IP multicast data. MESP extends the IPsec Encapsulating Security Payload (ESP) protocol for multicast operation and supports source message authentication for multicast packets. MESP offers three improvements to IPsec ESP for multicast operation. First, it allows a mix of group-secrecy, group-authentication, and source-authentication transforms to be applied to an MESP packet. Second, it extends ESP to authenticate messages sent by a member of the group using a digital signature or hybrid MAC and signature transform. And third, MESP identifies a security association (SA) using the IP address of the source in addition to the destination address and SPI. INTERNET-DRAFT Multicast ESP October 25, 2002 TABLE OF CONTENTS 1.0 Notational Conventions..........................................2 2.0 Introduction....................................................2 3.0 Changes from the IPsec Specifications...........................3 3.1 Changes from RFC 2401..........................................3 3.2 Changes from RFC 2406..........................................4 4.0 IP Multicast Security Functionalities...........................5 4.1 Composition of the Functionalities.............................6 4.2 MESP Security Association and Parameters.......................7 5.0 MESP Packet Format.............................................7 5.1 MESP Transforms................................................9 5.2 MESP Conformance Requirements.................................10 5.3 MESP Signaling................................................11 5.3.1 GDOI......................................................11 5.3.2 GSAKMP....................................................11 5.3.3 MIKEY.....................................................11 6.0 Security Considerations........................................11 7.0 IANA Considerations............................................13 8.0 Acknowledgements...............................................13 9.0 Author's Address...............................................13 10.0 References....................................................14 10.1 Normative References.........................................14 10.2 Informative References.......................................15 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 Like the IPsec Encapsulation Security Payload (ESP), MESP provides a set of security services that include access control, connectionless integrity, data origin authentication, rejection of replayed packets, confidentiality (encryption), and limited traffic-flow confidentiality [Section 3.1, RFC2401]. Unlike ESP, MESP provides data origin authentication for multicast sources. Thus, MESP is not ESP: MESP has a distinct protocol number from ESP. MESP does extend ESP, however, and MESP includes the base IPsec ESP documents in its definition. This I-D, therefore, assumes that the reader is familiar with the "Security Architecture for Internet Protocol" [RFC2401] and the "IP Encapsulating Security Payload (ESP)" [RFC2406] RFCs. Section 3 describes MESP changes to the IPsec RFCs for IP multicast data security. Section 4 reviews the functionalities of multicast data-security transforms for use by a variety of IP multicast applications such as Baugher, Canetti, Cheng, Rohatgi [Page 2] INTERNET-DRAFT Multicast ESP October 25, 2002 media streaming, process control, and reliable multicast applications. Section 4 describes the problem of authenticating the source of IP multicast data, and it describes the requirement for an IP multicast security association (SA) to support both "Any Source Multicast" (ASM) and "Source Specific Multicast" (SSM) groups [SSM, IGMPV3]. IPsec ESP is suitable for IP multicast groups that are (a) restricted to a single sender or (b) where all senders use a single group controller/key server. Case (a) relies upon the network configuration to prevent multiple senders. Case (b) requires that each sender be trusted not to impersonate any other sender and that all receivers accept parameters from within a single security domain. For cases where such restrictions do not hold, however, this proposed standards-track I-D RECOMMENDS use of MESP, which complements IGMPv3 source pruning and features source message- authentication for ASM and SSM environments. Section 5 describes the MESP extensions to the IPsec Encapsulating Security Payload (ESP) protocol for source message authentication and the other functionalities of Section 4. The design of MESP emphasizes flexibility, simplicity and maximal reuse of IPSec ESP. MESP preserves ESP functionality when multicast source authentication and sender-based indexing of SAs are not needed. Thus, the MESP packet structure is indistinguishable from ESP for particular mixes of the secure multicast functionalities. As there are three inter-dependent functionalities for MESP, Section 5 specifies their composition and ordering. The three functionalities are realized in cryptographic transforms that are secure for various uses and Section 6 recites the security considerations for each MESP transform. Section 6 considers IP multicast risks, the transforms that address a particular risk, and the suitability of a transform for various applications and environments. MESP has its own namespace, and Section 7 identifies Internet Assigned Names and Number (IANA) requirements for MESP. 3.0 Changes from the IPsec Specifications Although MESP has its own namespace, protocol number, and is a distinct security protocol from ESP, MESP reuses IPsec ESP's base specifications, RFC 2401 and RFC 2406. This I-D assumes that the reader is familiar with these specifications, which are referenced and not copied by MESP. The changes to RFC 2401 and RFC 2406 are listed in this section. 3.1 Changes from RFC 2401 MESP extends IPsec ESP to feature data-origin authentication for IP multicast data. "Data origin authentication...is limited by the extent to which secrets used with the authentication algorithm...are Baugher, Canetti, Cheng, Rohatgi [Page 3] INTERNET-DRAFT Multicast ESP October 25, 2002 shared among multiple possible sources" [Section 4.6, RFC 2401]. In an IP multicast group, symmetric encryption and authentication keys are shared among multiple potential sources thereby making data- origin authentication using symmetric keys impossible. Thus, the most significant change introduced by MESP to IPsec ESP are methods to uniquely identify sources of IP packets to a multicast group. The following are the specific changes introduced by MESP to RFC 2401. 1) MESP operates in both gateway (tunnel mode) and host (transport mode) environments without support for the IPsec Authentication Header protocol [Sections 3, 3.2 and 4.3, RFC2401]. MESP MAY be tunneled in an IPsec AH tunnel, but such operation is in the realm of IPsec and outside the scope of MESP. 2) An MESP destination-address selector MUST always be an IPv4 or IPv6 multicast address [Section 4.4.2, RFC2401]. 3) An MESP security association database (SAD) entry MUST be identified by the pair; there is no need to specify the protocol, which is always MESP [Section 4.4.3, RFC2401]. 4) MESP supports SA update for key refresh in addition to SA replacement, and IKE is not the default, automated key mangement protocol for MESP [Section 4.6.2, RFC2401]. 5) MESP receivers do not allocate the security parameter index (SPI), which MAY be allocated by the sender or by the group controller/key server (GCKS) for a multicast group [Section 4.7, RFC 2401]. 6) An MESP receiver MUST NOT share an SA among multiple senders to a multicast group [Section 4.7, RFC 2401]. Multicast groups having many senders might require that an SA be shared among all senders in the group. This sharing would obviate IPsec-style replay protection unless an MESP SA were re-defined to allow a replay list to be dynamically created for each observed sender. This seems onerous but so is the requirement for a receiver to support a large number of SAs for a group having a large number of senders. For these and other reasons, the use of a wildcard source-address in an MESP SA is for further study. 3.2 Changes from RFC 2406 Some MESP changes to RFC 2406 are also listed above for RFC 2401; these are included in this section for the sake of completeness. 1) MESP uses protocol number xxxx and not 50 [Section 2, RFC2406]. Baugher, Canetti, Cheng, Rohatgi [Page 4] INTERNET-DRAFT Multicast ESP October 25, 2002 2) An MESP SPI is selected by the sender or by the group controller/key server (GCKS) [Section 2.1, RFC 2406]. 3) MESP does not support use of AH for IP multicast packets [Section 3.1, RFC2406]. 4) MESP REQUIRES some form of message authentication; NULL authentication [Section 3.2.2, RFC2406] is supported only under certain circumstances that are defined in Section 4.1, below. 5) MESP refers to ESP authentication as the "external authentication," which MUST be a hash-based message authentication code [RFC2104, RFC2404] and which MUST NOT be a digital signature [Section 3.4.4, RFC2406]. 6) MESP has a different set of conformance requirements than IPsec ESP [Section 3.5, RFC2406]. Section 5.2 lists MESP conformance requirements. MESP conformance subsumes IPsec ESP conformance for authentication but not for encryption (see Section 5.2). MESP, however, classifies ESP message authentication as "group authentication" and ESP message confidentiality (encryption) as "group secrecy." The following section defines these functionalities. 4.0 IP Multicast Security Functionalities The security requirements for multicast have been discussed in [CP]. In particular, these reference documents identify three different functionalities that must be part of any complete solution. a) Group Secrecy (GS) The GS functionality ensures that the transmitted data is 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 is to encrypt data using a key known only to group members. Essentially, the solution for multicast is the 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 the potential risks of multicast operation and how those risks are averted. b) Group Authentication (GA). The GA functionality ensures that any group member can verify that the received data originated from someone in the group. 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 Baugher, Canetti, Cheng, Rohatgi [Page 5] INTERNET-DRAFT Multicast ESP October 25, 2002 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. IPsec ESP authentication using a hash-based message authentication code (HMAC) is strictly GA. c) Source and Data Authentication (SrA). The SrA functionality ensures that any group member can verify that the received data originated from the claimed source and was not modified en-route by anyone (including other malicious group members). Source and Data Authentication provides a much stronger security guarantee than the Group Authentication functionality. Realizing 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. 4.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 present [p. 11, RFC2406]. This 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 encryption offers a better defense against invalid packets in a denial of service attack. In MESP, therefore, the group secrecy (GS) transforms MUST precede group authentication (GA). 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. A digital signature over the plaintext packet payload, however, provides both message source authentication and non-repudiation. Digital signatures offer the simplest method for multicast source authentication (SrA) but are computationally expensive and impractical for high-rate packet flows. Given the relatively high cost of signature verification, a digital signature leaves the receiver highly vulnerable to denial of service attack when an attacker succeeds in getting the receiver to perform signature validation of bad packets. MESP protects a digitally-signed packet by applying a message authentication code to it 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," Baugher, Canetti, Cheng, Rohatgi [Page 6] INTERNET-DRAFT Multicast ESP October 25, 2002 which the sender applies to the packet payload before the MAC. Thus, MAC authentication 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. Thus, the digital signature is an internal-authentication transform that MUST be applied first at the sender and last at the receiver. MAC-based Group authentication 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 external authentication (GA). Other SrA transforms MAY be applied as internal or external authentication depending on the particular transform; TESLA, for example is an external authentication transform that obviates the use of a MAC (see Section 5.0). 4.2 MESP Security Association and Parameters The three secure-multicast functionalities are realized in an MSEC security association (SA), which is an extension of an IPsec SA [Section 4.4.3, RFC 2401]. MESP uses all of the SA "policy" parameters for IPsec ESP with the exception of the AH parameters as noted in Section 3, above. Any ESP encryption transform [p.10 RFC2407] MAY be used for MESP for the group-secrecy functionality. MESP also supports NULL encryption (NULL GS). The ESP authentication algorithm is the MESP GA transform, which must be an HMAC [RFC2404]. NULL GA authentication is supported for MESP when a MAC-based SrA transform is used in its place. NULL GA authentication MUST NOT be used with an SrA digital signature or with a NULL SrA transform. Thus, SrA is the single MESP addition to the IPsec SA database (SAD) parameters of RFC 2401. The SrA parameter consists of a named group source-authentication transform and a set of parameters that are unique to that particular transform. An MESP SA is also identified differently from an IPsec SA. An MESP SA is identified by the triple where "s" is the source IP address of the sender, "g" is the destination IP multicast address, and "SPI" is the security parameter index that MAY be assigned by the sender or by a third party entity such as a GCKS. This SA identification method allows any sender, s, to multicast group, g, to select an SPI without coordination with other senders to g. This method also allows a GCKS to operate on an basis with no need to mandate a common controller for all senders to g. As discussed above in Section 3.1, use of a wildcard value for s is for further study. 5.0 MESP Packet Format The MESP packet is identical to an ESP packet in situations where no internal authentication is applied. As with ESP, MESP MAY operate Baugher, Canetti, Cheng, Rohatgi [Page 7] INTERNET-DRAFT Multicast ESP October 25, 2002 in either tunnel mode from an MESP host or security gateway, or it MAY operate in transport mode at an MESP host only. As in ESP, the transport-mode MESP packet header appears between the IP header and the upper-layer protocol header (e.g. the transport header). The IP header carries the MESP protocol number that is designated in the IANA Considerations section of this I-D. As in ESP, the tunnel-mode MESP packet header appears after the encapsulating IP header and before the encapsulated IP packet. The encapsulating IP header carries the MESP protocol number that is designated in the IANA Considerations section of this I-D. Figure 5-1: MESP Format. 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 (if any) ~| | | || | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | | || ^ | ~ Internal Authentication Parameters (if any) ~| | | | |I E E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+N N X | |T C T ~ Data (variable) ~| | | |...............................................................|v | | | Internal Authentication Tag (variable) | | | | | | | | | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Padding (0-255 bytes) | | | ~ ~ | | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ External Authentication Data (variable) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The MESP Packet format is illustrated in Figure 5-1. As in the ESP packet format, the MESP packet starts with a 32-bit Security Parameter Index (SPI) field followed by a 32-bit sequence number field. Unlike, ESP, the IP address of the packet sender together Baugher, Canetti, Cheng, Rohatgi [Page 8] INTERNET-DRAFT Multicast ESP October 25, 2002 with the SPI and the destination IP address uniquely identify a Security Association (SA) and associated keying material. As in an ESP packet, the sequence number field is followed by an optional IV field. In cases where the MESP does not use internal authentication, the structure of the encrypted data field is identical to that of the ESP packet. In cases where the MESP uses internal authentication, the encrypted data consists of the following fields: * Internal Transform 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. A sender of an MESP packet MAY use an internal-authentication transform (INT). When INT is applied to the packet, its output (if any) is placed in the Internal Authentication Tag. Section 5.1 identifies the INT transforms, which the sender MUST perform prior to the encryption transform. A sender of an MESP packet MAY use an encryption-transform (ENC). As in an ESP packet, the encrypted payload (ENC in Figure 5-1) ends with variable amount (0-255 bytes) of padding followed by the pad length and next header fields. The next header field still refers to the next protocol header (e.g. transport header) in the actual data. Section 5.1 identifies the ENC transforms, which the sender MUST perform prior to the external authentication transform. A sender of an MESP packet MAY use an external-authentication transform (EXT). Section 5.1 identifies the EXT transforms, which the sender MUST perform last (and the receiver performs first). Thus the sender performs the MESP transforms in the order of INT, ENC, and EXT while the receiver performs them in the order of EXT, ENC and INT. 5.1 MESP Transforms Table 5.1-1 lists the MESP transforms and any dependencies that are associated with their application. As noted above, MESP REQUIRES that a MAC external authentication be used in conjunction with an internal-authenticating digital signature. This restriction reduces the effectiveness of a denial of service attack by a non-group member (i.e. by an MESP entity that does not hold the symmetric authentication key). The RSA-SHA1 [PKCS1] internal authentication Baugher, Canetti, Cheng, Rohatgi [Page 9] INTERNET-DRAFT Multicast ESP October 25, 2002 MUST have a zero-length Internal Transform Parameters field; the signed RSA appendix is placed in the Internal Authentication Tag. The size of the security of the RSA signature is of course determined by the size of the RSA key, which MUST be long enough to suffice for the duration of the ESP session (see Security Considerations). This version of MESP does not consider key sizes or other digital signature transforms. A future version of this I-D will consider the issue of digital signature key sizes for MESP sessions and the use of ECDSA as an alternative transform. TABLE 5.1-1: Pre-defined MESP Transforms +-----------------+----------------------+---------------+ | Transform Class | Transform Identifier | Dependencies | +-----------------+----------------------+---------------+ | | RSA-SHA1 | HMAC-SHA1 EXT | | INT +----------------------+---------------+ | | NULL | None | +-----------------+----------------------+---------------+ | ENC | Any ESP encryption | None | | | transform [RFC2407] | | +-----------------+----------------------+---------------+ | | HMAC-SHA1 | None | | EXT +----------------------+---------------+ | | TESLA | No INT | +-----------------+----------------------+---------------+ As indicated in Table 5.1-1, MESP MAY use any ESP encryption transform that is defined in RFC 2407. New MESP encryption transforms SHOULD be specified in an Internet RFC. As shown in Table 5.1-1, HMAC-SHA1 [RFC2404] is the only pre-defined MESP MAC and is REQUIRED when internal authentication is used. In addition to HMAC-SHA1, TESLA MAY be applied when no internal- authentication transform applies to an MESP packet. The Table 5.1-1 transforms are mutually exclusive by class: There MAY be at most one INT, ENC or EXT transform applied to an MESP packet. 5.2 MESP Conformance Requirements TABLE 5.2-1: Default and Mandatory MESP Transforms +-----------------+----------------------+ | Transform Class | Transform Identifier | +-----------------+----------------------+ | INT | RSA-SHA1 | +-----------------+----------------------+ | ENC | 3DES-CBC [RFC2451] | +-----------------+----------------------+ | EXT | HMAC-SHA1 | +-----------------+----------------------+ Baugher, Canetti, Cheng, Rohatgi [Page 10] INTERNET-DRAFT Multicast ESP October 25, 2002 5.3 MESP Signaling MESP parameters are signaled through a key management protocol or interface such as GDOI, GSAKMP, GKMP, or SDP. 5.3.1 GDOI GDOI MUST signal an MESP session using PROTO_MSEC_MESP as defined in the IANA Section of this I-D. PROTO_MSEC_MESP has the same TEK protocol-specific payload as PROTO_IPSEC_ESP [Section 5.4.1, GDOI]. MESP replaces the RFC 2407 attributes in the TEK payload with the following attributes. class value type ----------------------------------------- INT Transform 1 B EXT Transform 2 B Encapsulation Mode 3 B SA Life Type 4 B SA Life Duration 5 V Signature PubKey 6 V The INT Transform MAY be NULL, which has the value 1. When the EXT Transform is HMAC-SHA1, the INT Transform MAY be RSA-SHA1, which has the value 2. The EXT Transform MAY be HMAC-SHA1, which has the value 1, or it MAY be TESLA, which has the value 2 when the INT Transform is NULL. The Encapsulation Mode MAY be 1 for transport mode or 2 for tunnel mode. SA Life Type and Life Duration are as defined in RFC 2407. Life Type and Duration 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.} 5.3.2 GSAKMP TBD 5.3.3 MIKEY TBD 6.0 Security Considerations Baugher, Canetti, Cheng, Rohatgi [Page 11] INTERNET-DRAFT Multicast ESP October 25, 2002 MESP provides a set of security services that include access control, data origin authentication, rejection of replayed packets, confidentiality (encryption), limited traffic-flow confidentiality and connectionless integrity. With its default transforms, MESP services support 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. Some packet loss, delay and reordering are unavoidable on IP networks through normal operation as well as a result of attack from an interloper who has gained access to the packet flow. IP multicast packets are vulnerable to snooping and tampering, particularly on shared-media networks such as local area networks; the MESP group secrecy function (see Section 4) controls access to packet data and provides confidentiality to data exchanged among group members. Even encrypted packets carry IP headers in plaintext, however, and some environments might consider the source, destination, packet length and other packet-header information to be worthy of protection from unauthorized parties; MESP features the IPsec tunnel mode of operation to encrypt the entire IP multicast packet and thereby provide some traffic-flow confidentiality though the encapsulating IP packet unavoidably reveals some information about the tunnel endpoints (MESP implementations could alter the encapsulated packet length to further thwart traffic analysis by an attacker). An attacker that has access to the flow of IP multicast packets can "replay" the packets by capturing and resending the packets in an effort to disrupt the IP multicast session through a "denial of service" attack. MESP features the IPsec ESP replay counter to detect replayed IP packets (or packets duplicated during routine operation). Unlike IPsec, there is no provision in MESP for a receiver to disable replay protection through signaling since MESP sends to multiple receivers. Like IPsec ESP, however, key management MAY choose to configure group senders and receivers to neither set nor read the MESP packet sequence number though proper use of the replay counter is RECOMMENDED by MESP. If more than one sender shares an MESP security association (SA), however, then the IPSec-defined replay protection mechanism will not work. Thus, the current version of MESP mandates that an MESP SA MUST NOT be shared by multiple senders. It is for future study to determine whether SA-sharing is needed in MESP. The MESP replay counter is vulnerable to tampering if the integrity of the IP packet that contains the counter is not protected. MESP REQUIRES message integrity for MESP packets through one of two mechanisms. The first mechanism uses HMAC-SHA1 integrity with a symmetric authentication key. Unlike unicast IP packets, the MAC cannot authenticate the source of the packet for a multicast group where multiple members share the symmetric authentication key. Baugher, Canetti, Cheng, Rohatgi [Page 12] INTERNET-DRAFT Multicast ESP October 25, 2002 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 second MESP mechanism augments the MAC with a digital signature over the packet data to uniquely identify the sender of the packet. Digital signatures leave multicast receivers vulnerable to denial- of-service attack that the receiver attempts to validate through computationally-expensive signature validation. MESP mandates that HMAC-SHA1 message authentication MUST accompany a digital signature so as to limit the effectiveness of forging digitally signed packets by non-group members. Unfortunately, group members are still capable of sending packets with a valid MAC and invalid digital signature, i.e. a group member can launch a DoS attack on the group using invalid digital signatures. When this threat is an application concern, MESP supports multicast source authentication using hybrid MAC/digital signature and Timed MAC schemes, such as TESLA, to mitigate attacks by group members upon the group. TESLA source authentication can uniquely identify the source in a manner that amortizes the cost of a single digital signature over a very long chain of packets [TESLA]. 7.0 IANA Considerations MESP uses protocol number xxxx. Both of these values MUST be registered with IANA. GDOI uses PROTO_MSEC_MESP, which has the value xxxx. Within PROTO_MSEC_ESP, GDOI signals the INT Transform with the number 1, the EXT transform with the number 2, the Encapsulation Mode with the value 3, SA Life Type with 4, SA Life Duration with 5, and Signature PubKey with the value 6. Within the INT Transform, GDOI reserves the number 1 for the NULL digital signature and 2 for RSA-SHA1. Within the EXT transform, GDOI reserves the number 1 for HMAC-SHA1 and the number 2 for TESLA. Within Encapsulation Mode, GDOI reserves 1 for transport mode and 2 for tunnel mode. The values MUST be registered with IANA. 8.0 Acknowledgements The authors wish to thank Brian Weis and Scott Fluhrer, who identified some problems in a previous version of the draft. 9.0 Author's Address Ran Canetti IBM T.J. Watson Research Center 30 Saw Mill River Road Hawthorne, NY 10598, USA Baugher, Canetti, Cheng, Rohatgi [Page 13] INTERNET-DRAFT Multicast ESP October 25, 2002 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 Mark Baugher Cisco Systems, Inc. 5510 SW Orchid Street Portland, Oregon mbaugher@cisco.com +1-503-245-4543 10.0 References 10.1 Normative References [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. [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 [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. Baugher, Canetti, Cheng, Rohatgi [Page 14] INTERNET-DRAFT Multicast ESP October 25, 2002 [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. [RFC2406] S. Kent, R. Atkinson, IP Encapsulating Security Payload (ESP), Internet Request for Comments 2406, IETF, November 1998, http://www.ietf.org/rfc/rfc2406.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] 10.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. [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. Baugher, Canetti, Cheng, Rohatgi [Page 15] INTERNET-DRAFT Multicast ESP October 25, 2002 [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 16]