Internet Engineering Task Force Thomas Hardjono (VeriSign) INTERNET-DRAFT Brian Weis (Cisco) draft-ietf-msec-arch-00.txt Expires May 2003 November 2002 The Multicast Security (MSEC) Architecture 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 protocols developed by the Multicast Security (MSEC) group. The document begins by introducing a Reference Framework, and proceeds to identify functional areas which must be addressed as part of a secure multicast solution. Hardjono, Weis Expires May, 2003 1 MSEC Architecture October, 2002 Table of Contents 1. Introduction.......................................................2 1.1 Summary of Contents of Document.................................2 1.2 Audience........................................................3 1.3 Related Documents...............................................3 2. Architectural Design: The MSEC Reference Framework.................4 2.1 A Reference Framework...........................................4 2.2 Elements of the Reference Framework.............................5 2.2.1 Group Controller and Key Server.............................5 2.2.2 Sender and Receiver.........................................6 2.2.3 Policy Server...............................................6 2.2.4 Centralized and Distributed Designs.........................7 3. Functional Areas...................................................7 3.1 Multicast Data..................................................7 3.2 Management of Keying Material...................................8 3.3 Multicast Security Policies.....................................8 4. Group Security Associations (GSA).................................10 4.1 SAs and Multicast..............................................10 4.1 Structure of a GSA: Reasoning..................................11 5. Security Services.................................................14 5.2.1 Multicast Data Confidentiality.............................14 5.2.2 Multicast Source Authentication and Data Integrity.........15 5.2.3. Multicast Group Authentication............................15 5.2.4 Multicast Group Membership Management......................16 5.2.5 Multicast Key Management...................................16 5.2.6 Multicast Policy Management................................17 6. MSEC Documents Roadmap............................................18 7. Conclusion........................................................19 8. Acknowledgments...................................................19 9. References........................................................19 9.1 Normative References...........................................19 9.2 Informative References.........................................20 Authors Addresses....................................................21 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 functional areas that address different aspects of the problem. This document describes those functional areas, and protocols which have been developed which fit into those component areas. 1.1 Summary of Contents of Document Hardjono, Weis Expires May, 2003 2 MSEC Architecture October, 2002 This document provides an architectural overview of the work being conducted in the MSEC Working Group. It provides a Reference Framework for covering the scope of the problems in multicast security, and explains the elements of the Reference Framework. The Reference Framework, in turn, provides the division of labor along three Functional Areas pertaining to security. These cover the treatment of data from a security perspective when it is to be sent to a group, the management of keying material used to protect the data and the policies governing a group. Another important item in this document is the definition and explanation of Group Security Associations (GSA), which is the multicast counterpart of the unicast Security Association (SA). The GSA is specific to multicast security, and is the foundation of the work on group key management. 1.2 Audience This document is addressed to the technical community and implementers of IP multicast security technology others interested in gaining a general background understanding of multicast security. This document assumes that the reader is familiar with the Internet Protocol, the IPsec suite of protocols (e.g. IPsec, IKE, ISAKMP), related networking technology, and general security terms and concepts. 1.3 Related Documents Other documents provide detailed explanations of the Functional Areas within the MSEC Reference Framework. These include the following set of documents: a. "Group Key Management Architecture" document [BCDL] -- a document that provides the key management architecture for multicast security, building on the Group Security Association (GSA) concept defined in the current document. b. "Group Domain of Interpretation" [BHHW] and "GSAKMP Light" [HSC], which are two instances of protocols implementing the group key management function. c. "Multicast Encapsulating Security Payload" [BCCR], which provides the definition for Multicast ESP, for data traffic. d. "Multicast Source Authentication Transform Specification" [PCW], which defines the use of the TESLA algorithm for source authentication in multicast. Hardjono, Weis Expires May, 2003 3 MSEC Architecture October, 2002 2. Architectural Design: The MSEC 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 functional areas, functional elements, and interfaces. 2.1 A Reference Framework Based on the three broad functional 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 functional areas), from the perspective of architectures (centralized 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 functional areas can be identified and classified and the relationships among the functional areas can be recognized. Note that some issues span more than one so-called functional area. In fact, the framework encourages the precise identification and formulation of issues that involve more than one functional area or those which are difficult to express in terms of a single functional area. An example of such a case is the expression of policies concerning group keys, which involves both the functional 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. Rather, a box in the framework should be interpreted loosely as pertaining to a given function related to a functional 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 labeled "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 functional 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. Hardjono, Weis Expires May, 2003 4 MSEC Architecture October, 2002 +-----------------------------------------------------------------+ | CENTRALIZED \ DISTRIBUTED | | DESIGNS \ DESIGNS | | FUNCTIONAL \ | | AREAS \ | | +------+ \ +------+ | | Multicast |Policy|<-------\------------------------>|Policy| | | Security |Server| \ |Server| | | Policies +------+ \ +------+ | | ^ \ ^ | | | \ | | | | \ | | | v \ v | | +------+ \ +------+ | | Group |Group |<-------------- \---------------> |Group | | | Key |Ctrl/ |<---------+ \ |Ctlr/ | | | Management |Key | | \ |Key | | | |Server| V \ |Server| | | +------+ +--------+ \ +------+ | | ^ | | \ ^ | | | |Receiver| \ | | | | | | | | | | v +--------+ | | | | +------+ ^ | V | | | | | | +--------+ | | Multicast |Sender|<---------+ | | | | | Data | |<--------------------- |-------->|Receiver| | | Handling | | | | | | | +------+ | +--------+ | +-----------------------------------------------------------------+ Figure 1: MSEC Reference Framework 2.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. 2.2.1 Group Controller and Key Server The Group Controller and Key Server (GCKS) 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. Hardjono, Weis Expires May, 2003 5 MSEC Architecture October, 2002 In a distributed architecture the GCKS entity also interacts with other GCKS 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 GCKS entity (say, the "nearest" GCKS entity, measured in terms of a well-defined and consistent metric). Similarly, in a distributed architecture a GCKS 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. 2.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 GCKS 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. The influence of policies on both Senders and Receivers is seen as coming indirectly through the GCKS entities, since the event of joining a multicast group is typically coupled with the Sender/Receiver obtaining keying material from a GCKS 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 GCKS entity (centralized architecture) and where the Sender and Receiver employ different GCKS entities (distributed architecture). 2.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 GCKS 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. Hardjono, Weis Expires May, 2003 6 MSEC Architecture October, 2002 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. 2.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 GCKS entity must be able to interact securely with other GCKS 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. 3. Functional Areas In order to begin to address the problems in securing IP multicast, we identify three functional area emanating from the reference framework. The three functional area are: ¡ Multicast data handling. This area covers problems concerning the security-related treatments of multicast data by the sender and the receiver. This functional area is further discussed in Section 3.1. ¡ Group Key Management. This area is concerned with the secure distribution and refreshment of keying material. This functional area is further discussed in Section 3.2. ¡ 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 functional area is further discussed in Section 3.3. 3.1 Multicast Data 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: 2.1 Source authentication and data integrity. This functionality guarantees that the data originate with the claimed source and was not modified en route (either by a group member or an external attacker). Hardjono, Weis Expires May, 2003 7 MSEC Architecture October, 2002 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 [RFC2246]) 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. 3.2 Management of Keying Material 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 GCKS 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 GCKS 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. Core to the problem of key management is Security Association (SA) Management, which will be discussed further below. 3.3 Multicast Security Policies 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 Hardjono, Weis Expires May, 2003 8 MSEC Architecture October, 2002 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 [Har1, Har2], 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 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 resynchronize. Hardjono, Weis Expires May, 2003 9 MSEC Architecture October, 2002 4. Group Security Associations (GSA) 4.1 SAs and Multicast It is clear that the security associations (SA) for group key management are more complex, or at least more numerous, than for Internet key management [RFC2409]. The latter establishes a key management SA to protect application SAs (where a minimum of two are needed to key an Internet application process). However, group key management requires at least three: There is a registration SA between the group member and the GCKS, a rekey SA between the GCKS and all the group members, and an SA to protect application data from sender-members to receiver-members. In fact, each sender to the group may use a unique key for their data and use a separate SA: there may be more SAs than there are group senders. Group key management, therefore, uses a different set of abstractions than ISAKMP and IKE. Notwithstanding, the abstractions used in our Group Key Management functional area may be built from the ISAKMP abstractions. In our approach the Group Security Association (GSA) includes the attributes of the Internet Security Architecture SA, which is succinctly defined as the encapsulation of keys and policies [RFC2409] as follows. - An SA has selectors, such as source and destination transport addresses. - An SA has properties, such as an security parameter index (SPI) or cookie pair, and identities. - An SA has cryptographic policy, such as the algorithms, modes, key lifetimes, and key lengths used for authentication or confidentiality. - An SA has keys, such as authentication, encryption and signing keys. As is discussed in the next section of this memo, a GSA contains the SA attributes plus some additional ones. As shown in Figure 2 (a), the GSA is a superset of the SA. ¡ A GSA has group policy attributes, such as the kind of signed credential needed for group membership and whether the group will be given new keys when a member is added (called "backward re-key" below) or whether group members will be given new key when a member is removed from the group ("forward re-key"). - A GSA has SAs as attributes. Hardjono, Weis Expires May, 2003 10 MSEC Architecture October, 2002 +------------------------------------------------------------+ | | | +---------------+ +-------------------+ | | | GSA | | GSA | | | | | | +-----+ +-----+ | | | | | | | SA1 | | SA2 | | | | | +----+ | | +-----+ +-----+ | | | | | SA | | | +-----+ | | | | +----+ | | | SA3 | | | | | | | +-----+ | | | +---------------+ +-------------------+ | | | | (a) superset (b) aggregation | | | +------------------------------------------------------------+ Figure 2: Relationship of GSA to SA 4.1 Structure of a GSA: Reasoning There are three categories of SAs aggregated into a GSA in Figure 2(b). We choose this structure to better realize a GSA in our key management environment. There is a need to maintain SAs between a Key Server and a group member (either a sender, a receiver or both) and among members. The Key Server is called the "GCKS," which is charged with access control to the group keys, with policy distribution to client members or prospective members, and with group key dissemination to sender and receiver client members. This structure is common in many group key management environments [HH, CP99, RFC2627, BMS]. There are two SAs established between the GCKS and the members, and there is an SA established among the sending and receiving members as shown in Figure 3. The first category of SA (namely REG in Figure 3, for "registration SA") is initiated by the member to pull GSA information from the GCKS. This is how the member requests to join the secure group or has its GSA keys re-initialized after being disconnected from the group (e.g., when its host computer has been turned off during re-key operations as described below). The GSA information pulled down from the GCKS include the SA, keys and policy used to secure the data transmission between sending and receiving members; this is DATA in Figure 3, "for data security SA". Note that DATA is a category of SA, and this implies that there may be multiple SAs established between member senders and member receivers - at least as an option. There may exist, for example, a single DATA SA in which all senders share common keys and associated information. On the other hand, there may be one or more DATA SAs that are unique to the particular sender. A DATA SA may be reestablished or have its keys modified through re-key operations, which occur over a REKEY SA (for "rekey SA). Keys are pushed through a REKEY SA to support subscription groups. Hardjono, Weis Expires May, 2003 11 MSEC Architecture October, 2002 Thus, despite the fact that the data to be protected are multicast, registration exchanges through a REG SA should be unicast or point- to-point key determination exchanges. Some group key management solutions rely solely point-to-point. Most others combine unicast exchanges for initialization with multicast distribution for re-key. In some cases, such as in a pure "pay-per-session" application, all of the SA information needed for the session may be distributed at the time of registration or selection of a session, i.e. over a REG SA; re-key and re-initialization may not be necessary, so there is no REKEY SA. For subscription groups where keying material is changed as membership changes, a REKEY SA is needed to re-initialize a DATA SA. +------------------------------------------------------------+ | | | +------------------+ | | | GCKS | | | | | | | | REG REG | | | | / REKEY \ | | | +---/-----|----\---+ | | / | \ | | / | \ | | / | \ | | / | \ | | / | \ | | +-------------/------+ | +------\-------------+ | | | REG | | | REG | | | | REKEY-----+----REKEY | | | | MEMBER SENDER | | MEMBER RECEIVER| | | | DATA----------DATA | | | +--------------------+ +--------------------+ | | | | | +------------------------------------------------------------+ Figure 3: GSA Structure and 3 categories of SAs 4.2 Definition of GSA The GSA includes an aggregate of the three aforementioned categories of SAs. The three categories of SAs correspond to the three kinds of communications as seen from the point of view of the Receiver (Member). Figure 3 depicts this concept: - Registration (REG) SA: An SA is required for (bi-directional) unicast communications between the GCKS and a group member (be it a Sender or Receiver). This SA is established only between the GCKS and a Member. The GCKS entity is charged with access control to the group keys, with policy distribution to members (or prospective members), and with group key dissemination to Sender and Receiver members. This use of a (unicast) SA as a starting point for key management is Hardjono, Weis Expires May, 2003 12 MSEC Architecture October, 2002 common in a number of group key management environments [HH, CP99, RFC2627, BMS, Bris99]. Note that this (unicast) SA is used to protect the other elements of the GSA (such as the other following two categories of SAs), either in a "push" or "pull" model. As such, this SA is crucial and is inseparable from the other two SAs as the definition of a GSA. From the perspective of one given GCKS, there are as many unique registration SAs as there are members (Senders and/or Receivers) in the group. This may constitute a scalability concern for some applications, so a registration SA may be used on-demand whereas re-key and data security SAs are established at least for the life of the sessions that they support. - Re-key (REKEY) SA: An SA is required for the multicast transmission of key management messages (unidirectional) from the GCKS to all group members. As such, this SA is known by the GCKS and by all members of the group. This SA is not negotiated, since all the group members must share it. Thus, the GCKS must be the authentic source and act as the sole point of contact for the group members to obtain this SA. From the perspective of each participant in a group (GCKS and all members), there is at least one registration SA for the group. Note that this allows for the possibility of the GCKS deploying multiple re-key SAs for group key management purposes. - Data Security (DATA) SA: One or more SAs are required for the multicast transmission of data-messages (unidirectional) from the Sender to other group members. This SA is known by the GCKS and by all members of the group. Similarly, regardless of the number of instances of this third category of SA, this SA is not negotiated. Rather, all group members obtain it from the GCKS. The GCKS itself does not use this category of SA. From the perspective of the Receivers, there is at least one data security SA for the member sender (one or more) in the group. This allows for the possibility of including group IDs (GID) in transmission of data packets from the senders in the group. There are a number of possibilities with respect to the number of data security SAs and the use of Group IDs (GIDs): (i) Each sender in the group could be assigned a unique dta security SA, thereby resulting in each receiver having to Hardjono, Weis Expires May, 2003 13 MSEC Architecture October, 2002 maintain as many data security SAs as there are senders in the group. (ii) The entire group deploys a single data security SA for all senders, together with the use of GIDs. Receivers would then be able to filter based on the GIDs, whilst maintaining only one data security SA. (iii) A combination of (i) and (ii) above. 5. Security Services Referring to our Reference Diagram, this section identifies security services for designated interfaces of Figure 1. In this section, distinct security services 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. A security service 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 of security services in the following sections. This preliminary list of services is intended to serve as a basis for discussion in the MSEC working group. 5.2.1 Multicast Data Confidentiality This security service handles the encryption of multicast data at the Sender's end and the decryption at the Receiver's end. This security service may also 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 security service will need to evaluate the real-time and other requirements of multicast senders and receivers, and recommend a small set of promising ciphers and Hardjono, Weis Expires May, 2003 14 MSEC Architecture October, 2002 data protocols for IP multicast and application-layer multicast data confidentiality. Regarding application-layer multicast, some consideration is needed to consider 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 security service 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 security service is placed in Multicast Data Handling Area along the interface between Senders and Receivers. The algorithms and protocols that are realized from work on this security service may be applied to other interfaces and areas of Figure 1 when multicast data confidentiality is needed. 5.2.2 Multicast Source Authentication and Data Integrity This security service 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 MSEC Working Group members suggests that this is one of the harder areas of multicast security. This is due to 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 previously, 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 security service is placed in Multicast Data Handling Area along the interface between Senders and Receivers. The algorithms and protocols that are produced for this functional area may have applicability to building blocks in other functional area that use multicast services such as Group Key Management. 5.2.3. Multicast Group Authentication This security service 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 authenticity of the data in case that other group members are not trusted. Hardjono, Weis Expires May, 2003 15 MSEC Architecture October, 2002 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 security service is placed in the Multicast Data Handling Area along the interface between Senders and Receivers. 5.2.4 Multicast Group Membership Management This security service 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 5.2.5). This security service 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 security service is placed in the Group Key Management Area and has interfaces to Senders and Receivers. 5.2.5 Multicast Key Management This security service 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). - Updating of current keying material, depending on circumstances and policies. Hardjono, Weis Expires May, 2003 16 MSEC Architecture October, 2002 - 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 security service 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 security service 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 security service 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 security service 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 security service 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 the Group Key Management Area. 5.2.6 Multicast Policy Management This security service 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 security service 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 security service may be realized using a standard policy infrastructure such as a Policy 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 security service will be Hardjono, Weis Expires May, 2003 17 MSEC Architecture October, 2002 realized in a set of policy definitions, such as multicast security conditions and actions. The Multicast Policy Management security service 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 security service also describes communication between and among Policy Servers. Thus, the Multicast Policy Management security service 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 security service. However, this option is not ruled out. 6. MSEC Documents Roadmap The roadmap of MSEC WG documents is shown the in the following. +--------------+ | MSEC | | Requirements | +--------------+ : : +--------------+ | MSEC | | Architecture | +--------------+ : .....................:....................... : : : +--------------+ +--------------+ +--------------+ | Policy | | GKM | | Data Security| | Architecture | | Architecture | | Architecture | +--------------+ +--------------+ +--------------+ : : : : : : . +------------+ : +------------+ : . | GDOI | : |TESLA/MESP | : | Resolution |-: | |-: | | : | | : +------------+ : +------------+ : : : : : +------------+ : +------------+ : | GSAKMP- | : | | : | Resolution |-: | TBD |-: | | : | | : +------------+ : +------------+ : : : Hardjono, Weis Expires May, 2003 18 MSEC Architecture October, 2002 : : +------------+ : +------------+ : | | : | | : | RE-KEY |-: | TBD |-: | | : | | : +------------+ : +------------+ : : : . . . . Figure 4: MSEC Document Roadmap 7. Conclusion This document has provided an architectural overview of the work being conducted in the MSEC Working Group and introduced several important aspects of the standardization efforts in the MSEC WG. A Reference Framework for covering the scope of the problems in multicast security was introduced, and a division of labor along three Functional Areas pertaining to security was discussed. These cover the treatment of data from a security perspective when it is to be sent to a group, the management of keying material used to protect the data and the policies governing a group. This document also defined the notion of Group Security Associations (GSA), which is the foundation of the work on group key management in the MSEC Working Group. 8. Acknowledgments This document was derived from an IRTF SMuG Working Group draft that was originally co-authored by Thomas Hardjono, Ran Canetti, Mark Baugher, and Pete Dinsmore. 9. References 9.1 Normative References [BCDL] M. Baugher, R. Canetti, L. Dondeti, F. Lindholm, Group Key Management Architecture, draft-ietf-msec-gkmarch-03.txt. IETF, October 2002. Work in Progress. [HSC] H. Harney, A. Schuett, A. Colegrove, GSAKMP Light. draft-ietf- msec-gsakmp-light-sec-01.txt. IETF, July 2002. Work in Progress. [BHHW] M. Baugher, T. Hardjono, H. Harney, B. Weis, The Group Domain of Interpretation, draft-ietf-msec-gdoi-06.txt. IETF, February 2002. Work in Progress. Hardjono, Weis Expires May, 2003 19 MSEC Architecture October, 2002 [BCCR] M. Baugher, R. Canetti, P. Cheng, P. Rohatgi, MESP: Multicast Encapsulating Security Payload, draft-ietf-msec-mesp-00.txt. IETF, October 2002. Work in Progress. [PCW] A. Perrig, R. Canetti, B. Whillock, TESLA: Multicast Source Authentication Transform Specification. draft-ietf-msec-tesla-spec- 00.txt. IETF, October 2002. Work in Progress. 9.2 Informative 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 Oerview of the DCCM Project," DARPA Information Survivability Conference and Exposition, To Be Published. [Har1] Harney, H., and Muckenhirn, C., "Group Key Management Protocol (GKMP) Specification," RFC 2093, July 1997. [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. [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. [RFC2246] Dierks, T. and C. Allen, The TLS Protocol Version 1.0, RFC 2246, January 1999. [RFC2406] S. Kent, R. Atkinson, IP Encapsulating Security Payload (ESP),November 1998. [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. Hardjono, Weis Expires May, 2003 20 MSEC Architecture October, 2002 [RFC2627] D. M. Wallner, E. Harder, R. C. Agee, Key Management for Multicast: Issues and Architectures, September 1998. Authors Addresses Thomas Hardjono VeriSign 401 Edgewater Place, Suite 280 Wakefield, MA 01880 (781) 245-6996 thardjono@verisign.com Brian Weis Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134-1706, USA (408) 526-4796 bew@cisco.com Hardjono, Weis Expires May, 2003 21
Datatracker
Report a datatracker bug
draft-ietf-msec-arch-00
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3740.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |