1、ATIS-0800037 IPTV Device Identity and Device and Subscriber Authentication Interoperability Specification Alliance for Telecommunications Industry Solutions Approved December 16, 2011 Abstract As part of ensuring interoperability across equipment and networks providing IPTV service, it is important
2、to establish an ecosystem where a set of requirements are specified and met for device identities. This specification provides a format and syntax for IPTV device identities to meet the requirements set for these identities. It also profiles the IETF Extensible Authentication Protocol (EAP) to produ
3、ce a new EAP method that enables interoperable device and subscriber authentication, including the binding of a subscriber to one or more devices. ATIS-0800037 ii Foreword The Alliance for Telecommunication Industry Solutions (ATIS) serves the public through improved understanding between carriers,
4、customers, and manufacturers. The IPTV Interoperability Forum (IIF) develops requirements, standards, and specifications that will determine the industrys end-to-end solution for Internet Protocol Television (IPTV). The mandatory requirements are designated by the word shall and recommendations by t
5、he word should. Where both a mandatory requirement and a recommendation are specified for the same criterion, the recommendation represents a goal currently identifiable as having distinct compatibility or performance advantages. The word may denotes an optional capability that could augment the sta
6、ndard. The standard is fully functional without the incorporation of this optional capability. Suggestions for improvement of this document are welcome. They should be sent to the Alliance for Telecommunications Industry Solutions, IIF Staff, 1200 G Street NW, Suite 500, Washington, DC 20005. At the
7、 time it approved this document, the IIF, which is responsible for the development of this standard, had the following members: Alcatel-Lucent ARRIS Group AT Technical Specification Group Services and System Aspects; 3G Security; Security architecture (Release 8), March 2009.423 ATIS-0800034, Secure
8、 Time Interoperability Specification, November 2010.124 IETF RFC 2818, HTTP over TLS, May 2000.225 ATIS-0800001.v003, IPTV DRM Interoperability Requirements (Version 3), not yet published.126 ATIS-0800017.v002, Network Attachment and Initialization of Devices and Client Discovery of IPTV Services, A
9、pril 2009.127 IETF RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, May 2008.23 Definitions, Acronyms, the intent is not to provide an authentication framework for controlling access to network and application resources. The IETF-developed
10、 EAP, defined in RFC 3748 7, provides a framework for network access control and key management that offers the following benefits and flexibilities: ATIS-0800037 7 1. EAP is designed to be carried over a variety of access links: both non-IP links such as Ethernet, IEEE 802.1, and wireless networks
11、as well as IP-Links. Therefore, it does not require a pre-established Transmission Control Protocol (TCP) connection. This makes EAP ideal as an authentication framework that would serve many types of layer 2 technologies deployed by the network providers providing IP connectivity. When deployed ove
12、r an IP link, EAP can be carried over a protocol called Protocol for Carrying Authentication for Network Access (PANA) 10. Figure 2: EAP Signaling over IP Links 2. EAP is designed to be flexible through its request-response mechanism. It can signal the use of various authentication algorithms and ca
13、n accommodate any future use of new algorithms as the existing ones become cryptographically weak or inadequate with respect to the credentials that they protect. Additionally, EAP signaling can encapsulate, for example, a TLS or an Authentication Key Agreement (AKA) exchange between an EAP peer and
14、 an EAP server. In this way, EAP not only accommodates the transport of TLS (exchange of digital certificates for authentication) over an IP link or non-IP link (layer 2), but also provides a flexible means to use certificates as well as other credentials such as Subscriber Identity Modules (SIMs) f
15、or subscriber authentications. 3. Depending on the choice of authentication algorithm and exchange, EAP can provide unidirectional or mutual authentication based on the network security requirements and policies. EAP can also provide different authentication mechanisms in each direction - e.g. using
16、 certificates (EAP-TLS) in one direction and passwords (EAP-TTLS) or pre-shared keys in the other. 4. EAP is designed as a two-party protocol i.e., EAP signaling is performed between an EAP peer and an EAP server acting as authenticator. However, EAP can also be deployed in a pass-through mode (e.g.
17、, three parties), where an edge entity acts as a pass-through between an EAP peer and a backend EAP server acting as authenticator. Many modern topologies rely on a scalable model, where simple, low-cost edge devices are deployed in large numbers, acting as enforcement points for network policies, s
18、uch as security, quality of service, and bandwidth control policies. In the “pass-through” mode, EAP can be configured to simply block all traffic except EAP signaling, until it receives a directive from a backend server that the peer is fully authenticated (EAP Success Message). In a pass-through m
19、ode, the backend EAP server has access to peer (e.g., device) credential databases and performs the server-side operations of the authentication algorithm. This avoids the need to upgrade crypto-algorithms and credentials at low-cost edge devices acting as pass-through authenticators. This also supp
20、orts mobility, because if the subscriber moves to another point, an association with the new edge entity can be easily established through a simple mediation of the central entity. Since the pass-through mode has the advantage that an EAP server can be implemented within an Authentication, Authoriza
21、tion, and Accounting (AAA) server and, since the AAA server also has access to service profiles, it could potentially perform authorization functions following a successful authentication. Implementing this model, however, means that EAP signaling needs to be adapted to the type of link it is carrie
22、d over. For instance, signaling between an EAP peer and a pass-through authenticator could be carried over the access technology, while signaling between the pass-through authenticator and the EAP server can be carried over a AAA protocol (such as RADIUS or Diameter). ATIS-0800037 8 EAP ServerAAA se
23、rverProvider DomainEAP/AAAAuthenticatorAuthenticatorEAP peerEAP/PANA/IPEAP peerEAP/L2Figure 3: EAP Signaling Using a Pass-through Authenticator EAP provides a key management framework 8, where the two parties completing the initial authentication exchange can use the result of the authentication exc
24、hange to create more keys for the purpose of creating further security associations between the device and the network. The EAP key management framework has specific guidelines about the export of various EAP master session keys. This is especially useful when such keys are used to protect subsequen
25、t signaling or sensitive data. When available, a device secure execution environment (e.g., the Secure Execution Environment SEE as described in ATIS-0800014 16 and ATIS-8000024 5) can leverage this EAP characteristic to further enhance the security of key management and associated signaling. 4.3 Su
26、bscriber Authentication and Binding Although IPTV service and content are delivered to the device, they should only be provided to a paying subscriber. Subscriber identification and authentication is required to perform authorization and billing functions. A subscriber profile is created by the serv
27、ice provider at the time of registration for service or Content on Demand (COD) purchase. The profile could, aside from type of content and service, include a subscriber identity and credential for later authentication signaling. The format and syntax of subscriber identity may vary from service pro
28、vider to service provider and therefore may be difficult to standardize. The credentials for subscriber authentication are typically designed to provide easy human reference, which from a cryptographic point of view may be weak. This is explained in more detail later in this specification. This mean
29、s subscriber authentication exchange may require additional cryptographic protection to ensure adequate protection for subscriber and service provider business interests. Such additional protection can be provided, for example, through secure tunnels that are established during the device authentica
30、tion process. However, to ensure the tunnel itself is not hijacked by an illegitimate device, it is important to bind the protected subscriber identity to the identity of the device providing the tunnel. Aside from confidentiality concerns, billing is another reason for providing identity binding. B
31、illing is typically performed using subscriber identity, while most IP-based accounting clients may only have the capability to report accounting records associated with a device identity. To accommodate charging functions that translate device information to billing information, the accounting syst
32、em must be able to perform (or have access to a subscriber management system that holds) a binding between subscriber identity and device identity. Finally, another reason to perform identity binding is to prevent service theft through password sharing. There is a possibility for subscribers to hand
33、 out their credentials to other persons with legitimate devices to access password-protected IPTV services. Such password sharing must be prevented unless it is explicitly allowed by the service provider service policy, so that each subscriber is allowed to use only one device to access the same con
34、tent at any given time. Binding of a device identity to a subscriber identity and allowing only one device binding for each subscriber identity would prevent such password sharing. ATIS-0800037 9 As mentioned earlier, the exact definition of subscriber identity is determined by each service provider
35、s policy. Typically, the service provider assigns a subscriber identity to the subscriber at the time of registration. The specification of subscriber authentication and authorization in this document is not directly dependent on the exact format and syntax of subscriber identity, as it is expected
36、that these mechanisms will be designed in such a way that this information can be carried in an opaque manner. An example of a possible subscriber identity format to indicate the affiliation of an individual subscriber with a service provider could be: “individual_idservice_provider_”. It is importa
37、nt to make a distinction between a user identity and a subscriber identity to allow multiple users within a family or a team to enjoy the services of a subscription. In that case, the user identity/ password may simply be used locally at the device rather than transmitted to the service provider aut
38、hentication/authorization server to simplify the authentication and subscriber databases and procedures. However, in this specification, a further distinction between users associated with a single subscriber ID is out of scope. 4.3.1 Subscriber Credentials For ease of use, “weak passwords” are ofte
39、n used as subscriber credentials. Weak passwords are those that adhere to proper password creation rules, such as the use of more than eight characters and a mix of alphanumeric and other ASCII characters, but are non-random, easy to guess, and subject to dictionary attacks. This is the opposite of
40、“strong passwords”, which are randomly generated to provide a minimum amount of entropy, but may be difficult to be remembered by a human. Subscriber authentication must accommodate the use of weak passwords while protecting sensitive subscriber information and credentials. This means the subscriber
41、 authentication cannot be protected by the use of passwords only, but must be protected by other security means, such as a secure TLS tunnel, especially when such information is being carried over the access network between IPTV receiving devices and the SP-AA. 4.4 Application Security Bootstrapping
42、 Given that the initial authentication and authorization process is a lengthy and CPU-intensive process that also requires access to device and subscriber information, and there can be a large number of application servers that come in contact with the end device and subscriber, it is more scalable
43、to perform such authentication and authorization with a dedicated centralized server that then assists all other application servers with their security needs. An example of such an application server is a Hypertext Transfer Protocol (HTTP) streaming server that is required to protect the HTTP trans
44、actions by using TLS (i.e., by establishing an HTTPS session 24). Such a server could simply rely on the knowledge at the central authentication server about the state of authentication of the device and subscriber before engaging in TLS establishment. Such knowledge can be conveyed to the applicati
45、on server either through use of tokens or through use of keying material that is known only by an authenticated device/subscriber. Such keying material could be created as a result of an integrated authentication and key management design involving the authentication server. Note that Conditional Ac
46、cess Systems/Digital Rights Management (CAS/DRM ) mechanisms relying on initial authentication and authorization of a device and subscriber are other examples using this same concept. In the case of the HTTP streaming server, deploying TLS by itself for the protection of the HTTP session between the
47、 HTTP servers and the device does not provide adequate authorization for guarding the service providers business interests. This is further illustrated below. 1. The authentication during the TLS handshake exchange is in many cases unilateral, meaning that while the server presents its certificate t
48、o the client to authenticate the server, the client authentication to the server using the client certificate is optional. Even in exchanges where the client does perform certificate-based authentication, the purpose of authentication is only to deter man-in-the-middle attacks in conjunction with TL
49、S session key exchange and not for authentication and authorization of the device for receiving content. 2. TLS is typically performed for establishing session keys to protect the HTTP transactions between the HTTP server and client. Closing the TLS session will end the HTTPS session. The result of TLS (a successful authentication) is not recorded anywhere and cannot be used for other purposes, as the HTTP server is designed to provide HTTP service, not authentication or authorization service. 3. The authorization for the HTTP server to establish HTTPS wi
