INTERNET-DRAFT N. Sakimura Intended Status: Proposed Standard NRI Expires: August 29, 2013 B. Kihara, Ed K. Shimizu Lepidum February 25, 2013 Access Token as per Client Password for Non-Web Protocols draft-sakimura-oidc-extension-nonweb-01 Abstract This specification describes the usage of the access token as a per client "password" for non-web clients that utilizes password based authentication, and the mechanism to issue such access tokens. Since the access token is used as the password for the client, the existing client application can be used as-is without any change, which is a considerable advantage for the deployment. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Sakimura, et al. Expires August 29, 2013 [Page 1] INTERNET DRAFT Access Token as Password for Non-Web February 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Auth Scope Values . . . . . . . . . . . . . . . . . . . . 4 2.2. Auth UserInfo Response . . . . . . . . . . . . . . . . . . 5 3. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Obtaining a per client "password" (access token) . . . . . 6 3.2. Using the "per client password" (access token) . . . . . . 6 3.2.1. Access Token Revocation . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Integration with Traditional Services . . . . . . . . 11 Appendix B. Document History . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Sakimura, et al. Expires August 29, 2013 [Page 2] INTERNET DRAFT Access Token as Password for Non-Web February 2013 1. Introduction Protocols such as IMAP ([RFC3501]) and SMTP ([RFC5321]) use passwords for authentication, and thus end-users are threatened by problems of passwords. End-users tend to use weak passwords, to leak passwords, and to carry same passwords to multiple service providers. To resolve the problem, the Simple Authentication and Security Layer (SASL) ([RFC4422]) and non-password authentication protocols over SASL are introduced. However, these protocols require upgrading client applications which has become a hurdle for a quick adoption among the consumer clients. This document describes the issuance and the usage of OAuth 2.0 bearer access tokens ([RFC6750]) as the per client password for client applications that do not support token handling defined in protocols such as OAuth ([RFC6749]). It leverages on OpenID Connect ([OIDF.Connect.Messages]) as the federated authentication protocol. Since the access token is used as a per client password, when an end- user loses his/her smartphone, he/she can revoke the token put in the smartphone without resetting other client software instances. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Sakimura, et al. Expires August 29, 2013 [Page 3] INTERNET DRAFT Access Token as Password for Non-Web February 2013 2. Messages Most client applications for protocols such as IMAP ([RFC3501]) and SMTP ([RFC5321]) do not support token handling in OAuth ([RFC6749]) or other frameworks; they cannot request authorization, cannot receive authorization code, and cannot request access tokens. To resolve this problem, service providers can provide end-users with web pages that handle tokens and instruct end-users to copy access tokens from the page to the password box on the client application. As client applications cannot refresh access tokens, long-lived access tokens are sought for the end-user usability reasons. As a result, token providers may have to handle such access tokens specially. In order to support authentication and authorization by using access tokens as credentials, new scope values and behaviors are introduced to the OpenID Connect specifications ([OIDF.Connect.Messages]). 2.1. Auth Scope Values This specification defines the auth scope values. The auth scope values are scope values which start with "auth_" and indicate that the client wants an access token as a credential for client application authentication and authorization. When the OpenID Provider received auth scope values in an authorization request, the OpenID Provider MUST provide Bearer type access tokens and is expected to issue a long-lived access token which can be revoked. If auth scope values are specified in an authorization request, the client SHOULD NOT request other unnecessary scopes, because the issued access token will be long-lived and transferred in uncertain ways. It is RECOMMENDED to use auth scope values only with the openid scope. The OpenID Provider SHOULD deny requests with auth scope values when scopes other than openid scope is specified. The following is a non-normative example of a scope Request using an auth scope. scope=openid auth_imap [[Note: the name of the scope values are unsettled. One implementation uses a PAM module to validate tokens in protocols such as IMAP and SMTP, so values like pam_imap and pam_smtp should be also suitable.]] [[Note: if using OpenID Connect, we can use OpenID Request Object Sakimura, et al. Expires August 29, 2013 [Page 4] INTERNET DRAFT Access Token as Password for Non-Web February 2013 instead of/ together with scopes. For example, "auth" scope indicates that the required access token is used as a credential, and precise control of authorization (protocol names, control in the protocol, etc.) are represented in other ways.]] 2.2. Auth UserInfo Response When the client requests UserInfo with the access token issued in response to auth scope values, the OpenID Provider returns claims for the auth scope values. The name of the claim is the same as the scope value, and the value of the claim is a JSON object ([RFC4627]). The members of the JSON object are undefined and reserved for future use. The following is a non-normative example of a UserInfo Response for an auth scope. { "sub": "fb5e4c66b91e929171f6d31b984447a3", "auth_imap": {} } [[Note: the current draft is based on OpenID Connect. However, using OAuth Token Introspection draft (draft-richer-oauth-introspection), this protocol might become independent of OpenID Connect.]] Sakimura, et al. Expires August 29, 2013 [Page 5] INTERNET DRAFT Access Token as Password for Non-Web February 2013 3. Protocol Flows In this section, the protocol flows using auth scope values and auth UserInfo response are described. 3.1. Obtaining a per client "password" (access token) To obtain an access token for client application authentication and authorization, the service provider, the OpenID Provider, and the end-user will act as follows: 1. The end-user accesses the web page of the service provider in order to obtain the information including the "password (access token)" to use a client application. 2. The end-user logs in to the web page using his/her local credentials, typically a username and a password for the application, e.g., IMAP. 3. The end-user selects an OpenID provider and the service provider sends an authentication and authorization request to the OpenID Provider with auth scope values. 4. The OpenID Provider asks the end-user whether he/she wants to authorize the request. It is RECOMMENDED for the OpenID Provider to provide the end-user with methods to distinguish access tokens in order to revoke the intended access token if necessary such as a user specified nickname for the client, e.g., "my iphone", "my pc thunderbird", etc. 5. The service provider receives an authorization response and obtains a Bearer type access token. 6. The service provider receives the sub claim from the OpenID Provider by using the access token or by decoding ID token if exists, and links the OpenID Provider, the sub claim, and the local account that the service provider manages. 7. The service provider shows the access token to the end-user and instruct to copy the access token to the password box on the client application. 3.2. Using the "per client password" (access token) The access token obtained by the above process is used as a credential in the protocol that normally uses a password such as IMAP ([RFC3501]). When the service provider receives an access token, the service provider authenticates the end-user in the following way. 1. The client application sends the "paasword" (access token) to the service provider. Sakimura, et al. Expires August 29, 2013 [Page 6] INTERNET DRAFT Access Token as Password for Non-Web February 2013 2. The service provider sends UserInfo request to the OpenID Provider with the access token. [[Note: it could be to the token introspection endpoint]] 3. The OpenID Provider returns UserInfo response described in the section 2.2. 4. The service provider checks whether the there is the claim name that the service provider requires. 5. The service provider checks whether the sub claim is the same as the value that was obtained in the access token issue flow and makes an authorization decision based on it. Once the positive authorization decision was made, the service provider provides the specified service to the client. The following is a non-normative example of access token usage in IMAP. C: a001 LOGIN alice eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJpc3M... [Here, the service provider validates the token.] S: a001 OK LOGIN completed 3.2.1. Access Token Revocation Because access tokens issued for auth scope values are intended to be saved in the settings of client applications, OpenID providers that supports auth scope values MUST provide end-users with methods to revoke access tokens. If a service provider caches results of token validation, the duration of results MUST be short enough to prevent stolen access tokens from being used. Sakimura, et al. Expires August 29, 2013 [Page 7] INTERNET DRAFT Access Token as Password for Non-Web February 2013 4. Security Considerations As access tokens issued for auth scope values are intended to be transmitted in place of passwords, the communication MUST be secured by TLS ([RFC5246]) or other mechanisms. Such mechanisms are not REQUIRED if the transmission channel is insured to be safe (for example a local network within a company); however, use of TLS or other mechanisms is strongly RECOMMENDED. Protocols that this extension targets may implement the STARTTLS command (Section 6.2.1 in [RFC3501], [RFC3207] and so on). If the service provider uses STARTTLS, the man-in-the-middle can delete the STARTTLS capability advertisement from the server responses. Therefore, the service provider is RECOMMENDED to instruct end-users to configure their client applications to force TLS. Scope sets SHOULD be minimal. There is a trade-off between security and convenience; for example, it may be painful to input two long strings for IMAP and SMTP via a small on-screen keyboard. The rule SHOULD NOT be too strict in order not to motivate end-users to use traditional passwords. Access token strings MUST be long enough and hard to be guessed. Also, OpenID providers MUST protect their procedure to issue access tokens; for example, administration pages on OpenID providers or private keys to sign tokens MUST NOT be revealed. Service providers SHOULD deny malicious, insecure, or loose OpenID providers. Otherwise, an end-user links his/her account to such an OpenID provider and the service provider accepts a "valid" access token that is issued to a malicious party. Service providers MUST link information from the OpenID provider with local information and verify the links at token validation. Since a username and an access token is passed to the service provider, the subject of the access token and the account specified by the username MUST match. Protocols targeted by this extension might require password frequently, so the results of access token validation MAY be cached. However, the duration of results MUST be short enough and MUST NOT be updated in order to prevent stolen access tokens from being used. When a service provider validates a string which is a password or an access token, the service provider MUST first validate the string as a password. Otherwise, the password will leak to the OpenID provider. [[Note: if an end-user mistypes a password, the password validation will fail and the wrong password will be sent to the OpenID provider Sakimura, et al. Expires August 29, 2013 [Page 8] INTERNET DRAFT Access Token as Password for Non-Web February 2013 as an access token. This may be a security risk. To prevent such incidents, some structures or prefixes may be needed. This will be a future work.]] It is an advantage of this extension that the access tokens can be revoked individually unlike passwords that are shared among client applications. However, if the OpenID provider issues an access token and the end-user mistakenly changes the password to the token at the server side, the token revocation mechanism will not work properly; the "token" will be revoked and the "password" that is the same string as the token will remain valid. To prevent such cases, service providers SHOULD instruct end-users not to input the access token into the password configuration on the service provider management page. [[Note:Some structures or prefixes for tokens might also work for these cases.]] 5. Privacy Considerations Access tokens might contain data that should not be disclosed to other parties than the OpenID provider, the service provider and the end-user. Therefore, the service provider SHOULD instruct the end- user not to disclose access tokens to other parties. The OpenID provider is RECOMMENDED to issue opaque tokens or encrypted tokens. 6. IANA Considerations 7. References 7.1. Normative References [OIDF.Connect.Messages] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, "OpenID Connect Messages 1.0 - draft 15", January 2013, . [I-D.ietf-oauth-json-web-token] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", draft-ietf-oauth-json- web-token (work in progress), December 2012. [I-D.richer-oauth-introspection] J. Richer, "OAuth Token Introspection", draft-richer-oauth-introspection (work in progress), February 2013. Sakimura, et al. Expires August 29, 2013 [Page 9] INTERNET DRAFT Access Token as Password for Non-Web February 2013 7.2. Informative References [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, October 2012. [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. [RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002. Sakimura, et al. Expires August 29, 2013 [Page 10] INTERNET DRAFT Access Token as Password for Non-Web February 2013 Appendix A. Integration with Traditional Services When a service provider integrates this extension with password mechanism, the service provider will accept both access tokens and passwords for authenticating and authorizing parties that access the service provider. The followings are notes for such cases: o When the service provider receives a pair of a username and a string for authentication, the service provider MUST validate the string as a password before validating the string as an access token, otherwise the password will leak to OpenID provider. o When the service provider cease to accept passwords, the service provider SHOULD keep the password database and keep to check whether the string for authentication is the same as the password. This is because the service provider may keep accepting the password in other services and because the end-user's preference of passwords may be guessed. o When the service provider prompts an end-user to change his/her password, the service provider SHOULD confirm to the end-user that the password is not a valid access token. The end-user may input an access token obtained from an OpenID provider into both the account management page on the service provider and the password box on the client application. In such a case, the end-user can revoke the access token but cannot prevent the "password" from being used. Appendix B. Document History -01 o Renamed draft's title. o Renamed several sections' titles. o Inserted Access Token Revocation section. o Inserted Security Considerations and Privacy Consideration sections. o Inserted Integration with Traditional Services section. o Clarified that the end-user inputs his/her credentials into the service provider web page in order to link accounts. -00 o Initial draft. Authors' Addresses Nat Sakimura Nomura Research Institute EMail: n-sakimura@nri.co.jp Sakimura, et al. Expires August 29, 2013 [Page 11] INTERNET DRAFT Access Token as Password for Non-Web February 2013 Boku Kihara (editor) Lepidum Co. Ltd. EMail: kihara@lepidum.co.jp Kazuki Shimizu Lepidum Co. Ltd. Sakimura, et al. Expires August 29, 2013 [Page 12]