MBONED W. Atwood Internet-Draft B. Li Intended status: Informational Concordia University/CSE Expires: April 25, 2014 S. Islam United International University/CSE October 22, 2013 Architecture for IP Multicast Receiver Access Control draft-atwood-mboned-mrac-arch-00 Abstract This document specifies the architecture of IP multicast receiver access control (MRAC). The interacting components, the protocols and the operations in MRAC system are specified in this document. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 25, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Atwood, et al. Expires April 25, 2014 [Page 1] Internet-Draft MRAC Architecture October 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. MRAC Architecture Overview . . . . . . . . . . . . . . . . . 3 3. Multicast Architecture . . . . . . . . . . . . . . . . . . . 5 3.1. IGMP/MLD . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Multicast Routing Protocol (MRP) . . . . . . . . . . . . 6 4. AAA Architecture . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Diameter / RADIUS . . . . . . . . . . . . . . . . . . . . 6 4.2. EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. PANA . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. IP Security (IPsec) Architecture . . . . . . . . . . . . . . 8 6. MRAC System Operation . . . . . . . . . . . . . . . . . . . . 8 6.1. Mapping the Multicast and AAA Architectures to the Network Boxes . . . . . . . . . . . . . . . . . . . . . . 8 6.2. EAP Exchanges . . . . . . . . . . . . . . . . . . . . . . 9 6.3. PANA Exchanges . . . . . . . . . . . . . . . . . . . . . 10 6.4. Diameter/RADIUS Exchanges . . . . . . . . . . . . . . . . 10 6.5. IPsec Exchanges . . . . . . . . . . . . . . . . . . . . . 10 6.6. IGMP/MLD Exchanges . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Group communication at the application level usually implies IP multicast at the network level. The use of IP multicast can only be justified in certain environments if it is possible to authenticate the receiving users, and verify their authorization to receive the multicast data stream. However, the design of IP multicast [RFC1112] ensures that there can be no relationship between the sender and the receiving users, i.e., the sender is not aware of the identity of the receivers (or even if there are any receivers at all). This can make it very difficult for the sender to generate any revenue from the receivers of IP multicast services. An alternative to access control by the sender is access control by the Network Service Provider, based on policies provided (directly or indirectly) by the sender. [I-D.atwood-mboned-mrac-req] lists the requirements on a set of mechanisms that allow a Network Service Provider to act on behalf of a sender (since the Network Service Provider has access to information from the receiving user that the sender does not have access to) to meet the access control and Atwood, et al. Expires April 25, 2014 [Page 2] Internet-Draft MRAC Architecture October 2013 revenue generation goals, while remaining as independent as possible from the specific business model in use. This document assumes that the various business models could be simplified into two assumptions as follows: The receiving user that receives the multicast data possesses a "ticket", which contains a description of the multicast group to be joined and whose validity can be demonstrated. The Network Service Provider that delivers the multicast data possesses the "policies" that contain a description of how to validate the "ticket" of a receiving user. [I-D.atwood-mboned-mrac-req] has presented how to fulfill the two assumptions in our business models. This document proposes a Multicast Receiver Access Control (MRAC) architecture that satisfies all the requirements in [I-D.atwood-mboned-mrac-req]. In this draft, the above two assumptions are used so that the business model in use does not have to be considered. 2. MRAC Architecture Overview The MRAC system has the interacting components as shown in Figure 1. A brief description of the components is as follows: _________________________ | ________ ___ | _______ | |AAAS | |NAS| | |EU | | |______|^^^^^^^|___|^^|^^^^| ___ | | ^ |AR | | ||EUD|| | ^ |___|''|''''||___|| | ^ | |_____| | ^ ____ | _______ | ^ |NAS| | |EU | | ^^^^^^^^^^|___|^^|^^^^| ___ | | |AR | | ||EUD|| |NSP |___|''|''''||___|| |________________________| |_____| ^^^^ Application-level access control flow '''' Network-level access control flow EU End User EUD End User Device NSP Network Service Provider Atwood, et al. Expires April 25, 2014 [Page 3] Internet-Draft MRAC Architecture October 2013 AAAS Authentication, Authorization and Accounting Server AR Access Router NAS Network Access Server Figure 1: MRAC Architecture End User (EU): A subscriber who wishes to receive multicast data delivered in a multicast group. The EU possesses a "ticket" to verify his/her subscription for a specific group. However, the way how to distribute the ticket to the EU is dependent on the business model so that it is out of scope for this draft. End User Device (EUD): A device, connected to the Network Service Provider via one or more technologies, operated by an End User. Network Service Provider (NSP): An organization that delivers the multicast content to the End User Device and implements the access control of the receiving End Users for multicast groups. The NSP employs various devices to fulfill its services. AAA Server (AAAS): A device that manages authentication, authorization and accounting services for multicast groups in NSP. The AAAS possesses policies to validate the EU's tickets. However, the way how to distribute the policies to the AAAS is dependent on the business model so that it is out of scope for this draft. Access Router (AR): A router, close to the EU, which is responsible for adjudicating the access rights to the network and the multicast groups in the NSP. Network Access Server (NAS): The enforcement point for managing authentication, authorization and accounting services for multicast groups in the NSP. Normally the NAS is co-located with the Access Router. Atwood, et al. Expires April 25, 2014 [Page 4] Internet-Draft MRAC Architecture October 2013 The operations among the interacting components are generalized into two levels as follows: Application-level operations: The EU interacts with the NAS to request joining the group to which he/she has subscribed. The EU's ticket is carried in the request. The NAS consults the AAAS for the EU's request. The AAAS uses the policies to validate the ticket so as to authenticate the EU for the network and to authorize the EU for the multicast group. Then the AAAS returns the authentication and authorization result to the NAS. If the EU is authorized, some cryptographic materials derived from the ticket are also provided to the NAS by the AAAS. Moreover, the accounting information for the authorized EU is also exchanged between the NAS and the AAAS. Network-level operations: the EU interacts with the AR to join the data distribution tree that is delivering his/her subscription content. The exchanges between the EU and the AR at the network level are secured by the cryptographic materials derived from those used at the application level, to couple the access control for the two levels. 3. Multicast Architecture 3.1. IGMP/MLD Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) have been standardized by the IETF for IPv4 and IPv6 systems (host or router) to inform the neighbouring multicast router(s) about the multicast group memberships of these systems. In IGMP, an IPv4 system sends a join or leave message (through Membership Report) when it wants to join or leave a multicast group (or some specific sources of a group). All multicast routers that are directly connected to the IPv4 system receive the Membership Report to learn which multicast groups are of interest to the IPv4 systems. Among these multicast routers, only one will be elected as "Querier". Its role is to query IPv4 systems about their interest in multicast groups by sending Membership Query. The other multicast routers are called Non-Queriers; they just receive the Membership Report messages from the IPv4 system and the Membership Query message from the Querier. MLD is a similar protocol but it is used by IPv6 systems. Atwood, et al. Expires April 25, 2014 [Page 5] Internet-Draft MRAC Architecture October 2013 The details of the IGMP/MLD architecture and operation are specified in [RFC3376] and [RFC3810]. 3.2. Multicast Routing Protocol (MRP) The multicast routing protocol (typically PIM-SM) builds a multicast tree among routers to distribute multicast data to receivers. One of the receiver's neighbouring routers is elected as the designated router (DR) or group designated router (GDR). On receiving the IGMP/MLD join message, DR/GDR will be grafted to the multicast data distribution tree on behalf of the neighbouring receiver. On receiving an IGMP leave Message, DR/GDR will be pruned from the data distribution tree if no other neighbouring receivers are interested in the group. The details of PIM-SM architecture and operation are specified in [RFC4601]. 4. AAA Architecture 4.1. Diameter / RADIUS AAA protocols are used to support AAA communication between a AAA client and AAA server(s). RADIUS and Diameter are the two AAA protocols that the IETF has standardized. Remote Authentication Dial In User Service (RADIUS) is a protocol for carrying information related to authentication, authorization, and accounting between a RADIUS Client and RADIUS Server. A RADIUS Client is responsible for passing user information to designated RADIUS Servers, and then acting on the response that is returned. RADIUS Servers are responsible for receiving user connection requests, authenticating the user, and then returning all configuration information necessary for the client to deliver service to the user. Diameter is the successor of RADIUS. The Diameter base protocol provides a AAA framework. The Diameter applications, such as NASREQ and Mobile IPv4, specify how to use the base protocol within the context of their applications. The details of Diameter / RADIUS architecture and operation are specified in [RFC6733] and [RFC2865] 4.2. EAP Atwood, et al. Expires April 25, 2014 [Page 6] Internet-Draft MRAC Architecture October 2013 Extensible Authentication Protocol (EAP) provides an authentication framework for support of multiple authentication methods. An EAP exchange runs between an authenticator and a peer. The authenticator as an initiator uses one or more EAP methods in sequence to authenticate the peer. Rather than requiring the authenticator to support authentication methods, EAP permits the use of a backend authentication server, which implements EAP methods, with the authenticator acting as a pass-through. In this case, a backend authentication server is connected with the authenticator. The actual authentication will be performed by the backend authentication server. The authenticator forwards EAP packets received from the peer to the backend authentication server; packets received from the backend authentication server are forwarded to the peer. EAP does not run directly over the IP layer. The PANA protocol (Section 4.3) and the AAA protocol (Section 4.1) will be used to carry the EAP packets. The details of the EAP architecture and operation are specified in [RFC3748]. 4.3. PANA Protocol for carrying Authentication for Network Access (PANA) is a network access authentication protocol that works as an EAP lower layer for transmitting EAP packets. PANA carries EAP authentication methods (encapsulated inside EAP packets) between a PANA Client (PaC) and a PANA Authentication Agent (PAA) in the access network. The PaC, as the client implement of PANA, interacts with the PAA, as the server implement of PANA, in the authentication process using the PANA protocol. PAA consults an Authentication Server (AS) for authentication and authorization of a PaC. If the AS resides on the same node as the PAA, an API is sufficient for this interaction. When the PAA is separated from the AS, a AAA protocol (e.g., Diameter) will be used for their communication. The AS is a conventional backend AAAS that terminates the EAP and the EAP methods. A PANA Enforcement Point (EP) allows (blocks) data traffic of an authorized (unauthorized) PaC. When the PAA and EP reside on the same node, they use an API for communication; otherwise, a protocol (e.g., SNMP) is required. Atwood, et al. Expires April 25, 2014 [Page 7] Internet-Draft MRAC Architecture October 2013 The details of the PANA architecture and operation are specified in [RFC5191] and [RFC5193]. 5. IP Security (IPsec) Architecture The IP security (IPsec) architecture is designed to provide security services for traffic at the IP layer. Most of the security services are provided through use of two traffic security protocols, the Authentication Header (AH)[RFC4302] and the Encapsulating Security Payload (ESP)[RFC4303], and through the use of cryptographic key management procedures and protocols. A security association (SA) is created in both sender and receiver. It is a simplex "connection" that affords security services to the traffic carried by it. The sender and receiver maintain their local Security Association Database (SAD) to record their SAs. In the unicast case, the SAs could be dynamically negotiated between the sender and the receiver using IKEv2 [RFC5996]. In contrast, in the multicast case, a Group Controller / Key Server (GCKS) is responsible for distribution of the group SAs (GSA) to all the group members (GM) in the same group. The details of the IPsec architecture and its extension for multicast are specified in [RFC4301] and [RFC5374]. 6. MRAC System Operation The MRAC architecture is composed from individual elements drawn from the pieces outlined in Sections 3, 4, and 5. In this way, it is possible to meet the requirments as listed in [I-D.atwood-mboned-mrac-req]. 6.1. Mapping the Multicast and AAA Architectures to the Network Boxes In order to meet the requirements in [I-D.atwood-mboned-mrac-req], all the functional entities that are applied in the multicast routing, AAA and IPsec architectures are mapped into the participants in our MRAC architecture as shown in Table 1. The EU in MRAC system maps the IPv4/IPv6 system in IGMP/MLD, the receiver in multicast routing protocol, PaC in PANA and EAP peer in EAP. The NAS in MRAC system maps the Diameter/RADIUS Client in Diameter/ RADIUS, PAA in PANA and EAP Authenticator in EAP. Atwood, et al. Expires April 25, 2014 [Page 8] Internet-Draft MRAC Architecture October 2013 The AAAS in MRAC system maps the Diameter/RADIUS Server in Diameter/ RADIUS, EAP backend authenticator server in EAP. The AR in MRAC system maps the multicast router in IGMP/MLD including Querier and Non-Querier, the EP in PANA. Moreover, the AR who wins in DR/GDR election maps the DR/GDR in multicast routing protocol. The EU and AR also map the GMs in IPsec. It depends on the specific packet whether the sender is EU or AR. A special AR, called Querier, may map the GCKS in IPsec. +--------------------------------------+-----+------+-------+-----+ | Roles | EU | NAS | AAAS | AR | +--------------------------------------+-----+------+-------+-----+ | IPv4/IPv6 systems in IGMP | x | | | | | multicast routers in IGMP | | | | x | | receiver in MRP | x | | | | | DR/GDR in MRP | | | | x | | Diameter/RADIUS Client | | x | | | | Diameter/RADIUS Server | | | x | | | PaC in PANA | x | | | | | PAA in PANA | | x | | | | AS in PANA | | | x | | | EP in PANA | | | | x | | EAP peer in EAP | x | | | | | EAP authenticator in EAP | | x | | | | backend authentication server in EAP | | | x | | | GCKS in IPsec | | | | x | | GM in IPsec | x | | | x | +--------------------------------------+-----+------+-------+-----+ Table 1: Mapping the Multicast and AAA Architectures to the Network Boxes 6.2. EAP Exchanges The EAP runs between an EU and an NAS, where the NAS can act as a pass-through, and an AAAS is connected with the NAS. The policy is used to determine whether actual authentication is performed by the AAAS or the NAS. In MRAC, it is recommended that the NAS use EAP-FAST as the EAP authentication method to authenticate the EU. The EU carries a token of his/her ticket in EAP-FAST method. The token includes the user information and group information to make the NAS or AAAS to do the authentication and authorization decision for the EU. Atwood, et al. Expires April 25, 2014 [Page 9] Internet-Draft MRAC Architecture October 2013 6.3. PANA Exchanges PANA carries the EAP-FAST method (encapsulated inside EAP packets) between an EU and an NAS in the access network. An EU may be configured with an IP address of the NAS as its PAA or dynamically discover it using the default method of DHCP. An EU, on receiving a request to join a multicast group while no GSAs have been established for the group, initiates a PANA exchange with an NAS as its PAA. During the PANA session, the NAS authenticates and authorizes the EU. In addition, the re-authentication and re- authorization may be required if necessary. The NAS would consult the AAAS to perform the actual authentication if it is a pass-through in the EAP exchange. The communication between NAS and AAAS is implemented by Diameter/RADIUS exchanges explained in the next subsection. Moreover, the NAS updates the filter state of the EU according to the authorization result and provides the authorization result and authorization attributes (mainly referring to a key derived from the EAP-FAST method) to the AR(s) connected directly to the EU. 6.4. Diameter/RADIUS Exchanges When the NAS is a pass-through, the Diameter / RADIUS exchanges are used between NAS and AAAS to carry information related to authentication, authorization, and accounting. In the Diameter / RADIUS exchanges, the NAS is responsible for passing the EAP-FAST method (carrying the token of the EU's ticket) to the AAAS, and then acting on the response that is returned. The AAAS is responsible for authenticating and authorizing the EU, and then returning the result and attributes (mainly including a key derived from the EAP-FAST method) for the EU to the NAS. 6.5. IPsec Exchanges IPsec is used to enforce the receiver access control at the network level. A protocol is needed to create IPsec GSAs and then distribute them to authorized EUs and their ARs dynamically. The protocol may be very similar to the two existing IETF protocols, GDOI and G-IKEv2. In MRAC, the Querier will become the GCKS in the network segment. The authorized EUs and the other ARs interact with their Querier. The Querier is responsible for checking the authorized attributes of the EUs. Then the Querier creates and distributes IPsec GSAs to the EUs and their ARs in the same network segment. Atwood, et al. Expires April 25, 2014 [Page 10] Internet-Draft MRAC Architecture October 2013 However, the two existing IETF protocols (GDOI and G-IKEv2) do not satisfy all the requirements for IPsec GSA creation and distribution in MRAC. A new protocol has been drafted for use by MRAC. 6.6. IGMP/MLD Exchanges IGMP/MLD is running among the EUs and their ARs. According to [RFC3376] and [RFC3810], the EU uses the message of Membership Report to report the current multicast reception status to its ARs. The specific AR, called Querier, uses the message of Membership Query to query the multicast reception status of its EUs. However, in order to enforce the receiver access control at the network level, the ARs and the EUs would filter out the received Membership Report and Membership Query messages using their local IPsec systems. The message of Membership Report that reports the reception status of the subscribed group would be protected by IPsec GSAs whose source address is the EU's address and whose destination address is the address of the reported subscribed group. Also, the Membership Query message that queries the reception status of the subscribed group would be protected by IPsec GSAs whose source address is the Querier's address and whose destination address is the address of the queried subscribed group. In order to utilize the IPsec system, IGMP and MLD must be extended. However, the extension will be very small. 7. Security Considerations TBD 8. IANA Considerations This draft has no actions for IANA 9. Acknowledgements 10. References 10.1. Normative References [I-D.atwood-mboned-mrac-req] william.atwood@concordia.ca, w., Islam, S., and B. Li, "Requirements for IP Multicast Receiver Access Control", draft-atwood-mboned-mrac-req-00 (work in progress), October 2013. Atwood, et al. Expires April 25, 2014 [Page 11] Internet-Draft MRAC Architecture October 2013 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008. [RFC5193] Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA) Framework", RFC 5193, May 2008. [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008. [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012. 10.2. Informative References [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. Atwood, et al. Expires April 25, 2014 [Page 12] Internet-Draft MRAC Architecture October 2013 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. Authors' Addresses William Atwood Concordia University/CSE 1455 de Maisonneuve Blvd, West Montreal, QC H3G 1M8 Canada Phone: +1(514)848-2424 ext3046 Email: william.atwood@concordia.ca URI: http://users.encs.concordia.ca/~bill Bing Li Concordia University/CSE 1455 de Maisonneuve Blvd, West Montreal, QC H3G 1M8 Canada Email: leebingice@gmail.com Salekul Islam United International University/CSE House 80, Road 8/A, Mirza Golam Hafiz Road Dhanmondi, Dhaka 1209 Bangladesh Email: salekul@cse.uiu.ac.bd Atwood, et al. Expires April 25, 2014 [Page 13]