ITU-T Y 2723-2013 Support for OAuth in next generation networks (Study Group 13)《支持下一代网络中的开放授权 13号研究组》.pdf

《ITU-T Y 2723-2013 Support for OAuth in next generation networks (Study Group 13)《支持下一代网络中的开放授权 13号研究组》.pdf》由会员分享，可在线阅读，更多相关《ITU-T Y 2723-2013 Support for OAuth in next generation networks (Study Group 13)《支持下一代网络中的开放授权 13号研究组》.pdf（14页珍藏版）》请在麦多课文档分享上搜索。

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