idnits 2.17.1 draft-atwood-mcast-user-auth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 08, 2010) is 5162 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** 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) == Outdated reference: A later version (-10) exists of draft-ietf-mboned-maccnt-req-09 == Outdated reference: A later version (-12) exists of draft-ietf-mboned-multiaaa-framework-11 == Outdated reference: A later version (-07) exists of draft-ietf-karp-threats-reqs-00 == Outdated reference: A later version (-10) exists of draft-ietf-karp-design-guide-00 Summary: 2 errors (**), 0 flaws (~~), 6 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: Standards Track S. Islam 5 Expires: September 9, 2010 INRS-EMT 6 March 08, 2010 8 Multicast User Authentication 9 draft-atwood-mcast-user-auth-01 11 Abstract 13 RFC 1112 offers no facilities for participant control or accounting. 14 This document explores the requirements for such facilities, and 15 offers a potential solution, based on extending the IGMP and MLD 16 "join" operations to carry EAP and/or ERP packets. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on September 9, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Authenticating and Authorizing Multicast Users . . . . . . 4 62 3.2. Re-authentication and Re-authorization . . . . . . . . . . 4 63 3.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.4. Independence of Authentication and Authorization 65 Procedures . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.5. Coupling of Network and Application Level Controls . . . . 5 67 3.6. Separation of Network Access Controls from Group 68 Access Controls . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 5 70 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 6 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 The procedure for joining a network-level IP multicast group 82 [RFC1112] an open one---a request is made by the receiving host, 83 using MLD (IPv6) [RFC3810] or IGMP (IPv4) [RFC3376], and the 84 multicast routing protocol (typically PIM-SM [RFC4601]) is 85 responsibile for building a Data Distribution Tree (DDT) to ensure 86 that the data are delivered to the receiving host(s). 88 The procedure for joining an application-level group clearly depends 89 on the application. When IP multicast is used as the data 90 distribution technology, then it is desirable to be able to limit 91 delivery of the network-level multicast data packets to those hosts 92 that have receiving users who are valid members of the application- 93 level group. 95 The anyone-can-send, anyone-can-receive nature of IP multicast 96 [RFC1112] has resulted in restricted deployment of multicast 97 distribution technology, since it is impossible to generate any 98 revenue from services based on standard multicast. 100 However, several pieces of the problem have received significant 101 attention in recent years. The problem of security and key 102 management for application-level groups has been explored by the 103 Multicast Security (MSEC) working group, and a framework devised 104 [RFC3740]. 106 The use of AAA protocols (RADIUS [RFC2865], Diameter [RFC3588]) to 107 manage network-level access has been standardized. These protocols 108 (especially Diameter) can be extended to permit controlling access to 109 application-level groups. 111 The requirements for "well-managed" multicast have been stated in 112 [I-D.ietf-mboned-maccnt-req], and a framework for satisfying these 113 requirements with the help of AAA functionality has been described in 114 [I-D.ietf-mboned-multiaaa-framework]. 116 Finally, work is under way on securing the network routing 117 infrastructure [I-D.ietf-karp-threats-reqs] 118 [I-D.ietf-karp-design-guide] [I-D.ietf-karp-framework] and the 119 exchanges between adjacent multicast routers 120 [I-D.ietf-pim-sm-linklocal]. 122 However, one key piece is missing. To minimize the resource wastage 123 that would result from delivering multicast traffic to hosts that 124 have no entitlement to receive them, it is necessary to authenticate 125 and authorize receiving users and to correlate their right to access 126 a group with the action of putting the data on that part of the 127 network that is directly connected to the receiving host. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 134 They indicate requirement levels for compliant PIM-SM 135 implementations. 137 3. Problem Statement 139 3.1. Authenticating and Authorizing Multicast Users 141 The design of IP multicast [RFC1112] ensures that there is no 142 relationship between the receiving hosts and the sending host(s) in a 143 network-level multicast group. Multicast sending hosts do not even 144 know whether there are receiving hosts or not, much less who they are 145 or whether they are entitled to receive the data. The receiving host 146 issues a network-level "join" on behalf of a receiving user, using 147 IGMP (IPv4) [RFC3376] or MLD (IPv6) [RFC3810], and a designated 148 access router is responsible for grafting itself onto the data 149 distribution tree. The network exercises no control over this 150 process---it is required to provide the data flow. 152 Although specifications exist for encrypting the user data, thus 153 ensuring that only legitimate users can decrypt these data, these 154 specifications provide no way to ensure that the data distribution 155 tree is not extended when a non-authorized receiving user makes a 156 request to join the tree. Thus, key management and receiving user 157 access control have to be considered as separate problems. 159 Given the lack of a relationship between the sending user(s) and the 160 receiving user(s), it is difficult to create and enforce an 161 appropriate business model. 163 3.2. Re-authentication and Re-authorization 165 Several scenarios can cause a need for re-authentication and re- 166 authorization: 168 o When a user changes the group that he/she wishes to attach to; 170 o When a user changes the access router used for connection (e.g., 171 wireless roaming); 173 o When a user changes the medium used for physical connectivity 174 (e.g., cellular to wireless, etc.). 176 3.3. Accounting 178 The fact of delivery of group data needs to be recorded, to enable 179 revenue to be earned. This is only one of a range of accounting 180 issues that may need to be addressed, which points to the need for a 181 general solution. 183 3.4. Independence of Authentication and Authorization Procedures 185 There is a wide range of authentication and authorization procedures 186 that may be desired by an Internet Service Provider, including some 187 that may not yet be standardized. This implies the adoption of a 188 very general framework for such procedures. 190 3.5. Coupling of Network and Application Level Controls 192 It is conceivable that a solution could be found for the above issues 193 that would be based on standard network protocols and separate 194 (proprietary or standard) group management protocols. For example, 195 the key management and distribution protocol associated with the 196 application-level group could have authentication as one of its 197 features. However, the separation of the network-level controls from 198 the application-level controls enables a significant class of 199 security attacks. It is therefore important that control of access 200 to the network resources and control of access to the application- 201 level resources be strongly coupled. 203 3.6. Separation of Network Access Controls from Group Access Controls 205 Access to the network is different from access to a group. As an 206 example, the authorization to watch a particular video presentation 207 may be associated with a specific family member, while the 208 authorization to use the network connection may be associated with an 209 entire family (or to anyone present in the house). 211 While existing AAA procedures are designed to control network level 212 access, they must be extended (or alternatives found) if group access 213 must be controlled. 215 4. Proposed Solution 217 Two levels of action are apparent: the action of joining the network- 218 level data distribution tree, and the action of joining the group, 219 with its accompanying security properties. 221 Joining the data distribution tree should not occur unless and until 222 the receiving user has been authenticated and authorized. One way to 223 ensure that this relationship is enforced is to carry the receiving 224 user authentication material in the network-level join packet. 226 To support multiple types of authentication methods, the Extensible 227 Authentication Protocol (EAP) [RFC3748] provides a standardized 228 solution. 230 To support a method-independent and efficient re-authentication, the 231 EAP Re-Authentication Protocol (ERP) [RFC5296] provides a possible 232 solution. ERP is applicable for mobile receivers [MulticastMobile]. 234 To permit correlating the join actions (at the group level and the 235 network level) with the accounting procedures, the EAP/ERP packets 236 that are delivered to the access router by the extended network-level 237 join can be forwarded to the local AAA server for a decision, using 238 existing AAA protocols, such as RADIUS or Diameter. In keeping with 239 the statement in [I-D.ietf-mboned-multiaaa-framework] that "A CP may 240 delegate AAA responsibility to an NSP.", we observe that the NSP can 241 distribute the responsibility among a collection of local AAA 242 servers, and that there is sufficient generality in the AAA 243 architectural model that a wide range of policies could be 244 implemented, in support of a wide range of business models. 246 5. Protocol Details 248 Pending incorporation of the material into this document, readers are 249 invited to access Islam, et al. [MulticastReceiver]. 251 6. Security Considerations 253 TBD. 255 7. IANA Considerations 257 This document has no actions for IANA. 259 8. Acknowledgements 261 9. References 262 9.1. Normative References 264 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 265 RFC 1112, August 1989. 267 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 268 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 270 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 271 Thyagarajan, "Internet Group Management Protocol, Version 272 3", RFC 3376, October 2002. 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, March 1997. 277 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 278 "Remote Authentication Dial In User Service (RADIUS)", 279 RFC 2865, June 2000. 281 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 282 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 284 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 285 Levkowetz, "Extensible Authentication Protocol (EAP)", 286 RFC 3748, June 2004. 288 9.2. Informative References 290 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 291 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 292 Protocol Specification (Revised)", RFC 4601, August 2006. 294 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 295 Architecture", RFC 3740, March 2004. 297 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 298 authentication Protocol (ERP)", RFC 5296, August 2008. 300 [I-D.ietf-mboned-maccnt-req] 301 Hayashi, T., Satou, H., Ohta, H., He, H., and S. Vaidya, 302 "Requirements for Multicast AAA coordinated between 303 Content Provider(s) and Network Service Provider(s)", 304 draft-ietf-mboned-maccnt-req-09 (work in progress), 305 March 2010. 307 [I-D.ietf-mboned-multiaaa-framework] 308 Satou, H., Ohta, H., Hayashi, T., Jacquenet, C., and H. 309 He, "AAA and Admission Control Framework for 310 Multicasting", draft-ietf-mboned-multiaaa-framework-11 311 (work in progress), March 2010. 313 [I-D.ietf-karp-threats-reqs] 314 Lebovitz, G., "The Threat Analysis and Requirements for 315 Cryptographic Authentication of Routing Protocols' 316 Transports", draft-ietf-karp-threats-reqs-00 (work in 317 progress), March 2010. 319 [I-D.ietf-karp-design-guide] 320 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 321 Routing Protocols (KARP) Design Guidelines", 322 draft-ietf-karp-design-guide-00 (work in progress), 323 February 2010. 325 [I-D.ietf-karp-framework] 326 Atwood, W. and G. Lebovitz, "Framework for Cryptographic 327 Authentication of Routing Protocol Packets on the Wire", 328 draft-ietf-karp-framework-00 (work in progress), 329 February 2010. 331 [I-D.ietf-pim-sm-linklocal] 332 Atwood, W., Islam, S., and M. Siami, "Authentication and 333 Confidentiality in PIM-SM Link-local Messages", 334 draft-ietf-pim-sm-linklocal-10 (work in progress), 335 December 2009. 337 [MulticastReceiver] 338 Islam, S. and W. Atwood, "Multicast Receiver Access 339 Control by IGMP-AC, Computer Networks, 340 doi://10.1016/j.comnet.2008.12.005", January 2009. 342 [MulticastMobile] 343 Islam, S. and W. Atwood, "Receiver Access Control and 344 Secured Handoff in Mobile Multicast using IGMP-AC, LCN 345 2008, pp. 411--418", November 2008. 347 Authors' Addresses 349 J. William Atwood 350 Concordia University/CSE 351 1455 de Maisonneuve Blvd, West 352 Montreal, QC H3G 1M8 353 Canada 355 Phone: +1(514)848-2424 ext3046 356 Email: bill@cse.concordia.ca 357 URI: http://users.encs.concordia.ca/~bill 359 Salekul Islam 360 INRS-EMT 361 800 de La Gauchetiere, suite 800 362 Montreal, QC H5A 1K6 363 Canada 365 Email: Salekul.Islam@emt.inrs.ca 366 URI: http://users.encs.concordia.ca/~salek_is