Internet Research Task Force Haixiang He, Nortel Networks INTERNET-DRAFT Thomas Hardjono, Verisign Brad Cain, Cereva Networks Expire: May, 2002 November, 2001 Simple Multicast Receiver Access Control Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 seeks to provide a solution to secure the multicast edge, in particular the "last-hop" of the multicast between multicast edge routers and hosts within a network. In this document, we proposed a simple and light-weight solution to prevent an illegal host from pulling the multicast distribution tree into the host's network when no other legal hosts exists in that same network. 1. Introduction He, Hardjono, Cain [Page 1] Internet Draft draft-irtf-gsec-smrac-00.txt May, 2002 Multicast technology [1] provides an efficient transport mechanism for delivering packets to multiple destinations. An IP system (host or router) uses Internet Group Management Protocol (IGMP) [2,3] to express its interest in receiving multicast packets to a specific multicast address to its neighboring multicast routers. IGMPv3 [4] allows a system also to report interest in receiving packets only from specific source addresses, or from all but specific source addresses. The current multicast model allows any host to join a multicast group by issuing a join message. When it receives an IGMP request to join a given group, if it is not yet receiving the traffic for that group, a router typically issues a join request upstream towards the multicast distribution tree using a multicast routing protocol. Once the join request succeeds, the multicast distribution tree is effectively expanded towards the router and the host starts to receive the traffic. The multicast traffic is typically broadcasted in a shared network even there is only one host is interested in receiving it. Other hosts in the same network that are uninterested in receiving the traffic simply ignore the broadcasted packets. The end-to-end data encryption can be used to preventing these hosts from reading the data. However, there is currently no mechanism to prevent a host from joining groups by issuing bogus join messages to multicast routers. The lack of this security mechanism may cause access control problems, denial-of-service attacks, and many other problems. For example, a host can simply joins a multicast group without any intention of using the date being delivered to it. In such an attack, the host essentially extends or "pulls" the multicast distribution tree towards its network. This results a waste in bandwidth resources and in memory resources for state information within all the affected routers. Solving these problems needs a solution that provides security between a host and its neighboring multicast routers. Particularly a solution should provide the ability for a multicast router to authenticate and authorize a host's IGMP join requests. In this paper, we propose a simple method to achieve the goal of authenticating and authorizing a host's IGMP join requests. The method uses the approach: Proof of Membership. A host needs to provide its neighboring multicast routers with a proof of membership before its IGMP join requests are processed. The proof of membership in this method is an Access Token. The method is a light-weight solution and the light-weight feature maintains the scalability of multicast and provides enough incentives for this solution to be He, Hardjono, Cain [Page 2] Internet Draft draft-irtf-gsec-smrac-00.txt May, 2002 turned on. 2. Motivations for Receiver Access Control There are two main motivations for multicast receiver access control. The first motivation is to protect the multicast infrastructure. The second motivation is provide a simple solution to protect the multicast data. 2.1. Multicast Infrastructure Protection The multicast infrastructure can be divided into two parts, the core and the edge. The core contains all the multicast routers and multicast routing protocols are used to construct the multicast distribution trees. The edge contains multicast edge routers and hosts and IGMP is used to communicate the group membership subscriptions. There are three steps to deliver multicast packets to a host. First a host communicates its interests to its neighboring multicast edge routers. And then those group membership subscriptions are used to trigger the construction of the multicast distribution tree in the multicast core. Then the packets flow to the host along the newly constructed distribution tree. One of the main goals of the current multicast service model is scalability. To achieve this goal, a multicast router is designed to only keep track of whether or not there is an interest in packets to a particular multicast address from a particular source for an interface. It is not designed to keep track of each individual system that has the same interest. In another word, the receivers or hosts are anonymous especially in the multicast edge. The edge multicast routers don't maintain host identification information and don't pass any host identification information. The original IP multicast model [1,2] does not address multicast security issues. To secure the multicast infrastructure, both the multicast core and the multicast edge have to be secured. The multicast core protection is achieved by protecting the multicast routing protocol. In particular, the control messages of the multicast routing protocol are protected to ensure the correct construction of the distribution tree. For example, in MOSPF [5] and in PIM [6], the control messages are authenticated. Unfortunately, those solutions to protect the multicast core are not sufficient enough. They only ensure that the group membership subscription information maintained in the edge multicast routers are populated correctly. They don't check and don't have the ability to check whether the subscription information is legal or not. Bogus He, Hardjono, Cain [Page 3] Internet Draft draft-irtf-gsec-smrac-00.txt May, 2002 subscriptions can also attack the multicast core. This is why the multicast edge should be secured first. The current multicast model allows any host to join a multicast group. When there is no other receiver on the same network, a host can easily attack the multicast infrastructure by issuing bogus IGMP join messages without any intention of using the multicast data. These IGMP join messages trigger the multicast routing protocol and eventually cause the multicast tree to be extended or pulled towards the host's network. The encryption of the multicast data does not prevent such attacks since the encrypted packets still are delivered along the distribution tree to the host's network. The lack of host identification information makes it even harder for an edge router to pinpoint an illegal host. Such an attack can cause large amounts of unused data to be forwarded to the attacking host's network and hence wastes the network bandwidth resource and may affect other services on the same network. The network bandwidth resources along the expanded branches of the multicast distribution tree are also wasted. Besides the waste of bandwidth resources, it also wastes the memory resources that routers used to maintain the state information and the processing power used to process the control messages. A host can start another kind of denial-of-service attack to the multicast infrastructure even if there are no multicast packets flowing in the network. The current multicast routing protocols create multicast data forwarding states on the multicast routers along the reverse path from the receiver to the sender before the multicast packets flow into the network. A host can subscribe traffic to thousands of multicast addresses and from thousands of source addresses. This can cause routers to create huge amounts of forwarding states that may beyond the limits that routers can handle. Eventually a router starts to deny other legal multicast service requests. This is particularly true to routers that are roots or near the roots of the multicast distribution tree since they maintain the most multicast forwarding states. Such routers are Rendezvous Points (RPs) in Protocol Independent Multicast-Sparse Mode (PIM-SM) [7,8] and Designate Routers (DRs) in Source-Specific Multicast (SSM) [9, 10]. 2.2. Multicast Data Protection Multicast data protection is usually achieved through end-to-end data encryption. End-to-end data encryption ensures date integrity, source authentication, and data confidentiality. Another completely different security infrastructure targeted specifically for multicast He, Hardjono, Cain [Page 4] Internet Draft draft-irtf-gsec-smrac-00.txt May, 2002 data protection needs to be developed to manage and deliver the keying material used for data encryption. Such an infrastructure is typically called Group Key Management (GKM) protocol. Some of them have been developed in the IETF especially in the Multicast Security (MSEC) working group [11,12,13,14]. Developing and deploying a multicast security infrastructure is very expensive. In a non shared medium network such as switch Ethernet, it is enough to prevent users from getting multicast data by just using access control on the edge. Comparatively, the access control is cheaper and simpler. In some scenarios, even the encrypted multicast data is required not to deliver to illegal users since they may decrypt the data sooner or later and acquire the secret information. This can be achieved by using receiver access control on non share medium network. In a shared medium network, multicast packets are broadcasted. So if the legal hosts and illegal hosts coexist in the same network, the illegal hosts will also receive the packets even if they are encrypted. Access control won't help in this scenario. However, for some applications such as Internet TV, it may be tolerable for some illegal users to receive the packets for free as long as at least one legal user on the same network. Access control may be the best solution since it is simple and cheap. 3. Solution Goals and Requirements The primary goal of the multicast receiver access control solution proposed in this document is to prevent an illegal host from pulling the multicast distribution tree into the host's network when there are no other legal hosts in the same network. In another word, the primary goal is to protect the multicast routing infrastructure. The solution does not address the situation when there is already an legal host in a shared medium network. It does not solve the problem of hosts on a shared network intercepting data packets. However, the secondary goal of the solution is to provide a simple and cheap substitute to a complicated and expensive multicast security infrastructure used to protect multicast data. There is also some cost to provide last hop security. Similar to other scenarios requiring security, the cost of providing security must be considered against the amount of state that will result in the multicast edge routers if no last hop security is afforded. So in some circumstances rather than turning on the last hop security, it may perhaps be tolerable to allow an illegal host to pull the the He, Hardjono, Cain [Page 5] Internet Draft draft-irtf-gsec-smrac-00.txt May, 2002 multicast distribution tree to its network. This requires a receiver access control solution to be light weight. So that it can provide enough incentives to be turned on. 4. Receiver Access Control Framework In this section, we propose the use of the Access Token to achieve the goal of receiver access control. We also describe the details of the solution framework. 4.1. Solution Overview The receiver access control solution proposed in this document also uses the same approach introduced in [15]: Proof of Membership. The approach is for a receiver or a host to provide its neighboring routers with some "proof-of-membership". The proof must be pre- established before the receiver issues control messages to the multicast edge routers. Here the proof-of-membership is an access token that is digitally signed by a trusted authority such as Group Controller Key Server (GCKS) using the private key of a public-key pair designated for receiver access control. The solution requires that only legitimate multicast routers posses the public key of the key pair. The whole process of the solution is as follows. First, a host needs to communicate with a trusted authority. The trusted authority authenticates the host and delivers a signed access token to the host for multicast packets to a specific multicast address and from specific source address(es) if the host is authorized to access the multicast packets. Then the host attaches the access token to its IGMP report messages when it is required by a multicast edge router. Once it receives the access token, the router forwards it to the authentication module. According to the results of the authentication, the router will take appropriate actions. If the request is authenticated and authorized, the router updates the IGMP state information that it maintains. This may trigger the multicast router protocol when the router does not have the packets a host requests and eventually causes the packets to be forwarded to the host's network. If the request is not authenticated or not authorized, the router ignores the IGMP requests. The multicast routing infrastructure is protected and the illegal host won't receive the packets if there are no other legal hosts in the same network. He, Hardjono, Cain [Page 6] Internet Draft draft-irtf-gsec-smrac-00.txt May, 2002 4.2. Content of the Access Token An access token contains at least the following information: - Subscription information - Host IP address - Expiration time The subscription information is a multicast address and a list of source addresses. There can be zero, one, or more source addresses in the list. An access token can contain other information. Each information in the access token is used to counter one kind of attack. The subscription information defines the usage scope of the access token. It prevents a host to use the same access token for other subscriptions. In another word, it prevent a host to access packets that is not sent to the multicast address and from the source addresses that are in the access token. The host IP address is used to prevent another host outside the same network to use the same access token. When a router receive the access token, the authentication module compares the IP address of the IP packet that contains the access token with the IP address in the access token. If the two IP addresses don't match, then the request is not authenticated. A router has the ability to identify whether an IP packet is a legal packet from a network and drops the illegal packet. So even if a host fakes the IP address, the same access token still can not be used outside its legal owner's network. The expiration time is used to prevent a host to reuse the same access token after the expiration time. The expiration time is set according to the agreement between the host and the trust authority. The agreement related issues are beyond this document. 4.3. Access Token Management and Delivery The trust authority should manage the access tokens and deliver them to appropriate hosts through secure channel. There is some cost to develop a trust authority and the secure channel between the host and the trust authority. However we may use an infrastructure that has already been deployed. If the multicast security infrastructure has been deployed to protect the multicast data, the Group Controller Key Server (GCKS) [16] can also be used as the trust authority for receiver access control. When the host communicates with GCKS and is authenticated by the GCKS, besides delivering the group keys to decrypt the multicast data, the GCKS can also deliver the access tokens to the hosts through the same He, Hardjono, Cain [Page 7] Internet Draft draft-irtf-gsec-smrac-00.txt May, 2002 secure channel. If such a multicast security infrastructure is not deployed, the trust authority can co-locate with the billing server or the multicast session announcement server. The access token can be delivered with the multicast session information or billing information. 4.4. Upload the Access Token using IGMP When required by its neighboring multicast edge routers, a host has to attach the access token to its IGMP report messages. The necessary IGMP changes to upload authentication information from a host as well as the APIs between the IGMP module and the authentication module in the multicast edge routers are proposed in document [17]. To use the modified IGMP proposed in [17], we set the authentication type to 1 for uploading access token. The authentication module uses the system time, the subscription information in the group record, and the IP address of the IGMP report packet to authenticate the request as we described above. To avoid the complexity, we propose the Access Token is per multicast group based and is per group-and- source based for SSM. 5. Advantage of the Solution The big advantage of this solution is that it is a very simple and light-weight solution. In this solution, a multicast edge router only needs to maintain the public key of the public-key pair used for access control. The router need not identify any host since it trust the key management service to operate correctly. The previous approach [18] was considered too heavy-weight for multicast edge routers since it requires multiple challenge-response handshakes to be performed between a host and a multicast router. Furthermore, it requires an authentication server to be available continuously for the multicast edge routers in the domain to verify membership of hosts to multicast groups. It also changes the current multicast model and hence may cause the decrease of the multicast scalability. Compare to the approach [15], this solution is also light-weight. In [15], a Token-List has to be distributed to the multicast edge routers by the key server. If there are lots of hosts and each host subscribes many multicast traffic, there will be large amounts of access tokens. So the Token-List can be huge. Maintaining and He, Hardjono, Cain [Page 8] Internet Draft draft-irtf-gsec-smrac-00.txt May, 2002 distributing the huge Token-List is expensive and heavy-weight. In the same approach, a host also uses access token as the proof-of- membership, but the access token can only be used once. This may require the key server to generate new access tokens. There is also some cost to update and deliver the new access tokens. 6. Solution Weakness and Improvement There is a weakness in this solution. It can be improved but there are some extra costs for the improvement. 6.1. Solution Weakness The solution proposed in this document does not protect the IGMP control message itself directly, particularly the IGMP report messages. Although the IGMP control messages are not forwarded outside its network, but they can be intercepted within the network. A system on the same network can forge the IGMP control messages and cause lots of problem. The details of these problems can be found in [4]. When a host uses the access token, e.g., attaches the access token to its IGMP report messages, another host on the same network can intercept the access token. It cannot read or change the access token since it does not have the public key of the public-key pair used for access control, only legitimate multicast routers have the public key. But that host can reuse the same access token with faking the IP address using the access token's legal owner's IP address to subscribe the same subscription. As described above, the IP address of the access token's legal owner and the subscription information within IGMP report messages are not protected. However that host does not gain anything by reusing the same access token if the a legal is also subscribing the traffic since the multicast packets have already been forwarded into the network. Unfortunately, if the legal host stops subscribing the same multicast traffic before the expiration time contained in the access token, another illegal host can benefit from reusing the same access token. Reusing the same access token by an illegal host on the same network causes the multicast packets from the same subscription to be continuously forwarded into the network. To some service providers, this may not be a big issue and is tolerable. Since to them, the multicast packets are already allowed to be forwarded to the legal host's network until the expiration time. He, Hardjono, Cain [Page 9] Internet Draft draft-irtf-gsec-smrac-00.txt May, 2002 6.2. Solution Improvement The current solution can be improved to counter the attack of reusing the same access token within the same network. One simple improvement is to use another public-key pair to protect the IGMP report messages from a legal host. It works as follows. The trusted authority generates a new public-key pair for each host. It puts the public key of the new public-key pair in the access token to replace the host IP address. The host's IP address is not used in the improved solution. Then the trust authority delivers the private key of the new public-key along with the new access token that contains the public key to the host through the secure channel. The host uses the private key of the new public-key pair to sign its IGMP report messages and attaches the digital signature to its IGMP report messages. When it receives a IGMP report message, a multicast edge router must first verify the access token. Then it must verify the host's digital signature using the public key in the access token. And there is also some extra cost in this improvement. First, there are some cost in managing and delivering the new public-key pair. Second, there are some costs for a host to sign its IGMP report messages. Third, there are some extra bandwidth usage wastes to upload the digital signature. Fourth, there are some costs for a multicast edge router to verify the digital signature. Some of the costs can be reduced. For example, a host does not need to upload the digital signature every time for the same IGMP request. And a multicast edge router may ignore the digital signature sometimes. References [1] Deering, S., "Multicast Routing in a Datagram Network", PhD Thesis, Stanford University, Palo Alto, California, Dec. 1991. [2] Deering, S., "Host Extension for IP Multicasting", RFC 1112, August 1989. [3] Fenner, W., "Internet Group Management Protocol, Version2", RFC 2236, November 1997. [4] Cain, B., Deering, S., Fenner, W., Kouvelas, I., Thyagarajan, A., "Internet Group Management Protocol, Version 3", Internet-Draft, January 2001. [5] Moy, J., "Anatomy of an Internet Routing Protocol", Addison-Wesley, 1998. [6] Wei, L., "Authenticate PIM Version 2 Messages", Internet-Draft, Work in progress. [7] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and Wei, L., "Protocol Independent Multicast-Sparse Mode (PIM-SM), Protocol He, Hardjono, Cain [Page 10] Internet Draft draft-irtf-gsec-smrac-00.txt May, 2002 Specification", RFC 2362, June 1998. [8] Fenner, B., Handley, M., Holbrook, H., and Kouvelas, I., "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", draft-ietf-pim-sm-v2-new-03.txt, July 2001. [9] Holbrook, H., and Cain, B., "Using IGMPv3 For Source-Specific Multicast", draft-holbrook-idmr-igmpv3-ssm-01.txt, March 2001. [10] Holbrook, H., and Cain, B., "Source-Specific Multicast for IP", Internet-Draft, work in Progress. [11] Harney, H. and Muckenhim, C., "Group Key Management Protocol (GKMP) Architecture", RFC 2094. [12] Hardjono, T., Cain, B., and Monga, I., "Intra-Domain Group Key Management Protocol", draft-ietf-ipsec-intragkm-01.txt, March 2000. [13] Baugher, M., Hardjono, T., Harney, H., and Weis, B., "The Group Domain of Interpretation", draft-ietf-msec-gdoi-01.txt, July 2001, Work in Progress. [14] Harney, H., Colegrove, A., Harder, E., Meth, U., and Fleischer, R., "Group Secure Association Key Management Protocol", draft-ietf-msec-gsakmp-sec-00.txt, March 2001. [15] Hardjono, T. and Cain, B., "Key Establishment for IGMP Authentication in IP Multicast", IEEE European Conference on Universal Multiservice Networks (ECUMN), CERF, Colmar, France, September 2000. [16] Hardjono, T., Canetti, R., Baugher, M., Dinsmore, P., "Secure IP Multicast: Problem Areas, Framework and Building Blocks", draft-irtf-smug-framework-01.txt, September 2000, Work in Progress. [17] He, H., Cain, B., and Hardjono, T., "Upload Authentication Information Using IGMPv3", Internet-Draft, Work in Progress. [18] Ishikawa, N., Yamanouchi, N., and Takahashi, O., "IGMP Extension for Authentication of IP Multicast Senders and Receivers", draft-ishikawa-igmp-auth-01.txt, August 1998, Work in Progress. Author's Address: Haixiang He Nortel Networks 600 Technology Park Drive Billerica, MA 01821 Phone: 978-288-7482 Email: haixiang@nortelnetworks.com Thomas Hardjono Verisign 401 Edgewater Place, Suite 208 He, Hardjono, Cain [Page 11] Internet Draft draft-irtf-gsec-smrac-00.txt May, 2002 Wakefield, MA 01880 Email: thardjono@verisign.com Brad Cain Cereva Networks Email: bcain@cereva.com He, Hardjono, Cain [Page 12]