Internet Research Task Force Thomas Hardjono (Nortel) INTERNET-DRAFT Ran Canetti (IBM Watson) draft-irtf-smug-framework-00.txt Mark Baugher (Intel) Expires June 2000 Peter Dinsmore (NAI) Secure IP Multicast: Problem areas, Framework, and Building Blocks 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 This document provides a foundation for the research work done as the Secure Multicast Group (SMuG)of the IRTF. The document begins by introducing a Reference Framework and problem areas, and proceeds to identify functional building blocks for a secure multicast solution. The identified building blocks, their definition and realization will be the subject of future work of SmuG. 1. Introduction Securing IP multicast communication is a complex task that involves many aspects. Consequently, a secure IP multicast protocol suite must have a number of components that address different aspects of the problem. Secure IP Multicast [Page 1] Internet-Draft November 1999 This document proposes a reference framework for secure IP multicast protocol suites and defines a breakdown to functional building-blocks for such protocol suites. The proposal is a product of discussions at the Secure Multicast Group (SmuG) of the IRTF, and is addressed at the SmuG group as a basis for further discussion. In particular, this document may serve as a basis for considering the issues that have been addressed so far in the SMuG IRTF community, the issues that have yet to be addressed, the issues that need further in-depth attention, and technologies that may be ready for consideration by an IETF working group. Sections 2 and 3 present the problem areas, reference framework and briefly discusses the functional entities, and interfaces, which are identified by the framework. Section 4 presents the breakdown of the interfaces to individual functional building blocks. Section 5 presents the conclusion. 2. Problem Areas in Secure Multicast In order to begin to address the problems in securing IP multicast, we identify three problem-areas and define a reference framework expressing these problem areas. The three problem-areas are: Problem-Area-1: Multicast data handling. This area covers problems concerning the security-related treatments of multicast data by the sender and the receiver. This problem-area is further discussed in Section 2.1. Problem-Area-2: Management of keying material. This area is concerned with the secure distribution and refreshment of keying material. This problem-area is further discussed in Section 2.2. Problem-Area-3: Multicast security policies. This area covers aspects of policy in the context of multicast security, taking into consideration the fact that policies may be expressed in different ways, that they may exist at different levels in a given multicast security architecture and that they may be interpreted differently according to the context in which they are specified and implemented. This problem area is further discussed in Section 2.3. 2.1 Multicast Data Handling (Problem-Area-1) In a secure multicast group the data typically needs to be: 1. Encrypted using the group key, mainly for access control and possibly also for confidentiality. 2. Authenticated, for verifying the source and integrity of the data. Authentication takes two flavors: Secure IP Multicast [Page 2] Internet-Draft November 1999 2.1 Source authentication and data integrity. This functionality guarantees that the data originated with the claimed source and was not modified en route (either by a group member or an external attacker). 2.2 Group authentication. This type of authentication only guarantees that the data was generated (or last modified) by some group member. It does not guarantee data integrity unless all group members are trusted. While multicast encryption and group authentication are fairly standard and similar to encrypting and authenticating point-to-point communication, source authentication for multicast is considerably more involved. Consequently, off-the-shelf solutions (e.g., taken from IPSec [RFC2406], TLS [TLS]) may be sufficient for encryption. For source authentication, however, special-purpose transformations are necessary. See [CP99] for further elaboration on the concerns regarding the data transforms, on present solutions and remaining challenges. 2.2 Management of Keying Material (Problem-Area-2) The term "keying material" refers to the cryptographic key belonging to a group, the state associated with the keys and the other security parameters related to the keys. Hence, the management of the cryptographic keys belonging to a group necessarily requires the management of their associated state and parameters. A number of solutions for specific problems must be addressed. These may include the following: - Methods for member identification and authentication. - Methods to verify the membership to groups. - Methods to establish a secure channel between a KS+GC entity and the member, for the purpose of delivery of shorter-term keying material pertaining to a group. - Methods to establish a long-term secure channel between one KS+GC entity and another, for the purpose of distributing shorter-term keying material pertaining to a group. - Methods to effect the changing of keys and keying material - Methods to detect and signal failures and perceived compromises to keys and keying material The needs related to the management of keying material must be seen in the context of the policies that prevail within the given circumstance. Secure IP Multicast [Page 3] Internet-Draft November 1999 2.3 Multicast Security Policies (Problem-Area-3) Multicast Security Policies must provide the rules for operation for the other elements of the Reference Framework. While much of the work for the Multicast Security Policy area is focused in the Policy Controller, there are potential areas for work in the application of policy at the Group Controller element and the member (sender and receiver) elements. While there is already a basis for security policy management in the IETF between the Policy Working Group and the IP Security Policy Working Group, multicast security policy management will extend the concepts developed for unicast communication in the areas of: - Policy creation, - High-level policy translation, and - Policy representation. Examples of work in multicast security policies include the Dynamic Cryptographic Context Management project [Din], Group Key Management Protocol [Har], and Antigone[McD]. Policy creation for secure multicast has several more dimensions than the single administrator specified policy assumed in the existing unicast policy frameworks. Secure multicast groups are usually large and by their very nature extend over several administrative domains, if not spanning a different domain for each user. There are several methods that need to be explored for the creation of a single, coherent group security policy. They include a top-down specification of the group policy from the group initiator and negotiation of the policy between the group members (or prospective members). Negotiation can be as simple as a strict intersection of the policies of the members or extremely complicated using weighted voting systems. High-level policy translation is much more difficult in a multicast group environment, especially when group membership spans multiple administrative domains. When policies are specified at a high level with a Policy Management tool, they must then be translated into more precise rules that the available security mechanisms can both understand and implement. When dealing with multicast communication and its multiple participants, it is essential that the individual translation performed for each participant result in the use of a mechanism that is interoperable with the results of all of the other translations. Typically, the translation from high-level policy to implementation mechanisms must result in the same mechanism in order to achieve communication between all of the group members. The requirement that policy translation results in the same mechanism places constraints on the use and representations in the high-level policies. It is also important that policy Secure IP Multicast [Page 4] Internet-Draft November 1999 negotiation and translation be performed as an integral part of joining a group. Adding a member to a group is meaningless if they will not be able to participate in the group communications. Multicast security policies must represent, or contain, more information than a traditional peer-to-peer policy. In addition to representing the security mechanisms for the group communication, the policy must also represent the rules for the governance of the secure group. Policy must be established for the basic group operations of add and remove, as well as more advanced operations such as leave, rejoin, or resync. 3. Problem Scope and Reference Framework This section considers the complex problems of multicast security in the context of a heuristic device, the Reference Framework diagram, shown in Figure 1. The Reference Framework is used to classify problem areas, functional elements, and interfaces. The Reference Framework defines the building blocks and suggested program of work for research and standardization, which is presented in a later section of this paper. 3.1 A Reference Framework Based on the three broad problem-areas, a reference framework is proposed (Figure 1). The reference framework attempts to incorporate the main entities and functions relating to multicast security, and to depict the inter-relations among them. At the same time it also tries to express the complex multicast security question from the perspective of problem classification (i.e., the three problem areas), from the perspective of architectures (centralized and distributed), of multicast types (1-to-M or M-to-N), and protocols (the exchanged messages). The aim of the reference framework is to provide some general context within which problems can be identified and classified (as being under a given problem-area) and the relationships among the problems can be recognized. Note that some issues span more than one so-called problem- area. In fact, the framework encourages the precise identification and formulation of issues that involve more than one problem-area or those which are difficult to express in terms of a single problem area. An example of such a case is the expression of policies concerning group keys, which involves both the problem-areas of group key management and multicast policies. When considering the reference framework (Figure 1) it is important to realize that the singular "boxes" in the framework do not necessarily imply a corresponding singular entity implementing a given function. Secure IP Multicast [Page 5] Internet-Draft November 1999 Rather, a box in the framework should be interpreted loosely as pertaining to a given function related to a problem-area. Whether that function is in reality implemented as one or more physical entities is dependent on the particular solution. As an example, the box labelled "Key Server" must be interpreted in broad terms as referring to the functions of key management. Similarly, the Reference Framework acknowledges that some implementations may in fact merge a number of the "boxes" into a single physical entity. The reference framework can be viewed horizontally and vertically. Horizontally, it displays both the entities and functions as singular boxes, expressing each of the three broad problem-areas. Vertically, it expresses the basic architecture designs for solutions, namely a centralized architecture and a distributed architecture. The protocols to be standardized are depicted in Figure 1 by the arrows that connect the various boxes. See more details in Section 4, below. +------------------------------------------------------------------+ | CENTRALIZED \ DISTRIBUTED | | DESIGNS \ DESIGNS | | \ | | \ | | +------+ \ +------+ | | Problem |Policy|<-------\------------------------>|Policy| | | Area 1 |Server| \ |Server| | | +------+ \ +------+ | | ^ \ ^ | | | \ | | | | \ | | | v \ v | | +------+ \ +------+ | | |Group |<-------------- \---------------> |Group | | | Problem |Ctrl/ |<---------+ \ |Ctlr/ | | | Area 2 |Key | | \ |Key | | | |Server| V \ |Server| | | +------+ +--------+ \ +------+ | | ^ | | \ ^ | | | |Receiver| \ | | | | | | | | | | v +--------+ | | | | +------+ ^ | V | | | | | | +--------+ | | Problem |Sender|<---------+ | | | | | Area 1 | |<--------------------- |-------->|Receiver| | | | | | | | | | +------+ | +--------+ | +------------------------------------------------------------------+ FIGURE 1: PROPOSED REFERENCE FRAMEWORK FOR SECURE MULTICAST Secure IP Multicast [Page 6] Internet-Draft November 1999 3.2 Elements of the Reference Framework The Reference Framework diagram of Figure 1 contains boxes and arrows. The boxes are the functional entities and the arrows are the interfaces between them. Standard protocols are needed for the interfaces, which support the multicast services between the functional entities. There are three sets of functional entities in both centralized and distributed designs as discussed below. 3.2.1 Key Server and Group Controller The Key Server and Group Controller (KS+GC) represent both the entity and functions relating to the issuance and management of cryptographic keys used by a multicast group, which is subject to the user-authentication and authorization checks conducted on the candidate member of the multicast group. In a distributed architecture the KS+GC entity also interacts with other KS+GC entities to achieve scalability in the key management related services. In such a case, each member of a multicast group may interact with one or more KS+GC entity (say, the "nearest" KS+GC entity, measured in terms of a well-defined and consistent metric). Similarly, in a distributed architecture a KS+GC entity may interact with one or more Policy Servers, also arranged in a distributed architecture. We remark that the Key Server (KS) and the Group Controller (GC) have somewhat different functionality and may in principle be regarded as separate entities. Currently the framework regards the two entities as one "box" in order to simplify the design, and in order not to mandate standardization of the protocol between the KS and the GC. It is stressed that the KS and GC need NOT be co-located. Furthermore, future designs may choose to standardize the protocol between the GC and the KS, without altering other components. 3.2.2 Sender and Receiver The Sender is an entity that sends data to the multicast group. In a 1-to-N multicast group only a single sender is allowed to transmit data to the group. In an M-to-N multicast group many (or even all) group members can transmit data to the group. Both Sender and Receiver must interact with the KS+GC entity for the purpose of key management. This includes user-authentication, the obtaining of keying material in accordance with some key management policies for the group, obtaining new keys during key-updates, and obtaining other messages relating to the management of keying material and security parameters. Secure IP Multicast [Page 7] Internet-Draft November 1999 The influence of policies on both Senders and Receivers is seen as coming indirectly through the KS+GC entities, since the event of joining a multicast group is typically coupled with the Sender/Receiver obtaining keying material from a KS+GC entity. This does not preclude the direct interaction between the Sender/Receiver and the Policy Server. The reference framework displays two Receiver boxes corresponding to the situation where both the Sender and Receiver employ the same KS+GC entity (centralized architecture) and where the Sender and Receiver employ different KS+GC entities (distributed architecture). 3.2.3 Policy Server The Policy Server represents both the entity and functions used to create and manage security policies specific to a multicast group. The Policy Server interacts with the KS+GC entity in order to install and manage the security policies related to the membership of a given multicast group and those related to keying material for a multicast group. The interactions between the Policy Server and other entities in the reference framework is dependent to a large extent on the security circumstances being addressed by a given policy. 3.2.4 Centralized and Distributed Designs The need for solutions to be scalable to large groups across wide geographic regions of the Internet requires the elements of the framework to also function as a distributed system. This implies that a KS+GC entity must be able to interact securely with other KS+GC entities in a different location. Similarly, Policy Servers must interact with each other securely to allow the communication and enforcement of policies across the Internet. 4. Building Blocks This section breaks down the secure multicast problem to functional building blocks. The breakdown uses the Reference Framework presented in Section 2 to identify high-level building blocks. A "multicast security building block" provides a multicast security service, such as multicast data confidentiality, or it provides a service to multicast security, such as an application programming interface (API). Specifications for an API or multicast confidentiality protocol, however, are building blocks that can be directly Secure IP Multicast [Page 8] Internet-Draft November 1999 implemented. This paper describes "functional building blocks," which are at a higher level of abstraction than algorithm or protocol specifications. Our goal is to identify functional building blocks that will focus work on algorithms, protocols, and other specifications that can be implemented to solve multicast security problems. In our approach, a functional building block is mapped to specific boxes or interfaces in the Reference Diagram of Figure 1. This section identifies which functions are performed where in Figure 1 without defining a specific realization of a functional building block. As an example, an algorithm such as Diffie-Hellman key exchange is one possible realization of a key management functional building block. An algorithmic building block is at a lower level of abstraction than a functional building block. Protocols or APIs that can be directly implemented in computer hardware or software may in turn, realize algorithms. The Internet Key Exchange [RFC2409], for example, realizes Diffie-Hellman and ISAKMP [RFC2408]; the TLS Handshake Protocol [RFC2246] realizes Diffie-Hellman and RSA. Thus, our treatment of functional building blocks for multicast security is relatively abstract and will only be of practical use when functional building blocks are realized as algorithms and protocols. We propose to focus the work on multicast security algorithms and protocols along the lines of functional building blocks as a problem- solving strategy. Section 4.1 motivates the building blocks approach to multicast security by listing three reasons for using this approach followed by three criteria by which to evaluate multicast security building blocks. Section 4.2 considers some functional building blocks for multicast security. 4.1. Motivation A common approach to solving a complex problem is to subdivide the problem into manageable "blocks". Here, each block must serve a well- defined function and its relationship with other blocks must be clearly defined. Besides being more manageable, the approach inherently has a number of advantages including use and re-use of the functional block independently of the whole, and the ability to combine different blocks to satisfy multiple functions. There are a number of risks to the building blocks approach [RMT]: 1. Delayed development, which results from the need for additional work to develop ways to combine independent building blocks. 2. Increased complexity, which is caused by too many building blocks having too many interfaces. 3. Reduced performance, which may be caused by too much modularization. Secure IP Multicast [Page 9] Internet-Draft November 1999 4. Abandonment of prior work, which results from attempts to develop robust, general solutions. These risks were identified for the multicast file transfer work. The fourth risk addresses an historic fact in the development of multicast file transfer that is not true for multicast security. It may be true, however, that an attempt to develop general solutions for diverse requirements, such as IP multicast and application-layer multicast security requirements, may retard the development of particular solutions. Although we have restricted our attention to functional building blocks in this paper, as described in section 4.0, there may be algorithms that solve common problems in both application-layer multicast and IP multicast. The IETF IPSec working group, moreover, has already produced a key management protocol that aims to provide for both application-layer multicast and IP multicast services, if properly extended [RFC2408]. Despite the above-mentioned risks, there are at least three important benefits to multicast security in applying the building blocks approach. 1. Re-use of publicly-reviewed cryptographic protocols: Even the best cryptographic mechanism can be effectively attacked at the protocol level [Schneier p. 473], so we seek to benefit from the re-use of proven technologies, which is inherent in a building- blocks approach to cryptographic protocols. 2. Timely delivery of needed technology: Using multicast building blocks, we hope to standardize specific technology, such as multicast confidentiality, independently of other security services that may take longer to specify for a great variety of uses, such as multicast source and data authentication. 3. Robust support for a variety of application environments: Good building block definitions will permit the combination of individual building blocks to flexibly add security services to IP multicast or application-layer multicast traffic. 4. Simplicity in the proof of correctness and working of each building block as a separate block. To make the notion of building blocks more concrete, consider the example of the independence of protocols in the IPSec suite. Certain IPSec protocols such as AH [RFC2402] and ESP [RFC2406] perform their security functions independently of other protocols in the IPSec suite, such as Internet Key Exchange (IKE), which provides security association [RFC2401] and key management services to AH and ESP. As a result of this independence, a compliant ESP implementation can be used today to provide IP multicast confidentiality despite the fact that an IKE security association (SA) is unique to a pair of communicating Secure IP Multicast [Page 10] Internet-Draft November 1999 endpoints and is unsuitable for managing multicast group keys. If ESP uses an IPSec SA having a multicast address, however, it effectively supports IP multicast confidentiality since there is no requirement that an SA used by ESP be established by IKE (though this might be a reasonable policy for some environments). Thus, other applications, such as a future ISAKMP variant may be used to establish the keying material needed for an IP multicast ESP service. For this to work, however, an application-programming interface may be needed for updates to the host security association database - an API such as PF_KEY [RFC2367] may serve this purpose although the definition of an SA may need to be extended for multicast [HH]. Taken together, ESP and PF_KEY can provide a useful multicast security service - IP multicast confidentiality. The capacity to provide a useful security service is one important criterion for a multicast security building block, which is realized in an algorithm, protocol, API, or by other means. In cases where authentication of multicast packet sources is required, however, ESP is probably unsuitable: ESP source and data authentication use a symmetric key, which is a shared secret among all members of the particular multicast group [RFC2403, RFC2404]. An alternative approach of using an asymmetric signature algorithm [RFC2406] would generally be too slow for real-time multicast flows. The mechanisms used in ESP for authentication and integrity, therefore, will not authenticate individual senders to a multicast group. Just as some applications may need only a subset of multicast security services, others will require a "Whole Protocol" [RMT]. A multicast security building block should be able to be combined with other building blocks to provide additional security services. Without this property, the building block is little more than an incomplete solution to the general problem. Thus a second criterion for a good multicast security building block is that it can be combined with other building blocks to provide additional security services. A good building block for IP multicast confidentiality can be combined with other building blocks for IP multicast source authentication, data authentication (integrity), and additional security services. A good example of the building blocks approach is the work being done on multicast packet-level source and data authentication within the SMuG community. One output of this effort is a draft specification on multicast packet-level authentication for RTP applications [McCarthy], which is a proposed RTP Profile [RFC1889]. The "RTP Profile for Source Authentication and Non-Repudiation of Audio and Video Conferences," proposes to efficiently authenticate the sender and verify the integrity of multicast packets by applying a digital signature over the hash of a sequence of packets [Wong, McCarthy]. Although practical experience is needed to evaluate this protocol, it illustrates the use of a multicast security building block. A successful multicast source or data-packet authentication building block should be applicable to other applications such as SDP/SAP [RFC2327, SAP]. Indeed, technology Secure IP Multicast [Page 11] Internet-Draft November 1999 that solves source and data-packet authentication for real-time multicast application traffic should be considered for IP multicast traffic as well - at least the algorithm, if not the protocol. Thus, a third criterion for a multicast security building block is its applicability to IP multicast and application-layer multicast security. The preceding discussion has established a set of three criteria for good multicast security building blocks. 1. A building block provides a flexible security service. A protocol that realizes a building block should be standardizable independently of other building blocks. 2. Building blocks can be combined in a framework to provide a set of multicast security services that amount to a "Whole Protocol" for multicast security. 3. Building blocks can be applied to both IP multicast and application-layer multicast security; good multicast security building blocks can be adapted for both protocol and data security. As discussed above, useful solutions may not satisfy all three criteria, but we expect that the most promising proposals for standardization would satisfy more than a single criterion. Thus, our criteria are suggested as measures of goodness for a functional or protocol building block. In addition to the demands of productive use and standardization, the building blocks approach allows the identification of certain problems that are still ill understood and thus ill defined. In the context of the SMuG IRTF group, we expect that the building blocks approach will help focus our research mission and facilitate our standards objectives. By adopting this approach early, SMuG can avoid the near-impossible task of extracting building blocks from mature protocols and can positively influence multicast standards work that may occur in IETF working groups. The building blocks approach also allows the sharing of standardized technologies with working groups within the IRTF and the IETF. For example, certain blocks developed with the SMuG IRTF group may be useful and deployable by the Reliable Multicast Transport (RMT) Working Group in their efforts to secure the RMT protocols. The same blocks may also be used to secure other application protocols (e.g., RTP), multicast routing protocols, and be applied to other areas where both multicast and security services are needed. Secure IP Multicast [Page 12] Internet-Draft November 1999 4.2. Functional Building Blocks Referring to our Reference Diagram, this section identifies functional building blocks for designated interfaces of Figure 1. In this section, distinct functional building blocks are assigned to specific interfaces. For example, multicast source authentication, data authentication, and confidentiality occur on the multicast data interface between Senders and Receivers in Figure 1. Authentication and confidentiality services may also be needed between the Key Server and key clients (i.e., the Senders and Receivers of Figure 1), but the services that are needed for multicast key management may be unicast as well as multicast. Multicast Key Management is a separate function and has a separate building block. A functional building block for multicast security, therefore, identifies a specific function along one or more Figure 1 interfaces. This paper does not attempt to analyze the trust relationships, detailed functional requirements, performance requirements, suitable algorithms, and protocol specifications for IP multicast and application-layer multicast security. Instead, we propose these tasks as future work that will occur as the functional building blocks are further defined and realized in algorithms and protocols. We identify a set functional building blocks in the following sections. This preliminary list of building blocks is intended to serve as a basis for discussion at the SMuG working group. We anticipate that work done on the several high-level, functional building blocks described below will lead to the specification of lower-level building blocks that can be implemented to provide needed multicast security services. 4.2.1 Multicast Data Confidentiality This functional building block handles the encryption of multicast data at the Sender's end and the decryption at the Receiver's end. This building block presumably may apply the keying material that is provided by Multicast Key Management in accordance with Multicast Policy Management, but it is independent of both. An important part of the future work on the Multicast Data Confidentiality building block is in the identification of and motivation for specific ciphers that should be used for multicast data. Obviously, not all ciphers will be suitable for IP multicast and application-layer multicast traffic. Since this traffic will usually be connectionless UDP flows, stream ciphers may be unsuitable though hybrid stream/block ciphers may have advantages over some block ciphers. Those working on this functional building block will need to evaluate the real-time and other requirements of multicast senders and receivers, and recommend a small set of promising ciphers and data Secure IP Multicast [Page 13] Internet-Draft November 1999 protocols for IP multicast and application-layer multicast data confidentiality. Regarding application-layer multicast, some consideration is needed to the effects of sending encrypted data in a multicast environment lacking admission-control, where practically any application program can join a multicast event independently of its participation in a multicast security protocol. Thus, this building block is also concerned with the effects of multicast confidentiality services, intended and otherwise, on application programs in all senders and receivers. In Figure 1, the Multicast Data Confidentiality building block is placed in Problem Area 1 along the interface between Senders and Receivers. The algorithms and protocols that are realized from work on this building block may be applied to other interfaces and Problem Areas of Figure 1 when multicast data confidentiality is needed. 4.2.2 Multicast Source Authentication and Data Integrity This building block handles source authentication and integrity verification of multicast data. It includes the transforms to be made both at the Sender's end and at the Receiver's end. It assumes that the appropriate signature and verification keys are provided via Multicast Key Management in accordance with Multicast Policy Management as described below. Work done by members of the SMuG community suggests that this is one of the harder areas of multicast security based on the connectionless and real-time requirements of many IP multicast applications. There are classes of application-layer multicast security, however, where offline source and data authentication will suffice. As discussed in section 4.1, not all multicast applications require real-time authentication and data-packet integrity. A robust solution to multicast source and data authentication, however, is necessary for a Whole Protocol solution to multicast security. In Figure 1, the Multicast Source and Data Authentication building block is placed in Problem Area 1 along the interface between Senders and Receivers. The algorithms and protocols that are produced for this functional building block may have applicability to building blocks in other Problem Areas that use multicast services such as Multicast Key Management. 4.2.3. Multicast Group Authentication This building block provides a limited amount of authenticity of the transmitted data: It only guarantees that the data originated with (or was last modified by) one of the group members. It does not guarantee Secure IP Multicast [Page 14] Internet-Draft November 1999 authenticity of the data in case that other group members are not trusted. The advantage of group authentication is that it is guaranteed via relatively simple and efficient cryptographic transforms. Therefore, when source authentication is not paramount group authentication becomes useful. In addition, performing group authentication is useful even when source authentication is later performed: it provides a simple-to-verify weak integrity check that is useful as a measure against denial-of -service attacks. The Multicast Group Authentication building block is placed in Problem Area 1 along the interface between Senders and Receivers. 4.2.4 Multicast Group Membership Management This building-block describes the functionality of registration and de- registration of members. Registration includes member authentication, notification and negotiation of security parameters, and logging of information according to the policies of the group controller and the would-be member. (Typically, an out-of-band advertisement of group information would occur before the registration takes place. The registration process will typically be invoked by the would-be member.) De-registration may occur either at the initiative of the member or at the initiative of the group controller. It would result in logging of the de-registration event by the group controller and an invocation of the appropriate mechanism for terminating the membership of the de- registering member (see Section 4.2.5). This building block also describes the functionality of the communication related to group membership among different GC+KS servers in a distributed group design. In Figure 1, the Multicast Group Membership building block is placed in Problem Area 2 and has interfaces to Senders and Receivers. 4.2.5 Multicast Key Management This building-block describes the functionality of distributing and updating the cryptographic keying material throughout the life of the group. Components of this building may include: - GC+KS to Client (Sender or Receiver) notification regarding current keying material (e.g. group encryption and authentication keys, auxiliary keys used for group management, keys for source authentication, etc). Secure IP Multicast [Page 15] Internet-Draft November 1999 - Updating of current keying material, depending on circumstances and policies. - Termination of groups in a secure manner, including the multicast group itself and the associated keying material. Among the problems to be solved by this building block is the secure management of keys between Key Servers and Clients, the addressing issues for the multicast distribution of keying material, and the scalability or other performance requirements for multicast key management [RFC2627, BMS]. To allow for an interoperable and secure IP multicast security protocol, this building block may need to specify host abstractions such as a group security association database (GSAD) and a group security policy database (GSPD) for IP multicast security. The degree of overlap between IP multicast and application-layer multicast key management needs to be considered. Thus, work on this functional building block must take into account the key management requirements for IP multicast, the key management requirements for application-layer multicast, and to what degree specific realizations of a Multicast Key Management building block can satisfy both. ISAKMP, moreover, has been designed to be extensible to multicast key management for both IP multicast and application-layer multicast security [RFC2408]. Thus, multicast key management protocols may use the existing ISAKMP standard's Phase 1 and Phase 2 protocols, possibly with needed extensions (such as an ISAKMP Domain of Interpretation for IP multicast or application-layer multicast security). This building block also describes the functionality of the communication related to key management among different GC+KS servers in a distributed group design. Multicast Key Management appears in both the centralized and distributed designs as shown in Figure 1 and is placed in Problem Area 2. 4.2.6 Multicast Policy Management This functional building block handles all matters related to multicast group policy including membership policy and multicast key management policy. Indeed, one of the first tasks in further defining this functional building block is identifying the different areas of multicast policy. Multicast Policy Management includes the design of the policy server for multicast security, the particular policy definitions that will be used for IP multicast and application-layer multicast security, and the communication protocols between the Policy Server and the Key Server. This functional building block may be realized using a standard policy infrastructure such as a Policy Secure IP Multicast [Page 16] Internet-Draft November 1999 Decision Point (PDP) and Policy Enforcement Point (PEP) architecture. Thus, it may not be necessary to re-invent a separate architecture for multicast security policy; we expect that this work will evaluate use of the products of IETF efforts in the areas of network and security policy. At minimum, however, this functional building block will be realized in a set of policy definitions, such as multicast security conditions and actions. The Multicast Policy Management building block describes the functionality of the communication between an instance of a GC+KS to an instance the Policy Server. The information transmitted may include policies concerning groups, memberships, keying material definition and their permissible uses, and other information. This building block also describes communication between and among Policy Servers. Thus, the Multicast Policy Management building block is placed in Problem Area 3, along the interface between Key Servers and Policy Servers. Group members are not expected to directly participate in this building block. However, this option is not ruled out. 5. Conclusion As stated in section 4, the ultimate goal of developing multicast security building blocks is to produce better specifications that can be standardized as expeditiously as possible. Section 2 classifies the problems we seek to solve along the lines of Problem Areas. And Section 3 presents a heuristic device, the Reference Framework, to facilitate investigation and standardization of multicast security building blocks. Section 4.1 motivates this approach as having three distinct advantages. Section 4.1 also advances some criteria for evaluating algorithms, protocols, and other specifications for the six functional building blocks that are proposed in section 4.2. We recommend that work be undertaken to elucidate the requirements and functions of each of the building blocks that are proposed in section 4.2. This work should be closely followed by analysis of algorithms and the specification of protocol building blocks. We expect that the partitioning of multicast security services along the lines of functional building blocks, as described in this document, has a number of advantages: The building blocks approach should encourage the development of particular technology for particular problems and foster the development of individual pieces of a whole multicast security protocol. Rather than delayed development, which is the first problem identified by RMT [RMT} above, work on the individual building blocks should proceed in parallel despite some obvious dependencies. Secure IP Multicast [Page 17] Internet-Draft November 1999 For a given building block, one dependency exists between parts of the building block that deal with a different building block (Centralized Design) and parts that deal with different instances of the same building block (Distributed Design). This dependency, however, does not prevent work on the Centralized Design to proceed, while at the same time the requirements and functions needed for distributed designs are considered by others who are working on this problem independently in SMuG. A second dependency exists between the Multicast Confidentiality and the Source and Data Authentication building blocks. The protocols and packet formats for encrypted data transmission must accommodate the needs of source authentication and data integrity. Cryptographic protocols tend to be modular, however, and follow a building block approach. To draw an example from IPSec, the AH and ESP protocols are specified independently but are capable of being applied to any packet flow. We believe that de-coupling multicast security services such as confidentiality and authentication/integrity can produce better protocols more quickly. And we expect to draw on a large body of experience of developing transport and network security protocols to avoid the risks and pitfalls of the building block approach while reaping its advantages for multicast security research and standardization. References [BMS] D. Balenson, D. McGrew, A. Sherman, Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization, http://www.ietf.org/internet-drafts/draft-balenson-groupkeymgmt-oft- 00.txt, February 1999, Work in Progress. [CP99] R. Canetti and B. Pinkas, A taxonomy of multicast security issues, http://search.ietf.org/internet-drafts/draft-irtf-smug-taxonomy- 01.txt, April 1999, Work in Progress. [Din] Dinsmore, P., Balenson, D., Heyman, M., Kruus, P., Scace, C., and Sherman, A., "Policy-Based Security Management for Large Dynamic Groups: An Overview of the DCCM Project," DARPA Information Survivability Conference and Exposition, To Be Published. [HCD] T. Hardjono, B. Cain, N. Doraswamy, A framework for group key management for multicast security, http://www.ietf.org/internet- drafts/draft-ietf-ipsec-gkmframework-00.txt, July 1998, Work in Progress. [Har1] Harney, H., and Muckenhirn, C., "Group Key Management Protocol (GKMP) Specification," RFC 2093, July 1997. Secure IP Multicast [Page 18] Internet-Draft November 1999 [Har2] Harney, H., and Muckenhirn, C., "Group Key Management Protocol (GKMP) Architecture," RFC 2094, July 1997. [HH] H. Harney, E. Harder, Group Secure Association Key Management Protocol, http://search.ietf.org/internet-drafts/draft-harney-sparta- gsakmp-sec-00.txt, April 1999, Work in Progress. [IKEdraft] D. Harkins, D. Carrel, The Internet Key Exchange (IKE), http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-01.txt, May 1999, Work in Progress. [McCarthy] L. McCarthy, RTP Profile for Source Authentication and Non- Repudiation of Audio and Video Conferences, draft-mccarthy-smug-rtp- profile-src-auth-00.txt, May 1999, Work in Progress. [McD] McDaniel, P., Honeyman, P., and Prakash, A., "Antigone: A Flexible Framework for Secure Group Communication," Proceedings of the Eight USENIX Security Symposium, pp 99-113, August, 1999. [RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A Transport Protocol for Real-Time Applications, January 1996. [RFC2014] A. Weinrib and J. Postel, IRTF Research Group Guidelines and Procedures, RFC 2014, October 1996. [RFC2246] Dierks, T. and C. Allen, The TLS Protocol Version 1.0, RFC 2246, January 1999. [RFC2327] M. Handley, V. Jacobson, SDP: Session Description Protocol, April 1998. [RFC2367] D. McDonald, C. Metz, B. Phan, PF_KEY Key Management API, Version 2, July 1998. [RFC2401] S. Kent, R. Atkinson, Security Architecture for the Internet Protocol, November 1998 [RFC2402] S. Kent, R. Atkinson, IP Authentication Header, November 1998 [RFC2403] C. Madson, R. Glenn, The Use of HMAC-MD5-96 within ESP and AH, November 1998. [RFC2404] C. Madson, R. Glenn, The Use of HMAC-SHA-1-96 within ESP and AH, November 1998. [RFC2406] S. Kent, R. Atkinson, IP Encapsulating Security Payload (ESP), November 1998. [RFC2407] D. Piper, The Internet IP Domain of Interpretation for ISAKMP, November 1998. Secure IP Multicast [Page 19] Internet-Draft November 1999 [RFC2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, Internet Security Association and Key Management Protocol, November 1998. [RFC2409] D. Harkins, D. Carrel, The Internet Key Exchange (IKE), November, 1998. [RFC2627] D. M. Wallner, E. Harder, R. C. Agee, Key Management for Multicast: Issues and Architectures, September 1998. [RMT] B.Whetten, L. Vicisano, R. Kermode, M. Handley, S. Floyd, Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer, http://www.ietf.org/internet-drafts/draft-ietf-rmt- buildingblocks-00.txt, June 1999, Work in Progress. [Schneier] B. Schneier, Applied Cryptography, Second Edition, John Wiley, 1996. [SAP] M. Handley, C. Perkins, E. Whelan, Session Announcement Protocol, http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sap-v2-01.txt, June 1999, Work in Progress. [SAPPK] P. Kirstein, G. Montasser-Kohsari, E. Whelan, SAP Security Using Public Key Algorithms, http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sap-sec-04.txt, September 1998, Work in Progress. [Wong] C.K.Wong, S.S. Lam, Digital Signatures for Flows and Multicasts, Proceedings of IEEE ICNP'98, October 14-16, 1998. [WP96] A. Weinrib and J. Postel, IRTF Research Group Guidelines and Procedures, RFC 2014, October 1996. Secure IP Multicast [Page 20] Internet-Draft November 1999 Authors' addresses: Thomas Hardjono Advanced Networks Nortel Networks 600 Technology Park Dr. Billerica, MA 01821 (978) 288-4538 thardjono@baynetworks.com Ran Canetti IBM Research 30 Saw Mill River Rd Hawthorne, NY 10532 (914) 784-7076 canetti@watson.ibm.com Mark Baugher Intel Architecture Labs 2111 NE 25th Avenue Hillsboro, OR 97124 (503) 466-8406 mbaugher@intel.com Peter Dinsmore NAI Labs 3060 Washington Road, Glenwood, MD 21738 (443) 259-2346 Pete_Dinsmore@NAI.com Expires June 2000 Secure IP Multicast [Page 21]