| MBONED Working Group | W. Atwood |
| Internet-Draft | Concordia University/CSE |
| Intended status: Informational | S. Islam |
| Expires: January 5, 2015 | United International University |
| B. Li | |
| Concordia University/CSE | |
| July 04, 2014 |
Requirements for IP Multicast Receiver Access Control
draft-atwood-mboned-mrac-req-01
IP multicast offers no facilities for receiver access control or accounting. This document explores the requirements for such facilities.
This Internet-Draft is submitted to IETF 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 January 5, 2015.
Copyright (c) 2014 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.
When using group communication at the application level, there is a variety of ways that the subscribers to a group (the End Users) can be managed. Encryption can be used at this level to secure the group data, i.e., to prevent a non-subscribing End User from interpreting the resulting group data as they are delivered.
When an End User joins an application-level group, this normally implies that the End User Device will join the corresponding network-level IP multicast group. The procedure for effecting this join, as defined in [RFC1112], is an open one:
This "unconditional join" implies that there is no access control at the network level, i.e., it is not possible to prevent an arbitrary End User Device from asking that the multicast data stream be delivered to it.
The unconditional construction of the data distribution tree is thus entirely receiver-driven, with the result that there is no relationship between the sender and the receiver(s), 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 Content Provider to generate any revenue from the receivers of IP multicast services.
There are some environments where sufficient access control to the multicast data stream can be achieved because of the physical characteristics of the delivery medium (e.g., DSL links, point-to-point links).
There are some environments where access control is undesired or irrelevant (e.g., internal corporate distribution, subscriber controlled by a set-top box).
There are some environments where the use of multicast data distribution could result in resource savings (for the Content Provider and/or the Network Service Provider), but the Network Service Provider is reluctant to use this technology because of the inability to correlate the receiving End Users with the service being delivered, which makes it very difficult for the Network Service Provider to derive any revenue from the multicast stream.
Access control can be viewed at two levels: the application level and the network level. At the application level, an End User will obtain permission to subscribe to a group session. This permission will contain at least two components: a description of how the session is to be accessed and a certification that the End User is authorized to access the session.
The certification will be presented at the application level, and if it is valid the End User will be permitted to join the group.
At the network level, the session descriptor will be used to issue the network level join, which allows the session data to flow to the end user host.
To prevent the end user from presenting an arbitrary session descriptor, it is necessary to coordinate the application level join and the network level join. Two possible ways of achieving the necessary coordination are:
Effective access control must be secured. It is not meaningful to implement access control without also ensuring that the party making the request for access (i.e., the End User) is authenticated. Since the network-level request is made using MLD/IGMP, this implies that the MLD/IGMP exchanges must also be secured.
The overall goal of this work is to list the requirements on a set of mechanisms that allow the Network Service Provider to act on behalf of the Content Provider (since the Network Service Provider has access to information from the End User that the Content Provider does not have access to) to meet the access control and revenue generation goals, while remaining as independent as possible from the specific business model in use.
Several pieces of the solution have received significant attention in recent years.
The problem of security and key management for application-level groups has been explored by the Multicast Security (MSEC) working group, and a framework devised [RFC3740].
The use of AAA protocols (RADIUS [RFC2865], Diameter [RFC3588]) to manage network-level access has been standardized. The approach outlined in this document is based on the observation that the AAA protocols (especially Diameter) can be extended to permit controlling access to application-level groups.
Some requirements for "well-managed" multicast have been stated in [I-D.ietf-mboned-maccnt-req], and a framework for satisfying these requirements with the help of AAA functionality has been described in [I-D.ietf-mboned-multiaaa-framework]. These documents suggest various business models for the interaction with the End User(s), with (potentially) separated functions corresponding to the Content Provider and the Network Service Provider.
The requirements document [I-D.ietf-mboned-maccnt-req] gives general requirements for authentication, authorization, accounting and Quality of Service (QoS) control. It assumes that the required goals can be achieved by integrating AAA with a multicast Content Distribution System, with MLD/IGMP at the edge of the network. The framework document [I-D.ietf-mboned-multiaaa-framework] presents a basic AAA enabled model as well as an extended fully enabled model with resource and admisison control coordination.
The approach of extending IGMP to carry authentication information has been proposed for a number of years [I-D.irtf-gsec-igmpv3-security-issues], [I-D.irtf-gsec-smrac], [I-D.he-magma-igmpv3-auth], [I-D.coan-hasm], [I-D.hayashi-igap].
Van Moffaert [I-D.irtf-gsec-igmpv3-security-issues] has proposed a mechanism for securing the IGMPv3 packets using IPsec. The IGMP [RFC3376] specification suggests the use of IPsec with Authentication Header (AH) [RFC4302] to secure the packet exchanges, and notes certain limitations on its use. The MLD [RFC3810] specification is silent on the issue of securing the packets.
A receiver access control architecure has been proposed in [MulticastReceiver] and [MulticastPANA]. In addition to the Network Service Provider and Content Provider of the "well-managed multicast" model, it incorporates the concepts of a Merchant (to offer the available services to the End User) and a Financial Institution (to verify the ability of the End User to pay for the desired services).
A sender access control architecture has been proposed in [MulticastSender].
[I-D.liu-mboned-mldauth-ps] provides additional requirements for the case where the End User device is mobile. [MulticastMobile] provides a solution for the issue of device mobility, using the EAP Reauthorization Protocol [RFC6696].
As an extensive mechanism for QoS management already exists [RSVP], this part of the problem will be considered to be out-of-scope for this document.
Finally, work is under way on securing the network routing infrastructure [RFC6862] [RFC6518]. In particular, securing of the exchanges between adjacent PIM-SM routers is specified in [RFC5796].
However, one key piece is missing. It is necessary to authenticate and authorize receiving users and to correlate their right to access a group with the action of putting the data on that part of the network that is directly connected to the receiving host. These two actions must be done securely, to ensure the correctness of the authentication and authorization actions. As noted in the Introduction, there are two approaches to achieving the correlation: carry the application-level information in the network-level join message, or spearate the two messages and ensure that they are correlated cryptographically. These two approaches will be explored in Section 4, and the choice of one of them will be justified. Ensuring that the network-level join is not done unless the application-level join is authorized also has the desirable side effect of minimizing the resource wastage that would result from delivering multicast traffic to devices whose End Users have no entitlement to receive them.
A system for the delivery of multicast data will have interacting components, which are illustrated in Figure 1 to facilitate discussion. Note that only the components that are inside the dotted line are in scope for this document. The components outside the dotted line are presented only to show how the inside components relate to the outside components.
__________ __________ __________ | | | | | | | CP |o o o o o o o o o o| MR |+++++++++++++++++++| FI | | |o o o o o o | | | | | | o | |++++++++++++++ | | | | o | |++++++++++++ + | | | | o | | + + | | | | o |________| + + |________| | | o o + + + + | | o o + + + + | | ________________________________ + + + + | | | | + + + + | | | NSP | + + + + | | | ...........................|..+.+.........+..+... | | | . | + + + + . | | | . __________ ______ | + + ________ + . | | | . | | |NAS | | + ++++| ____ | + . | | | . | AAAS | |____| |<-+---->| |EU| | + . | | | . | | |AR | |==+====>| |__| | + . | | | . |________| |____| | + | EUD | + . | | | . | + |______| + . | | | ................... | + + . | ______ | | ______ . ______ | + ________ . | | | | | |NAS | ______ ______ . |NAS | | +++++++++| ____ | . | | CS | |<--->| |____| | | | | . |____| |<--------->| |EU| | . | | | |====>| |AR | | CR | | CR | . |AR | |==========>| |__| | . | |____| | | |____| |____| |____| . |____| | | EUD | . | | | . | |______| . | | | .........|..................... |________| |_______________________________| o o o Policy flow +++++ Purchase flow <---> Access Control flow ====> Data flow ..... Scope of interest CP Content Provider CS Content Server MR Merchant FI Financial Institution EU End User EUD End User Device NSP Network Service Provider AAAS AAA Server AR Access Router NAS Network Access Server CR Core Router
Figure 1: Reference Architecture
A brief description of the components follows:
These components illustrate separate functionalities. The functionalities may in fact be under separate administrative control, or they may be combined in various ways.
Since the end point of the NSP side of several interactions cannot be precisely determined until the detailed design is done, the term "NSP Representative" will be used in this document. A typical NSP Representative will be located on a router or other device that is "close" to the End User Device.
There are four kinds of information flow in Figure 1.
The operation of the components and the exchange of information may be illustrated through the following example:
The Content Provider arranges to provide a live video multicast session for a football match. It contracts with the Merchant to act as its "sales agent", and provides relevant policies concerning the distribution of this particular content stream. The Merchant will offer this content stream to interested subscribers (the End Users), using any available mechanism (in this case, its website, www.mcast-football.com). When an End User (Alice) subscribes to the content, the Merchant will verify with the Financial Institution that Alice is able to pay. Depending on the nature of the realitionship among the Merchant, Alice, and her Financial Institution, the payment may be taken immediately, or it may be defered to some point after delivery of the subscribed stream. The Merchant then issues a "ticket" to Alice, containing the information to identify Alice and information to identify the content stream to which she has subscribed. This could have, for example, the following form:
Alice has a video client that will process the multicast address and request receipt of the video stream at the network level. However, Alice's right to receive the video stream must also be established (transparently to Alice) before she starts to receive the subscribed stream. The requirements on this verification form the core of the purpose of this document. If the verification is successful, the Access Router will be grafted onto the multicast data distribution tree within the Network Service Provider. The multicast content is streamed to the Network Service Provider at the appropriate time by the Content Server. The Network Service Provider will begin to stream the content to the End User Device once it becomes available.
Policies concerning the access to the data stream are exchanged between the Content Provider and the Merchant; they may also be exchanged between the Content Provider and the Network Service Provider. Policies concerning the validation of a "ticket" are exchanged between the Merchant and the Network Service Provider; these may depend in part on the policies that were received by the Merchant from the Content Provider. In total, the policies received by the Network Service Provider are expected to contain sufficient information that the AAAS will be able to validate a ticket without having to refer directly to the Content Provider.
As noted in the Introduction, access control can be viewed at two levels: the application level and the network level. To ensure that permissions given at the application level are reflected in the corresponding network-level actions, it is necessary to coordinate them. Section 2 has outlined several proposals that have been made in the past for extensions to IGMP to achieve this coordination. However, these proposals each appear to be heavily tied to a particular version of IGMP, and so will be incompatible with future versions of MLD or IGMP. In addition, such proposals are in effect a new version of MLD/IGMP, and even after several years, IGMPv3 is not universally available in mainstream Operating Systems. This makes it more desirable to find a solution to the access control problem that does not require the presence of application-level access control information in MLD (or IGMP) packets. Thus, the approach labeled "Solution 1" in Section 1 is assumed in the following.
To allow for independent development of application-level mechanisms and network-level mechanisms, the requirements in this document are based on the assumption that a single method can be used for securing the MLD/IGMP exchanges, where the associated cryptographic parameters for this method are correlated with the authentication and authorization that has already been done at the application level.
This leads to a natural separation of the requirements into three categories: constraints on the application-level interactions, constraints on the network-level interactions, and constraints on the coordination between them.
The design of IP multicast [RFC1112] ensures that there can be no relationship between the End Users and the Content Provider(s). The primary goal is therefore to establish an equivalent relationship between each End User and the associated NSP Representative.
Although specifications exist for encrypting the user data, thus ensuring that only legitimate users can decrypt these data, these specifications provide no way to ensure that the data distribution tree is not extended when a non-authorized receiving user makes a request to join the tree. Thus, "group membership" and "multicast receiver access control" have to be considered (and solved) as separate problems.
There is a wide range of authentication and authorization procedures that may be desired by an Internet Service Provider, including some that may not yet be standardized. This implies the adoption of a very general framework for such procedures. If a general framework is used, then it is likely to be independent of the specific business model in use by the CP or the NSP.
Several scenarios can cause a need for re-authentication and re-authorization:
This implies the need for a general solution to the access control problem that facilitates re-authentication and re-authorization.
The fact of delivery of group data needs to be recorded, to enable revenue to be earned. This is only one of a range of accounting issues that may need to be addressed, which points to the need for a general solution that allows a range of accounting actions to be supported.
Since an End User may wish to join multiple groups simultaneously, it must be possible to associate multiple sessions with a single End User Device.
Since multiple devices on a LAN may have End Users who wish to join the session, it must be posible to differentiate these End Users on the LAN.
Mutual authentication of the NSP Representative and the End User must be possible.
The proposed solution should be compatible with all current versions of MLD and IGMP. It is important that a solution not be tied to the semantics or packet format of a particular version of MLD or IGMP.
The solution developed should minimize any alteration to the semantics and the packet layout of MLD and IGMP.
It has to be possible for an End User Device to issue multiple distinct network-level join requests. (This is implied by the constraint in the Application level.)
It has to be possible for the NSP Representative to manage multiple Network Level joins for a single shared medium. (This is implied by the constraint in the Application level.)
Mutual authentication of the NSP Representative and the End User must be possible.
It is conceivable that a solution could be found for the above issues that would be based on standard network protocols and separate (proprietary or standard) group management protocols. For example, the key management and distribution protocol associated with the application-level group could have authentication as one of its features. However, the separation of the network-level controls from the application-level controls enables a significant class of security attacks. It is therefore important that control of access to the network resources and control of access to the application-level resources be strongly coupled. This implies that the method used to cryptographically secure the MLD/IGMP interactions should be strongly coupled to the method used to ensure authentication and authorization at the application level. However, it does not imply that the application-level interaction should be responsible for securing the network-level access, or that the network-level access should carry application-level information.
Access to the network is different from access to a group. As an example, the authorization to watch a particular video presentation may be associated with a specific family member, while the authorization to use the network connection may be associated with an entire family (or to anyone present in the house).
While existing AAA procedures are designed to control network level access, they would have to be extended (or alternatives found) if group access needs to be controlled.
TBD.
This document has no actions for IANA.