ATIS 1000045-2012 ATIS Identity Management Mechanisms and Procedures Standard.pdf

《ATIS 1000045-2012 ATIS Identity Management Mechanisms and Procedures Standard.pdf》由会员分享，可在线阅读，更多相关《ATIS 1000045-2012 ATIS Identity Management Mechanisms and Procedures Standard.pdf（48页珍藏版）》请在麦多课文档分享上搜索。

1、 AMERICAN NATIONAL STANDARD FOR TELECOMMUNICATIONS ATIS-1000045.2012 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 prioriti

2、es. 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 design and

3、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 Generation Par

4、tnership 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 NATIONAL

5、 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, substantial ag

6、reement 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 use o

7、f 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 National

8、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 Insti

9、tute. 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 require tha

10、t 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 ATIS-100

11、0010.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 Network (NG

12、N). 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. ATI

13、S-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. ATIS-1000045.2012 2 2.2 ITU-T References2ITU-T X.509 ITU-T Recommendation X.509 (2008),

14、 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 management terms and

15、 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 authorization req

16、uirements 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 Requirements and use

17、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 information of oth

18、er 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: AKA Authentica

19、tion and Key Agreement ASP Application Service Provider AV Authentication Vector BSF Bootstrapping Server Function CK Ciphering Key DBF Data Border Function GBA Generic Bootstrapping Architecture HSS Home Subscriber System IdM Identity Management IdP Identity Provider 2This document is available fro

20、m the International Telecommunications Union. ATIS-1000045.2012 3 IdSP Identity Service Provider IK Integrity Key IMPI IP Multimedia Private user Identity IMPU IP Multimedia Public User identity IMS IP Multimedia Subsystem IMSI International Mobile Subscriber Identity IPTV Internet Protocol Televisi

21、on 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) PKI Public Ke

22、y 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 Equipment UICC Universal Integrated Circuit Card UMTS Universal Mobile Telecommunicatio

23、ns 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 keywords “is recommen

24、ded” 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 conformance to t

25、his 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 optionally enabled by

26、 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 to be interpre

27、ted, respectively, as is required to, is prohibited from, is ATIS-1000045.2012 4 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 Mechanisms if not, the authe

28、ntication procedure is halted. Generates a secret key K. Generates value UprNpuK|K(RAND), sets the parameter pki-auth-user-signature to that value, and sends it in the body of an HTTP POST message to A-2. The header Content-Type of the message must be set to the value application/x-www-form-urlencod

29、ed. 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 value D|E, where D

30、is supposedly equal to NpuK and E is supposedly equal to K(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 A-2 now share k

31、ey 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 element to the value sender-vouches. Computes value Ks(K). Includes the assertion in a SAML response. It then delivers the SAML response and the

32、computed value Ks(K) over HTTP in the same manner as described for the SAML request in 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 as specified in clause

33、10.2.4.5.2, Security Considerations, of ITU-T X.1141. The shared secret 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, the AS retrieves the

34、value Ks(K) and decrypts it using shared Ksto obtain K. At this point, AS has authenticated the End-User Function and both entities share the key K, which can be used for securing communications between them. 7. The AS, if it is required by policy for making an authorization decision, obtains inform

35、ation about the 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 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 Functio

38、nal 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 Requirements f

39、or 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 are

40、 as follows: The interface between the End-User Function and the Application Server must support HTTP protocol b-IETF RFC 2616. The interfaces between the End-User Function and A-2 Functional Entities must support HTTP protocol b-IETF RFC 2616. The interface between A-2 and Application Server must s

41、upport SAML ITU-T X.1141. The interface between the A-2 and S-5 Functional Entities must support a query-response mechanism 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

42、with 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 n

43、etwork and web services environment with an existing ISIM application, as well as with other SIM applications that rely on AKA. Allows users to control their public identifiers on the Web as specified in b-OpenID v.2 while leveraging NGN services. Improves user security by engaging a user-trusted ne

44、twork provider in the access control to the Web applications. ATIS-1000045.2012 19 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 inte

45、gration 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 e

46、ntity is capable of running a Web client and communicating with the appropriate 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 OpenID b-OpenID v.2 iden

47、tity provider. (The A-2 optionally shares a short-term secret with the Application 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: En

48、d User 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 procedur

49、e of 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-10