idnits 2.17.1 draft-sarikaya-mboned-mldauth-ps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 429. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 436. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 442. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2007) is 6130 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) == Unused Reference: 'OMA-DRM-Requirement' is defined on line 366, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-mboned-multiaaa-framework-03 == Outdated reference: A later version (-10) exists of draft-ietf-mboned-maccnt-req-04 -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft P. Yang 4 Expires: January 2, 2008 Y. Liu 5 Huawei Technologies 6 July 2007 8 MLDv2 User Authentication Problem Statement 9 draft-sarikaya-mboned-mldauth-ps-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 2, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document defines architectural considerations and problem 43 statement for authenticating the user before entering into a 44 multicast group using the multicast listener discover protocol 45 version 2 (MLDv2). The issues regarding identifying multiple users, 46 authenticating the channel, accounting, mobile multicast and security 47 are identified. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Architectural Considerations . . . . . . . . . . . . . . . . . 4 54 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 55 4.1. Identifying Multicast Users Issues . . . . . . . . . . . . 6 56 4.2. Authenticating Channel Issues . . . . . . . . . . . . . . 6 57 4.3. Accounting Issues . . . . . . . . . . . . . . . . . . . . 6 58 4.4. Mobile Multicasting Issues . . . . . . . . . . . . . . . . 6 59 4.5. EAP Method Issues . . . . . . . . . . . . . . . . . . . . 7 60 4.6. Secure Multicasting Issues . . . . . . . . . . . . . . . . 7 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 6. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 8 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 66 8.2. Informative references . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 68 Intellectual Property and Copyright Statements . . . . . . . . . . 11 70 1. Introduction 72 Currently commercial IP multicast services are not widely deployed 73 and this is partly because of IP multicast model that enables non- 74 secure, non-controlled way for end systems attached to a network to 75 access multicast traffic. Lack of accounting and access control in 76 IP multicast makes it difficult for a service provider to generate 77 enough revenue to sustain multicast services such as IP multicast- 78 based Internet TV and mobile IP TV. 80 Internet Protocol version 6 multicast membership control protocol 81 MLDv2 runs in two parts: host and router [RFC3810]. MLDv2 currently 82 does not support authentication of the user before any membership 83 request is made by the host. 85 Extensible authentication protocol (EAP) is run in a three-party 86 authentication method [RFC3748] between the peer who is to be 87 authenticated, the authenticator and the authentication server (AS) 88 or Authentication, Authorization and Accounting (AAA) server. In 89 most cases, EAP methods generate keys that are used to secure the 90 network access. 92 Functional requirements related to the authentication, authorization 93 and Accounting (AAA) for IP multicasting to be used in commercial 94 services like content delivery services (CDS) have been stated in 95 [I-D.ietf-mboned-maccnt-req]. For CDS, the end user must be 96 authenticated for both the network access and content access. A 97 multi-domain AAA environment where the AAA server located in the 98 network service provider (NSP) has to work with the AAA servers 99 located in the content providers (CP) is needed. Accounting 100 information required to be collected includes joining and leaving the 101 multicast group/channel activities, notifying the user when 102 accounting really starts, and other information. As a first step 103 towards the solution, a framework for specifying the AAA capabilities 104 for the deployment and operation of IP multicast services is being 105 developed [I-D.ietf-mboned-multiaaa-framework]. 107 This document is intended to state the requirements on AAA in well 108 managed IP multicasting services for mobile users accessing real-time 109 content. These are the requirements additional to those described in 110 [I-D.ietf-mboned-maccnt-req] and the framework additional to the one 111 described in [I-D.ietf-mboned-multiaaa-framework]. These 112 requirements are expected to apply to SDOs such as WiMAX 113 [WiMAX-NWG-Stage-2], [WiMAX-NWG-Stage-3]. 115 The document continues in Section 3 with a discussion on the 116 architectural considerations and in Section 4 with the problem 117 statement. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 This document uses the definitions and abbreviations of 126 [I-D.ietf-mboned-maccnt-req] and 127 [I-D.ietf-mboned-multiaaa-framework]. Additional abbreviations are 128 defined here. 129 MS: Mobile Station. 130 BS: Base Station. 131 AR: Access Router. 132 DRM: Digital Rights Management. 133 PIM: Protocol Independent Multicast. 134 MLDv2: Multicast Listener Discovery Protocol version 2. 135 REK: Right Encryption Key. 136 EAP: Extensible Authentication Protocol. 137 HA: Home Agent. 139 3. Architectural Considerations 141 In cellular networks, the mobile stations (MS) establish a cellular 142 link to a base station (BS) which is connected to an IP entity called 143 the access router (AR). However, the multicast content is provided 144 by the content providers and delivered using a multicast routing 145 protocol. The edge router is usually at the leaf of the multicast 146 routing. 148 Figure 1 shows the authentication architecture when no client or 149 network based mobility management is used. 151 The access router is in charge of the memberships to the multicast 152 groups in the local access network and runs MLDv2 with MSs. 154 The edge router runs multicast routing protocols such as Protocol 155 Independent multicast (PIM) in the global Internet. The access 156 router also runs PIM but it is always a leaf node. 158 At the network entry, MS joins a multicast group by running MLDv2 159 with the access router. Due to mobility, MS MAY leave the group 160 anytime at this access router and MAY rejoin the group at a different 161 access router. 163 When EAP is used, the three parties of the authentication are MS as a 164 supplicant, AR as an authenticator, and AAA server as an 165 authentication server. 167 Customer | Access Provider | Service Provider 168 Premise | | (Backend Network) 170 +-----+ +-----+ +------+ +--------+ 171 | MSs |--Cellular--| BS |-----+Access+---+ Edge | Content 172 +-----+ +-----+ |Router| | Router +==>Provider 173 +--+---+ +--------+ 174 +-----+ +-----+ | | +------+ 175 | Mss |-- Link --| BS |--------+ +--|AAA | 176 +-----+ +-----+ |Server| 177 +------+ 179 Figure 1: Authentication Architecture 1 181 Figure 2 shows the authentication architecture when client or network 182 based mobility management is used. 184 When Client Mobile IP or Proxy Mobile IP is used, AR tunnels MS' 185 traffic to the home agent. MS joins multicast groups using its home 186 address. MLDv2 runs between MS and HA. HA takes part in the 187 multicast routing protocol. MS mobility does not affect MLDv2 188 operation and MS continues its membership with the multicast groups 189 regardless of its mobility. 191 When EAP is used, the three parties of the authentication are MS (AR 192 in case of Proxy Mobile IP) as a supplicant, HA as an authenticator, 193 and AAA server as an authentication server. 195 Customer | Access Provider | Service Provider 196 Premise | | (Backend Network) 198 +-----+ +-----+ +------+ +--------+ 199 | MSs |--Cellular--| BS |-----+Access+===+ Home | Content 200 +-----+ +-----+ |Router| | Agent +==>Provider 201 +--+---+ +--------+ 202 +-----+ +-----+ | | +------+ 203 | Mss |-- Link --| BS |--------+ +--|AAA | 204 +-----+ +-----+ |Server| 205 +------+ 207 Figure 2: Authentication Architecture 2 209 4. Problem Statement 211 4.1. Identifying Multicast Users Issues 213 IP multicast provides an efficient mechanism for delivering packets 214 to multiple destinations. However, IP multicast does not support 215 user authentication, and provides by nature a non-secure, non- 216 controlled way for users attached to a network to access multicast 217 traffic. Users can arbitrarily join and leave a multicast group at 218 any time from anywhere. Multicast sources are unable to know when a 219 user joins or leaves a multicast group, or unable to know how many 220 users on the network are receiving multicast traffic at a point of 221 time. Multicast network devices are unable to know whether a user is 222 fully entitled to receive multicast traffic. 224 Lack of information about service users and access control in this 225 model makes it vulnerable to different types of attacks and also 226 creates problems for a service provider to generate enough revenue. 228 4.2. Authenticating Channel Issues 230 There is a need for IP multicast-based services to identify users' 231 privilege to access the corresponding contents when users login 232 multicast-based services system. However, sometimes it is necessary 233 to identify once again users' privilege when the users have already 234 logged in multicast-based services system. For example, in the case 235 of IPTV, some violent movies program of IPTV are not fit for young 236 children. But young children can watch these contents as long as 237 they turn on TV and set-top box. Therefore, there is indeed a need 238 for IPTV system to provide the second-time authentication so that 239 some special channels can be received. 241 4.3. Accounting Issues 243 In IP multicast communication with current standards (e.g., IGMPv3 or 244 MLDv2) the multicast source transports its streaming media content to 245 the multicast router. Then, the multicast router replicates the data 246 to any link which has at least one client requesting the information. 247 In this process, no eligibility check is conducted. the multicast 248 source and the multicast router do not know how many eligible and 249 non-eligible clients are receiving information. In other words, the 250 current standards do not provide multicasting capabilities sufficient 251 to meet the requirements of accounting. 253 4.4. Mobile Multicasting Issues 255 In the mobile IP multicast communication, users will access to the 256 different multicast network. There is a need for multicast network 257 to know whether a user is entitled to receive multicast traffic. 259 4.5. EAP Method Issues 261 EAP methods that do not generate keys MAY be preferred because as a 262 result of authenticating the multicast user, a new key need not be 263 generated. 265 Since no key needs to be generated, key transport at the end of 266 successful EAP method execution is not needed. If the authentication 267 fails, MLDv2 filter mode of the user MUST be set to EXCLUDE. 269 4.6. Secure Multicasting Issues 271 In some cases, for example, IPTV, content encryption scheme is used 272 to achieve Digital Rights Management (DRM) purposes. Legal users 273 must register with the Key Server or Rights Issuer [RFC3740] to 274 download the content keys and Right Encryption Key (REK) before they 275 initiate the data stream service. 277 An access control process is performed during each user's 278 registration process with Rights Issuer/Key Server. A user is 279 authenticated and his/her authorization is checked to decide whether 280 he/she has access to the keys. Through the registration method, 281 unauthorized users can be denied from seeing multicast content even 282 if he/she gets the streaming data. IETF MSEC working group has 283 defined a number of RFCs on multicast key management , 284 [RFC3547][RFC3830] and [RFC4535]. They are used by some DRM 285 specifications. 287 Obviously, multicast content encryption scheme can be used to achieve 288 multicast content access control. It can also be used by Content 289 Provider to learn the dynamic group membership for charging purpose. 290 However, multicast content encryption can not prevent unauthorized 291 access to the network. Unauthorized users may abuse the NSP's 292 network bandwith by joining multiple multicast groups through MLDv2 293 even if they can not consume the multicast data. Network-layer 294 access control is still necessary even application level content 295 encryption is used. Two access control schemes will exist in 296 multicast usage scenarios where DRM is required, e.g., IPTV. 298 However, two separate access control schemes may adversely affect 299 users' usage experience. For example, a user may have to fill in 300 duplicate user&password dialoges when consuming services, or have to 301 separately transact with the Content Provider and NSP for charging 302 issues. Such things are both unnecessarily duplicate and unpleasant. 304 On the other hand, the two access control systems are internally 305 related. Legal users of course should be able to pull down the 306 multicast traffic if they are authorized access to the content 307 encryption keys. Vice versa. 309 Thus, there is a need to unify the application level access control 310 that is achieved by some DRM schemes and network multicast access 311 control in those multicast usage scenarios where use of DRM is 312 mandated. 314 5. Security Considerations 316 This document does not introduce any security threats additional to 317 [I-D.ietf-mboned-maccnt-req]. 319 6. IANA consideration 321 None. 323 7. Acknowledgements 325 8. References 327 8.1. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, March 1997. 332 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 333 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 335 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 336 Levkowetz, "Extensible Authentication Protocol (EAP)", 337 RFC 3748, June 2004. 339 8.2. Informative references 341 [I-D.ietf-mboned-multiaaa-framework] 342 Satou, H., "AAA Framework for Multicasting", 343 draft-ietf-mboned-multiaaa-framework-03 (work in 344 progress), March 2007. 346 [I-D.ietf-mboned-maccnt-req] 347 He, H., "Requirements for Accounting, Authentication and 348 Authorization in Well Managed IP Multicasting Services", 349 draft-ietf-mboned-maccnt-req-04 (work in progress), 350 February 2006. 352 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 353 Architecture", RFC 3740, March 2004. 355 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 356 Group Domain of Interpretation", RFC 3547, July 2003. 358 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 359 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 360 August 2004. 362 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 363 "GSAKMP: Group Secure Association Key Management 364 Protocol", RFC 4535, June 2006. 366 [OMA-DRM-Requirement] 367 "OMA DRM Requirements", , March 2006. 369 [WiMAX-NWG-Stage-2] 370 "WiMAX Forum Network Architecture Stage 2: Architecture 371 Tenets, Reference Model and Reference Points", , 372 March 2007. 374 [WiMAX-NWG-Stage-3] 375 "WiMAX Forum Network Architecture Stage 3: Detailed 376 Protocols and Procedures", , March 2007. 378 Authors' Addresses 380 Behcet Sarikaya 381 Huawei Technologies 382 1700 Alma Dr. Suite 100 383 Plano, TX 75075 385 Phone: +1 972-509-5599 386 Email: sarikaya@ieee.org 388 Peilin Yang 389 Huawei Technologies 390 Huihong Mansion,No.91 Baixia Rd. 391 Nanjing, Jiangsu, China 210001 393 Phone: 86-25-84565464 394 Email: yangpeilin@huawei.com 396 Ya Liu 397 Huawei Technologies 398 HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base Hai-Dian District 399 Beijing, Beijing, China 100085 401 Phone: 86-10-82836072 402 Email: liuya@huawei.com 404 Full Copyright Statement 406 Copyright (C) The IETF Trust (2007). 408 This document is subject to the rights, licenses and restrictions 409 contained in BCP 78, and except as set forth therein, the authors 410 retain all their rights. 412 This document and the information contained herein are provided on an 413 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 414 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 415 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 416 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 417 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 418 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 420 Intellectual Property 422 The IETF takes no position regarding the validity or scope of any 423 Intellectual Property Rights or other rights that might be claimed to 424 pertain to the implementation or use of the technology described in 425 this document or the extent to which any license under such rights 426 might or might not be available; nor does it represent that it has 427 made any independent effort to identify any such rights. Information 428 on the procedures with respect to rights in RFC documents can be 429 found in BCP 78 and BCP 79. 431 Copies of IPR disclosures made to the IETF Secretariat and any 432 assurances of licenses to be made available, or the result of an 433 attempt made to obtain a general license or permission for the use of 434 such proprietary rights by implementers or users of this 435 specification can be obtained from the IETF on-line IPR repository at 436 http://www.ietf.org/ipr. 438 The IETF invites any interested party to bring to its attention any 439 copyrights, patents or patent applications, or other proprietary 440 rights that may cover technology that may be required to implement 441 this standard. Please address the information to the IETF at 442 ietf-ipr@ietf.org. 444 Acknowledgment 446 Funding for the RFC Editor function is provided by the IETF 447 Administrative Support Activity (IASA).