Network Working Group Y. Liu
Internet-Draft B. Sarikaya
Expires: August 20, 2008 P. Yang
Huawei Technologies
February 17, 2008
MLDv2 User Authentication Problem Statement
draft-liu-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 August 20, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Liu, et al. Expires August 20, 2008 [Page 1]
Internet-Draft MLDv2 User Authentication February 2008
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. Re-authentication Issues . . . . . . . . . . . . . . . . . 6
4.3. Accounting Issues . . . . . . . . . . . . . . . . . . . . 6
4.4. Mobile Multicasting Issues . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Liu, et al. Expires August 20, 2008 [Page 2]
Internet-Draft MLDv2 User Authentication February 2008
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.
Liu, et al. Expires August 20, 2008 [Page 3]
Internet-Draft MLDv2 User Authentication February 2008
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 client (MIPv6) or
network based mobility management (PMIPv6) is not 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
Liu, et al. Expires August 20, 2008 [Page 4]
Internet-Draft MLDv2 User Authentication February 2008
authentication server.
Customer | Access Provider | Service Provider
Premise | | (Backend Network)
+-----+ +-----+ +------+ +--------+
| MS |--Cellular--| BS |-----+Access+---+ Edge | Content
+-----+ +-----+ |Router| | Router +==>Provider
+--+---+ +--------+
+-----+ +-----+ | | +------+
| MS |-- 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 Mobile IPv6 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
[RFC3775].
Currently Proxy Mobile IPv6 does not support multicasting.
When EAP is used, the three parties of the authentication are MS 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|
+------+
Liu, et al. Expires August 20, 2008 [Page 5]
Internet-Draft MLDv2 User Authentication February 2008
Figure 2: Authentication Architecture 2
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. Re-authentication Issues
It is necessary to re-authenticate end-users when end-users change to
a channel which needs special control. For example, in the case of
IPTV, some channels need parental control. Children can not watch
the channels' contents until they get their parents' permission, that
is to say, children must get password of accessing channels from
their parents.
It is necessary to re-authenticate end-users when end-users roam and
access different networks from one place to another without switching
off user equipment. Network devices(such as switch, router) in a new
access network will be very difficult to identify end-users'
privilege without re-authentication.
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.
Liu, et al. Expires August 20, 2008 [Page 6]
Internet-Draft MLDv2 User Authentication February 2008
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
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 purposes.
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 when 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
Liu, et al. Expires August 20, 2008 [Page 7]
Internet-Draft MLDv2 User Authentication February 2008
issues. Such things are both unnecessarily duplicate and unpleasant.
In fact, the two access control schemes are tightly related. If a
user is authorized access to the multicast content encryption keys,
of course he/she should also be authorized to pull down the multicast
traffic, because key access authorization would not be meaningful
without an access authorization to multicast traffic. On the other
hand, since access to multicast traffic is well controlled by MLD
authentication, if a user is authorized to access the multicast
traffic, he/she must be a legal content consumer; therefore, he/she
should be authorized access to the multicast content encryption keys.
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.
Liu, et al. Expires August 20, 2008 [Page 8]
Internet-Draft MLDv2 User Authentication February 2008
8.2. Informative references
[I-D.ietf-mboned-multiaaa-framework]
Satou, H., "AAA Framework for Multicasting",
draft-ietf-mboned-multiaaa-framework-05 (work in
progress), November 2007.
[I-D.ietf-mboned-maccnt-req]
He, H., "Requirements for Multicast AAA coordinated
between Content Provider(s) and Network Service
Provider(s)", draft-ietf-mboned-maccnt-req-05 (work in
progress), October 2007.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 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.
Liu, et al. Expires August 20, 2008 [Page 9]
Internet-Draft MLDv2 User Authentication February 2008
Authors' Addresses
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
Behcet Sarikaya
Huawei Technologies
1700 Alma Dr. Suite 500
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
Liu, et al. Expires August 20, 2008 [Page 10]
Internet-Draft MLDv2 User Authentication February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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).
Liu, et al. Expires August 20, 2008 [Page 11]