Multicast User Authentication
draft-atwood-mcast-user-auth-00

Status of this Memo

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), 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.

This Internet-Draft will expire on September 5, 2009.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

RFC 1112 offers no facilities for participant control or accounting. This document explores the requirements for such facilities, and offers a potential solution, based on extending the IGMP and MLD "join" operations to carry EAP and/or ERP packets.

Table of Contents

1.  Introduction
2.  Terminology
3.  Problem Statement
    3.1.  Authenticating and Authorizing Multicast Users
    3.2.  Re-authentication and Re-authorization
    3.3.  Accounting
    3.4.  Independence of Authentication and Authorization Procedures
    3.5.  Coupling of Network and Application Level Controls
    3.6.  Separation of Network Access Controls from Group Access Controls
4.  Proposed Solution
5.  Protocol Details
6.  Security Considerations
7.  IANA Considerations
8.  Acknowledgements
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Authors' Addresses

1.  Introduction

The procedure for joining a network-level IP multicast group [RFC1112] (Deering, S., “Host extensions for IP multicasting,” August 1989.) an open one---a request is made by the receiving host, using MLD (IPv6) [RFC3810] (Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” June 2004.) or IGMP (IPv4) [RFC3376] (Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, “Internet Group Management Protocol, Version 3,” October 2002.), and the multicast routing protocol (typically PIM-SM [RFC4601] (Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” August 2006.)) is responsibile for building a Data Distribution Tree (DDT) to ensure that the data are delivered to the receiving host(s).

The procedure for joining an application-level group clearly depends on the application. When IP multicast is used as the data distribution technology, then it is desirable to be able to limit delivery of the network-level multicast data packets to those hosts that have receiving users who are valid members of the application-level group.

The anyone-can-send, anyone-can-receive nature of IP multicast [RFC1112] (Deering, S., “Host extensions for IP multicasting,” August 1989.) has resulted in restricted deployment of multicast distribution technology, since it is impossible to generate any revenue from services based on standard multicast.

However, several pieces of the problem 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] (Hardjono, T. and B. Weis, “The Multicast Group Security Architecture,” March 2004.).

The use of AAA protocols (RADIUS (Rigney, C., Willens, S., Rubens, A., and W. Simpson, “Remote Authentication Dial In User Service (RADIUS),” June 2000.) [RFC2865], Diameter (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) [RFC3588]) to manage network-level access has been standardized. These protocols (especially Diameter) can be extended to permit controlling access to application-level groups.

The requirements for "well-managed" multicast have been stated in [I‑D.ietf‑mboned‑maccnt‑req] (Hayashi, T., Satou, H., Ohta, H., He, H., and S. Vaidya, “Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s),” March 2010.), and a framework for satisfying these requirements with the help of AAA functionality has been described in [I‑D.ietf‑mboned‑multiaaa‑framework] (Satou, H., Ohta, H., Hayashi, T., Jacquenet, C., and H. He, “AAA and Admission Control Framework for Multicasting,” March 2010.).

Finally, work is under way on securing the network infrastructure [I‑D.lebovitz‑kmart‑roadmap] (Lebovitz, G., “Roadmap for Cryptographic Authentication of Routing Protocol Packets on the Wire,” November 2009.) and the exchanges between adjacent multicast routers [I‑D.ietf‑pim‑sm‑linklocal] (Atwood, W., Islam, S., and M. Siami, “Authentication and Confidentiality in PIM-SM Link-local Messages,” December 2009.).

However, one key piece is missing. To minimize the resource wastage that would result from delivering multicast traffic to hosts that have no entitlement to receive them, 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.

2.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119]. They indicate requirement levels for compliant PIM-SM implementations.

3.  Problem Statement

3.1.  Authenticating and Authorizing Multicast Users

The design of IP multicast [RFC1112] (Deering, S., “Host extensions for IP multicasting,” August 1989.) ensures that there is no relationship between the receiving hosts and the sending host(s) in a network-level multicast group. Multicast sending hosts do not even know whether there are receiving hosts or not, much less who they are or whether they are entitled to receive the data. The receiving host issues a network-level "join" on behalf of a receiving user, using IGMP (IPv4) [RFC3376] (Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, “Internet Group Management Protocol, Version 3,” October 2002.) or MLD (IPv6) [RFC3810] (Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” June 2004.), and a designated access router is responsible for grafting itself onto the data distribution tree. The network exercises no control over this process---it is required to provide the data flow.

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, key management and receiving user access control have to be considered as separate problems.

Given the lack of a relationship between the sending user(s) and the receiving user(s), it is difficult to create and enforce an appropriate business model.

3.2.  Re-authentication and Re-authorization

Several scenarios can cause a need for re-authentication and re-authorization:

• When a user changes the group that he/she wishes to attach to;
• When a user changes the access router used for connection (e.g., wireless roaming);
• When a user changes the medium used for physical connectivity (e.g., cellular to wireless, etc.).

3.3.  Accounting

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.

3.4.  Independence of Authentication and Authorization Procedures

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.

3.5.  Coupling of Network and Application Level Controls

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.

3.6.  Separation of Network Access Controls from Group Access Controls

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 must be extended (or alternatives found) if group access must be controlled.

4.  Proposed Solution

Two levels of action are apparent: the action of joining the network-level data distribution tree, and the action of joining the group, with its accompanying security properties.

Joining the data distribution tree should not occur unless and until the receiving user has been authenticated and authorized. One way to ensure that this relationship is enforced is to carry the receiving user authentication material in the network-level join packet.

To support multiple types of authentication methods, the Extensible Authentication Protocol (EAP) [RFC3748] (Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” June 2004.) provides a standardized solution.

To support a method-independent and efficient re-authentication, the EAP Re-Authentication Protocol (ERP) [RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.) provides a possible solution. ERP is applicable for mobile receivers [MulticastMobile] (Islam, S. and W. Atwood, “Receiver Access Control and Secured Handoff in Mobile Multicast using IGMP-AC, LCN 2008, pp. 411--418,” November 2008.).

To permit correlating the join actions (at the group level and the network level) with the accounting procedures, the EAP/ERP packets that are delivered to the access router by the extended network-level join can be forwarded to the local AAA server for a decision, using existing AAA protocols, such as RADIUS or Diameter. In keeping with the statement in [I‑D.ietf‑mboned‑multiaaa‑framework] (Satou, H., Ohta, H., Hayashi, T., Jacquenet, C., and H. He, “AAA and Admission Control Framework for Multicasting,” March 2010.) that "A CP may delegate AAA responsibility to an NSP.", we observe that the NSP can distribute the responsibility among a collection of local AAA servers, and that there is sufficient generality in the AAA architectural model that a wide range of policies could be implemented, in support of a wide range of business models.

5.  Protocol Details

Pending incorporation of the material into this document, readers are invited to access Islam, et al. (Islam, S. and W. Atwood, “Multicast Receiver Access Control by IGMP-AC, Computer Networks, doi://10.1016/j.comnet.2008.12.005,” January 2009.) [MulticastReceiver].

6.  Security Considerations

TBD.

7.  IANA Considerations

This document has no actions for IANA.

8.  Acknowledgements

9.  References

9.1. Normative References

9.2. Informative References

Authors' Addresses