Internet DRAFT - draft-sakimura-oidc-extension-nonweb
draft-sakimura-oidc-extension-nonweb
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
<IANA considerations text>
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,
<http://openid.net/specs/openid-connect-messages-
1_0.html>.
[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]
