Internet DRAFT - draft-atwood-mboned-mrac-req

draft-atwood-mboned-mrac-req







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

Abstract

   IP multicast offers no facilities for receiver access control or
   accounting.  This document explores the requirements for such
   facilities.

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

   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.





Atwood, et al.           Expires January 5, 2015                [Page 1]

Internet-Draft              MRAC Requirements                  July 2014


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Previous Work . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Reference Architecture  . . . . . . . . . . . . . . . . . . .   6
   4.  Requirements on the Solution  . . . . . . . . . . . . . . . .  10
     4.1.  Application-level constraints . . . . . . . . . . . . . .  10
       4.1.1.  Authenticating and Authorizing Multicast End Users  .  10
       4.1.2.  Group Membership and Access Control . . . . . . . . .  10
       4.1.3.  Independence of Authentication and Authorization
               Procedures  . . . . . . . . . . . . . . . . . . . . .  11
       4.1.4.  Re-authentication and Re-authorization  . . . . . . .  11
       4.1.5.  Accounting  . . . . . . . . . . . . . . . . . . . . .  11
       4.1.6.  Multiple Sessions on One Device . . . . . . . . . . .  11
       4.1.7.  Multiple Independent Sessions on a LAN  . . . . . . .  11
       4.1.8.  Application level interaction must be secured . . . .  12
     4.2.  Network Level Constraints . . . . . . . . . . . . . . . .  12
       4.2.1.  Maximum Compatibility with MLD and IGMP . . . . . . .  12
       4.2.2.  Minimal Modification to MLD/IGMP  . . . . . . . . . .  12
       4.2.3.  Multiple Network Level Joins for End User Device  . .  12
       4.2.4.  NSP Representative Differentiates Multiple Joins  . .  12
       4.2.5.  Network-level Interaction must be secured . . . . . .  12
     4.3.  Interaction Constraints . . . . . . . . . . . . . . . . .  12
       4.3.1.  Coupling of Network and Application Level Controls  .  12
       4.3.2.  Separation of Network Access Controls from Group
               Access Controls . . . . . . . . . . . . . . . . . . .  13
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   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:





Atwood, et al.           Expires January 5, 2015                [Page 2]

Internet-Draft              MRAC Requirements                  July 2014


   o  a request is made by the receiving host, using MLD (IPv6)
      [RFC3810] or IGMP (IPv4) [RFC3376],

   o  the Access Router that receives the request is required to use the
      multicast routing protocol (typically PIM-SM [RFC4601]) to graft
      itself to the network-level multicast data distribution tree.

   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.




Atwood, et al.           Expires January 5, 2015                [Page 3]

Internet-Draft              MRAC Requirements                  July 2014


   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:

   [Solution 1]  Carry the application level rights certification in an
      extended network level join exchange;

   [Solution 2]  Provide separate application level join and network
      level join functions, along with a method for explicitly
      coordinating them.

   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.

2.  Previous Work

   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



Atwood, et al.           Expires January 5, 2015                [Page 4]

Internet-Draft              MRAC Requirements                  July 2014


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



Atwood, et al.           Expires January 5, 2015                [Page 5]

Internet-Draft              MRAC Requirements                  July 2014


   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.

3.  Reference Architecture

   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  | +  .
   |        |     |    .                          |  +     |______| +  .
   |        |     |    ...................        |  +              +  .



Atwood, et al.           Expires January 5, 2015                [Page 6]

Internet-Draft              MRAC Requirements                  July 2014


   | ______ |     | ______               . ______ |  +        ________ .
   | |    | |     | |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:

   Content Provider (CP):  A person or organization that creates content
      for distribution.

   Content Server (CS):  A device that distributes the content via
      multicast data distribution.

   Merchant (MR):  An organization that offers content from one or more
      Content Providers to End Users, to be delivered via the facilities
      of one or more Network Service Providers.

   Financial Institution (FI):  An organization that certifies that a
      particular End User is able to pay for content that has been
      ordered through a Merchant.

   Network Service Provider (NSP):  An organization that delivers
      content from a Content Server to End User Devices.



Atwood, et al.           Expires January 5, 2015                [Page 7]

Internet-Draft              MRAC Requirements                  July 2014


   AAA Server (AAAS):  A device for managing Authentication,
      Authorization and Accounting within the Network Service Provider.

   Access router (AR):  A routing device within the Network Service
      Provider, close to the End User Device, which is responsible for
      adjudicating access rights to the network.

   Network Access Server (NAS)  The enforcement function for managing
      Authentication, Authorization and Accounting within the Network
      Service Provider.  Normally co-located with the Access Router.

   Core Router (CR):  A routing device within the Network Service
      Provider that does not have any End User Device connected to it.

   End User (EU):  A subscriber who wishes to receive multicast data.

   End User Device (EUD):  A device, connected to the Network Service
      Provider via one or more technologies, operated by an End User.

   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.

   Policy flow:  Exchange of policy information.

   Purchase flow:  The transactions related to subscribing to and paying
      for a group session.

   Access Control flow:  The presentation of authentication and
      authorization information.

   Data flow:  The delivery of the subscribed data stream.

   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



Atwood, et al.           Expires January 5, 2015                [Page 8]

Internet-Draft              MRAC Requirements                  July 2014


   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:

   o  A pair of (public and private) keys generated by the Merchant
      exclusively for Alice, plus the digital certificate that
      authenticates the identity of Alice and carries the public key of
      Alice, which is signed by the Merchant or any other well-known
      Certificate Authority

   o  The multicast address (e.g., w.x.y.z:port) to which the data would
      be sent.

   o  If required, a symmetric key to decrypt the multicast data.  (Note
      that the encryption is optional (but likely).  It is also
      unrelated to the Access Control features, and so out of scope for
      this document.)

   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.



Atwood, et al.           Expires January 5, 2015                [Page 9]

Internet-Draft              MRAC Requirements                  July 2014


4.  Requirements on the Solution

   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.

4.1.  Application-level constraints

4.1.1.  Authenticating and Authorizing Multicast End Users

   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.

4.1.2.  Group Membership and Access Control

   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.



Atwood, et al.           Expires January 5, 2015               [Page 10]

Internet-Draft              MRAC Requirements                  July 2014


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

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

   This implies the need for a general solution to the access control
   problem that facilitates re-authentication and re-authorization.

4.1.5.  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 that allows a range of accounting actions to be
   supported.

4.1.6.  Multiple Sessions on One Device

   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.

4.1.7.  Multiple Independent Sessions on a LAN

   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.







Atwood, et al.           Expires January 5, 2015               [Page 11]

Internet-Draft              MRAC Requirements                  July 2014


4.1.8.  Application level interaction must be secured

   Mutual authentication of the NSP Representative and the End User must
   be possible.

4.2.  Network Level Constraints

4.2.1.  Maximum Compatibility with MLD and IGMP

   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.

4.2.2.  Minimal Modification to MLD/IGMP

   The solution developed should minimize any alteration to the
   semantics and the packet layout of MLD and IGMP.

4.2.3.  Multiple Network Level Joins for End User Device

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

4.2.4.  NSP Representative Differentiates Multiple Joins

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

4.2.5.  Network-level Interaction must be secured

   Mutual authentication of the NSP Representative and the End User must
   be possible.

4.3.  Interaction Constraints

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



Atwood, et al.           Expires January 5, 2015               [Page 12]

Internet-Draft              MRAC Requirements                  July 2014


   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.

4.3.2.  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 would have to be extended (or alternatives found) if
   group access needs to be controlled.

5.  Security Considerations

   TBD.

6.  IANA Considerations

   This document has no actions for IANA.

7.  Acknowledgements

8.  References

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





Atwood, et al.           Expires January 5, 2015               [Page 13]

Internet-Draft              MRAC Requirements                  July 2014


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

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, December
              2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
              4303, December 2005.

8.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]
              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)",
              draft-ietf-mboned-maccnt-req-10 (work in progress), August
              2010.

   [I-D.ietf-mboned-multiaaa-framework]
              Satou, H., Ohta, H., Hayashi, T., Jacquenet, C., and H.
              He, "AAA and Admission Control Framework for
              Multicasting", draft-ietf-mboned-multiaaa-framework-12
              (work in progress), August 2010.

   [I-D.liu-mboned-mldauth-ps]
              Liu, Y., Sarikaya, B., and P. Yang, "MLDv2 User
              Authentication Problem Statement", draft-liu-mboned-
              mldauth-ps-00 (work in progress), February 2008.





Atwood, et al.           Expires January 5, 2015               [Page 14]

Internet-Draft              MRAC Requirements                  July 2014


   [I-D.irtf-gsec-igmpv3-security-issues]
              Paridaens, O. and A. Moffaert, "Security issues in
              Internet Group Management Protocol version 3 (IGMPv3)",
              draft-irtf-gsec-igmpv3-security-issues-01 (work in
              progress), March 2002.

   [I-D.draft-ishikawa-igmp-auth]
              Ishikawa, N., Yamanouchi, N., and O. Takahashi, "IGMP
              Extension for Authentication of IP Multicast Senders and
              Receivers", draft-ishikawa-igmp-auth-01 (work in
              progress), August 1998.

   [I-D.irtf-gsec-smrac]
              He, H., "Simple Multicast Receiver Access Control", draft-
              irtf-gsec-smrac-00 (work in progress), November 2001.

   [I-D.he-magma-igmpv3-auth]
              He, H., "Upload Authentication Information Using IGMPv3",
              draft-he-magma-igmpv3-auth-00 (work in progress), November
              2001.

   [I-D.coan-hasm]
              Coan, B., "HASM: Hierarchical Application-Level Secure
              Multicast", draft-coan-hasm-00 (work in progress),
              December 2001.

   [I-D.hayashi-igap]
              Hayashi, T., "Internet Group membership Authentication
              Protocol (IGAP)", draft-hayashi-igap-03 (work in
              progress), August 2003.

   [RFC6862]  Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
              Authentication for Routing Protocols (KARP) Overview,
              Threats, and Requirements", RFC 6862, March 2013.

   [RFC6518]  Lebovitz, G. and M. Bhatia, "Keying and Authentication for
              Routing Protocols (KARP) Design Guidelines", RFC 6518,
              February 2012.

   [RFC5796]  Atwood, W., Islam, S., and M. Siami, "Authentication and
              Confidentiality in Protocol Independent Multicast Sparse
              Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010.

   [RFC6696]  Cao, Z., He, B., Shi, Y., Wu, Q., and G. Zorn, "EAP
              Extensions for the EAP Re-authentication Protocol (ERP)",
              RFC 6696, July 2012.





Atwood, et al.           Expires January 5, 2015               [Page 15]

Internet-Draft              MRAC Requirements                  July 2014


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

   [MulticastSender]
              Islam, S. and W. Atwood, "Sender Access and Data
              Distribution Control for Inter-domain Multicast Groups,
              Computer Networks, doi://10.1016/j.comnet.2010.01.006",
              October 2010.

   [MulticastPANA]
              Islam, S. and W. Atwood, "Multicast Receiver Access
              Control using PANA, 1st Taibah University International
              Conference on Computing and Information Technology (ICCIT
              2012), Al-Madinah Al-Munawwarah, Saudi Arabia, pp. 816--
              821.", March 2012.

   [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: william.atwood@concordia.ca
   URI:   http://users.encs.concordia.ca/~bill


   Salekul Islam
   United International University
   House # 80, Road # 8/A
   Mirza Golam Hafiz Road
   Dhanmondi, Dhaka  1209
   Bangladesh

   Email: salekul@cse.uiu.ac.bd







Atwood, et al.           Expires January 5, 2015               [Page 16]

Internet-Draft              MRAC Requirements                  July 2014


   Bing Li
   Concordia University/CSE
   1455 de Maisonneuve Blvd, West
   Montreal, QC  H3G 1M8
   Canada

   Email: leebingice@gmail.com












































Atwood, et al.           Expires January 5, 2015               [Page 17]