draft-ietf-oauth-v2-threatmodel-02.txt   draft-ietf-oauth-v2-threatmodel-03.txt 
Web Authorization Protocol (oauth) T. Lodderstedt, Ed. Web Authorization Protocol (oauth) T. Lodderstedt, Ed.
Internet-Draft Deutsche Telekom AG Internet-Draft Deutsche Telekom AG
Intended status: Informational M. McGloin Intended status: Informational M. McGloin
Expires: August 22, 2012 IBM Expires: November 26, 2012 IBM
P. Hunt P. Hunt
Oracle Corporation Oracle Corporation
February 19, 2012 May 25, 2012
OAuth 2.0 Threat Model and Security Considerations OAuth 2.0 Threat Model and Security Considerations
draft-ietf-oauth-v2-threatmodel-02 draft-ietf-oauth-v2-threatmodel-03
Abstract Abstract
This document gives security considerations based on a comprehensive This document gives security considerations based on a comprehensive
threat model for the OAuth 2.0 Protocol. threat model for the OAuth 2.0 Protocol.
Requirements Language
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 RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 22, 2012. This Internet-Draft will expire on November 26, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 37 skipping to change at page 5, line 29
config files and databases) . . . . . . . . . . . . . 60 config files and databases) . . . . . . . . . . . . . 60
5.3.3. Store secrets in a secure storage . . . . . . . . . . 60 5.3.3. Store secrets in a secure storage . . . . . . . . . . 60
5.3.4. Utilize device lock to prevent unauthorized device 5.3.4. Utilize device lock to prevent unauthorized device
access . . . . . . . . . . . . . . . . . . . . . . . . 60 access . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3.5. Platform security measures . . . . . . . . . . . . . . 60 5.3.5. Platform security measures . . . . . . . . . . . . . . 60
5.3.6. Link state parameter to user agent session . . . . . . 60 5.3.6. Link state parameter to user agent session . . . . . . 60
5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 61 5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 61
5.4.1. Authorization headers . . . . . . . . . . . . . . . . 61 5.4.1. Authorization headers . . . . . . . . . . . . . . . . 61
5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 61 5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 61
5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 62 5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 62
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 5.5. A Word on User Interaction and User-Installed Apps . . . . 62
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63
8.1. Normative References . . . . . . . . . . . . . . . . . . . 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.2. Informative References . . . . . . . . . . . . . . . . . . 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 63
Appendix A. Document History . . . . . . . . . . . . . . . . . . 63 8.2. Informative References . . . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65 Appendix A. Document History . . . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66
1. Introduction 1. Introduction
This document gives security considerations based on a comprehensive This document gives additional security considerations for OAuth,
threat model for the OAuth 2.0 Protocol [I-D.ietf-oauth-v2]. It beyond those in the OAuth specification, based on a comprehensive
contains the following content: threat model for the OAuth 2.0 Protocol
[I-D.ietf-oauth-v2]. It contains the following content:
o Documents any assumptions and scope considered when creating the o Documents any assumptions and scope considered when creating the
threat model. threat model.
o Describes the security features in-built into the OAuth protocol o Describes the security features in-built into the OAuth protocol
and how they are intended to thwart attacks. and how they are intended to thwart attacks.
o Gives a comprehensive threat model for OAuth and describes the o Gives a comprehensive threat model for OAuth and describes the
respective counter measures to thwart those threats. respective counter measures to thwart those threats.
skipping to change at page 9, line 44 skipping to change at page 9, line 44
consuming entity (e.g. authorization and resource server) in order consuming entity (e.g. authorization and resource server) in order
to validate the token and obtain token-bound data. This to validate the token and obtain token-bound data. This
communication might have an negative impact on performance and communication might have an negative impact on performance and
scalability if both entities reside on different systems. Handles scalability if both entities reside on different systems. Handles
are therefore typically used if the issuing and consuming entity are therefore typically used if the issuing and consuming entity
are the same. A 'handle' token is often referred to as an are the same. A 'handle' token is often referred to as an
'opaque' token because the resource server does not need to be 'opaque' token because the resource server does not need to be
able to interpret the token directly, it simply uses the token. able to interpret the token directly, it simply uses the token.
Assertions (aka self-contained token) a parseable token. An Assertions (aka self-contained token) a parseable token. An
assertion typically has a duration, an audience, and is digitally assertion typically has a duration, has an audience, and is
signed containing information about the user and the client. digitally signed. It contains information about the user and the
Examples of assertion formats are SAML assertions and Kerberos client. Examples of assertion formats are SAML assertions and
tickets. Assertions can typically directly be validated and used Kerberos tickets. Assertions can typically directly be validated
by a resource server without interactions with the authorization and used by a resource server without interactions with the
server. This results in better performance and scalability in authorization server. This results in better performance and
deployment where issuing and consuming entity reside on different scalability in deployment where issuing and consuming entity
systems. Implementing token revocation is more difficult with reside on different systems. Implementing token revocation is
assertions than with handles. more difficult with assertions than with handles.
Tokens can be used in two ways to invoke requests on resource servers Tokens can be used in two ways to invoke requests on resource servers
as follows: as follows:
bearer token A 'bearer token' is a token that can be used by any bearer token A 'bearer token' is a token that can be used by any
client who has received the token (e.g. client who has received the token (e.g.
[I-D.ietf-oauth-v2-bearer]). Because mere possession is enough to [I-D.ietf-oauth-v2-bearer]). Because mere possession is enough to
use the token it is important that communication between end- use the token it is important that communication between end-
points be secured to ensure that only authorized end-points may points be secured to ensure that only authorized end-points may
capture the token. The bearer token is convenient to client capture the token. The bearer token is convenient to client
skipping to change at page 11, line 51 skipping to change at page 11, line 51
2. The client uses it immediately in secure transport-level 2. The client uses it immediately in secure transport-level
communications to the authorization server and then securely communications to the authorization server and then securely
stores the long-lived refresh token. stores the long-lived refresh token.
3. The client always uses the refresh token in secure transport- 3. The client always uses the refresh token in secure transport-
level communications to the authorization server to get an access level communications to the authorization server to get an access
token (and optionally rollover the refresh token). token (and optionally rollover the refresh token).
So as long as the confidentiality of the particular token can be So as long as the confidentiality of the particular token can be
ensured by the client, a refresh tokens can also be used as an ensured by the client, a refresh token can also be used as an
alternative mean to authenticate the client instance itself. alternative means to authenticate the client instance itself..
3.4. Authorization Code 3.4. Authorization Code
An Authorization Code represents the intermediate result of a An Authorization Code represents the intermediate result of a
successful end-user authorization process and is used by the client successful end-user authorization process and is used by the client
to obtain access and refresh token. Authorization codes are sent to to obtain access and refresh token. Authorization codes are sent to
the client's redirection URI instead of tokens for two purposes. the client's redirection URI instead of tokens for two purposes.
1. Instead of (longer-lasting) tokens, the short-lived authorization 1. Instead of (longer-lasting) tokens, the short-lived authorization
code is exposed to potential attackers via URI query parameters code is exposed to potential attackers via URI query parameters
skipping to change at page 62, line 28 skipping to change at page 62, line 28
A resource server may decide to accept signed requests only, either A resource server may decide to accept signed requests only, either
to replace transport level security measures or to complement such to replace transport level security measures or to complement such
measures. Every signed request should be uniquely identifiable and measures. Every signed request should be uniquely identifiable and
should not be processed twice by the resource server. This should not be processed twice by the resource server. This
countermeasure helps to mitigate: countermeasure helps to mitigate:
o modifications of the message and o modifications of the message and
o replay attempts o replay attempts
5.5. A Word on User Interaction and User-Installed Apps
OAuth, as a security protocol, is distinctive in that its flow
usually involves significant user interaction, making the end user a
part of the security model. This creates some important difficulties
in defending against some of the threats discussed above. Some of
these points have already been made, but it's worth repeating and
highlighting them here.
o End users must understand what they are being asked to approve
(see Section Section 5.2.4.1). Users often do not have the
expertise to understand the ramifications of saying "yes" to an
authorization request. and are likely not to be able to see subtle
differences in wording of requests. Malicious software can
confuse the user, tricking the user into approving almost
anything.
o End-user devices are prone to software compromise. This has been
a long-standing problem, with frequent attacks on web browsers and
other parts of the user's system. But with increasing popularity
of user-installed "apps", the threat posed by compromised or
malicious end-user software is very strong, and is one that is
very difficult to mitigate.
o Be aware that users will demand to install and run such apps, and
that compromised or malicious ones can steal credentials at many
points in the data flow. They can intercept the very user login
credentials that OAuth is designed to protect. They can request
authorization far beyond what they have led the user to understand
and approve. They can automate a response on behalf of the user,
hiding the whole process. No solution is offered here, because
none is known; this remains in the space between better security
and better usability.
o Addressing these issues by restricting the use of user-installed
software may be practical in some limited environments, and can be
used as a countermeasure in those cases. Such restrictions are
not practical in the general case, and mechanisms for after-the-
fact recovery should be in place.
o While end users are mostly incapable of properly vetting
applications they load onto their devices, those who deploy
Authorization Servers might have tools at their disposal to
mitigate malicious Clients. For example, a well run Authorization
Server MUST only assert client properties to the end-user it is
effectively capable to validate, explicitely point out which
properties it cannot validate and indicate to the end-user the
risk associated with granting access to the particular client.
6. IANA Considerations 6. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
7. Acknowledgements 7. Acknowledgements
We would like to thank Hui-Lan Lu, Francisco Corella, Peifung E Lam, We would like to thank Barry Leiba, Hui-Lan Lu, Francisco Corella,
Shane B Weeden, Skylar Woodward, Niv Steingarten, Tim Bray, and James Peifung E Lam, Shane B Weeden, Skylar Woodward, Niv Steingarten, Tim
H. Manger for their comments and contributions. Bray, and James H. Manger for their comments and contributions.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-oauth-v2] [I-D.ietf-oauth-v2]
Hammer, E., Recordon, D., and D. Hardt, "The OAuth 2.0 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth
Authorization Protocol", draft-ietf-oauth-v2-23 (work in 2.0 Authorization Framework", draft-ietf-oauth-v2-26 (work
progress), January 2012. in progress), May 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 8.2. Informative References
[I-D.ietf-oauth-v2-bearer] [I-D.ietf-oauth-v2-bearer]
Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0 Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0
Authorization Protocol: Bearer Tokens", Authorization Protocol: Bearer Tokens",
draft-ietf-oauth-v2-bearer-17 (work in progress), draft-ietf-oauth-v2-bearer-19 (work in progress),
February 2012. April 2012.
[I-D.ietf-oauth-v2-http-mac] [I-D.ietf-oauth-v2-http-mac]
Hammer-Lahav, E., "HTTP Authentication: MAC Access Hammer-Lahav, E., "HTTP Authentication: MAC Access
Authentication", draft-ietf-oauth-v2-http-mac-01 (work in Authentication", draft-ietf-oauth-v2-http-mac-01 (work in
progress), February 2012. progress), February 2012.
[I-D.lodderstedt-oauth-revocation] [I-D.lodderstedt-oauth-revocation]
Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token
Revocation", draft-lodderstedt-oauth-revocation-03 (work Revocation", draft-lodderstedt-oauth-revocation-04 (work
in progress), September 2011. in progress), March 2012.
[portable-contacts] [portable-contacts]
Smarr, J., "Portable Contacts 1.0 Draft C", August 2008. Smarr, J., "Portable Contacts 1.0 Draft C", August 2008,
<http://portablecontacts.net/>.
Appendix A. Document History Appendix A. Document History
[[ to be removed by RFC editor before publication as an RFC ]] [[ to be removed by RFC editor before publication as an RFC ]]
draft-lodderstedt-oauth-security-01 draft-lodderstedt-oauth-security-01
o section 4.4.1.2 - changed "resource server" to "client" in o section 4.4.1.2 - changed "resource server" to "client" in
countermeasures description. countermeasures description.
skipping to change at page 65, line 5 skipping to change at page 66, line 5
o Improved section 5 o Improved section 5
o Renamed Refresh Token Replacement to Refresh Token Rotation o Renamed Refresh Token Replacement to Refresh Token Rotation
draft-ietf-oauth-v2-threatmodel-02 draft-ietf-oauth-v2-threatmodel-02
o Incoporated Tim Bray's review comments (e.g. removed all normative o Incoporated Tim Bray's review comments (e.g. removed all normative
language) language)
o removed 2119 boilerplate and normative reference
o incorporated shepherd review feedback
Authors' Addresses Authors' Addresses
Torsten Lodderstedt (editor) Torsten Lodderstedt (editor)
Deutsche Telekom AG Deutsche Telekom AG
Email: torsten@lodderstedt.net Email: torsten@lodderstedt.net
Mark McGloin Mark McGloin
IBM IBM
 End of changes. 16 change blocks. 
45 lines changed or deleted 93 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/