OAuth working group B. Leiba
Internet-Draft Huawei Technologies
Intended status: Informational March 28, 2011
Expires: September 29, 2011
OAuth Additional Security Considerations
draft-leiba-oauth-additionalsecurityconsiderations-00
Abstract
The Open Authentication Protocol (OAuth) specifies a security
protocol that involves significant end-user interaction -- the model
is based on having the end-user approve the authorization that is
being requested. That aspect makes the user interaction a part of
the security model, and raises additional security considerations
beyond those that are typical for client/server protocols. This
document describes those considerations.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 29, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Leiba Expires September 29, 2011 [Page 1]
Internet-Draft OAuth Additional Security Considerations March 2011
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Laying Out the Issues . . . . . . . . . . . . . . . . . . . 3
2.1. On Granting Access . . . . . . . . . . . . . . . . . . . . . 4
2.2. On Discovering and Revoking Access . . . . . . . . . . . . . 7
3. Recommendations . . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. Normative References . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . 10
Leiba Expires September 29, 2011 [Page 2]
Internet-Draft OAuth Additional Security Considerations March 2011
1. Introduction
The Open Authentication Protocol [I-D.ietf-oauth-v2] specifies a
security protocol used to authorize one service to act on behalf of a
user to a second service (to give a somewhat oversimplified
description). For example:
o A photo-printing service needs authorization to retrieve photos
from a user's private photo albums, stored with a photo-sharing
service.
o A social-network service needs authorization to read a user's
personal address book, stored in the email service she uses.
In most use cases, part of the protocol involves prompting the user
to log in to the second service and accept the authorization request.
That aspect makes the user interaction a part of the security model,
and raises additional security considerations beyond those that are
typical for client/server protocols.
[[anchor1: Should this be targeted for a BCP? I would prefer that,
as it would give it more weight.]]
2. Laying Out the Issues
The OAuth version 2 spec [I-D.ietf-oauth-v2] describes, in its
introduction, a typical example of the use of OAuth:
For example, a web user (resource owner) can grant a printing
service (client) access to her protected photos stored at a photo
sharing service (resource server), without sharing her username
and password with the printing service. Instead, she
authenticates directly with a server trusted by the photo sharing
service (authorization server) which issues the printing service
delegation-specific credentials (access token).
In such a typical case:
1. The user (resource owner) visits the client's web site (the
printing service) and makes a web request ("Print a photo from my
photo-sharing site.")
2. The client, behind the scenes and not apparent to the user,
requests authorization from the resource server, and is given a
request token.
Leiba Expires September 29, 2011 [Page 3]
Internet-Draft OAuth Additional Security Considerations March 2011
3. The client sends a response to the user's web request. The
response redirects the user's web browser to the authorization
server (of the photo-sharing service) and passes the server the
request token.
4. The authorization server prompts the user to accept the requested
authorization. The user sees this authorization prompt in the
browser, and it appears to be the first response to the original
request.
5. The user accepts the authorization request. She might have to
log in first, or an existing login might be used. Typically, she
will click a visual "button" that says "Accept", "Authorize",
"OK", or the like.
6. The authorization server sends a response to that action. The
response redirects the user's web browser to the client web
server (the printing service) and passes the server an access
token.
7. The client (the printing service) uses the access token behind
the scenes to contact the resource server (the photo-sharing
service) and to perform the service for the user. The user is
given a response that indicates that the request is in the works.
From the user's point of view, the interaction has seemed simple;
this is a great benefit of OAuth. But there was actually a
reasonable amount of complexity "behind the scenes" that the user did
not understand, and that leaves us with a conflicted situation:
1. the user shouldn't have to understand all of the behind-the-
scenes detail, but
2. the user needs to understand what she's being asked to authorize,
in order that she might make the right security decision about
the request.
2.1. On Granting Access
Some of the things a user might need to understand to make the
decision include
o Who is requesting the access. This can be a tricky point. The
authorization server might likely know only the domain name, or
even just the IP address of the client that's making the request.
The user *might* be able to make some sense of the domain name,
but really would do better with a real, human-readable name that
matches what she calls the service. And the authorization server
Leiba Expires September 29, 2011 [Page 4]
Internet-Draft OAuth Additional Security Considerations March 2011
has no cause to trust any human-readable string the requestor
gives.
A DKIM-like digital signature [I-D.crocker-dkim-doseta] along with
a mapping of known signing identities to readable names can be a
great help here. But be aware that any name provided by the
client is open to abuse by a bad actor, and should not be trusted.
o Who will be granting the access. It's easy to leave this out,
with the idea that it should be self-evident. The problem is that
if a client is requesting access beyond what it should be asking
for, it might be asking the wrong entity as well. If a user asks
for a photo to be printed, the requested authorization should not
be to the user's email account.
o The specific access that is being requested. This might not
always be obvious, depending upon the request, and depending upon
how the prompt is worded. "Print a photo for me," will likely
translate into read access to the photo. For "Auto-adjust the
contrast before printing, and save the adjusted version," the
service will need access to update the photo or to save a new
copy.
"Send e-cards to my family on their birthdays," might translate
into authority to send email on her behalf, plus read access to
her address book. The address book access is somewhat less
evident, and leaves a different avenue for abuse.
o The scope of the access. If she wants to print a single photo,
then read access to just that photo will do. If she wants to
print all photos in an album, she'll need to grant read access to
the whole album.
o The duration of the access. If she just wants to print a photo,
then a single read access to the photo should be enough. If she
wants the service to automatically print all her new photos every
week, persistent, long-term read access to her "new uploads" photo
album might work.
Because end-users are accepting or rejecting the authorization that
the client service is requesting, their understanding of what they're
being asked is important to the overall security of the system. And
because end-users often know nothing about computer security, the way
these various points are presented to them is a critical piece of the
security design. That is, the prompts and the user's understanding
of them and response to them have to be considered part of the
security model.
Leiba Expires September 29, 2011 [Page 5]
Internet-Draft OAuth Additional Security Considerations March 2011
This is especially important because the user is thinking in terms of
a task, while the authorization system is working in terms of what
accesses are needed for the task. The mapping between the two is
often not clear to the user, and the user's trust of the service
requesting the access might be tenuous.
We need to avoid asking users questions they're not prepared or
qualified to answer. Unfortunately, most security-related questions
fall into that category. The more we can put the request into plain
language, and the better we can explain, in clear, simple terms
what's being asked and what the ramifications of it are, the more
likely it is that we'll be working with informed consent and will
have a chance at fending off attacks on the system.
Consider the difference, for example, between the following two
prompts.
-----------------------------------------------------------------
Give printpix.example r/o access to
http://photoshare.example/usr213554/fnxgrptl/250/43/342500134.jpg
(OK) (Cancel)
-----------------------------------------------------------------
Example 1a
-----------------------------------------------------------------
The Print My Pix service (printpix.example) is asking PhotoShare
for access to your photo titled "Ralph in the park" in album
"New York". Granting access will allow Print My Pix to read, but
not alter nor delete, your photo. Access will be allowed one
time only.
For a more detailed explanation of what this means, [click here].
Do you want to allow access?
(Yes) (No)
-----------------------------------------------------------------
Example 1b
The second prompt is wordier, but might be easier for most people to
understand. Some of the technical details (such as the URL to the
photo in question) are available at a click, for users who want more
details.
Note how that difference appears to a user when the Print My Pix
service is actually abusive, and tries to get broader access than it
Leiba Expires September 29, 2011 [Page 6]
Internet-Draft OAuth Additional Security Considerations March 2011
needs.
-----------------------------------------------------------------
Give printpix.example r/w access to
http://photoshare.example/usr213554/
(OK) (Cancel)
-----------------------------------------------------------------
Example 2a
-----------------------------------------------------------------
The Print My Pix service (printpix.example) is asking PhotoShare
for access to all your photo albums. Granting access will allow
Print My Pix to read, alter and delete, your photos. Access will
be allowed permanently.
For a more detailed explanation of what this means, [click here].
Do you want to allow access?
(Yes) (No)
-----------------------------------------------------------------
Example 2b
The second prompt makes it clearer that Print My Pix is asking for a
lot. Specific warnings might also be added for atypical access
requests, or ones that seem to be overstepping.
It is not the intent, here, to give specific user-interface design
advice, and the design and wording of these prompts and other user-
interface elements will not necessarily come out well if given to
some protocol designers. The point, rather, is to highlight the
issues and raise awareness of the security implications of how OAuth
requests are communicated, so interface designers can take that into
account.
2.2. On Discovering and Revoking Access
As we use a great many services that each act as clients to other
services we use, we soon get into a very complex and hard-to-manage
situation. Suppose our hypothetical user allows Facebook to access
Flickr and to import contacts from Gmail; she allows her Blogger
account to post photos to Flickr and to read the photos there; she
allows Twitter to post her tweets to Facebook....
By the nature of these arrangements, and by the design of OAuth,
there's no central place that keeps track of all the authorizations.
Leiba Expires September 29, 2011 [Page 7]
Internet-Draft OAuth Additional Security Considerations March 2011
Each service knows what accesses she has authorized to it, but she
has to check each service individually. It's critical that she have
an easy way to do that, that she can easily find the way to do that,
and that she can understand the results that her queries return -- it
won't do to have them in computer-geek gibberish.
Further, it has to be easy for her to suspend or revoke the
authorizations she's made -- stale authorizations are entry points
for security vulnerabilities. She needs to be able to correct errors
she has made in authorizing things, as well as to rescind the
authorizations that are no longer appropriate.
3. Recommendations
1. Implementations should consider clarity to end users as a
critical part of the security model. Because users who are not
experts in security are being asked to make security decisions,
it is very important that the questions be clear, and that it be
easy to find more information.
2. Implementations should explain exactly what is being requested by
whom, and should provide one-click access to a more detailed
explanation.
3. Implementations should explain the ramifications of accepting the
request. Because the user is thinking of a specific task, other
aspects of what the requested access permits are not in the
user's mind. Put them there. Explain that this means that they
will be able to put all your photos into their photo pool, send
email on your behalf forever, and put everyone you know into
their marketing database.
4. Implementations should be attuned to the more usual requests, and
should highlight unusual requests when they arrive. If most
reasonable requests need read access and one asks for read/write,
tell the user it's unusual. Similarly, if most requests need
one-time access, or access to a single resource, let the user
know that a request for permanent access to multiple resources is
cause for concern. This particular task might need it, but make
sure the user is aware that this isn't what you usually see.
5. This should be a tractable problem, because most authorization
servers will be dealing with a limited set of resources, and,
hence, a limited set of typical authorization requests. The set
of typical requests will often be readily enumerable, and out-of-
the-ordinary ones will usually stand out.
Leiba Expires September 29, 2011 [Page 8]
Internet-Draft OAuth Additional Security Considerations March 2011
6. Implementations should provide an easy way, obvious to the user,
to inquire about active authorizations. This should not be
hidden behind a sort of "advanced" page, but should be within
easy reach of every user, along with a clear explanation of what
it means.
7. Implementations should provide an easy way, once the active
authorizations are shown, to get a detailed explanation of the
authorization -- what it means, what it allows access to, what
the ramifications are. Anything that should have been part of
the original access prompt should be available here.
8. Implementations should provide an easy way, once the active
authorizations are shown, to suspend or revoke each authorization
immediately.
9. Client implementations should gracefully re-authorize in the
event of a revoked authorization. Failure because an expected
authorization has been revoked is considered poor quality of
implementation. It is only appropriate to fail after an attempt
to re-authorize is denied.
4. Security Considerations
This entire document is about security considerations. Can we have
the RFC Editor remove this section prior to publication?
5. IANA Considerations
There are no IANA actions needed for this document, and the RFC
Editor may remove this section prior to publication.
6. Acknowledgements
[Thanks will go here.]
7. Normative References
[I-D.crocker-dkim-doseta]
Crocker, D. and M. Kucherawy, "DomainKeys Security Tagging
(DOSETA)", draft-crocker-dkim-doseta-00 (work in
progress), January 2011.
[I-D.ietf-oauth-v2]
Leiba Expires September 29, 2011 [Page 9]
Internet-Draft OAuth Additional Security Considerations March 2011
Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth
2.0 Authorization Protocol", draft-ietf-oauth-v2-13 (work
in progress), February 2011.
Author's Address
Barry Leiba
Huawei Technologies
Phone: +1 646 827 0648
Email: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/
Leiba Expires September 29, 2011 [Page 10]