Internet Engineering Task Force G. Chaddoud INTERNET-DRAFT I. Chrisment A. Schaff February, 2002 LORIA/INRIA-Lorraine S-SSM : A Secure SSM Architecture Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft. 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: The SSM model is appeared in order to overcome the problems of deployment of IP multicast. However, a real commercial deployment of SSM have to offer some security services. Our work proposes an architecture, called S-SSM, for securing the SSM model. S-SSM defines two mechanisms for access control and content protection. The first one is carried out through subscriber authentication and access permission. As for the second, it is realized through the management of a unique key, called the channel key, k_ch, shared among the sender and subscribers. Table of contents: 1. Introduction 2. SSM environment 3. S-SSM archirecure 3.1 S-SSM overview 3.2 Access control 3.2.1 Authentication 3.2.2 Validity check 3.3 Channel key management 4. Related works 5. Conclusion References Author's Addresses 1. Introduction The IP multicast model [1] is appeared as a way to optimize the communication used by multimedia applications (audio and video conferences, video diffusion) involving several participants. But today, we can see that commercial multicast deployment is not a reality yet. Moreover, this model presents some limits such as scalable routing problems, address allocation problems, and notably security issues. Indeed, any host can send data to any IP multicast address and any host can join any group. In order to overcome these problems, some simplified approachs have been proposed. Express [2] has defined a point-to-multipoint diffusion, and presents a group as the the tuple (S,E), where S is the unique sender and E the multicast destination address. The tuple (S,E) is called "channel". Simple Multicast [3] is similar to Express but uses a birectional tree like CBT [4]. These different approaches, known as Source Specific Multicast (SSM) has been standardized in IETF with the proposition of PIM-SSM [5], version modified of PIM-SM [6] which allows source- filtering. Subscription to channels is supported by the version 3 of IGMP [7], called IGMP specific-source [8] . The SSM scheme presents a solution to address allocation, routing problems and a partial access control. But, an effective commercial deployments of SSM should involve some security services such as access control and content provider protection. Having in mind the idea of ensuring SSM security, we propose in this draft a new architecture for securing an environment of multimedia diffusion, called S-SSM. The diffusion environment is basically composed of SSM (PIM-SSM/IGMPv3) routing, video server, and potential receivers. Our S-SSM architecture is composed of two security mechanisms: the access control and content protection. The access control mechanism is an extension of a solution proposed in [9] which uses a signed token to control access to group communication. The aim of such solution is to authenticate members by their local routers and to protect membership demands against attacks. As for the second one, it is achieved via sender authentication and data ciphering. This last one requires the management of a unique key, called the channel key, k_ch, shared among the sender and subscribers. This scheme is a variant of Baal [9,11] which is a scalable solution for the management of dynamic group keys. In this document, we present S-SSM, a secure architecture for an environment of 1-to-n multimedia diffusion. In Section 2, we present our general approach to secure an SSM environment. Then, in Section 3, we describe, more in details, the S-SSM architecture. In section 4, we present related works. Finaly, we conclude with Section 5. 2. SSM environment In our approach, we specify how securing an environment of multimedia multicasting. This environment is composed of (figure 1) : +--------+ | server | +---+----+ | SSM router | +---------+----------+ | | | SSM cloud | | | +--/-------------\---+ / \ SSM router SSM router / \ --------/----- --\------ | | | subscriber subscriber subscriber Figure 1 : SSM environment - SSM (PIM-SSM/IGMPv3) [5,8] routing. The version 3 of IGMP offers support for ``source filtering'', i.e., the possibility for a system to report interest in receiving packets only from specific sources. - Video server or another type of applications like Internet TV, vedio-conference. - Potential subscribers who have paid for a service In SSM communication, a multicast " channel" is defined as a datagram delivery service [2]. A channel is identified by a tuple (S,E) where E is a "channel destination address". L'IANA has allocated the address suffix 232.*.*.*/8, i.e, 2^24 class D addresses, for experimental use by the single-source multicast model. Only the source host S may send to (S,E). A "subscriber" host request reception of data sent to a channel by explicitly specifying both S and E in a request, via an IGMPv3-report. The source S sends to a channel by simply transmitting datagrams addressed to E. The network layer guarantees that all datagrams sent by S to destination E are delivered to all subscribers of channel (S,E). The principal advantage of a such multicast diffusion service is a partiel access control to the channel : - A source can not send data to a channel owned by another source. Contrary to the classic IP multicast model, the two channels (S,E) and (S',E) which have the same destination address E, are unrelated, despite the common destination address. Thus is guaranted by SSM routing. - A subscriber to (S,E) does not automatically receive data sent to (S',E). Filtering by source guarantees that a subscriber does not receive all data sent with the same destination address E. The SSM model appears appealing, but it has some limits when it is used by Internet access providers, especially, the contractors of multimedia diffusion services such as Internet TV, who require subscription fee for their services. An SSM model of security must allow only legitimate entities to access to channels for which they have payed subscription fee. Having in mind the idea of the protection of SSM communication, we have defined S-SSM, a more complete security architecture, which offers two mechanisms of security : the access control and content protection : - Access control This mechanism aims at, more either, protecting network resources against malicious and illegitimate subscription requests. It is realized through : - Authentication of new subscribers when they subscribe to a channel. - Check of access permission to channel provided by the contractor when they subscribe to channel. - Content protection It is achieved via data ciphering. It requires the management of a unique key, called the channel key k_ch, shared among the sender and subscribers. Before diffusion, channel source encryptes data with the key k_ch. Only subscribers having the key k_ch are capable of decrypting data. Thus, in addition to content secrecy, source authentication is ensured, because SSM routing forwards data coming only from the source. We consider that the first mechanism is an SSM extension and would be an integrated and inseperable part of subscription to channels. The second mechanism is independent from SSM and would be used, according to the security policy of service diffusion, by contractors who require secrecy for their content. 3. S-SSM architecture In this Section, we describe in more details the S-SSM architecture and explain how these offered services are applied at the time of subscription and content diffusion. 3.1 S-SSM overview Our S-SSM architecture proposes that the actors of the diffusion environment, notably, the IGMPv3-capable routers, would be responsible for the security of the channel. Two reasons explain this idea : - The first one is to control some events that could compromise the network resources, in particular, the multicast routers. From the moment that one entity sends a subscription request, i.e, an IGMPv3- report, the first router receiving the request, must be capable to seal the request's fate. Indeed, if the entity meets certain conditions imposed by the channel security, the router can follow up the subscription request. Like that, we limit as much as possible network resource waste. Moreover, every malicious request is prevented from illegal access to channel flow. - The second aspect is a scalability concern. The decentralized management of channel security is more flexible than the centralized one. In other words, Instead of having only one entity controlling all the security operations within the channel, certain entities distributed within domains where we can have subscribers, can be delegated to do some security tasks. There are many advantages for this choice. The propagation of control messages will be limited to only domains where the subscription requests are issued. Moreover, the subscription latency to a channel is minimized and the bottleneck for the entity responsible for the security management is avoided. So, the channel manager delegates the security tasks to the actors of the diffusion environnment. The set of actors cooperate through a group of communication, or a channel (GC,M) where GC is the address of the channel manager and M is an SSM address. This channel is called control channel or a signalization channel. This channel is responsible for the access control to diffusion channel and the management of the channel key k_ch. The architecture S-SSM defines four security actors (figure 2): Directory server, DS +--------+ / | server | Global controller, GC +---+----+ / | SSM router SSM router __/ | / +---------+----------/ | | | SSM cloud | | | +--/-------------\---+ / \ SSM router + SSM router + Local controller local controller, LC / \ --------/----- --\-------------- | | | subscriber subscriber subscriber, h Figure 2 : S-SSM architecture - Global controller, GC. It is an entity delegated by an authority responsible for data distribution such as content providers. According to information stored in a server, the global controller grants access to new subscribers and revokes channel subscribers. It coordinates with local controllers in order to manage the channel key k_ch. In addition, the global controller tells the other controllers if there are any compromised subscribers in their domains. It rekeys the subscriber channel periodically. In addition, GC creates and manages the control channel. - Local controller, LC. It is delegated by the global controller within its domain. It authenticates new subscribers and distributes k_ch to subscribers within its domains. It can, with the GC authorization, periodically rekey channel. A local controller can be implemented in an IGMPv3-capable router or an IGMP-proxy [12], which allows to extand delegation of the secured environment to a domain more large than a local area network. We call channel controller any local or global controller. - Directory Server, DS. The service provider memorizes all information related to his clients or subscribers and needed to the management of the channel in a server, called Directory Server, DS. For each subscriber, DS contains a register or an entry per susbscriber. An entry can be formed of several fields such as, Validity to prove that the entry is valid, Start_date and End_date beginning and ending date of the subscription, and specific nonce, Ns, attributed randomly to the subscriber. GC has access to DS to only read. An example of a DS could be an LDAP server. - Subscriber. Any entity which can receive channel flow and has payed, according to the relationship with the service provider, subscription fee. Prior to subscription, the new subscriber must have a valid entry in the DS server. the valid entry defines the access permission. According to the server DS, GC and local controllers create a global recovery list, RECOV_List, composed of entities which had compromised or tryed to compromise the channel security. A member of this list has no more access to channel data. In addition, every LC has a list of local subscribers, LOCALSUB_List. This list is updated after every join or eviction of a subscriber. A LC distributes the key k_ch only to members of the list LOCALSUB_List. In the remainder of this section, we show how to carry out the access control mechanism. We describe next the management of the channel key. 3.2 Access control Before accepting subscribers to the channel, the global controller creates tow keys for the control channel ; K_ctl key for controlling channel and K_KEK key for rekeying the first key. These keys are distributed to LCs. A local controller becomes delegated controller as soon as it has, after authenication by the global controller, these two keys. In the following , we assume that a local controller is an SSM-capable router (IGMPv3/PIM-SSM) and that IGMPv3 defines a type of message which recognizes the definition of a signed token. The signed token forms an essential part of the authentication process of exchanged messages. A Token is composed of: - Ns specific number attributed by the service provider at the time of subscription and payement to the channel service, - The tuple (S,ch), where S is the address of the source and ch is the channel destination address ; - Timestamp, - The IP address of the subscriber. Remark : For a signed token of a local controller, the field Ns will be ignored or set to zero. It should be noted that the role of the token is to protect a non-secure subscription request against attacks. As mentioned in Section 2, subscription phase is carried out in two steps: - Authentication which is made by a local controller. - Access permission check which is done by the global controller. In the following paragraphs, we present the access control through the scenario depicted in figure 2, which shows the subscription of the host h to a channel (S,ch). We assume that a local controller is on the SSM tree. 3.2.1 Authentication The entity, h, which wants to subscribe to the channel, sends a subscription message, composed of an IGMPv3-report with ch the address SSM of the channel and S the address of the channel source. This message is protected by the signed token of h. h sends the message to its local controller. On receipt of this message, the LC authenticates the sender. We suppose that the LC knows the public keys of systems within its domain. The subscription message is: h => LC : IGMP-report(S,ch), [token_h]^pK_h [token_h]^pK_h is token of h signed with its private key. If the authentication succeed, the LC checks whether h is not in the RECOV_List. If not, it must verify with the GC whether h has right to access to channel (S,ch). If the authentication fails or if h is in the list RECOV_List, the message will be ignored. This step triggers the next step : validity check. 3.2.1 Validity check The purpose of this step is to verify with the GC whether the new subscriber has a valid entry in the DS server. The LC sends a message to GC. This message contains the tokens of LC and of the new subscriber. The message is: LC => GC : {[token_h]^pk_h, [token_lc]^pk_lc} By receiving this message, the GC authenticates first the LC. Then, if successful, it authenticates the host and checks with the DS server its Ns for the demanded channel and its period validity. This is done with the message GC => DS in figure 2. This message is acknowledged by the DS with message DS => GC. If the answer is positive, the GC confirms the validity of the subscription by sending the following message to the LC: GC => LC : {[token_h]^pK_h, [token_gc]^pk_gc, Start_date, End_date} This message contains the signed token of the host and the token of the GC and the both fields Start_date, End_date which indicates the beginning and the expiration validity of the subscription. In fact, these two fields forms with the subscriber's Ns the access permission to the channel. At the reception of this message, the LC interprets this message as follow: - If End_date > Start_date AND TIME < End_date THEN the host can have access to channel data. The channel must be rekeyed ; - If End_date > Start_date AND TIME > End_date THEN the subscription demand is ignored. 3.3 Channel key management In the case of channel diffusion, 1-to-n multicast, where there is only one sender, the channel key is used to ensure confidentiality and sender authentication. The channel rekeying should take place after: - Reception of a new subscription request in order to avoid the subscriber from access to old channel traffic ; - Access permission expiration or eviction of a subscriber in order to avoid him from access to futur channel flow; - The periodicity of channel rekeying in order to avoid key forging. In all cases, channel rekey is done by the GC. It creates a new key, k_ch', and forms a message of rekey, msg_rekey. The message is composed of the channel address (S,ch), th GC's identity, the new key k_ch', and two fields, type and INFO. The field type is used to indicate the type of rekey. In the case of expiration of validity or eviction of subscribers, the field INFO contains informations about the evicted subscriber. The message msg_key is encrypted with the key of channel control, K_ctl, then diffused through the control channel to all LCs. When a LC receives a rekeying message, it decrypts this message and extracts the keys, then, in function, to the field type: - Message of periodic rekey, it distributes the new key k_ch' to all members of the list LOCALSUB_List ecrypted with the old key k_ch. - Message after subscription, if the new subscriber is not in their domain, it behaves as if it was a periodic rekey message. If not, it sends the new key encrypted with the public key of the receiver, to all the members of the list LOCALSUB_List including the new subscriber. - Message after expiration of validity or expulsion, if the subscriber whose access permission validity has expired, is within its domain, first, it removes this subscriber from the list LOCALSUB_List. In the case of message of expulsion, all LCs must add the evicted subscriber to the list RECOV_List. Then, it sends the new key encrypted with the public key of the receiver, to all the members of the liste LOCALSUB_List except the evicted one. If the expulsed subscriber does not belong to its domain, it can distribute the new key encrypted with the old one to all LOCALSUB_List members. Remark : The channel rekeying is, in all cases, carried out by the GC, but however, it can completely or partially delegate this task to LCs. 4. Related works According to [13], securing IP multicast is divided into three parts : 1. Membership access control at the subnet level. 2. End-to-End data protection together with the group key management protocol. 3. Multicast routing protection (to ensure multicast control packets are authentic and thus preserves the correct routing behavior). S-SSM presents a solution for membership access control and end-to-end content protection. If we consider that the protection of multicast routing is specific to each multicast routing protocol i.e, in our context, the responsibility of SSM routing protocols. Thus, our approach is a complete solution for securing SSM communication. The use of signed token is not a new concept . First, we have used it in Baal [9] to protect membership request in dynamic group communication and to authenticate new members, by local routers, befor joining groups. [13] and [14] has used the token to provide access control through IGMP authentication. The access control is achieved via the provision of the token, as a proof-of-membership, to local multicast routers when hosts request joining to multicast trees. In the context of dynamic group communication (DGC), many approaches key management, such GKMP[15,16], LKH [17,18,19], or OFT [20] can be integrated in our solution for the management of the channel key. In the works done in Express [2], the authors have emphasized on interests of some aspects of security. They have proposed the use of the authentication for subscription requests : a host who desirs subscribe to a channel must provide, in addition to the adresses S and E, the key K_(S,E). The subscription request propagates as long as the path toward the source, allowing the first router on the diffusion tree and receiving the request to authenticate the new subscriber because this router memorizes the key K_(S,E). But this key is seen by routers as an optional parameter which allows to limit access to the channel. And the mechanism of the management of the key is not explained here. 5.Conclusion In this document, we have presented a new architecture for securing SSM communication. The aim of this work is to allow only legitimate subscribers, i.e, subscribers who pay subscription fee, to have access to channel flow in a dynamic environment. We have brought the security services on two phases. The first one is intended to ensure the subscription of a new host : we have used the access control, which is considered as a new extension to non-secure subscription to an SSM channel. In the second phase, we have ensured confidentiality and sender authentication through the management of the channel key shared among the source and the subscribers of channels. We have conceived the architecture S-SSM of such a way that other approaches for the dynamic group key management such as GKMP, LKH, or OFT could be used for the management of the channel key. References [1] Deering, S., "Multicast routing in a datagram internetwork". Ph.D. thesis, Stanford University, Octobre 1991. [2] Holbrook, H. and Cheriton, D., " IP Multicast Channels: EXPRESS Support for Large-scale Single-source Applications. ", ACM SIGCOMM, November 1999. [3] Ballardie, T. and Perlman, R. and Lee, C. and Crowcroft, J., "Simple Scalable Internet Multicast", tech. rep., University College London, April 1999. [4] Ballardie, A., "Core Based Trees (CBT version 2) Multicast Routing", RFC-2189, September 1997. [5] Holbrook, H. and Cain, B. " Source-Specific Multicast for IP", , May 2000. [6] Estrin, D. and Farinacci, D. and Helmy, A. et al., "Protocol Independent Multicast Sparse Mode (PIM-SM): Protocol Specification", RFC-2117, Juin 1997. [7] Cain, B. and Deering, S. and Kouvelas, W. and Thyagarajan, A., "Internet Group management Protocole, Version 3", , January 2001. [8] Holbrook, H. and Cain, B., " Using IGMPv3 for Source-specific Multicast", , March 2001. [9] Chaddoud, G. and Chrisment, I. and Schaff, A., "Dynamic Group Communication Security", MMM-ACNS 2001, SaintPetersburg, Russia, May 2001. [10] Ballardie, T. , "Scalable Multicast Key Distribution", RFC-1949, May 1996. [11] Chaddoud, G. and Chrisment, I. and Schaff, A., " Dynamic Group Key Management", ISCC2001, Hammamet, Tunisia, July 2001 [12] Fenner, B. and He, H. and Haberman, B. and Sandick H., " IGMP-based Multicast Forwarding (IGMP Proxying)", , November 2001 [13] He, H. and Hardjono, T. and Cain, B., " Simple Multicast Receiver Access Control", , November 2001. [14] Hardjono, T. and Cain, B., " Key Establishment for IGMP Authentication in IP Multicast ", 1st IEEE European Conference on Universal Multiservice Networks (ECUMN'2000), Colmar France, October 2000. [15] Harney, H. and Mucknhirn, C., "Group Key Management Protocol (GKMP) Specification", RFC-2093, July 1997. [16] Harney, H. and Mucknhirn, C., "Group Key Management Protocol (GKMP) Architecture", RFC-2094, July 1997. [17] Wong, C. and Gouda, M. and Lam, S., "Secure Group Communications using Key Graphs", ACM-SIGCOMM'98, September 1998. [18] Wallner, D. and Harder, E. and Agee, R., "Key Management for Multicast : Issues and Architecture", , September 1998. [19] Rafaeli, S. and Mathy, L. and Hutchison, D., "LKH+2: An improvement on the LKH+ algorithm for removal operations", , January 2002. [20] McGrew, David A. and SHerman, Alan T., "Key Establishment in Large Dynamic Groups using One-way Function Trees", TIS Labs at Network Associates, Inc. Gleenwood, Maryland, 1998. Author's Addresses Ghassan Chaddoud LORIA/INRIA-Lorriane Campus Scientifique BP 239 Phone : +33 383 59 20 48 54506 Vandoeuvre-les-Nancy Email : chaddoud@loria.fr France Isabelle Chrisment LORIA Campus Scientifique BP 239 Phone : +33 383 59 20 17 54506 Vandoeuvre-les-Nancy Email : ichris@loria.fr France Andre Schaff LORIA Campus Scientifique BP 239 Phone : +33 383 59 20 11 54506 Vandoeuvre-les-Nancy Email :schaff@loria.fr France