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]