idnits 2.17.1 draft-atwood-mboned-mrac-req-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 04, 2014) is 3583 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Solution 1' is mentioned on line 152, but not defined == Missing Reference: 'Solution 2' is mentioned on line 155, but not defined == Missing Reference: 'RSVP' is mentioned on line 233, but not defined == Unused Reference: 'RFC2119' is defined on line 621, but no explicit reference was found in the text == Unused Reference: 'RFC3748' is defined on line 631, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'RFC5296' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-ishikawa-igmp-auth' is defined on line 677, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 5296 (Obsoleted by RFC 6696) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONED Working Group W. Atwood 3 Internet-Draft Concordia University/CSE 4 Intended status: Informational S. Islam 5 Expires: January 5, 2015 United International University 6 B. Li 7 Concordia University/CSE 8 July 04, 2014 10 Requirements for IP Multicast Receiver Access Control 11 draft-atwood-mboned-mrac-req-01 13 Abstract 15 IP multicast offers no facilities for receiver access control or 16 accounting. This document explores the requirements for such 17 facilities. 19 Status of This Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 5, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Previous Work . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Reference Architecture . . . . . . . . . . . . . . . . . . . 6 53 4. Requirements on the Solution . . . . . . . . . . . . . . . . 10 54 4.1. Application-level constraints . . . . . . . . . . . . . . 10 55 4.1.1. Authenticating and Authorizing Multicast End Users . 10 56 4.1.2. Group Membership and Access Control . . . . . . . . . 10 57 4.1.3. Independence of Authentication and Authorization 58 Procedures . . . . . . . . . . . . . . . . . . . . . 11 59 4.1.4. Re-authentication and Re-authorization . . . . . . . 11 60 4.1.5. Accounting . . . . . . . . . . . . . . . . . . . . . 11 61 4.1.6. Multiple Sessions on One Device . . . . . . . . . . . 11 62 4.1.7. Multiple Independent Sessions on a LAN . . . . . . . 11 63 4.1.8. Application level interaction must be secured . . . . 12 64 4.2. Network Level Constraints . . . . . . . . . . . . . . . . 12 65 4.2.1. Maximum Compatibility with MLD and IGMP . . . . . . . 12 66 4.2.2. Minimal Modification to MLD/IGMP . . . . . . . . . . 12 67 4.2.3. Multiple Network Level Joins for End User Device . . 12 68 4.2.4. NSP Representative Differentiates Multiple Joins . . 12 69 4.2.5. Network-level Interaction must be secured . . . . . . 12 70 4.3. Interaction Constraints . . . . . . . . . . . . . . . . . 12 71 4.3.1. Coupling of Network and Application Level Controls . 12 72 4.3.2. Separation of Network Access Controls from Group 73 Access Controls . . . . . . . . . . . . . . . . . . . 13 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 79 8.2. Informative References . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 82 1. Introduction 84 When using group communication at the application level, there is a 85 variety of ways that the subscribers to a group (the End Users) can 86 be managed. Encryption can be used at this level to secure the group 87 data, i.e., to prevent a non-subscribing End User from interpreting 88 the resulting group data as they are delivered. 90 When an End User joins an application-level group, this normally 91 implies that the End User Device will join the corresponding network- 92 level IP multicast group. The procedure for effecting this join, as 93 defined in [RFC1112], is an open one: 95 o a request is made by the receiving host, using MLD (IPv6) 96 [RFC3810] or IGMP (IPv4) [RFC3376], 98 o the Access Router that receives the request is required to use the 99 multicast routing protocol (typically PIM-SM [RFC4601]) to graft 100 itself to the network-level multicast data distribution tree. 102 This "unconditional join" implies that there is no access control at 103 the network level, i.e., it is not possible to prevent an arbitrary 104 End User Device from asking that the multicast data stream be 105 delivered to it. 107 The unconditional construction of the data distribution tree is thus 108 entirely receiver-driven, with the result that there is no 109 relationship between the sender and the receiver(s), i.e., the sender 110 is not aware of the identity of the receivers (or even if there are 111 any receivers at all). 113 This can make it very difficult for the Content Provider to generate 114 any revenue from the receivers of IP multicast services. 116 There are some environments where sufficient access control to the 117 multicast data stream can be achieved because of the physical 118 characteristics of the delivery medium (e.g., DSL links, point-to- 119 point links). 121 There are some environments where access control is undesired or 122 irrelevant (e.g., internal corporate distribution, subscriber 123 controlled by a set-top box). 125 There are some environments where the use of multicast data 126 distribution could result in resource savings (for the Content 127 Provider and/or the Network Service Provider), but the Network 128 Service Provider is reluctant to use this technology because of the 129 inability to correlate the receiving End Users with the service being 130 delivered, which makes it very difficult for the Network Service 131 Provider to derive any revenue from the multicast stream. 133 Access control can be viewed at two levels: the application level and 134 the network level. At the application level, an End User will obtain 135 permission to subscribe to a group session. This permission will 136 contain at least two components: a description of how the session is 137 to be accessed and a certification that the End User is authorized to 138 access the session. 140 The certification will be presented at the application level, and if 141 it is valid the End User will be permitted to join the group. 143 At the network level, the session descriptor will be used to issue 144 the network level join, which allows the session data to flow to the 145 end user host. 147 To prevent the end user from presenting an arbitrary session 148 descriptor, it is necessary to coordinate the application level join 149 and the network level join. Two possible ways of achieving the 150 necessary coordination are: 152 [Solution 1] Carry the application level rights certification in an 153 extended network level join exchange; 155 [Solution 2] Provide separate application level join and network 156 level join functions, along with a method for explicitly 157 coordinating them. 159 Effective access control must be secured. It is not meaningful to 160 implement access control without also ensuring that the party making 161 the request for access (i.e., the End User) is authenticated. Since 162 the network-level request is made using MLD/IGMP, this implies that 163 the MLD/IGMP exchanges must also be secured. 165 The overall goal of this work is to list the requirements on a set of 166 mechanisms that allow the Network Service Provider to act on behalf 167 of the Content Provider (since the Network Service Provider has 168 access to information from the End User that the Content Provider 169 does not have access to) to meet the access control and revenue 170 generation goals, while remaining as independent as possible from the 171 specific business model in use. 173 2. Previous Work 175 Several pieces of the solution have received significant attention in 176 recent years. 178 The problem of security and key management for application-level 179 groups has been explored by the Multicast Security (MSEC) working 180 group, and a framework devised [RFC3740]. 182 The use of AAA protocols (RADIUS [RFC2865], Diameter [RFC3588]) to 183 manage network-level access has been standardized. The approach 184 outlined in this document is based on the observation that the AAA 185 protocols (especially Diameter) can be extended to permit controlling 186 access to application-level groups. 188 Some requirements for "well-managed" multicast have been stated in 189 [I-D.ietf-mboned-maccnt-req], and a framework for satisfying these 190 requirements with the help of AAA functionality has been described in 192 [I-D.ietf-mboned-multiaaa-framework]. These documents suggest 193 various business models for the interaction with the End User(s), 194 with (potentially) separated functions corresponding to the Content 195 Provider and the Network Service Provider. 197 The requirements document [I-D.ietf-mboned-maccnt-req] gives general 198 requirements for authentication, authorization, accounting and 199 Quality of Service (QoS) control. It assumes that the required goals 200 can be achieved by integrating AAA with a multicast Content 201 Distribution System, with MLD/IGMP at the edge of the network. The 202 framework document [I-D.ietf-mboned-multiaaa-framework] presents a 203 basic AAA enabled model as well as an extended fully enabled model 204 with resource and admisison control coordination. 206 The approach of extending IGMP to carry authentication information 207 has been proposed for a number of years 208 [I-D.irtf-gsec-igmpv3-security-issues], [I-D.irtf-gsec-smrac], 209 [I-D.he-magma-igmpv3-auth], [I-D.coan-hasm], [I-D.hayashi-igap]. 211 Van Moffaert [I-D.irtf-gsec-igmpv3-security-issues] has proposed a 212 mechanism for securing the IGMPv3 packets using IPsec. The IGMP 213 [RFC3376] specification suggests the use of IPsec with Authentication 214 Header (AH) [RFC4302] to secure the packet exchanges, and notes 215 certain limitations on its use. The MLD [RFC3810] specification is 216 silent on the issue of securing the packets. 218 A receiver access control architecure has been proposed in 219 [MulticastReceiver] and [MulticastPANA]. In addition to the Network 220 Service Provider and Content Provider of the "well-managed multicast" 221 model, it incorporates the concepts of a Merchant (to offer the 222 available services to the End User) and a Financial Institution (to 223 verify the ability of the End User to pay for the desired services). 225 A sender access control architecture has been proposed in 226 [MulticastSender]. 228 [I-D.liu-mboned-mldauth-ps] provides additional requirements for the 229 case where the End User device is mobile. [MulticastMobile] provides 230 a solution for the issue of device mobility, using the EAP 231 Reauthorization Protocol [RFC6696]. 233 As an extensive mechanism for QoS management already exists [RSVP], 234 this part of the problem will be considered to be out-of-scope for 235 this document. 237 Finally, work is under way on securing the network routing 238 infrastructure [RFC6862] [RFC6518]. In particular, securing of the 239 exchanges between adjacent PIM-SM routers is specified in [RFC5796]. 241 However, one key piece is missing. It is necessary to authenticate 242 and authorize receiving users and to correlate their right to access 243 a group with the action of putting the data on that part of the 244 network that is directly connected to the receiving host. These two 245 actions must be done securely, to ensure the correctness of the 246 authentication and authorization actions. As noted in the 247 Introduction, there are two approaches to achieving the correlation: 248 carry the application-level information in the network-level join 249 message, or spearate the two messages and ensure that they are 250 correlated cryptographically. These two approaches will be explored 251 in Section 4, and the choice of one of them will be justified. 252 Ensuring that the network-level join is not done unless the 253 application-level join is authorized also has the desirable side 254 effect of minimizing the resource wastage that would result from 255 delivering multicast traffic to devices whose End Users have no 256 entitlement to receive them. 258 3. Reference Architecture 260 A system for the delivery of multicast data will have interacting 261 components, which are illustrated in Figure 1 to facilitate 262 discussion. Note that only the components that are inside the dotted 263 line are in scope for this document. The components outside the 264 dotted line are presented only to show how the inside components 265 relate to the outside components. 267 __________ __________ __________ 268 | | | | | | 269 | CP |o o o o o o o o o o| MR |+++++++++++++++++++| FI | 270 | |o o o o o o | | | | 271 | | o | |++++++++++++++ | | 272 | | o | |++++++++++++ + | | 273 | | o | | + + | | 274 | | o |________| + + |________| 275 | | o o + + + + 276 | | o o + + + + 277 | | ________________________________ + + + + 278 | | | | + + + + 279 | | | NSP | + + + + 280 | | | ...........................|..+.+.........+..+... 281 | | | . | + + + + . 282 | | | . __________ ______ | + + ________ + . 283 | | | . | | |NAS | | + ++++| ____ | + . 284 | | | . | AAAS | |____| |<-+---->| |EU| | + . 285 | | | . | | |AR | |==+====>| |__| | + . 286 | | | . |________| |____| | + | EUD | + . 287 | | | . | + |______| + . 288 | | | ................... | + + . 290 | ______ | | ______ . ______ | + ________ . 291 | | | | | |NAS | ______ ______ . |NAS | | +++++++++| ____ | . 292 | | CS | |<--->| |____| | | | | . |____| |<--------->| |EU| | . 293 | | | |====>| |AR | | CR | | CR | . |AR | |==========>| |__| | . 294 | |____| | | |____| |____| |____| . |____| | | EUD | . 295 | | | . | |______| . 296 | | | .........|..................... 297 |________| |_______________________________| 299 o o o Policy flow 300 +++++ Purchase flow 301 <---> Access Control flow 302 ====> Data flow 303 ..... Scope of interest 305 CP Content Provider 306 CS Content Server 307 MR Merchant 308 FI Financial Institution 309 EU End User 310 EUD End User Device 311 NSP Network Service Provider 312 AAAS AAA Server 313 AR Access Router 314 NAS Network Access Server 315 CR Core Router 317 Figure 1: Reference Architecture 319 A brief description of the components follows: 321 Content Provider (CP): A person or organization that creates content 322 for distribution. 324 Content Server (CS): A device that distributes the content via 325 multicast data distribution. 327 Merchant (MR): An organization that offers content from one or more 328 Content Providers to End Users, to be delivered via the facilities 329 of one or more Network Service Providers. 331 Financial Institution (FI): An organization that certifies that a 332 particular End User is able to pay for content that has been 333 ordered through a Merchant. 335 Network Service Provider (NSP): An organization that delivers 336 content from a Content Server to End User Devices. 338 AAA Server (AAAS): A device for managing Authentication, 339 Authorization and Accounting within the Network Service Provider. 341 Access router (AR): A routing device within the Network Service 342 Provider, close to the End User Device, which is responsible for 343 adjudicating access rights to the network. 345 Network Access Server (NAS) The enforcement function for managing 346 Authentication, Authorization and Accounting within the Network 347 Service Provider. Normally co-located with the Access Router. 349 Core Router (CR): A routing device within the Network Service 350 Provider that does not have any End User Device connected to it. 352 End User (EU): A subscriber who wishes to receive multicast data. 354 End User Device (EUD): A device, connected to the Network Service 355 Provider via one or more technologies, operated by an End User. 357 These components illustrate separate functionalities. The 358 functionalities may in fact be under separate administrative control, 359 or they may be combined in various ways. 361 Since the end point of the NSP side of several interactions cannot be 362 precisely determined until the detailed design is done, the term "NSP 363 Representative" will be used in this document. A typical NSP 364 Representative will be located on a router or other device that is 365 "close" to the End User Device. 367 There are four kinds of information flow in Figure 1. 369 Policy flow: Exchange of policy information. 371 Purchase flow: The transactions related to subscribing to and paying 372 for a group session. 374 Access Control flow: The presentation of authentication and 375 authorization information. 377 Data flow: The delivery of the subscribed data stream. 379 The operation of the components and the exchange of information may 380 be illustrated through the following example: 382 The Content Provider arranges to provide a live video multicast 383 session for a football match. It contracts with the Merchant to act 384 as its "sales agent", and provides relevant policies concerning the 385 distribution of this particular content stream. The Merchant will 386 offer this content stream to interested subscribers (the End Users), 387 using any available mechanism (in this case, its website, www.mcast- 388 football.com). When an End User (Alice) subscribes to the content, 389 the Merchant will verify with the Financial Institution that Alice is 390 able to pay. Depending on the nature of the realitionship among the 391 Merchant, Alice, and her Financial Institution, the payment may be 392 taken immediately, or it may be defered to some point after delivery 393 of the subscribed stream. The Merchant then issues a "ticket" to 394 Alice, containing the information to identify Alice and information 395 to identify the content stream to which she has subscribed. This 396 could have, for example, the following form: 398 o A pair of (public and private) keys generated by the Merchant 399 exclusively for Alice, plus the digital certificate that 400 authenticates the identity of Alice and carries the public key of 401 Alice, which is signed by the Merchant or any other well-known 402 Certificate Authority 404 o The multicast address (e.g., w.x.y.z:port) to which the data would 405 be sent. 407 o If required, a symmetric key to decrypt the multicast data. (Note 408 that the encryption is optional (but likely). It is also 409 unrelated to the Access Control features, and so out of scope for 410 this document.) 412 Alice has a video client that will process the multicast address and 413 request receipt of the video stream at the network level. However, 414 Alice's right to receive the video stream must also be established 415 (transparently to Alice) before she starts to receive the subscribed 416 stream. The requirements on this verification form the core of the 417 purpose of this document. If the verification is successful, the 418 Access Router will be grafted onto the multicast data distribution 419 tree within the Network Service Provider. The multicast content is 420 streamed to the Network Service Provider at the appropriate time by 421 the Content Server. The Network Service Provider will begin to 422 stream the content to the End User Device once it becomes available. 424 Policies concerning the access to the data stream are exchanged 425 between the Content Provider and the Merchant; they may also be 426 exchanged between the Content Provider and the Network Service 427 Provider. Policies concerning the validation of a "ticket" are 428 exchanged between the Merchant and the Network Service Provider; 429 these may depend in part on the policies that were received by the 430 Merchant from the Content Provider. In total, the policies received 431 by the Network Service Provider are expected to contain sufficient 432 information that the AAAS will be able to validate a ticket without 433 having to refer directly to the Content Provider. 435 4. Requirements on the Solution 437 As noted in the Introduction, access control can be viewed at two 438 levels: the application level and the network level. To ensure that 439 permissions given at the application level are reflected in the 440 corresponding network-level actions, it is necessary to coordinate 441 them. Section 2 has outlined several proposals that have been made 442 in the past for extensions to IGMP to achieve this coordination. 443 However, these proposals each appear to be heavily tied to a 444 particular version of IGMP, and so will be incompatible with future 445 versions of MLD or IGMP. In addition, such proposals are in effect a 446 new version of MLD/IGMP, and even after several years, IGMPv3 is not 447 universally available in mainstream Operating Systems. This makes it 448 more desirable to find a solution to the access control problem that 449 does not require the presence of application-level access control 450 information in MLD (or IGMP) packets. Thus, the approach labeled 451 "Solution 1" in Section 1 is assumed in the following. 453 To allow for independent development of application-level mechanisms 454 and network-level mechanisms, the requirements in this document are 455 based on the assumption that a single method can be used for securing 456 the MLD/IGMP exchanges, where the associated cryptographic parameters 457 for this method are correlated with the authentication and 458 authorization that has already been done at the application level. 460 This leads to a natural separation of the requirements into three 461 categories: constraints on the application-level interactions, 462 constraints on the network-level interactions, and constraints on the 463 coordination between them. 465 4.1. Application-level constraints 467 4.1.1. Authenticating and Authorizing Multicast End Users 469 The design of IP multicast [RFC1112] ensures that there can be no 470 relationship between the End Users and the Content Provider(s). The 471 primary goal is therefore to establish an equivalent relationship 472 between each End User and the associated NSP Representative. 474 4.1.2. Group Membership and Access Control 476 Although specifications exist for encrypting the user data, thus 477 ensuring that only legitimate users can decrypt these data, these 478 specifications provide no way to ensure that the data distribution 479 tree is not extended when a non-authorized receiving user makes a 480 request to join the tree. Thus, "group membership" and "multicast 481 receiver access control" have to be considered (and solved) as 482 separate problems. 484 4.1.3. Independence of Authentication and Authorization Procedures 486 There is a wide range of authentication and authorization procedures 487 that may be desired by an Internet Service Provider, including some 488 that may not yet be standardized. This implies the adoption of a 489 very general framework for such procedures. If a general framework 490 is used, then it is likely to be independent of the specific business 491 model in use by the CP or the NSP. 493 4.1.4. Re-authentication and Re-authorization 495 Several scenarios can cause a need for re-authentication and re- 496 authorization: 498 o When a user changes the group that he/she wishes to attach to; 500 o When a user changes the access router used for connection (e.g., 501 wireless roaming); 503 o When a user changes the medium used for physical connectivity 504 (e.g., cellular to wireless, etc.). 506 This implies the need for a general solution to the access control 507 problem that facilitates re-authentication and re-authorization. 509 4.1.5. Accounting 511 The fact of delivery of group data needs to be recorded, to enable 512 revenue to be earned. This is only one of a range of accounting 513 issues that may need to be addressed, which points to the need for a 514 general solution that allows a range of accounting actions to be 515 supported. 517 4.1.6. Multiple Sessions on One Device 519 Since an End User may wish to join multiple groups simultaneously, it 520 must be possible to associate multiple sessions with a single End 521 User Device. 523 4.1.7. Multiple Independent Sessions on a LAN 525 Since multiple devices on a LAN may have End Users who wish to join 526 the session, it must be posible to differentiate these End Users on 527 the LAN. 529 4.1.8. Application level interaction must be secured 531 Mutual authentication of the NSP Representative and the End User must 532 be possible. 534 4.2. Network Level Constraints 536 4.2.1. Maximum Compatibility with MLD and IGMP 538 The proposed solution should be compatible with all current versions 539 of MLD and IGMP. It is important that a solution not be tied to the 540 semantics or packet format of a particular version of MLD or IGMP. 542 4.2.2. Minimal Modification to MLD/IGMP 544 The solution developed should minimize any alteration to the 545 semantics and the packet layout of MLD and IGMP. 547 4.2.3. Multiple Network Level Joins for End User Device 549 It has to be possible for an End User Device to issue multiple 550 distinct network-level join requests. (This is implied by the 551 constraint in the Application level.) 553 4.2.4. NSP Representative Differentiates Multiple Joins 555 It has to be possible for the NSP Representative to manage multiple 556 Network Level joins for a single shared medium. (This is implied by 557 the constraint in the Application level.) 559 4.2.5. Network-level Interaction must be secured 561 Mutual authentication of the NSP Representative and the End User must 562 be possible. 564 4.3. Interaction Constraints 566 4.3.1. Coupling of Network and Application Level Controls 568 It is conceivable that a solution could be found for the above issues 569 that would be based on standard network protocols and separate 570 (proprietary or standard) group management protocols. For example, 571 the key management and distribution protocol associated with the 572 application-level group could have authentication as one of its 573 features. However, the separation of the network-level controls from 574 the application-level controls enables a significant class of 575 security attacks. It is therefore important that control of access 576 to the network resources and control of access to the application- 577 level resources be strongly coupled. This implies that the method 578 used to cryptographically secure the MLD/IGMP interactions should be 579 strongly coupled to the method used to ensure authentication and 580 authorization at the application level. However, it does not imply 581 that the application-level interaction should be responsible for 582 securing the network-level access, or that the network-level access 583 should carry application-level information. 585 4.3.2. Separation of Network Access Controls from Group Access Controls 587 Access to the network is different from access to a group. As an 588 example, the authorization to watch a particular video presentation 589 may be associated with a specific family member, while the 590 authorization to use the network connection may be associated with an 591 entire family (or to anyone present in the house). 593 While existing AAA procedures are designed to control network level 594 access, they would have to be extended (or alternatives found) if 595 group access needs to be controlled. 597 5. Security Considerations 599 TBD. 601 6. IANA Considerations 603 This document has no actions for IANA. 605 7. Acknowledgements 607 8. References 609 8.1. Normative References 611 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 612 RFC 1112, August 1989. 614 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 615 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 617 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 618 Thyagarajan, "Internet Group Management Protocol, Version 619 3", RFC 3376, October 2002. 621 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 622 Requirement Levels", BCP 14, RFC 2119, March 1997. 624 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 625 "Remote Authentication Dial In User Service (RADIUS)", RFC 626 2865, June 2000. 628 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 629 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 631 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 632 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 633 3748, June 2004. 635 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 636 2005. 638 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 639 4303, December 2005. 641 8.2. Informative References 643 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 644 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 645 Protocol Specification (Revised)", RFC 4601, August 2006. 647 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 648 Architecture", RFC 3740, March 2004. 650 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 651 authentication Protocol (ERP)", RFC 5296, August 2008. 653 [I-D.ietf-mboned-maccnt-req] 654 Hayashi, T., Satou, H., Ohta, H., He, H., and S. Vaidya, 655 "Requirements for Multicast AAA coordinated between 656 Content Provider(s) and Network Service Provider(s)", 657 draft-ietf-mboned-maccnt-req-10 (work in progress), August 658 2010. 660 [I-D.ietf-mboned-multiaaa-framework] 661 Satou, H., Ohta, H., Hayashi, T., Jacquenet, C., and H. 662 He, "AAA and Admission Control Framework for 663 Multicasting", draft-ietf-mboned-multiaaa-framework-12 664 (work in progress), August 2010. 666 [I-D.liu-mboned-mldauth-ps] 667 Liu, Y., Sarikaya, B., and P. Yang, "MLDv2 User 668 Authentication Problem Statement", draft-liu-mboned- 669 mldauth-ps-00 (work in progress), February 2008. 671 [I-D.irtf-gsec-igmpv3-security-issues] 672 Paridaens, O. and A. Moffaert, "Security issues in 673 Internet Group Management Protocol version 3 (IGMPv3)", 674 draft-irtf-gsec-igmpv3-security-issues-01 (work in 675 progress), March 2002. 677 [I-D.draft-ishikawa-igmp-auth] 678 Ishikawa, N., Yamanouchi, N., and O. Takahashi, "IGMP 679 Extension for Authentication of IP Multicast Senders and 680 Receivers", draft-ishikawa-igmp-auth-01 (work in 681 progress), August 1998. 683 [I-D.irtf-gsec-smrac] 684 He, H., "Simple Multicast Receiver Access Control", draft- 685 irtf-gsec-smrac-00 (work in progress), November 2001. 687 [I-D.he-magma-igmpv3-auth] 688 He, H., "Upload Authentication Information Using IGMPv3", 689 draft-he-magma-igmpv3-auth-00 (work in progress), November 690 2001. 692 [I-D.coan-hasm] 693 Coan, B., "HASM: Hierarchical Application-Level Secure 694 Multicast", draft-coan-hasm-00 (work in progress), 695 December 2001. 697 [I-D.hayashi-igap] 698 Hayashi, T., "Internet Group membership Authentication 699 Protocol (IGAP)", draft-hayashi-igap-03 (work in 700 progress), August 2003. 702 [RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and 703 Authentication for Routing Protocols (KARP) Overview, 704 Threats, and Requirements", RFC 6862, March 2013. 706 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 707 Routing Protocols (KARP) Design Guidelines", RFC 6518, 708 February 2012. 710 [RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and 711 Confidentiality in Protocol Independent Multicast Sparse 712 Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010. 714 [RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., and G. Zorn, "EAP 715 Extensions for the EAP Re-authentication Protocol (ERP)", 716 RFC 6696, July 2012. 718 [MulticastReceiver] 719 Islam, S. and W. Atwood, "Multicast Receiver Access 720 Control by IGMP-AC, Computer Networks, doi://10.1016/ 721 j.comnet.2008.12.005", January 2009. 723 [MulticastSender] 724 Islam, S. and W. Atwood, "Sender Access and Data 725 Distribution Control for Inter-domain Multicast Groups, 726 Computer Networks, doi://10.1016/j.comnet.2010.01.006", 727 October 2010. 729 [MulticastPANA] 730 Islam, S. and W. Atwood, "Multicast Receiver Access 731 Control using PANA, 1st Taibah University International 732 Conference on Computing and Information Technology (ICCIT 733 2012), Al-Madinah Al-Munawwarah, Saudi Arabia, pp. 816-- 734 821.", March 2012. 736 [MulticastMobile] 737 Islam, S. and W. Atwood, "Receiver Access Control and 738 Secured Handoff in Mobile Multicast using IGMP-AC, LCN 739 2008, pp. 411--418", November 2008. 741 Authors' Addresses 743 J. William Atwood 744 Concordia University/CSE 745 1455 de Maisonneuve Blvd, West 746 Montreal, QC H3G 1M8 747 Canada 749 Phone: +1(514)848-2424 ext3046 750 Email: william.atwood@concordia.ca 751 URI: http://users.encs.concordia.ca/~bill 753 Salekul Islam 754 United International University 755 House # 80, Road # 8/A 756 Mirza Golam Hafiz Road 757 Dhanmondi, Dhaka 1209 758 Bangladesh 760 Email: salekul@cse.uiu.ac.bd 761 Bing Li 762 Concordia University/CSE 763 1455 de Maisonneuve Blvd, West 764 Montreal, QC H3G 1M8 765 Canada 767 Email: leebingice@gmail.com