1、 International Telecommunication Union ITU-T Y.2723TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (11/2013) SERIES Y: GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-GENERATION NETWORKS Next Generation Networks Security Support for OAuth in next generation networks Recommendat
2、ion ITU-T Y.2723 ITU-T Y-SERIES RECOMMENDATIONS GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-GENERATION NETWORKS GLOBAL INFORMATION INFRASTRUCTURE General Y.100Y.199 Services, applications and middleware Y.200Y.299 Network aspects Y.300Y.399 Interfaces and protocols Y.400Y.4
3、99 Numbering, addressing and naming Y.500Y.599 Operation, administration and maintenance Y.600Y.699 Security Y.700Y.799 Performances Y.800Y.899 INTERNET PROTOCOL ASPECTS General Y.1000Y.1099 Services and applications Y.1100Y.1199 Architecture, access, network capabilities and resource management Y.1
4、200Y.1299 Transport Y.1300Y.1399 Interworking Y.1400Y.1499 Quality of service and network performance Y.1500Y.1599 Signalling Y.1600Y.1699 Operation, administration and maintenance Y.1700Y.1799 Charging Y.1800Y.1899 IPTV over NGN Y.1900Y.1999 NEXT GENERATION NETWORKS Frameworks and functional archit
5、ecture models Y.2000Y.2099 Quality of Service and performance Y.2100Y.2199 Service aspects: Service capabilities and service architecture Y.2200Y.2249 Service aspects: Interoperability of services and networks in NGN Y.2250Y.2299 Enhancements to NGN Y.2300Y.2399 Network management Y.2400Y.2499 Netwo
6、rk control architectures and protocols Y.2500Y.2599 Packet-based Networks Y.2600Y.2699 Security Y.2700Y.2799Generalized mobility Y.2800Y.2899 Carrier grade open environment Y.2900Y.2999 FUTURE NETWORKS Y.3000Y.3499 CLOUD COMPUTING Y.3500Y.3999 For further details, please refer to the list of ITU-T R
7、ecommendations. Rec. ITU-T Y.2723 (11/2013) i Recommendation ITU-T Y.2723 Support for OAuth in next generation networks Summary Recommendation ITU-T Y.2723 specifies the mechanisms and procedures for employing “The OAuth 2.0 Authorization Framework (OAuth)“, defined by the Internet Engineering Task
8、Force, for the scenarios where the role of the OAuth authorization server is performed by a next generation network (NGN) provider. The companion document, Recommendation ITU-T Y.2724, “Framework for supporting OAuth and OpenID in next generation networks“, provides the context, architectural consid
9、erations and high-level framework for employing OAuth in NGNs. This Recommendation specifies the requirements pertinent to the restriction of OAuth option selections, as well as additional requirements that make the use of OAuth consistent with NGN security and identity management requirements. Hist
10、ory Edition Recommendation Approval Study Group 1.0 ITU-T Y.2723 2013-11-15 13 ii Rec. ITU-T Y.2723 (11/2013) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications, information and communication technologies (ICTs). The I
11、TU 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 telecommunications on a worldwide basis. The World Telecommunication Standardi
12、zation 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 procedure laid down in WTSA Resolution 1. In some areas of information tec
13、hnology 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 telecommunication administration and a recognized operating agency. Compli
14、ance 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 mandatory provisions are met. The words “shall“ or some other obl
15、igatory 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 draws attention to the possibility that the practice or implementat
16、ion 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 or others outside of the Recommendation development process. As o
17、f 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 represent the latest information and are therefore strongly urged t
18、o consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2013 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Rec. ITU-T Y.2723 (11/2013) iii Table of Contents Page 1 Scope 1 2 References. 1 3 Def
19、initions 1 3.1 Terms defined elsewhere 1 3.2 Terms defined in this Recommendation . 2 4 Abbreviations and acronyms 2 5 Conventions 2 6 Support for OAuth in NGN 2 6.1 Selection of OAuth client types based on NGN security requirements . 2 6.2 Selection of the authorization grant types 3 6.3 Recommenda
20、tions on the OAuth options for NGN-supported clients . 3 6.4 Authentication of a resource owner 4 6.5 Security considerations . 5 Bibliography. 6 iv Rec. ITU-T Y.2723 (11/2013) Introduction Recommendation ITU-T Y.2723 provides a framework for the support and use of OAuth and OpenID in next generatio
21、n networks (NGNs). This Recommendation builds upon Recommendation ITU-T Y.2724 to define specific methods for supporting OAuth. NOTE This Recommendation does not make any changes or modifications to the OAuth protocol. It focuses only on the support and use of OAuth by NGNs. Rec. ITU-T Y.2723 (11/20
22、13) 1 Recommendation ITU-T Y.2723 Support for OAuth in next generation networks 1 Scope This Recommendation describes the mechanisms and procedures for the support of OAuth 2.0 authorization protocol (OAuth) in next generation networks (NGNs). The mechanisms and procedures described in this Recommen
23、dation can be used to support application services in a multi-service, multi-provider environment. This Recommendation assumes that the OAuth authorization service is provided by the NGN. 2 References The following ITU-T Recommendations and other references contain provisions which, through referenc
24、e in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most rec
25、ent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. ITU-T X.1254 Recommend
26、ation ITU-T X.1254 (2012), Entity authentication assurance framework. ITU-T Y.2701 Recommendation ITU-T Y.2701 (2007), Security requirements for NGN release 1. ITU-T Y.2702 Recommendation ITU-T Y.2702 (2008), Authentication and authorization requirements for NGN release 1. ITU-T Y.2720 Recommendatio
27、n ITU-T Y.2720 (2009), NGN identity management framework. ITU-T Y.2721 Recommendation ITU-T Y.2721 (2010), NGN identity management requirements and use cases. ITU-T Y.2724 Recommendation ITU-T Y.2724 (2013), Framework for supporting OAuth and OpenID in next generation networks. IETF RFC 6749 IETF RF
28、C 6749 (2012), The OAuth 2.0 Authorization Framework. 3 Definitions 3.1 Terms defined elsewhere This Recommendation uses the following terms defined elsewhere: 3.1.1 access token IETF RFC 6749: Access tokens are credentials used to access protected resources. An access token is a string representing
29、 an authorization issued to the client. The string is usually opaque to the client. Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization server. 3.1.2 (entity) authentication b-ITU-T X.1252: A process used to a
30、chieve sufficient confidence in the binding between the entity and the presented identity. 3.1.3 authorization b-ITU-T X.800: The granting of rights, which includes the granting of access based on access rights. 2 Rec. ITU-T Y.2723 (11/2013) 3.1.4 authorization grant IETF RFC 6749: An authorization
31、grant is a credential representing the resource owners authorization (to access its protected resources) used by the client to obtain an access token. 3.1.5 authorization server IETF RFC 6749: The server issuing access tokens to the client after successfully authenticating the resource owner and obt
32、aining authorization. 3.1.6 client IETF RFC 6749: An application making protected resource requests on behalf of the resource owner and with its authorization. The term “client“ does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a deskto
33、p or other devices). 3.1.7 confidential clients IETF RFC 6749: These are clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other mean
34、s. 3.1.8 public clients IETF RFC 6749: These are clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client au
35、thentication via any other means. 3.1.9 resource owner IETF RFC 6749: An entity capable of granting access to a protected resource. When the resource owner is a person, they are referred to as an end-user. 3.1.10 resource server IETF RFC 6749: The server hosting the protected resources, capable of a
36、ccepting and responding to protected resource requests using access tokens. 3.2 Terms defined in this Recommendation None. 4 Abbreviations and acronyms This Recommendation uses the following abbreviations and acronyms: IdM Identity Management NGN Next Generation Network OAuth OAuth 2.0 Authorization
37、 Protocol SAML Security Assertion Markup Language URI Uniform Resource Identifier 5 Conventions None. 6 Support for OAuth in NGN This clause describes the main aspects of supporting OAuth in NGN. 6.1 Selection of OAuth client types based on NGN security requirements IETF RFC 6749 defines two OAuth c
38、lient types: confidential and public clients. Public clients do not meet the authentication requirements for NGN third party application providers ITU-T Y.2702, because public clients cannot be authenticated by the NGN provider ITU-T Y.2724. This Recommendation recommends that the NGN supports only
39、confidential clients. The clients must meet the following requirements: Rec. ITU-T Y.2723 (11/2013) 3 1. The NGN OAuth client must be able to be authenticated at specific assurance levels ITU-T Y.2702, ITU-T X.1254. 2. The NGN OAuth client must be registered with the authorization server as specifie
40、d in section 2 of IETF RFC 6749. OAuth 2.0 IETF RFC 6749 defines the following client profiles: web application, user-agent-based application, and native application. The web application is a profile of a private client, while the last two are profiles of the public clients. This Recommendation desc
41、ribes NGN support only for the client of the web application profile. 6.2 Selection of the authorization grant types IETF RFC 6749 defines the following types of authorization grants: authorization code, implicit, resource owner password credentials, and client credentials. Additionally, IETF are cu
42、rrently working on defining an extension, which specifies the SAML 2.0 assertion grant type for OAuth 2.0. IETF RFC 6749 explains that “when issuing an access token during the implicit grant flow, the authorization server does not authenticate the client. In some cases, the client identity can be ve
43、rified via the redirection URI used to deliver the access token to the client. The access token may be exposed to the resource owner or other applications with access to the resource owners user-agent“. Thus, the OAuth flows that use the implicit grant type do not result in authentication that meets
44、 the requirements for authentication of the NGN third party application provider ITU-T Y.2702. This Recommendation focuses on describing NGN support of the confidential client of the web application profile with the use of the following authorization grants: authorization code resource owner passwor
45、d credentials client credentials SAML 2.0 assertion. 6.3 Recommendations on the OAuth options for NGN-supported clients IETF RFC 6749 flows are optimized for several client profiles of the two types of clients. The RFC specifies the options for selecting the authorization grant types, parameters and
46、 security requirements. This clause provides recommendations for supporting confidential clients of the web application profile. This clause also focuses on those requirements and optional parameters whose selection is essential for OAuth support in NGNs. 6.3.1 Client registration Section 2.2 of IET
47、F RFC 6749 recommends the registration of the clients redirection URIs with an authorization server, because the clients with the registered URIs enable higher security. This Recommendation requires that NGN-supported clients register their redirection URIs with the authorization server. 6.3.2 Confi
48、dentiality of the messages to the client redirection endpoint Section 3.1.2.1 of IETF RFC 6749, makes the following recommendation: “the redirection endpoint SHOULD require the use of TLS as described in section 1.6 when the requested response type is “code“ or “token“, or when the redirection reque
49、st will result in the transmission of sensitive credentials over an open network“. This Recommendation requires that TLS be used for the transmission of any sensitive information. 4 Rec. ITU-T Y.2723 (11/2013) 6.3.3 Client authentication The clients defined by the web application profile are confidential clients. Therefore, the clients authentication to an authorization server is required. 6.3.4 Authorization procedures This Recommendation covers confidential clients of the we
