[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01

MBONED Working Group                                           W. Atwood
Internet-Draft                                  Concordia University/CSE
Intended status: Standards Track                                S. Islam
Expires: September 5, 2009                    INRS Energie, Materiaux et
                                                      Telecommunications
                                                          March 04, 2009


                     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.



Atwood & Islam          Expires September 5, 2009               [Page 1]


Internet-Draft        Multicast User Authentication           March 2009


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
























Atwood & Islam          Expires September 5, 2009               [Page 2]


Internet-Draft        Multicast User Authentication           March 2009


1.  Introduction

   The procedure for joining a network-level IP multicast group
   [RFC1112] an open one---a request is made by the receiving host,
   using MLD (IPv6) [RFC3810] or IGMP (IPv4) [RFC3376], and the
   multicast routing protocol (typically PIM-SM [RFC4601]) 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] 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].

   The use of AAA protocols (RADIUS [RFC2865], Diameter [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], and a framework for satisfying these
   requirements with the help of AAA functionality has been described in
   [I-D.ietf-mboned-multiaaa-framework].

   Finally, work is under way on securing the network infrastructure
   [I-D.lebovitz-kmart-roadmap] and the exchanges between adjacent
   multicast routers [I-D.ietf-pim-sm-linklocal].

   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.




Atwood & Islam          Expires September 5, 2009               [Page 3]


Internet-Draft        Multicast User Authentication           March 2009


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 [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] 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] or MLD (IPv6) [RFC3810], 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:

   o  When a user changes the group that he/she wishes to attach to;

   o  When a user changes the access router used for connection (e.g.,
      wireless roaming);

   o  When a user changes the medium used for physical connectivity
      (e.g., cellular to wireless, etc.).




Atwood & Islam          Expires September 5, 2009               [Page 4]


Internet-Draft        Multicast User Authentication           March 2009


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



Atwood & Islam          Expires September 5, 2009               [Page 5]


Internet-Draft        Multicast User Authentication           March 2009


   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] provides a standardized
   solution.

   To support a method-independent and efficient re-authentication, the
   EAP Re-Authentication Protocol (ERP) [RFC5296] provides a possible
   solution.  ERP is applicable for mobile receivers [MulticastMobile].

   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] 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.  [MulticastReceiver].


6.  Security Considerations

   TBD.


7.  IANA Considerations

   This document has no actions for IANA.


8.  Acknowledgements


9.  References







Atwood & Islam          Expires September 5, 2009               [Page 6]


Internet-Draft        Multicast User Authentication           March 2009


9.1.  Normative References

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, August 1989.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

9.2.  Informative References

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC3740]  Hardjono, T. and B. Weis, "The Multicast Group Security
              Architecture", RFC 3740, March 2004.

   [RFC5296]  Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-
              authentication Protocol (ERP)", RFC 5296, August 2008.

   [I-D.ietf-mboned-maccnt-req]
              Ohta, H., Satou, H., Vaidya, S., Hayashi, T., and H. He,
              "Requirements for Multicast AAA coordinated between
              Content Provider(s) and  Network Service Provider(s)",
              draft-ietf-mboned-maccnt-req-07 (work in progress),
              January 2009.

   [I-D.ietf-mboned-multiaaa-framework]
              Jacquenet, C., Hayashi, T., He, H., and H. Satou, "AAA and
              Admission Control Framework for Multicasting",



Atwood & Islam          Expires September 5, 2009               [Page 7]


Internet-Draft        Multicast User Authentication           March 2009


              draft-ietf-mboned-multiaaa-framework-08 (work in
              progress), January 2009.

   [I-D.lebovitz-kmart-roadmap]
              Lebovitz, G., "Roadmap for Cryptographic Authentication of
              Routing Protocol Packets on the  Wire",
              draft-lebovitz-kmart-roadmap-00 (work in progress),
              January 2009.

   [I-D.ietf-pim-sm-linklocal]
              Atwood, W., Islam, S., and M. Siami, "Authentication and
              Confidentiality in PIM-SM Link-local Messages",
              draft-ietf-pim-sm-linklocal-07 (work in progress),
              February 2009.

   [MulticastReceiver]
              Islam, S. and W. Atwood, "Multicast Receiver Access
              Control by IGMP-AC, Computer Networks,
              doi://10.1016/j.comnet.2008.12.005", January 2009.

   [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.


Authors' Addresses

   J. William Atwood
   Concordia University/CSE
   1455 de Maisonneuve Blvd, West
   Montreal, QC  H3G 1M8
   Canada

   Phone: +1(514)848-2424 ext3046
   Email: bill@cse.concordia.ca
   URI:   http://users.encs.concordia.ca/~bill


   Salekul Islam
   INRS Energie, Materiaux et Telecommunications
   800, de La Gauchetiere, suite 800
   Montreal, QC  H5A 1K6
   Canada

   Email: Salekul.Islam@emt.inrs.ca
   URI:   http://users.encs.concordia.ca/~salek_is




Atwood & Islam          Expires September 5, 2009               [Page 8]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/