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]
