Internet Research Task Force Ran Canetti (IBM Watson) INTERNET-DRAFT Pankaj Rohatgi (IBM Watson) Pau-Chen Cheng (IBM Watson) Multicast Data Security Transformations: Requirements, Considerations, and Prominent Choices 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 to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract In the framework document , the Secure Multicast Group (SMuG) has identified three building blocks that deal with security transformations for the multicasted data. These are data encryption, source authentication, and group authentication. This document expands on the issues to be taken into consideration when designing transforms that realize these building blocks. These issues include the order of applying the transforms, their placement in the communication layers, possible aggregation of several building blocks in a single transform, and the relationships with other protocols (such as reliable multicast protocols). Next a specific design is proposed, that attemts to meet the requirements of prominent application in a simple yet flexible way. Contents: 1. Introduction.................................................. 2 2. Data security transforms...................................... 3 2.1 The three building blocks ................................. 3 2.2 Considerations ............................................ 4 3. The proposed design .......................................... 6 4. Possible usage patterns ...................................... 9 5. References.................................................... 11 Canetti Rohatgi Cheng 1 A remark on terminology: we make a distinction between the term "functional building block" (in the sense of [HCBD]) and the term "security transform". The former refers to a cryptographic functionality (e.g., encryption, source authentication, or group authentication). The latter refers to an actual transform that is being carried out on the data (e.g., ESP or AH). In particular, a single transform can provide the functionality of more than one building block. 1. Introduction A security solution for IP multicast consists of three main components: a component that sets the security policy of the group (typically set by the group controller), a component that handles the interaction between group members and the group controller(s) (and in particular guarantees secure dissemination and update of policy and cryptographic keys to the group members), and a component that applies actual cryptographic transforms to the data in order to implement the security policy. See more details in the SMuG framework document [HCBD]. This document concentrates on the design and placement of the cryptographic transforms applied to the multicasted data. It starts with a short review of the building blocks for multicast security data transforms. Next it reviews the issues related to the ordering, placement and aggregation of these building blocks. This includes integration of the transforms with each other, with the current IP multicast model, with reliable multicast protocols, and with the secure multicast framework. Next a specific design for the security data transforms is proposed. The design emphasizes flexibility, simplicity and maximal reuse of IPSec (in particular, ESP [KA]). It allows providing security either in the IP layer or in the application/transport layer. It also allows for easy incorporation within the reliable multicast protocols that are being designed in the Reliable Multicast Transport (RMT) working group. The design is quite simple. It consists of two ESP-like transforms, MESP (for Multicast ESP) which is an IP layer transform and AMESP which is an application/transport layer transform: * MESP is an extension of ESP, in a sense that for certain choice of parameters, MESP is identical to ESP. In particular, MESP can keep the same IANA protocol number as ESP (namely, protocol 50). This also means that the existing ESP transform can be used to provide limited support for secure multicast. * AMESP is similar to MESP, but works in the application/transport layer. Canetti Rohatgi Cheng 2 Each one of these transforms is capable of providing full security for the data (encryption, group and source authentication) independently of the other. Furthermore, in general a secure multicast protocol-suite will apply *both* transforms to the data. It is up to the security policy (set by the application) to specify which cryptographic algorithms, if any, are invoked in each transform. This design allows for increased flexibility in the ordering and layer placement of the three basic building blocks. Using different sets of policy parameters, a system can do all the cryptographic transforms in the application layer, all in the network layer, or some in the application and some in the network layer. In addition, AMESP can be used in conjunction with a transport-layer reliable multicast transform, to obtain a single transform that guarantees both reliability and security. See more details in Section 4. 2. Data security transforms: Issues and considerations. The security requirements for multicast have been discussed and enumerated in the SMuG Framework document [HCBD] and also in [CP]. In particular, these reference documents identify three different building blocks for data transforms that must be part of any complete solution. 2.1 The three building blocks The functional building blocks for multicast security data transforms are: a) Group Secrecy (GS). The group secrecy building block ensures that the transmitted data is accessible only to group members. 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 confidentiality in unicast b) Group Authentication (GA). This building block 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 could have been forged by any malicious group member. It can be efficiently realized using standard shared key authentication mechanisms such as Message Authentication Codes (MACs), e.g., CBC-MAC or HMAC. Canetti Rohatgi Cheng 3 c) Source Authentication (SrA). This building block 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). Clearly Source Authentication provides a much stronger security guarantee than the Group authentication Transform. Realizing source authentication requires stronger cryptographic techniques such as digital signatures, stream signatures [GR], flow signatures [WL], hybrid signatures [R], timed MACs [PCTS], asymmetric MACs [CGIMNP], etc. 2.2 Considerations regarding ordering, layer placement and aggregation of the building blocks. A secure multicast solution is likely to utilize all three of the basic building blocks. Due to the diverse application and deployment scenarios, several issues arise with respect to the layering of these building blocks (i.e., in which layer of the networking stack each building block is applied to the data), ordering of application of the building blocks and use of composite transforms that aggregate more than one building block. These issues are listed below. 1. Should transforms include only a single building block or should transforms combine several building blocks for common usage scenarios? For example using ESP provide both encryption and group authentication. 2. Potential for interactions between transforms and Reliable Multicast Protocols: A. Several multicast reliability mechanisms are based on local recovery from packet loss. In such scenarios, the reliability mechanism resides above the network layer. The encryption transform would interfere with local recovery, if the local recovery agent (e.g., "repair node") is not a group member and the encryption is performed at network layer. B. Other types of reliable multicast protocols (e.g., protocols based on Forward Error Correction (FEC) techniques) require source authentication to be done below or together with the reliability transform. This is because these reliability solutions are very susceptible to denial-of-service attacks based on a small number of forged packets. C. The Source Authentication Transform can be realized much more efficiently over Reliable Multicast than over plain IP-Multicast. This means that the choice of a data transform could depend on whether reliable multicast is provided. Canetti Rohatgi Cheng 4 3. Should all transforms be applied at the same level in the networking stack, either application or network layer or should there be flexibility ? Flexibility complicates the design. However if a flexible solution is used then consistency is cleaner, and there is no conflict on granularity of group membership (it can be either host or application). furthermore, flexibility may allow the use of existing IPSec components directly, and may facilitate the transition from application-layer transforms to network-layer transforms without changing the overall design. 4. Considerations regarding placing transforms at different layers of the stack. Arguments in favor of application level transforms: - Supports application -level group membership granularity. - Faster to implement and deploy, requires no kernel modifications. - Less efficient, especially in multiple group members per host scenarios - requires modification to current multicast applications Arguments in favor of network level transforms: - Supports host-level group membership granularity. - more efficient, especially in multiple group members/host scenarios - if done right, secure multicast should be transparent to current multicast applications 5. In scenarios where more than one building block is used, the order of application of he building blocks could be important. - Source authentication should ideally be done before encryption. Two reasons are: -- For the purpose of non-repudiation, it is a good cryptographic practice to apply source authentication before any encryption. If a source authenticates encrypted data, then for non-repudiation purposes there may be ambiguity regarding the cleartext, since every different key potentially yields a different cleartext. (To mitigate this problem the source could also authenticate the key used but then one cannot assume on the source authentication tag on encrypted data and the key used will not leak information about the key.) -- Encrypted data may get decrypted and re-encrypted by a different key at gateways between different domains, e.g., in Iolus or because of legal restrictions on permissible encryption schemes. Therefore in this scenario source authentication information should be added before encryption. Canetti Rohatgi Cheng 5 - To minimize impact of denial-of-service attacks, it is usually best to have group authentication transformation performed last, i.e., checked first. In summary, the order GA[GS[SrA[M]]] seems best from a cryptographic point of view. However, since exceptions are likely to arise it is best not to mandate an order. REMARK: Order of transform application and the level (in the network stack) they are applied are related. Order of application can only move down the stack. 3. The proposed design 3.1 Network layer transform: MESP The Network layer transform (MESP) is intended to be an extension of the ESP transform in IPSec, in that the encryption algorithm of the ESP is overloaded to perform both encryption and source authentication. Also, the authentication algorithm of ESP can be replaced by an algorithms that guarantee source authentication (such as timed MACs algorithms). Thus the MESP packet is identical to an ESP packet in situations where no source authentication is done in the network layer. Canetti Rohatgi Cheng 6 Figure 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) | Ext. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth | Sequence Number | cov. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | | IV (if any) | | | ~ ~ | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | --- | --- | Source ID | | ^ | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Multicast Session ID | | | | | ~ ~ | I | | | | | n | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | t. | | | Internal Authentication SEQ # | | A | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | u | | | Reserved | Data Length | | t | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | h. | | | | P co | | | Data (variable) | a ve | | ~ ~ y ra | | | | l ge | | | | o v | | |...............................................................| a --- | | | Internal Authentication Tag (variable) | d | | | | | |Conf +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |Cov. | | Padding (0-255 bytes) | | | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Pad Length | Next Header | v v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- --- | External Authentication Data (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Canetti Rohatgi Cheng 7 The MESP Packet format is illustrated in Figure 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. As in IPSec, the SPI together with the destination address uniquely identify a Security Association (SA) and associated keying material. The main difference between the unicast and multicast case is that the destination address in this case is a multicast address. It is also expected that each sender in a multicast group would be assigned a different SPI, so that each source can manage its own sequence number. The sequence number field is followed by a variable amount of encrypted data as in an ESP packet. In cases where the MESP does not involve any internal authentication, the structure of the encrypted data is identical to that of the ESP packet. In case the MESP involves internal authentication, the structure of the encrypted data is essentially the ESP encryption transform applied to the result of applying the internal authentication algorithm on the data. Thus in this case the encrypted data consists of an optional IV, followed by an encryption of variable sized data block consisting of a variable sized internal authenticated data, followed by variable amount (0-255 bytes) of padding followed by the pad length and next header fields as in ESP. The next header field still refers to the next protocol header in the actual data. The format of the internal authenticating data will be described in greater detail later. As in ESP, the encrypted data is followed by the external authentication data or tag, which provides either group or source authentication (depending on the algorithm used) for the SPI, SEQ Number and encrypted data. If the current authentication algorithms of ESP are used then the the external authentication data provides only group authentication. If appropriate algorithms are used (such as timed MACs) then the external authentication may provide also source authentication. 3.1.1 Internal Authentication transform format. We now describe the internal authentication transform format in greater detail. The internal authentication transform prepends a fixed size internal authentication header to the data to be authenticated and appends a variable sized internal authentication tag at the end of the data. The internal authentication tag authenticates both the header and the data. The internal authentication header consists of of a 32-bit Source ID field, followed by a TBD sized Multicast Session ID field, followed by a 32-bit Internal Authentication Sequence Number field followed by a 16-bit reserved field (currently mandated to be all 0 bits) followed by a 16 bit Data Length field. The function of each of these fields is as follows. Canetti Rohatgi Cheng 8 Source ID: This is a 32 bit quantity which identifies the source. The source identifier could be independent of the particular SPI that is assigned to the source for the particular multicast session. Multicast Session ID: This identifier uniquely specifies the current multicast session in which the source is participating. This field is intended to prevent out-of-context substitution attacks wherein source authenticated data from a particular source in one multicast session is replayed by an attacker in another session. The size of this field is TBD. Internal Authentication SEQ number: This sequence number is with respect to the stream/flow of internal authenticated data from the source in the current multicast session. In general this may not be related to the ESP sequence number which may be only group authenticated. Reserved field. This 16-bit field which is currently set to 0's is reserved for future extensions. Data Length field. This 16-bit field must contain the length of the data (in bytes) that is authenticated using the internal authentication algorithm. Since both the length of the authenticated data and the internal authentication tag are variable sized this field is to be used to determine the beginning of the internal authentication tag. 3.2 Application layer transform: AMESP The structure of the AMESP mimics the structure of MESP. The only difference is that the next header field in not meaningful and is mandated to be set to all 0's. Other fields are meant to be functionally equivalent. 4. Possible usage patterns To exemplify the usability of the above design, we briefly mention some potential usage patterns. (1) AMESP with encryption, source and group authentication, null MESP. Here all the security is applied in the transport/application layer, and no network layer mechanisms are deployed. This mode requires no kernel modifications and can be used in groups where hosts do not have IPSec deployed. Canetti Rohatgi Cheng 9 (2) AMESP with source authentication, MESP with encryption and group authentication. Here source authentication is applied in the transport/application layer, and encryption and group authentication are applied in the network layer. This mode requires no kernel modifications and can be used wherever IPSec is deployed. (3) Null AMESP, MESP with encryption, source and group authentication. Here all the security is applied in the network layer. This mode requires some kernel changes (adding a transform in the ESP format), but has the advantage that security is transparent to applications. However, this mode is incompatible with retransmission-based reliable multicast, unless all the retransmission points become group members. (4) AMESP used in conjunction with a reliable multicast transform. When a secure multicast protocol is used in conjunction with a transport-layer reliable multicast protocol, it is possible to use AMESP to obtain reliable multicast transport-layer transform that provides both security and reliability. Such a transform would have a dedicated security field, and its processing can proceed roughly as follows. (The description corresponds to the processing of an outgoing packet. Processing of an incoming packet is analogous.) a. Apply a first-pass of the reliability transform, with the security field "zeroed out". Obtain a packet (or frame) denoted P. b. Feed P (as data) to AMESP. c. Use the fields of the generated packet (in AMESP format) to modify P as follows: - Replace the data field of P with the encrypted payload of AMESP. - Fill the security field in the header of P with: -- The header information of AMESP, including the SPI, the sequence number and IV. -- The external authentication tag of AMESP The obtained modified packet, P', is the result of the combined transform. The combined transform has the advantage that the security algorithms are applied to the data *after* the reliability algorithms, and are still done at the transport layer (and potentially outside of the kernel). Furthermore, there is only one transport-layer multicast header. This can potentially be useful when one needs to provide, at the transport layer, source authentication of individual data packets. Canetti Rohatgi Cheng 10 5. 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. [GR] R. Gennaro, P. Rohatgi, "How to Sign Digital Streams", Advances in Cryptology - Crypto '97, Springer-Verlag LNCS 1294, pp. 180-197, 1997. [HCBD] T. Hardjono, R. Canetti, M. Baugher, P. Dinsmore, "Secure IP Multicast: Problem areas, Framework, and Building Blocks", Internet Draft draft-irtf-smug-framework-00.txt, October 1999. [KA] Stephen Kent, Randall Atkinson, "IP Encapsulating Security Payload (ESP)", Internet Draft draft-ietf-ipsec-esp-v2-06.txt, July 1998. [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 Authenticatio". 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. Authors Addresses Ran Canetti EMail: canetti@watson.ibm.com Pau-Chen Cheng EMail: pau@watson.ibm.com Pankaj Rohatgi EMail: rohatgi@watson.ibm.com IBM T.J. Watson Research Center 30 Saw Mill River Road Hawthorne, NY 10598, USA Tel: +1-914-784-6692 Canetti Rohatgi Cheng 11