1、 International Telecommunication Union ITU-T J.366.9TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (11/2006) SERIES J: CABLE NETWORKS AND TRANSMISSION OF TELEVISION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS IPCablecom IPCablecom2 IP Multimedia Subsystem (IMS): Generic authentication architectur
2、e specification ITU-T Recommendation J.366.9 ITU-T Rec. J.366.9 (11/2006) i ITU-T Recommendation J.366.9 IPCablecom2 IP Multimedia Subsystem (IMS): Generic authentication architecture specification Summary This Recommendation describes the security features and a mechanism to bootstrap authenticatio
3、n and key agreement for application security. Source ITU-T Recommendation J.366.9 was approved on 29 November 2006 by ITU-T Study Group 9 (2005-2008) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. J.366.9 (11/2006) FOREWORD The International Telecommunication Union (ITU) is the United N
4、ations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommuni
5、cations on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedu
6、re laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecom
7、munication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the Recommendation is achieved when all of these
8、mandatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU dr
9、aws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members
10、or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not re
11、present the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2007 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. ITU-T Rec. J.366.9 (1
12、1/2006) iii CONTENTS Page 1 Scope 1 1.1 Relationship between IPCablecom 2.0 and 3GPP IMS 1 1.2 Scope of the present Recommendation 1 2 References. 1 3 Definitions, abbreviations symbols and conventions . 2 3.1 Definitions 2 3.2 Abbreviations . 2 3.3 Symbols 2 3.4 Conventions 2 4 Generic Bootstrappin
13、g Architecture. 2 4.1 Reference model. 2 4.2 Network elements. 2 4.3 Bootstrapping architecture and reference points 3 4.4 Requirements and principles for bootstrapping 4 4.5 Procedures 5 5 UICC-based enhancements to Generic Bootstrapping Architecture (GBA_U) . 6 6 HTTP Digest Over TLS enhancements
14、to Generic Bootstrapping Architecture (GBA_H) 6 6.1 Bootstrapping procedure 6 6.2 Procedures using bootstrapped Security Association. 8 Annex A Void . 10 Annex B (normative) Specification of the key derivation function KDF. 10 B.2 Generic key derivation function . 10 B.3 NAF specific key derivation
15、in GBA, and GBA_U, and GBA_H. 10 Annex C (informative) Void. 11 Annex D (informative) Dialog example for user selection of UICC application used in GBA 11 Annex E (normative) TLS profile for securing Zn reference point . 12 Annex F (informative) Handling of TLS certificates 12 Annex G (normative) GB
16、A_U UICC-ME interface. 12 Annex H (normative) Ua security protocol identifier. 12 ITU-T Rec. J.366.9 (11/2006) 1 ITU-T Recommendation J.366.9 IPCablecom2 IP Multimedia Subsystem (IMS): Generic authentication architecture specification 1 Scope 1.1 Relationship between IPCablecom 2.0 and 3GPP IMS The
17、Third Generation Partnership Project (3GPP) has developed the specification in a form optimized for the wireless environment. This Recommendation references the ETSI version of the 3GPP specification and specifies only the modifications necessary to optimize it for the cable environment. Additions a
18、re shown in blue underline and deletions in red strikethrough. It is an important objective of this work that interoperability between IPCablecom 2.0 and 3GPP IMS is provided. IPCablecom 2.0 is based upon 3GPP IMS, but includes additional functionality necessary to meet the requirements of cable ope
19、rators. Recognizing developing converged solutions for wireless, wireline, and cable, it is expected that further development of IPCablecom 2.0 will continue to monitor and contribute to IMS developments in 3GPP, with the aim of alignment of 3GPP IMS and IPCablecom 2.0. The modifications to ETSI TS
20、133.220 V6.7.0 (2005-12), Generic Authentication Architecture (GAA); Generic bootstrapping architecture are listed below. 1.2 Scope of the present Recommendation The present document describes the security features and a mechanism to bootstrap authentication and key agreement for application securit
21、y from the 3GPP AKA mechanism and from HTTP Digest over TLS. Candidate applications to use this bootstrapping mechanism include but are not restricted to subscriber certificate distribution TS 33.221 5. Subscriber certificates support services whose provision mobile operator assists, as well as serv
22、ices that mobile operator provides. The scope of this specification includes a generic AKA bootstrapping function, an HTTP Digest over TLS function, an architecture overview and the detailed procedures on how to bootstrap the credential. Clause 4 of this specification describes a mechanism, called G
23、BA_ME, to bootstrap authentication and key agreement, which does not require any changes to the UICC. Clause 5 of this specification describes a mechanism, called GBA_U, to bootstrap authentication and key agreement, which does require changes to the UICC, but provides enhanced security by storing c
24、ertain derived keys on the UICC. Clause 6 of this specification describes the HTTP Digest over TLS mechanism. 2 References 27 IETF RFC 4279 (2005): “Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)“.IETF Internet-Draft: “Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)“,
25、December 2005, URL: http:/www.ietf.org/internet-drafts/draft-ietf-tls-psk-09.txt. 30 IETF RFC 2782 (2000): “A DNS RR for specifying the location of services (DNS SRV).“ 31 IETF RFC 1750 (1994): “Randomness Recommendations for Security“. 2 ITU-T Rec. J.366.9 (11/2006) 3 Definitions, abbreviations sym
26、bols and conventions 3.1 Definitions HTTP Digest over TLS-based GBA: This is a GBA that uses HTTP Digest over TLS. 3.2 Abbreviations GBA_H GBA with HTTP Digest over TLS enhancements 3.3 Symbols 3.4 Conventions 4 Generic Bootstrapping Architecture 4.1 Reference model 4.2 Network elements 4.2.1 Bootst
27、rapping server function (BSF) A generic Bootstrapping Server Function (BSF) and the UE shall mutually authenticate using the AKA protocol or the HTTP Digest over TLS mechanisms, and agree on session keys that are afterwards applied between UE and a Network Application Function (NAF). The BSF shall r
28、estrict the applicability of the key material to a specific NAF by using the key derivation procedure as specified in Annex B. The key derivation procedure may be used with multiple NAFs during the lifetime of the key material. The lifetime of the key material is set according to the local policy of
29、 the BSF. The generation of key material is specified in clause 4.5.2. The BSF shall be able to acquire the GBA user security settings (GUSS) from the HSS. The BSF shall be able to keep a list, which assigns NAFs to NAF Groups. This list is used to select if any and which application-specific USS wi
30、thin GUSS is valid for a certain NAF. NOTE 1 The operator does the assignment of NAFs to NAF Groups. NAF Group definitions in HSS and all connected BSFs belonging to the same operators network shall be equal (cf., clause 4.2.3). As these network elements belong to the same operators network, standar
31、dization of the NAF Group definitions themselves is not necessary in 3GPP. NOTE 2 The NAF grouping may be e.g., “home“ and “visited“. It allows the BSF to send USSs for the same application with e.g., different authorization flags to different NAFs, e.g., in home network and visited networks. The NA
32、F e.g., in visited network indicates only the requested application, but it is unaware of the grouping in home network of the subscriber. 4.2.2 Network application function (NAF) ITU-T Rec. J.366.9 (11/2006) 3 4.2.2a Diameter proxy (D-Proxy) 4.2.3 HSS 4.2.4 UE The required functionalities from the U
33、E that supports a UICC are: the support of HTTP Digest AKA protocol; the capability to use both a USIM and an ISIM in bootstrapping; the capability to select either a USIM or an ISIM to be used in bootstrapping, when both of them are present; the capability for a Ua application on the ME to indicate
34、 to the GBA Function on the ME the type or the name of UICC application to use in bootstrapping (see clause 4.4.8); the capability to derive new key material to be used with the protocol over Ua interface from CK and IK; support of NAF-specific application protocol (For an example see TS 33.221 5).
35、The required functionalities from the UE that does not support a UICC are: the support of HTTP Digest over TLS; support of NAF-specific application protocol defined in TS 33.222 25). A UE that supports a UICC may support the HTTP Digest over TLS functionality. A GBA-aware ME with a UICC shall suppor
36、t both GBA_U, as specified in clause 5.2.1 and GBA_ME procedures, as specified in clause 4.5. 4.2.5 SLF 4.3 Bootstrapping architecture and reference points 4.3.1 Reference point Ub The reference point Ub is between the UE and the BSF. Reference point Ub provides mutual authentication between the UE
37、and the BSF. It allows the UE to bootstrap the session keys based on 3GPP AKA infrastructure or by using HTTP Digest over TLS mechanism. The HTTP Digest AKA protocol, which is specified in RFC 3310 4, is used on the reference point Ub. It is based on the 3GPP AKA TS 33.102 2 protocol. The interface
38、to the USIM is as specified in TS 31.102 1 and to the ISIM is as specified in TS 31.103 10. The HTTP Digest protocol, which is specified in RFC 2617 3, in conjunction with TLS is also used on the reference point Ub. 4.3.2 Reference point Ua The reference point Ua carries the application protocol, wh
39、ich is secured using the keys material agreed between UE and BSF as a result of the run of HTTP Digest AKA or HTTP Digest over TLS over reference point Ub. For instance, in the case of support for subscriber certificates TS 33.221 5, it is a protocol, which allows the user to request certificates fr
40、om the NAF. In this case the NAF would be the PKI portal. 4 ITU-T Rec. J.366.9 (11/2006) 4.3.3 Reference point Zh 4.3.4 Reference point Zn The reference point Zn is used by the NAF to fetch the key material agreed during a previous HTTP Digest AKA protocol or HTTP Digest over TLS run over the refere
41、nce point Ub from the UE to the BSF. It is also used to fetch application-specific user security settings from the BSF, if requested by the NAF. 4.3.5 Reference point Dz 4.4 Requirements and principles for bootstrapping 4.4.1 Access Independence 4.4.2 Authentication methods Authentication between th
42、e UE and the BSF shall not be possible without a valid cellular subscription. Authentication shall be based on the 3GPP AKA protocol or HTTP Digest over TLS. 4.4.3 Roaming 4.4.4 Requirements on reference point Ub The requirements for reference point Ub are: the BSF shall be able to identify the UE;
43、the BSF and the UE shall be able to authenticate each other based on AKA; the BSF and the UE shall be able to authenticate each other based on HTTP Digest over TLS; the BSF shall be able to send a bootstrapping transaction identifier to the UE; the UE and the BSF shall establish shared keys; the BSF
44、 shall be able to indicate to the UE the lifetime of the key material. The key lifetime sent by the BSF over Ub shall indicate the expiry time of the key. NOTE This does not preclude a UE to refresh the key before the expiry time according to the UEs local policy. 4.4.5 Requirements on reference poi
45、nt Zh The requirements for reference point Zh are: mutual authentication, confidentiality and integrity shall be provided; NOTE 1 This requirement may be fulfilled by physical or proprietary security measures if BSF and HSS are located within the same operators network. the BSF shall be able to send
46、 bootstrapping information request concerning a subscriber; the HSS shall be able to send one 3GPP AKA vector at a time to the BSF; the HSS shall be able to send HTTP Digest credentials to the BSF; the HSS shall be able to send the complete set of subscribers GBA user security settings needed for se
47、curity purposes to the BSF; ITU-T Rec. J.366.9 (11/2006) 5 NOTE 2 If subscribers GUSS is updated in HSS, this is not propagated to the BSF. The GUSS in the BSF is updated when the BSF next time fetches the authentication vectors and GUSS from the HSS over Zh reference point as part of the bootstrapp
48、ing procedure. no state information concerning bootstrapping shall be required in the HSS; all procedures over reference point Zh shall be initiated by the BSF; the number of different interfaces to HSS should be minimized. 4.4.6 Requirements on reference point Zn 4.4.7 Requirements on Bootstrapping
49、 Transaction Identifier 4.4.8 Requirements on selection of UICC application and related keys The requirements in this clause apply when a UICC is present in the UE. When several applications are present on the UICC, which are capable of running AKA, then the ME shall choose one of these UICC applications for performing the GBA procedures specified in this document in the following order of preference: 4.4.9 Requirements on reference point Ua 4.4.10 Requirements on reference point Dz 4.5 Pr
