Network Working Group B. Sarikaya Internet-Draft P. Yang Expires: January 2, 2008 Y. Liu Huawei Technologies July 2007 MLDv2 User Authentication Problem Statement draft-sarikaya-mboned-mldauth-ps-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 2, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Sarikaya, et al. Expires January 2, 2008 [Page 1] Internet-Draft MLDv2 User Authentication July 2007 Abstract This document defines architectural considerations and problem statement for authenticating the user before entering into a multicast group using the multicast listener discover protocol version 2 (MLDv2). The issues regarding identifying multiple users, authenticating the channel, accounting, mobile multicast and security are identified. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architectural Considerations . . . . . . . . . . . . . . . . . 4 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Identifying Multicast Users Issues . . . . . . . . . . . . 6 4.2. Authenticating Channel Issues . . . . . . . . . . . . . . 6 4.3. Accounting Issues . . . . . . . . . . . . . . . . . . . . 6 4.4. Mobile Multicasting Issues . . . . . . . . . . . . . . . . 6 4.5. EAP Method Issues . . . . . . . . . . . . . . . . . . . . 7 4.6. Secure Multicasting Issues . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative references . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Sarikaya, et al. Expires January 2, 2008 [Page 2] Internet-Draft MLDv2 User Authentication July 2007 1. Introduction Currently commercial IP multicast services are not widely deployed and this is partly because of IP multicast model that enables non- secure, non-controlled way for end systems attached to a network to access multicast traffic. Lack of accounting and access control in IP multicast makes it difficult for a service provider to generate enough revenue to sustain multicast services such as IP multicast- based Internet TV and mobile IP TV. Internet Protocol version 6 multicast membership control protocol MLDv2 runs in two parts: host and router [RFC3810]. MLDv2 currently does not support authentication of the user before any membership request is made by the host. Extensible authentication protocol (EAP) is run in a three-party authentication method [RFC3748] between the peer who is to be authenticated, the authenticator and the authentication server (AS) or Authentication, Authorization and Accounting (AAA) server. In most cases, EAP methods generate keys that are used to secure the network access. Functional requirements related to the authentication, authorization and Accounting (AAA) for IP multicasting to be used in commercial services like content delivery services (CDS) have been stated in [I-D.ietf-mboned-maccnt-req]. For CDS, the end user must be authenticated for both the network access and content access. A multi-domain AAA environment where the AAA server located in the network service provider (NSP) has to work with the AAA servers located in the content providers (CP) is needed. Accounting information required to be collected includes joining and leaving the multicast group/channel activities, notifying the user when accounting really starts, and other information. As a first step towards the solution, a framework for specifying the AAA capabilities for the deployment and operation of IP multicast services is being developed [I-D.ietf-mboned-multiaaa-framework]. This document is intended to state the requirements on AAA in well managed IP multicasting services for mobile users accessing real-time content. These are the requirements additional to those described in [I-D.ietf-mboned-maccnt-req] and the framework additional to the one described in [I-D.ietf-mboned-multiaaa-framework]. These requirements are expected to apply to SDOs such as WiMAX [WiMAX-NWG-Stage-2], [WiMAX-NWG-Stage-3]. The document continues in Section 3 with a discussion on the architectural considerations and in Section 4 with the problem statement. Sarikaya, et al. Expires January 2, 2008 [Page 3] Internet-Draft MLDv2 User Authentication July 2007 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document uses the definitions and abbreviations of [I-D.ietf-mboned-maccnt-req] and [I-D.ietf-mboned-multiaaa-framework]. Additional abbreviations are defined here. MS: Mobile Station. BS: Base Station. AR: Access Router. DRM: Digital Rights Management. PIM: Protocol Independent Multicast. MLDv2: Multicast Listener Discovery Protocol version 2. REK: Right Encryption Key. EAP: Extensible Authentication Protocol. HA: Home Agent. 3. Architectural Considerations In cellular networks, the mobile stations (MS) establish a cellular link to a base station (BS) which is connected to an IP entity called the access router (AR). However, the multicast content is provided by the content providers and delivered using a multicast routing protocol. The edge router is usually at the leaf of the multicast routing. Figure 1 shows the authentication architecture when no client or network based mobility management is used. The access router is in charge of the memberships to the multicast groups in the local access network and runs MLDv2 with MSs. The edge router runs multicast routing protocols such as Protocol Independent multicast (PIM) in the global Internet. The access router also runs PIM but it is always a leaf node. At the network entry, MS joins a multicast group by running MLDv2 with the access router. Due to mobility, MS MAY leave the group anytime at this access router and MAY rejoin the group at a different access router. When EAP is used, the three parties of the authentication are MS as a supplicant, AR as an authenticator, and AAA server as an Sarikaya, et al. Expires January 2, 2008 [Page 4] Internet-Draft MLDv2 User Authentication July 2007 authentication server. Customer | Access Provider | Service Provider Premise | | (Backend Network) +-----+ +-----+ +------+ +--------+ | MSs |--Cellular--| BS |-----+Access+---+ Edge | Content +-----+ +-----+ |Router| | Router +==>Provider +--+---+ +--------+ +-----+ +-----+ | | +------+ | Mss |-- Link --| BS |--------+ +--|AAA | +-----+ +-----+ |Server| +------+ Figure 1: Authentication Architecture 1 Figure 2 shows the authentication architecture when client or network based mobility management is used. When Client Mobile IP or Proxy Mobile IP is used, AR tunnels MS' traffic to the home agent. MS joins multicast groups using its home address. MLDv2 runs between MS and HA. HA takes part in the multicast routing protocol. MS mobility does not affect MLDv2 operation and MS continues its membership with the multicast groups regardless of its mobility. When EAP is used, the three parties of the authentication are MS (AR in case of Proxy Mobile IP) as a supplicant, HA as an authenticator, and AAA server as an authentication server. Customer | Access Provider | Service Provider Premise | | (Backend Network) +-----+ +-----+ +------+ +--------+ | MSs |--Cellular--| BS |-----+Access+===+ Home | Content +-----+ +-----+ |Router| | Agent +==>Provider +--+---+ +--------+ +-----+ +-----+ | | +------+ | Mss |-- Link --| BS |--------+ +--|AAA | +-----+ +-----+ |Server| +------+ Figure 2: Authentication Architecture 2 Sarikaya, et al. Expires January 2, 2008 [Page 5] Internet-Draft MLDv2 User Authentication July 2007 4. Problem Statement 4.1. Identifying Multicast Users Issues IP multicast provides an efficient mechanism for delivering packets to multiple destinations. However, IP multicast does not support user authentication, and provides by nature a non-secure, non- controlled way for users attached to a network to access multicast traffic. Users can arbitrarily join and leave a multicast group at any time from anywhere. Multicast sources are unable to know when a user joins or leaves a multicast group, or unable to know how many users on the network are receiving multicast traffic at a point of time. Multicast network devices are unable to know whether a user is fully entitled to receive multicast traffic. Lack of information about service users and access control in this model makes it vulnerable to different types of attacks and also creates problems for a service provider to generate enough revenue. 4.2. Authenticating Channel Issues There is a need for IP multicast-based services to identify users' privilege to access the corresponding contents when users login multicast-based services system. However, sometimes it is necessary to identify once again users' privilege when the users have already logged in multicast-based services system. For example, in the case of IPTV, some violent movies program of IPTV are not fit for young children. But young children can watch these contents as long as they turn on TV and set-top box. Therefore, there is indeed a need for IPTV system to provide the second-time authentication so that some special channels can be received. 4.3. Accounting Issues In IP multicast communication with current standards (e.g., IGMPv3 or MLDv2) the multicast source transports its streaming media content to the multicast router. Then, the multicast router replicates the data to any link which has at least one client requesting the information. In this process, no eligibility check is conducted. the multicast source and the multicast router do not know how many eligible and non-eligible clients are receiving information. In other words, the current standards do not provide multicasting capabilities sufficient to meet the requirements of accounting. 4.4. Mobile Multicasting Issues In the mobile IP multicast communication, users will access to the different multicast network. There is a need for multicast network Sarikaya, et al. Expires January 2, 2008 [Page 6] Internet-Draft MLDv2 User Authentication July 2007 to know whether a user is entitled to receive multicast traffic. 4.5. EAP Method Issues EAP methods that do not generate keys MAY be preferred because as a result of authenticating the multicast user, a new key need not be generated. Since no key needs to be generated, key transport at the end of successful EAP method execution is not needed. If the authentication fails, MLDv2 filter mode of the user MUST be set to EXCLUDE. 4.6. Secure Multicasting Issues In some cases, for example, IPTV, content encryption scheme is used to achieve Digital Rights Management (DRM) purposes. Legal users must register with the Key Server or Rights Issuer [RFC3740] to download the content keys and Right Encryption Key (REK) before they initiate the data stream service. An access control process is performed during each user's registration process with Rights Issuer/Key Server. A user is authenticated and his/her authorization is checked to decide whether he/she has access to the keys. Through the registration method, unauthorized users can be denied from seeing multicast content even if he/she gets the streaming data. IETF MSEC working group has defined a number of RFCs on multicast key management , [RFC3547][RFC3830] and [RFC4535]. They are used by some DRM specifications. Obviously, multicast content encryption scheme can be used to achieve multicast content access control. It can also be used by Content Provider to learn the dynamic group membership for charging purpose. However, multicast content encryption can not prevent unauthorized access to the network. Unauthorized users may abuse the NSP's network bandwith by joining multiple multicast groups through MLDv2 even if they can not consume the multicast data. Network-layer access control is still necessary even application level content encryption is used. Two access control schemes will exist in multicast usage scenarios where DRM is required, e.g., IPTV. However, two separate access control schemes may adversely affect users' usage experience. For example, a user may have to fill in duplicate user&password dialoges when consuming services, or have to separately transact with the Content Provider and NSP for charging issues. Such things are both unnecessarily duplicate and unpleasant. On the other hand, the two access control systems are internally Sarikaya, et al. Expires January 2, 2008 [Page 7] Internet-Draft MLDv2 User Authentication July 2007 related. Legal users of course should be able to pull down the multicast traffic if they are authorized access to the content encryption keys. Vice versa. Thus, there is a need to unify the application level access control that is achieved by some DRM schemes and network multicast access control in those multicast usage scenarios where use of DRM is mandated. 5. Security Considerations This document does not introduce any security threats additional to [I-D.ietf-mboned-maccnt-req]. 6. IANA consideration None. 7. Acknowledgements 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. 8.2. Informative references [I-D.ietf-mboned-multiaaa-framework] Satou, H., "AAA Framework for Multicasting", draft-ietf-mboned-multiaaa-framework-03 (work in progress), March 2007. [I-D.ietf-mboned-maccnt-req] He, H., "Requirements for Accounting, Authentication and Authorization in Well Managed IP Multicasting Services", Sarikaya, et al. Expires January 2, 2008 [Page 8] Internet-Draft MLDv2 User Authentication July 2007 draft-ietf-mboned-maccnt-req-04 (work in progress), February 2006. [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004. [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006. [OMA-DRM-Requirement] "OMA DRM Requirements", , March 2006. [WiMAX-NWG-Stage-2] "WiMAX Forum Network Architecture Stage 2: Architecture Tenets, Reference Model and Reference Points", , March 2007. [WiMAX-NWG-Stage-3] "WiMAX Forum Network Architecture Stage 3: Detailed Protocols and Procedures", , March 2007. Sarikaya, et al. Expires January 2, 2008 [Page 9] Internet-Draft MLDv2 User Authentication July 2007 Authors' Addresses Behcet Sarikaya Huawei Technologies 1700 Alma Dr. Suite 100 Plano, TX 75075 Phone: +1 972-509-5599 Email: sarikaya@ieee.org Peilin Yang Huawei Technologies Huihong Mansion,No.91 Baixia Rd. Nanjing, Jiangsu, China 210001 Phone: 86-25-84565464 Email: yangpeilin@huawei.com Ya Liu Huawei Technologies HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base Hai-Dian District Beijing, Beijing, China 100085 Phone: 86-10-82836072 Email: liuya@huawei.com Sarikaya, et al. Expires January 2, 2008 [Page 10] Internet-Draft MLDv2 User Authentication July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Sarikaya, et al. Expires January 2, 2008 [Page 11]