Internet Research Task Force Ran Canetti (IBM Watson) INTERNET-DRAFT Pankaj Rohatgi (IBM Watson) June 2000 Pau-Chen Cheng (IBM Watson) Multicast Data Security Transformations: Requirements, Considerations, and Proposed Design 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 functionalities 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 functionalities. These issues include the order of applying the transforms, their placement in the communication layers, possible aggregation of several functionalities in a single transform, and the relationships with other protocols (such as reliable multicast protocols). Next a specific design is proposed, that attempts to meet the requirements of prominent application in a simple yet flexible way. Canetti Rohatgi Cheng 1 Contents: 1. Introduction.................................................. 3 2. Data security transforms...................................... 4 2.1 The functionalities ....................................... 4 2.2 Considerations ............................................ 5 3. The proposed design .......................................... 7 4. Possible usage patterns ...................................... 10 5. References.................................................... 12 Canetti Rohatgi Cheng 2 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 functionalities for multicast security data transforms. Next it reviews the issues related to the ordering, placement and aggregation of these functionalities. 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 protocols (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. 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. Canetti Rohatgi Cheng 3 This design allows for increased flexibility in the ordering and layer placement of the three basic functionalities. 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. A remark on terminology: we make a distinction between the term functionality (or, "functional building block" in the terminology 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 more than one functionality. 2. Data security transforms: Issues and considerations. 2.1 The functionalities 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 functionalities that must be part of any complete solution. The functionalities for multicast security data transforms are: a) Group Secrecy (GS). The group secrecy functionality 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 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 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 4 c) Source and Data Authentication (SrA). This 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 [Ch,PCTS], asymmetric MACs [CGIMNP], etc. 2.2 Considerations regarding ordering, layer placement and aggregation 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 layering of these functionalities (i.e., in which layer of the networking stack each functionality should be applied to the data), ordering of application of the functionalities and use of composite transforms that aggregate more than one functionality. These issues are listed below. 1. Should transforms include only a single functionality or should transforms combine several functionalities for common usage scenarios? For example ESP provides both encryption and group authentication. 2. Potential for interactions between security transforms and Reliable Multicast protocols: A. Reliable multicast 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. B. Other multicast reliability mechanisms are based on having intermediary network entities (e.g., "repair nodes") retransmit lost packets. Since the reliability mechanism resides above the network layer, a network layer encryption transform would interfere with the retransmission mechanism unless the intermediary entities have access to the group key and decrypt and re-encrypt data. C. On the other hand, the Source Authentication functionality 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 5 3. Should all transforms be applied at the same level in the networking stack, either application or network layer or should there be flexibility in applying different transforms at different layers? The main advantage of a flexible approach is that it may allow the re-use of existing IPSec components directly, and may facilitate the transition from application-layer transforms to network-layer transforms without changing the overall design. However, the flexibility to apply different transforms in different layers would complicate both the design and the security analysis. For example, the end-points of the connections in different layers are different entities (e.g., host vs. application). 4. More 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. - some source authentication transforms are more efficient when applied at the application layer above some form of reliable multicast transport. Arguments in favor of network level transforms: - Supports host-level group membership granularity. - more efficient, especially in multiple group members/host scenarios. - Does not require modification of current multicast applications; if done right, secure multicast should be transparent to current multicast applications. 5. In scenarios where more than one functionality is used, the order of application of the functionalities 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. This may not be trivial since one has to make sure that authenticating the key does not leak any information on 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 applied before encryption. Canetti Rohatgi Cheng 6 - 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, it seems best not to mandate an order. For example, GA[GS[SrA[M]]] may be preferable in some scenarios, and SrA[GS[M]] may be more appropriate in other scenarios. 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 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 7 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 and Option Length | | t | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | h. | | | Transform-specific options (variable) | P co | | | + | a ve | | ~ Data (variable) ~ 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 8 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. As in an ESP packet, the sequence number field is followed by an optional IV field, plus a variable-length field of encrypted data. In cases where the MESP does not involve any internal authentication, the structure of the encrypted data field is identical to that of the ESP packet. In case that the MESP involves internal authentication, the encrypted data consists of the following fields: * Internal Authentication Sequence Number (4 bytes). This sequence number is potentially different than the ESP sequence number. (In particular, it can be source-specific.) Note that the Internal Authentication Sequence Number authenticated both by the internal authentication and by the external authentication transforms, whereas the ESP sequence number is authenticated only by the external authentication transform. * Reserved (2 Bytes) * Data and Options Length (2 Bytes) This field contains the combined length of the transform-specific options and of the data. It does NOT contain the length of the Internal Authentication Tag. * Transform-specific Options and Data (Variable) This field contains optional parameters that may be required by specific transforms, together with the data payload. For maximum flexibility, this document does not mandate any particular structure for this field; it is left to the designers of specific internal authentication transforms to come up with the most appropriate structure for this field. * Internal Authentication Tag (Variable) As in an ESP packet, the encrypted payload 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 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. Canetti Rohatgi Cheng 9 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 together with transform specific options, 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, options 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 and Options Length field. The function of each of these fields is as follows. 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 and Options 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. Canetti Rohatgi Cheng 10 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 even in groups where hosts do not have IPSec deployed. (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. Canetti Rohatgi Cheng 11 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. 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. [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. [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. Canetti Rohatgi Cheng 12 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 13