INTERNET-DRAFT R. Canetti, P-C. Cheng, draft-irtf-smug-sec-mcast-arch-00.txt D. Pendarakis, J.R. Rao, P.Rohatgi and D. Saha IBM Expires August 1999 February, 1999 An Architecture for Secure Internet Multicast <draft-irtf-smug-sec-mcast-arch-00.txt> 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. Canetti et. al. [Page 1]
INTERNET DRAFT February 1999 ABSTRACT This document proposes an architecture for secure IP multicast. It identifies the basic components and their functionalities, and specifies how these components interact with each other and with the surrounding systems. The main design principles followed in developing this architecture are simplicity, flexibility, ease of incorporation within existing systems. In particular, the design attempts to mimic the IPSec architecture, and to re-use existing IPSec mechanisms wherever possible. The proposed architecture is able to accommodate many of the existing proposals for multicast key management. In this draft, we concentrate on the architectural building blocks required to enable a group member (either a receiver or a sender of data) to use secure IP multicast. Design of the group controller(s) is left to future documents. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Security Requirements from Multicast Communication. . . . . . 3 3. Design Goals and Guidelines . . . . . . . . . . . . . . . . . 4 4. Architecture. . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 Architectural Block Diagram . . . . . . . . . . . . . . . 5 4.2 Architecture Overview . . . . . . . . . . . . . . . . . . 7 5. Design Guidelines for MIKE. . . . . . . . . . . . . . . . . . 11 5.1 Requirements of MIKE. . . . . . . . . . . . . . . . . . . 11 5.2 Architectural Block Diagram of MIKE . . . . . . . . . . . 12 5.3 An Example Group Key Management Module. . . . . . . . . . 12 5.4 Architectural Block Diagram of MKMM . . . . . . . . . . . 14 6. Issues for use of IKE and IPSEC . . . . . . . . . . . . . . 15 6.1 Use of IKE. . . . . . . . . . . . . . . . . . . . . . . . 15 6.2 Identifications of Multicast Security Associations. . . . 15 6.3 SPI Assignment. . . . . . . . . . . . . . . . . . . . . . 15 6.4 Sequence Number Handling and Replay-Prevention. . . . . . 16 7. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Authors Addresses . . . . . . . . . . . . . . . . . . . . . 17 Canetti et. al. [Page 2]
INTERNET DRAFT February 1999 1. Introduction This document proposes a basic architecture for a secure IP multicast standard. It identifies the basic components and their functionalities, and specifies how these components interact with each other and with the surrounding systems. We start with a brief overview of the security requirements for multicast communication. We then describe some basic design principles followed here. Next, we sketch and motivate the overall design. We also suggest design principles for two main modules: key management and source authentication. Finally, some issues for discussion and related work are presented. Given the large variance in the characteristics and security requirements of different multicast applications, it is unlikely that a single solution will be adequate for handling all possible applications (see [CP,Q]). Still, we believe that the architecture described here is flexible and general enough to serve as a common ground for most future solutions. Following the rationale of the IPSec architecture [KEN98c], this document goes beyond making the minimum specifications required for interoperability. It sketches the internal design required of a secure multicast protocol. Such a detailed specification is needed since the overall security of the system often depends on the correct internal operation of all the components. The current version of this document does not fully specify the internal structure of all the modules. These will be described in subsequent documents. Canetti et. al. [Page 3]
INTERNET DRAFT February 1999 2. Security requirements from multicast communication We briefly sketch the salient security requirements. A more detailed discussion appears in [CP]. (a) Group membership control and confidentiality: This means making sure that the group communication is accessible only to legitimate group members. This document concentrates on a "flat" access control structure; that is, all the group communication is accessible to all group members. Hierarchical group membership (as in, say, [HM]) is not addressed here, and can be added at a later stage. Group membership control is usually implemented by having a group key shared by all group members. All group data communication is encrypted via symmetric encryption using this key. The architecture proposed here follows this approach. For many applications, group membership is likely to vary over time. It is often required that members leaving a group lose access to future group communication. It is also sometimes required that members joining a group will not gain access to group communication that occurred before they joined. Note that in order to implement access control it must be possible to authenticate the identity of potential group members. This can be done using public-key certificates of potential members. (b) Group data authentication: This refers to the process by which a group member is able to verify that the group communication originated from a source within the group. Here the recipient of the communication is not generally able to authenticate the individual source but is able to verify that the communication originated with some member of the group. We follow the usual approach of implementing group data authentication using a dedicated key shared among all group members. All the communicated data is authenticated via Message Authentication Codes, using the common key. (c) Individual source authentication: This refers to the process by which group members are able to verify the identity of the sender of data to the group. The problem of source authentication in multicast is inherently different from the source authentication problem for point-to-point connections since single MAC based solutions (such as those used in IPSec) are not applicable here. (see [CP] for a survey of techniques for achieving this goal). Other security concerns, like non-repudiability and anonymity, are not addressed here, and will be determined by the specific implementation. Canetti et. al. [Page 4]
INTERNET DRAFT February 1999 3. Design Goals and Guidelines Our main design goals are simplicity, flexibility, ease of incorporation within existing systems. To achieve these goals, we follow the guidelines listed here: (a) Make the design independent from the underlying routing mechanism. The architecture does not interfere with the routing mechanism of the data. Data packets may be routed via any multicast or unicast routing. For sake of simplicity and modularity of design, we recommend that the key management mechanism assume reliable communication. Yet, no specific mechanism for obtaining reliability is specified. Any reliable multicast or unicast mechanism (e.g., TCP) can be used. (b) Mimic the IPSec architecture and design as much as possible. As in IPSEC, we separate the modules that handle data from those that handle key management. Functions such as the generation, distribution and update of cryptographic keys are encapsulated in a key management module. In addition, the key management module is placed in the "application layer" of the communication, and outside the OS kernel. This facilitates application specific operations, such as multiplexing of data for different users and certificate verification. The data handling part lies mostly in the IP layer, using IPSec modules. (Yet, we introduce an additional level of data handling, in the interest of source authentication. See details in the sequel.) (c) Use existing components wherever possible. Specifically, we use IPSec's ESP and AH protocols for encrypting and authenticating data. The ESP protocol [KEN98a] is used for exchanging encrypted and authenticated multicast data. If confidentiality is not an issue or if additional authentication beyond what is provided by the ESP authentication mechanism is required (such as authentication of the IP header) then the AH protocol can also be used. Since IPSec was mostly designed for unicast, there are a few issues that arise when the ESP/AH protocols are used for multicast data. We discuss some of these issues in Section 6. Multicast-specific packet transformations may be introduced in the future. (d) Minimize modifications of the OS kernel. The current architecture is structured so that the new multicast security specific components are kept in the application space and the IPSec components that are currently in the OS kernel can be used Canetti et. al. [Page 5]
INTERNET DRAFT February 1999 for multicast security without modification. It is expected that with time, some of the multicast specific components may be moved to the kernel and IPSec components already in the kernel would be modified to better support multicast. (e) Flexibility in the choice of cryptographic algorithms and key management schemes. By re-using the IPSec design for data transport, we retain the flexibility of using any data encryption and authentication algorithm which can be supported by IPSec. The new components introduced in this document, namely the Multicast Internet Key Exchange Module (MIKE) and the Source Authentication Module (SAM) provide frameworks which are flexible enough to support most group key management and source authentication schemes. 4. Architecture This section presents the architecture. We start with a block diagram, and continue to describe the functionalities of the various components, and the data flows. 4.1 Architectural Block Diagram There are two types of entities involved in Secure Multicast, namely the group members which participate in the Secure Multicast communications and the controller(s) which manage keys for the group or parts of the group and enforce access control. The architecture of the controller(s) depends on the group access control and key management mechanism and is expected to vary widely. Therefore we concentrate on the architecture of a group member where uniformity is desirable and is achievable. The architecture separates between control and data plane functions. The primary responsibility of control plane functions is to manage group membership and enforce access control privileges. Data plane functions handle multicast data distribution and cryptographic operations such as encryption, decryption, digital signature generation and signature verification. Canetti et. al. [Page 6]
INTERNET DRAFT February 1999 The block diagram of a secure multicast host is shown below. CONTROL PLANE * DATA PLANE * ------------------------------------------------ | | | CLIENT APPLICATION | | | ------------------------------------------------ /\ * /\ || * || Control || join/leave * Data || send/receive API || * API || || * || \/ * || -------------------------- * || | | * || | MULTICAST INTERNET | * || | KEY EXCHANGE MODULE | * || | ( M I K E ) | * || -------------------------- * \/ /\ | * -------------------- || V * | | || --------------------- * | SENDER AUTHEN. | || | MULTICAST SECURITY |---->| MODULE | || | ASSOCIATION | * | ( S A M ) | || | ( M S A ) | * -------------------- || --------------------- * /\ || | * || User Space ===================|===============*=========================== || | * || Kernel || | * \/ || | * ------------------ || ------------------>| IPSec | || * | (AH + ESP) | \/ * ------------------ * /\ Secure Multicast Key * || Management Flows * \/ * * Secure Multicast Data * Flow Figure 1: Block diagram of secure multicast framework Canetti et. al. [Page 7]
INTERNET DRAFT February 1999 4.2. Architecture Overview We describe the architecture of a member of a secure multicast group. The member could either be a data recipient or a data sender or both. From the application's perspective, the secure multicast framework provides a simple API for using secure multicast. This API is logically partitioned into the Data API which deals with sending and receiving multicast data securely and the Control API which deals with the process of leaving and joining a secure multicast group and the associated access control and key update functions. 4.2.1 Architectural Components The major architectural components of the Secure Multicast Framework are: (a) MIKE - Multicast Internet Key Exchange. This module is responsible for key management and implements the Control API which permits applications to join and leave secure multicast groups. This module resides in the application layer, outside the OS kernel. It interacts with the MIKE modules of the group controller(s), and generates and maintains a Multicast Security Association (MSA) that contains: (i) Group keys for encryption/decryption and authentication of data (via the AH/ESP modules). (ii) Signing/Verification keys for source authentication of data by the SAM module, described below. (iii) Other information regarding the connection, as in an IPSec SA. In order to make a MIKE specification complete, the MIKE modules within the group controller(s) need to be specified. See more discussion on the design of MIKE in section 5. An additional functionality of MIKE is periodic updates of the MSA, whenever group keys or keys used by SAM are changed. Canetti et. al. [Page 8]
INTERNET DRAFT February 1999 (b) IPSec modules: AH/ESP. These are the IPSec modules that reside in the OS kernel and deal with encryption/decryption and authentication of data packets. These modules provide Encryption/Decryption and Group Authentication of incoming or outgoing Multicast Data. Data is encrypted with the group key by the sender(s) and decrypted using the same key by receivers. The ESP header remains as defined in the unicast case; the protocol header preceding the ESP header will contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field and its destination IP address will be the IP multicast group address, a class D address. Thus, the packet will be forwarded to all members of the group by routers supporting multicast delivery. ESP can be used in conjunction with the ESP authentication option (more on authentication below). In principle, ESP for multicast traffic can be used either in transport or tunnel mode, although transport mode is clearly more adequate in an environment where most participating members are end hosts. For multicast data authentication different techniques will be used depending on whether group or individual sender authentication is desired. For group authentication, the protocol designed for unicast IP security, namely the IP Authentication Header (AH) [KEN98b] and/or the authentication option within ESP are sufficient. All members share a common, symmetric authentication key which is administered by the group controller and which is used to generate the message authentication code (MAC). The AH header remains as defined in the unicast case; the protocol header preceding the ESP header will contain the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) field and its destination IP address will be the IP multicast group address, a class D address. The SPI value is selected, as for ESP, by the controller. (c) SAM - Source Authentication Module. This module is responsible for the transformations that enable authenticating the source of received data and possibly for replay protection. Scalable source authentication would typically involve operations that span more than a single packet, both for outgoing and incoming data. (UDP frames are good candidates for a basic unit for authentication.) Thus, it seems reasonable to place this component in a higher layer in the protocol stack, specifically in the application layer above UDP. Another advantage of placing SAM in the application layer is that this way the OS kernel need not be immediately changed. The internal structure of the SAM depends to a large extent on the source authentication mechanism used. Two basic source authentication mechanisms exist. One is authentication by public key signatures which may be applied on a group of packets via a variety of mechanisms (see [CP]). The other is authentication via symmetric authentication with multiple keys [CGJPMN]. Canetti et. al. [Page 9]
INTERNET DRAFT February 1999 An additional potential functionality of SAM is to provide replay protection for data, in case that the IPSEC replay protection mechanism is turned off because of multiple sender problems. (See Section 6.) We defer further design details of SAM to future documents. 4.2.2 Data and Control Flows Typical operation of the system proceeds as follows: Remark: Here we assume that the data is sent/received via reliable or unreliable IP multicast. However, the security mechanism described here can be used even when the data is being routed via point-to-point connections, such as TCP. The member initiates a secure multicast session by invoking the join operation in the Control API which is implemented by MIKE. This enables the member to register in the group as a sender or a receiver or both. Subsequently, the member is able to send and receive datagrams securely to the multicast group using the send/receive functions of the Data API. All group key management, data encryption/decryption and group/source authentication functions are managed by the secure multicast framework and are transparent to the member. If at some later point in time the member decides to leave the secure multicast group then this is done by invoking the leave operation in the Control API. This action eventually results in the termination of the member's ability to securely send/receive messages to the group. We now outline the data and control flows in more detail. (a) Control Flows: - Client Join: The application invokes MIKE to join a multicast group. At a minimum, the application must identify the group that it wishes to join and provide information as to the authentication required (e.g., whether or not source authentication is required and if so, the sources it will trust). MIKE then performs the process of registering with the group controller(s), sets up a Multicast Security Association (MSA), invokes a standard registration mechanism for the underlying IP multicast group and enables the ESP/AH and SAM modules to start processing data. The registration process will inevitably include communication with the group controller(s) and this communication will require mechanisms for authentication of the parties as well as confidentiality of the information exchanged. This communication, its authentication and encryption mechanisms should be dealt with within the MIKE module. Canetti et. al. [Page 10]
INTERNET DRAFT February 1999 At the end of the join process, a Multicast Security Association (MSA) needs to be set up. (See Section 4.2.1 for the proposed contents of the MSA.) The relevant information from the MSA is then pushed to the ESP/AH and SAM modules. - Key update: Key updates messages are internal MIKE messages and are not part of the high-level architecture. These messages are authenticated and encrypted separately, as specified in MIKE. A special class of key update messages consist of member expulsion messages in which the controller expels the member from the group. The expulsion process is dependent on the specifics of the Key Management Protocol, but should result in the member being cryptographically unable to send/receive messages from the secure multicast group. In this case MIKE module should treat an expulsion message like a member leave request without the need to contact the controller(s). - Client Leave: First MIKE is invoked to de-register with the group controller(s). Next the Multicast Security Association is deleted (or marked stale). Finally, the host executes the standard procedure for leaving the underlying IP multicast group. (b) Data Flows - Sending of data: If source authentication is not needed, then data is transmitted directly via UDP (or a reliable multicast layer) and the IPSec module in the IP layer, with the IP multicast group in the destination address. If source authentication is needed then the data is first transferred to the SAM. There the data is processed for source verification. (The keys for performing these operations are obtained from the MSA.) Next, the data is directed to the AH/ESP transformations in the kernel. These transformations are executed with the group keys that appear in the MSA. Finally the data packets are sent on the channel in the standard way. - Receipt of data: Incoming data packets are first being processed by IPSec's AH/ESP transformations in the kernel. There the data is decrypted and group authentication is verified. Next, the data stream is processed by the SAM and source identity is authenticated, if needed. Finally, the data is handed to the calling application. Canetti et. al. [Page 11]
INTERNET DRAFT February 1999 5. Design Guidelines For MIKE Although the design of MIKE deserves a separate document, we proceed to suggest some requirements for MIKE, describe an architectural framework that will allow MIKE to meet these requirements and yet be flexible enough to accommodate a variety of group key management techniques. This framework provides an interface for plugging in different group key management modules into MIKE. Next we suggest some design principles for one such pluggable group key management module which we call the Multicast Key Management Module (MKMM). 5.1 Requirements of MIKE (a) MIKE should support the simple scenario where there is only a single group controller that communicates with all group members. More complex environments where intermediate servers facilitate the communication may also be supported. (b) MIKE should support having a set of keys (for symmetric encryption and authentication) shared among all group members. In addition, MIKE will help in forwarding the public verification keys of the group controller and of senders in the group, to support source authentication by group members. (Note that these verification keys may be different from the long-term certificates of these parties.) (c) MIKE will be placed in the application layer of the communication, and outside the OS kernel. (d) MIKE should be flexible enough to accommodate any reasonable multicast group key management solution. Canetti et. al. [Page 12]
INTERNET DRAFT February 1999 5.2 Architectural Block Diagram of MIKE Control API /\ join/leave || \/ ---------------------------------------------- | /\ | | MULTICAST INTERNET || KEY EXCHANGE MODULE | | || | | || | | \/ | | ------------------------------ | | | KEY MANAGEMENT TECHNIQUE | | | | SELECTOR | | | ------------------------------ | | /\ | |========//=====================================| | // GROUP KEY AND MSA MANAGEMENT |- | \/ FRAMEWORK | | =============================================== | GROUP | GROUP | | GROUP | | GROUP | | KEY MGMT | KEY MGMT | | KEY MGMT | | KEY MGMT | | MODULE | MODULE | | MODULE | ..... | MODULE | | INITIATED | # 1 | | #2 | | #N | | MSA CONTROL ---------- ----------- ---------- | FLOWS /\ V || ---------- || | M S A | || ---------- || \/ Secure Multicast Key Management Flows Figure 2: Block diagram of MIKE 5.3 An example Group Key Management Module. This section suggests a group key management modules that can be plugged into MIKE. We call this suggested module as the Multicast Key Management Module (MKMM). The main design criterion for MKMM are similar to those for Secure Multicast Framework, i.e., simplicity and the re-use of existing solutions and standards such as IPSEC and IKE Canetti et. al. [Page 13]
INTERNET DRAFT February 1999 where possible. This module uses IPSEC to set-up secure channels for all point-to-point between the host and the controller(s). Of course, other solutions that provide secure channels (e.g., SSL or proprietary communication protocols) can be used instead. (a) Point-to-point communication between a group member and the controller (say, for group registration and de-registration) will be secured via a standard IPSec connection established by IKE. This connection will provide confidentiality as well as authentication of the information exchanged. In particular, the group keys and additional information will be transmitted as DATA in the secure connection. The IPSec SA between a group member and a controller will be short-lived, and will generally NOT last throughout the lifetime of the multicast group. (b) Key update messages will be transmitted from the group controller to the members using an abstract transportation mechanism, called "Reliable Multicast Shim" (RMS). This abstract mechanism provides reliable multicast, in the sense that any message transmitted via the RMS is guaranteed to reach all group members. The RMS abstraction can then be implemented via any available reliable multicast mechanism, or alternatively via point-to-point reliable communication (TCP). (c) Key update messages sent by the controller will have a special format. In particular, they will be authenticated using public-key signatures that are verifiable using a public key that is handed to the members at registration time. MKMM will implement its own signature verification mechanism. Canetti et. al. [Page 14]
INTERNET DRAFT February 1999 5.4 Architectural Block Diagram of Multicast Key Management Module (MKMM). The following is the architectural block diagram of MKMM. -----------------------------------------------| | MULTICAST INTERNET KEY EXCHANGE MODULE | |===============================================| | GROUP KEY AND MSA MANAGEMENT |- | FRAMEWORK | | =============================================== | GROUP | | | KEY MGMT | MULTICAST | | MODULE | KEY MANAGEMENT | | INITIATED | MODULE | | MSA CONTROL | | | FLOWS |-------------------------- | V | RELIABLE MULTICAST | | -------- | SHIM | | | M S A | |-------------------------- | -------- | RELIABLE MULTICAST | | | EMULATION USING | | | RMTP OR PGM | | | OR HOME GROWN REL. MCAST | | | OR POINT-TO-POINT TCP | | -------------------------------------- /\ /\ || || || User Space || =========================================||================= || Kernel Space || || || || || \/ \/ Mulitcastable Key ------------------- Management Flows | I P S E C | (incl. Key Updates | AH/ESP | ------------------- /\ Point-to-Point Flows || Required for Secure Multicast || Key Management (e.g., between || member and controller).\/ Figure 3: Structure of Multicast Key Management Module. Canetti et. al. [Page 15]
INTERNET DRAFT February 1999 6. Issues related to the use of IKE and IPSEC In this section we discuss some issues and apparent problems related to the use of the IPSEC components (IKE, AH, ESP) in a secure multicast protocol. Some of these issues appear to have satisfactory solutions. Other issues are brought up for further discussion. 6.1 Use of IKE It is clear that group key management is very different from key management for point-to-point communications and therefore the Internet Key Exchange Protocol (IKE) cannot be re-used for group key management. However, it is proposed that the key exchange module for multicast (which we call MIKE, for the Multicast Internet Key Exchange module) should use IKE whenever it needs to establish point-to-point security associations between entities. Similarly, the problem of source authentication for multicast requires a different solution than the approach used in IPSec. We also propose that the Source Authentication Module (SAM) in this framework use existing standards such as standards for digital signatures and certification wherever possible. 6.2 Identification of Multicast Security Associations In the Internet Protocol, a Security Association (SA) is uniquely identified by the combination of the destination address, Security Parameter Index (SPI) and the protocol used (e.g., AH, ESP). As stated in the Security Architecture for the Internet Protocol document [KEN98c], the destination address can be either unicast or multicast; the definition of an SA remains the same. 6.3 SPI Assignment In unicast SAs, in order to avoid potential conflicts of SPI values, receivers are responsible for assignment of the SPI. Since in the multicast case there are multiple destinations, all within the same multicast destination address, such an approach is impractical since it would require coordination by all receivers. Selection by the sender would also be problematic, especially in the case of multiple group senders. Within our framework, a reasonable solution to the problem is to utilize the benefits of the centralized controller by requiring that the group controller selects the SPI for each multicast group and communicates it to members, senders and receivers during registration. Selection by the controller guarantees that the SA is uniquely identified by the combination of the SPI value, the multicast group address and the protocol. Canetti et. al. [Page 16]
INTERNET DRAFT February 1999 As stated in [KEN98c], multiple senders to a multicast group MAY use a single Security Association (and hence Security Parameter Index) for all traffic to that group. In that case, the receiver only knows that the message came from a system knowing the security association data for that multicast group. Multicast traffic MAY also use a separate Security Association (and hence SPI) for each sender to the multicast group, in which case source authentication can also be provided via IPSEC. The assignment of SA's to senders can be done by the group controller. 6.4 Sequence Number Handling and Replay-Prevention According to the latest ESP and AH drafts, both ESP and AH headers contain a mandatory, monotonically increasing, sequence number field intended to provide anti-replay protection. Processing of the sequence number is at the discretion of the receiver, but the sender MUST always transmit it. The sender's and receiver's counters have to be initialized to 0 when the SA is established and the first packet of that SA will have a sequence number of 1. In the case of multiple senders using the same security association (and hence the same SPI value) consistency and monotonicity of the sequence number cannot be guaranteed. Hence, as stated in the latest ESP draft, anti-replay service SHOULD NOT be used in a multi-sender environment that employs a single SA. Multicast security implementations should thus ensure that receivers do not perform sequence number processing and verification. We see two possible solutions to provide anti-replay protection: (1) Using multiple SAs, one for each sender. (All these SAs may be part of a single MSA.) (2) Putting anti-replay protection in some higher level module such as SAM. This solution requires application-layer framing of multicast messages. Further work and debate is needed to decide which solution is best for the first implementations of secure multicast. 6.5 Allowing IPSEC processing of multicast packets Some current implementations of the IP protocol stack will discard any IP packet with a class D destination address and a "protocol" field that is not UDP. Such implementations need to be changed to support IP-multicast packets protected by IPSEC. Canetti et. al. [Page 17]
INTERNET DRAFT February 1999 7. Related work Several recent works suggest mechanisms for IP multicast [HCD,HM,HCM,HD]. (See also the mini-survey in [CP].) Typically, these works concentrate on the key management module (MIKE, in our terminology). Most of these suggest a design that can be incorporated within the architecture proposed here either as a pluggable group key management module under MIKE or in some cases even as a version of MKMM (such as the schemes based on [WHA].) An exception is the [HCD1] design that calls for a hierarchy of group keys for data encryption. The notion of Multicast Security Association (MSA) is addressed in the IPSec architecture document [KEN98c] and in [HCM], with roughly the same functionality. (Here we introduce the additional functionality of use by SAM.) 8. References: [CGIMNP] Canetti R., J. Garay, G. Itkis, D. Micciancio, M. Naor, B. Pinkas, "Multicast Security: A Taxonomy and Efficient Authentication", to be presented at INFOCOM '99. [CP] R. Canetti, B. Pinkas, "A taxonomy of multicast security issues", draft-canetti-secure-multicast-taxonomy-01.txt, Nov. 1998. [HCD] Hardjono T., Cain B., Doraswamy N., "A Framework for Group Key Management for Multicast Security", internet draft draft-ietf-ipsec-gkmframework-00.txt, July 1998. [HCM] Hardjono T., Cain B., Monga N., "Intra-Domain Group Key Management Protocol", internet draft, draft-ietf-ipsec-intragkm-00.txt, November 1998. [HM] Harney, H., C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997. [KEN98a] Stephen Kent, Randall Atkinson, "IP Encapsulating Security Payload (ESP)", Internet Draft draft-ietf-ipsec-esp-v2-06.txt, July 1998. [KEN98b] Stephen Kent, Randall Atkinson, "IP Authentication Header", Internet Draft draft-ietf-ipsec-auth-header-07.txt, July 1998. [KEN98c] Stephen Kent, Randall Atkinson, "Security Architecture for the Internet Protocol", Internet Draft draft-ietf-ipsec-arch-sec-07.txt, July 1998. Canetti et. al. [Page 18]
INTERNET DRAFT February 1999 [Quinn] Bob Quinn, "IP Multicast Applications: Challenges and Solutions", draft-quinn-multicast-apps-00.txt, Nov 1998. [WHA], D.M. Wallner, E. J. Harder, R. C. Agee, Key Management for Multicast: Issues and Architectures, , internet draft draft-wallner-key-arch-01.txt, September 1998. 9. Authors Addresses Ran Canetti EMail: canetti@watson.ibm.com Pau-Chen Cheng EMail: pau@watson.ibm.com Dimitris Pendarakis EMail: dimitris@watson.ibm.com J.R. Rao EMail: jrrao@watson.ibm.com Pankaj Rohatgi EMail: rohatgi@watson.ibm.com Debanjan Saha EMail: debanjan@us.ibm.com IBM T.J. Watson Research Center 30 Saw Mill River Road Hawthorne, NY 10598, USA Tel: +1-914-784-6692 Canetti et. al. [Page 18]
Expires August 1999
