1、AMERICAN NATIONAL STANDARD FOR TELECOMMUNICATIONS ATIS-1000045.2012(R2017) ATIS IDENTITY MANAGEMENT: MECHANISMS AND PROCEDURES STANDARD As a leading technology and solutions development organization, ATIS brings together the top global ICT companies to advance the industrys most-pressing business pr
2、iorities. Through ATIS committees and forums, nearly 200 companies address cloud services, device solutions, M2M communications, cyber security, ehealth, network evolution, quality of service, billing support, operations, and more. These priorities follow a fast-track development lifecyclefrom desig
3、n and innovation through solutions that include standards, specifications, requirements, business use cases, software toolkits, and interoperability testing. ATIS is accredited by the American National Standards Institute (ANSI). ATIS is the North American Organizational Partner for the 3rd Generati
4、on Partnership Project (3GPP), a founding Partner of oneM2M, a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications sectors, and a member of the Inter-American Telecommunication Commission (CITEL). For more information, visit .AMERICAN NAT
5、IONAL STANDARD Approval of an American National Standard requires review by ANSI that the requirements for due process, consensus, and other criteria for approval have been met by the standards developer. Consensus is established when, in the judgment of the ANSI Board of Standards Review, substanti
6、al agreement has been reached by directly and materially affected interests. Substantial agreement means much more than a simple majority, but not necessarily unanimity. Consensus requires that all views and objections be considered, and that a concerted effort be made towards their resolution. The
7、use of American National Standards is completely voluntary; their existence does not in any respect preclude anyone, whether he has approved the standards or not, from manufacturing, marketing, purchasing, or using products, processes, or procedures not conforming to the standards. The American Nati
8、onal Standards Institute does not develop standards and will in no circumstances give an interpretation of any American National Standard. Moreover, no person shall have the right or authority to issue an interpretation of an American National Standard in the name of the American National Standards
9、Institute. Requests for interpretations should be addressed to the secretariat or sponsor whose name appears on the title page of this standard. CAUTION NOTICE: This American National Standard may be revised or withdrawn at any time. The procedures of the American National Standards Institute requir
10、e that action be taken periodically to reaffirm, revise, or withdraw this standard. Purchasers of American National Standards may receive current information on all standards by calling or writing the American National Standards Institute. Notice of Disclaimer Security Architecture. ATIS-1000010 ATI
11、S-1000010.2006 (R2011), Support of Emergency Telecommunications Service in IP Networks. ATIS-1000018 ATIS-1000018, NGN Architecture. ATIS-1000029 ATIS-1000029.2008, Security Requirements for NGN. ATIS-1000030 ATIS-1000030.2008, Authentication and Authorization Requirements for Next Generation Networ
12、k (NGN). ATIS-1000034 ATIS-1000034.2010, Next Generation Network (NGN): Security Mechanisms and Procedures. ATIS-1000035 ATIS-1000035.2009, Next Generation Network (NGN) Identity Management (IdM) Framework. ATIS-1000044 ATIS-1000044.2011, ATIS Identity Management: Requirements and Use Cases Standard
13、. ATIS-1000046 ATIS-1000046, Data Border Functions and Requirements. 1This document is available from the Alliance for Telecommunications Industry Solutions (ATIS), 1200 G Street N.W., Suite 500, Washington, DC 20005. 2 ATIS-1000045.2012(R2017)2.2 ITU-T References2 ITU-T X.509 ITU-T Recommendation X
14、.509 (2008), Information technology Open systems interconnection The Directory: Public-key and attribute certificate frameworks. ITU-T X.1141 ITU-T Recommendation X.1141 (2006), Security Assertion Markup Language (SAML 2.0). ITU-T X.1252 ITU-T Recommendation X.1252 (2010), Baseline identity manageme
15、nt terms and definitions. ITU-T Y.2012 Recommendation Y.2012, Functional Requirements and Architecture of the NGN of Release 1, 09/2006. ITU-T Y.2701 ITU-T Recommendation Y.2701 (2007), Security requirements for NGN release 1. ITU-T Y.2702 ITU-T Recommendation Y.2702 (2008), Authentication and autho
16、rization requirements for NGN release 1. ITU-T Y.2704 ITU-T Recommendation Y.2704 (2010), Security mechanisms and procedures for NGN. ITU-T Y.2720 ITU-T Recommendation Y.2720 (2009), NGN Identity Management Framework. ITU-T Y.2721 ITU-T Recommendation Y.2721 (2010), NGN Identity Management Requireme
17、nts and use cases. 3 Definitions This standard relies on the terms defined in ATIS-1000035 and ITU-T X.1252. 3.1 identity provider (IdP): See identity service provider (IdSP). 3.2 identity service provider (IdSP): An entity that verifies, maintains, manages, and may create and assign identity inform
18、ation of other entities. 3.3 application gateway functional entity (APL-GW-FE): A functional entity that serves as an interworking entity between the applications and the functional entities of the service stratum. 4 Abbreviations This Recommendation uses the following abbreviations and acronyms: AK
19、A Authentication and Key Agreement ASP Application Service Provider AV Authentication VectorBSF Bootstrapping Server Function CK Ciphering Key DBF Data Border Function GBA Generic Bootstrapping Architecture HSS Home Subscriber System IdM Identity ManagementIdP Identity Provider2This document is avai
20、lable from the International Telecommunications Union. ATIS-1000045.2012(R2017) 3 IdSP Identity Service Provider IK Integrity KeyIMPI IP Multimedia Private user Identity IMPU IP Multimedia Public User identity IMS IP Multimedia Subsystem IMSI International Mobile Subscriber Identity IPTV Internet Pr
21、otocol Television ISIM IMS Subscriber Identity Module LDAP Lightweight Directory Access Protocol NAF Network Application Function NGN Next Generation Networks OASIS Organization for the Advancement of Structured Information Standards OTP One Time Password PII Personally Identifiable Information (PII
22、) PKI Public Key Infrastructure SAML Security Assertion Markup Language SIP Session Initiation Protocol SLF Subscriber Locator Function SOAP Simple Object Access Protocol SQL Structured Query Language SSO Single Sign-On UE User EquipmentUICC Universal Integrated Circuit Card UMTS Universal Mobile Te
23、lecommunications System WSS Web Services Security XML eXtensible Markup Language 5 Conventions In this document: The keywords “is required to” indicate a requirement which must be strictly followed and from which no deviation is permitted if conformance to this document is to be claimed. The keyword
24、s “is recommended” indicate a requirement which is recommended but which is not absolutely required. Thus this requirement need not be present to claim conformance. The keywords “is prohibited from” indicate a requirement which must be strictly followed and from which no deviation is permitted if co
25、nformance to this document is to be claimed. The keywords “can optionally” indicate an optional requirement which is permissible, without implying any sense of being recommended. This term is not intended to imply that the vendors implementation must provide the option and the feature can be optiona
26、lly enabled by the network operator/service provider. Rather, it means the vendor may optionally provide the feature and still claim conformance with the specification. In the body of this document and its annexes, the words shall, shall not, should, and may sometimes appear, in which case they are
27、to be interpreted, respectively, as is required to, is prohibited from, is 4 ATIS-1000045.2012(R2017) recommended, and can optionally. The appearance of such phrases or keywords in an annex or in material explicitly marked as informative are to be interpreted as having no normative intent. 6 Mechani
28、sms if not, the authentication procedure is halted. Generates a secret key K. Generates value UprNpuK|K(RAND), sets the parameter pki-auth-user-signature tothat value, and sends it in the body of an HTTP POST message to A-2. The headerContent-Type of the message must be set to the value application/
29、x-www-form-urlencoded.After this step, the A-2 checks whether the response is valid. To that end, A-2 performs the following operations: Looks up the user certificate to obtain the user public key Upu. Decrypts with Uputhe received value C, which is supposedly equal to UprNpuK|K(RAND),to retrieve va
30、lue D|E, where D is supposedly equal to NpuK and E is supposedly equal toK(RAND). Decrypts with the network private key Nprvalue D to obtain K. Decrypts with K value E to obtain RAND. Compares RAND with RAND. If they match, the user has been authenticated and K = K.That is the End-User Function and
31、A-2 now share key K.6. If all the above steps were successful, the A-2 performs the following operations: Generates a SAML assertion setting the attribute Method of the elementto the value sender-vouches. Computes value Ks(K). Includes the assertion in a SAML response. It then delivers the SAML resp
32、onse and thecomputed value Ks(K) over HTTP in the same manner as described for the SAML requestin step 2 (i.e., as part of a query string). The value Ks(K) is carried by the parameter pki-auth-keyinfo To ensure origin authentication and integrity of the URL-encoded message, A-2 signs it asspecified
33、in clause 10.2.4.5.2, Security Considerations, of ITU-T X.1141. The sharedsecret Ksshould be used for signing.After validating the signed URL, AS is assured that the SAML assertion is made by A-2.The AS checks the assertion itself (e.g., to ensure that conditions are met). After that, theAS retrieve
34、s the value Ks(K) and decrypts it using shared Ksto obtain K. At this point, AShas authenticated the End-User Function and both entities share the key K, which can beused for securing communications between them.7. The AS, if it is required by policy for making an authorization decision, obtains inf
35、ormation aboutthe authentication context. In that case A-2 responds with information specified by the Public key X.509 authentication context class ITU-T X.1141.8. AS sends to the End-User Function the result of the authorization decision.6.2.7.4 Additional Requirements for the Entities Participatin
36、g in the Authentication In order to support the described mechanism, the participating entities must meet the following requirements: 6.2.7.4.1 Requirements for the End-User Function The End-User Function must be capable of: Running HTTP client. Securely storing its private key Upr(e.g., on a smart
37、card).ATIS-1000045.2012(R2017) 18 Obtaining the network public key Npu. Performing encryption and decryption. Generating a key K.6.2.7.4.2 Requirements for the Application Server (AS) AS must support SAML ITU-T X.1141. AS must have a shared secret (Ks) with A-2.6.2.7.4.3 Requirements for the A-2 Fun
38、ctional Entity The A-2 functional entity must be able to: Support HTTP protocol. Securely store its private key Npr. Obtain the user public key Upu. Perform encryption and decryption. Generate a random challenge RAND. Support SAML ITU-T X.1141. Have a shared secret (Ks) with AS.6.2.7.4.4 Requirement
39、s for the S-5 Functional Entity The S-5 Functional Entity should be capable of storing the users X.509 certificates or retrieving the certificates from the repository (or both). 6.2.7.5 Additional Requirements for the Interfaces Between the Participating Entities The requirements for the interfaces
40、are as follows: The interface between the End-User Function and the Application Server must support HTTPprotocol b-IETF RFC 2616. The interfaces between the End-User Function and A-2 Functional Entities must support HTTPprotocol b-IETF RFC 2616. The interface between A-2 and Application Server must
41、support SAML ITU-T X.1141. The interface between the A-2 and S-5 Functional Entities must support a query-responsemechanism that allows A-2 to obtain the users X.509 certificates from S-5.6.2.8 Integration of OpenID-based Authentication with the AKA Authentication Integration of AKA authentication w
42、ith OpenID-based authentication allows combination of network-centric and user-centric IdM capabilities. The integration mechanism: Enables the network providers to provide identity services to users accessing Web applications. Can be used to provide users with single sign-on (SSO) across the IMS ne
43、twork and webservices environment with an existing ISIM application, as well as with other SIM applications thatrely on AKA. Allows users to control their public identifiers on the Web as specified in b-OpenID v.2 whileleveraging NGN services. Improves user security by engaging a user-trusted networ
44、k provider in the access control to theWeb applications.19 ATIS-1000045.2012(R2017) Technical Report b-3GPP TR 33.924 describes several solutions for integration of OpenID with AKA that rely on the use of the Bootstrapping Server Function (BSF). This section describes an additional mechanism for int
45、egration of OpenID and AKA. To this end, the OpenID specification calls for a variety of authentication mechanisms. OpenID can interwork with other technologies, such as OAuth, as shown in the Appendix C. 6.2.8.1 Entities Involved in the Authentication & the Information Flow End-User Function: This
46、entity is capable of running a Web client and communicating with theappropriate SIM application. Application server: An entity providing a Web service. It plays a role of a Relying Party. A-2: Application gateway functional entity (APL-GW-FE), which is enabled to serve as an OpenIDb-OpenID v.2 ident
47、ity provider. (The A-2 optionally shares a short-term secret with theApplication server as specified in b-OpenID v.2.) S-5: Service user profile functional entity (SUP-FE).The corresponding entities from the ATIS NGN architecture defined in ATIS-1000018 and ATIS 1000046 are: End-User Function: End U
48、ser Functions. Application Server (AS): Application Server (AS). A-2: Data Border Function (DBF)For simplicity, the abbreviations (AS, A-2, and S-5) from ITU-T Y.2012 are used in the following subsections. The information flow of the authentication procedure is depicted by Figure 8. The procedure of
49、 establishing the short-term signing key between the Application server and A-2 is not shown. The figure shows the basic steps of the procedure for two OpenID options: a. The A-2 and the Application server share a secret.b. The A-2 and the Application server do not share a secret.The common steps for both options are 1 through 6. The step 7a is for option a only. The steps 7b, 8b, and 9b are for option b only. ATIS-1000045.2012(R2017) 20 Figure 8 - Inte
