draft-ietf-oauth-v2-threatmodel-04.txt   draft-ietf-oauth-v2-threatmodel-05.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: November 26, 2012 IBM Expires: November 28, 2012 IBM
P. Hunt P. Hunt
Oracle Corporation Oracle Corporation
May 25, 2012 May 27, 2012
OAuth 2.0 Threat Model and Security Considerations OAuth 2.0 Threat Model and Security Considerations
draft-ietf-oauth-v2-threatmodel-04 draft-ietf-oauth-v2-threatmodel-05
Abstract Abstract
This document gives additional security considerations for OAuth, This document gives additional security considerations for OAuth,
beyond those in the OAuth specification, based on a comprehensive beyond those in the OAuth specification, based on a comprehensive
threat model for the OAuth 2.0 Protocol. threat model for the OAuth 2.0 Protocol.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 November 26, 2012. This Internet-Draft will expire on November 28, 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 10 skipping to change at page 5, line 10
5.2.3. Client authentication and authorization . . . . . . . 54 5.2.3. Client authentication and authorization . . . . . . . 54
5.2.3.1. Don't issue secrets to public clients or 5.2.3.1. Don't issue secrets to public clients or
clients with inappropriate security policy . . . . 55 clients with inappropriate security policy . . . . 55
5.2.3.2. Public clients without secret require user 5.2.3.2. Public clients without secret require user
consent . . . . . . . . . . . . . . . . . . . . . 55 consent . . . . . . . . . . . . . . . . . . . . . 55
5.2.3.3. Client_id only in combination with redirect_uri . 55 5.2.3.3. Client_id only in combination with redirect_uri . 55
5.2.3.4. Deployment-specific client secrets . . . . . . . . 56 5.2.3.4. Deployment-specific client secrets . . . . . . . . 56
5.2.3.5. Validation of pre-registered redirect_uri . . . . 56 5.2.3.5. Validation of pre-registered redirect_uri . . . . 56
5.2.3.6. Client secret revocation . . . . . . . . . . . . . 57 5.2.3.6. Client secret revocation . . . . . . . . . . . . . 57
5.2.3.7. Use strong client authentication (e.g. 5.2.3.7. Use strong client authentication (e.g.
client_assertion / client_token) . . . . . . . . . 57 client_assertion / client_token) . . . . . . . . . 58
5.2.4. End-user authorization . . . . . . . . . . . . . . . . 58 5.2.4. End-user authorization . . . . . . . . . . . . . . . . 58
5.2.4.1. Automatic processing of repeated 5.2.4.1. Automatic processing of repeated
authorizations requires client validation . . . . 58 authorizations requires client validation . . . . 58
5.2.4.2. Informed decisions based on transparency . . . . . 58 5.2.4.2. Informed decisions based on transparency . . . . . 58
5.2.4.3. Validation of client properties by end-user . . . 58 5.2.4.3. Validation of client properties by end-user . . . 58
5.2.4.4. Binding of authorization code to client_id . . . . 59 5.2.4.4. Binding of authorization code to client_id . . . . 59
5.2.4.5. Binding of authorization code to redirect_uri . . 59 5.2.4.5. Binding of authorization code to redirect_uri . . 59
5.3. Client App Security . . . . . . . . . . . . . . . . . . . 59 5.3. Client App Security . . . . . . . . . . . . . . . . . . . 59
5.3.1. Don't store credentials in code or resources 5.3.1. Don't store credentials in code or resources
bundled with software packages . . . . . . . . . . . . 59 bundled with software packages . . . . . . . . . . . . 59
skipping to change at page 52, line 6 skipping to change at page 52, line 6
Self-contained may be encrypted for privacy reasons or to protect Self-contained may be encrypted for privacy reasons or to protect
system internal data. system internal data.
5.1.5.11. Random token value with high entropy 5.1.5.11. Random token value with high entropy
When creating token handles, the authorization server should include When creating token handles, the authorization server should include
a reasonable level of entropy in order to mitigate the risk of a reasonable level of entropy in order to mitigate the risk of
guessing attacks. The token value should be constructed from a guessing attacks. The token value should be constructed from a
cryptographically strong random or pseudo-random number sequence cryptographically strong random or pseudo-random number sequence
[RFC1750] generated by the Authorization Server. The probability of [RFC4086] generated by the Authorization Server. The probability of
any two token values being identical should be less than or equal to any two token values being identical should be less than or equal to
2^(-128) and should be less than or equal to 2^(-160). 2^(-128) and should be less than or equal to 2^(-160).
5.1.5.12. Assertion formats 5.1.5.12. Assertion formats
For service providers intending to implement an assertion-based token For service providers intending to implement an assertion-based token
design it is highly recommended to adopt a standard assertion format design it is highly recommended to adopt a standard assertion format
(such as SAML or JWT) that implements [draft-ietf-oauth-assertions]. (such as SAML or JWT) that implements [draft-ietf-oauth-assertions].
5.1.6. Access tokens 5.1.6. Access tokens
skipping to change at page 53, line 43 skipping to change at page 53, line 43
response allows the authorization server to return a new refresh response allows the authorization server to return a new refresh
token even for requests with grant type "refresh_token". token even for requests with grant type "refresh_token".
Note: this measure may cause problems in clustered environments since Note: this measure may cause problems in clustered environments since
usage of the currently valid refresh token must be ensured. In such usage of the currently valid refresh token must be ensured. In such
an environment, other measures might be more appropriate. an environment, other measures might be more appropriate.
5.2.2.4. Refresh Token Revocation 5.2.2.4. Refresh Token Revocation
The authorization server may allow clients or end-users to explicitly The authorization server may allow clients or end-users to explicitly
request the invalidation of refresh tokens. request the invalidation of refresh tokens. A mechanism to revoke
tokens is specified in [I-D.ietf-oauth-revocation].
This is a countermeasure against: This is a countermeasure against:
o device theft, o device theft,
o impersonation of resource owner, or o impersonation of resource owner, or
o suspected compromised client applications. o suspected compromised client applications.
5.2.2.5. Device identification 5.2.2.5. Device identification
The authorization server may require to bind authentication The authorization server may require to bind authentication
credentials to a device identifier. The IMEI is one example of such credentials to a device identifier. The IMEI is one example of such
an identifier, there are also operating system specific identifiers. an identifier, there are also operating system specific identifiers.
The authorization server could include such an identifier when The authorization server could include such an identifier when
authenticating user credentials in order to detect token theft from a authenticating user credentials in order to detect token theft from a
particular device. particular device.
skipping to change at page 63, line 25 skipping to change at page 63, line 25
o Addressing these issues by restricting the use of user-installed o Addressing these issues by restricting the use of user-installed
software may be practical in some limited environments, and can be software may be practical in some limited environments, and can be
used as a countermeasure in those cases. Such restrictions are used as a countermeasure in those cases. Such restrictions are
not practical in the general case, and mechanisms for after-the- not practical in the general case, and mechanisms for after-the-
fact recovery should be in place. fact recovery should be in place.
o While end users are mostly incapable of properly vetting o While end users are mostly incapable of properly vetting
applications they load onto their devices, those who deploy applications they load onto their devices, those who deploy
Authorization Servers might have tools at their disposal to Authorization Servers might have tools at their disposal to
mitigate malicious Clients. For example, a well run Authorization mitigate malicious Clients. For example, a well run Authorization
Server MUST only assert client properties to the end-user it is Server must only assert client properties to the end-user it is
effectively capable to validate, explicitely point out which effectively capable to validate, explicitely point out which
properties it cannot validate and indicate to the end-user the properties it cannot validate, and indicate to the end-user the
risk associated with granting access to the particular client. 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
skipping to change at page 64, line 8 skipping to change at page 64, line 8
8.1. Normative References 8.1. Normative References
[I-D.ietf-oauth-v2] [I-D.ietf-oauth-v2]
Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth
2.0 Authorization Framework", draft-ietf-oauth-v2-26 (work 2.0 Authorization Framework", draft-ietf-oauth-v2-26 (work
in progress), May 2012. in progress), May 2012.
8.2. Informative References 8.2. Informative References
[I-D.ietf-oauth-revocation]
Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token
Revocation", draft-ietf-oauth-revocation-00 (work in
progress), May 2012.
[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-19 (work in progress), draft-ietf-oauth-v2-bearer-19 (work in progress),
April 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] [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token Requirements for Security", BCP 106, RFC 4086, June 2005.
Revocation", draft-lodderstedt-oauth-revocation-04 (work
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/>. <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
skipping to change at page 65, line 49 skipping to change at page 66, line 4
o Synchronisation with the core's security consideration section o Synchronisation with the core's security consideration section
(UPDATE 10.12 CSRF, NEW 10.14/15) (UPDATE 10.12 CSRF, NEW 10.14/15)
o Added Resource Owner Impersonation o Added Resource Owner Impersonation
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)
draft-ietf-oauth-v2-threatmodel-03
o removed 2119 boilerplate and normative reference o removed 2119 boilerplate and normative reference
o incorporated shepherd review feedback 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
 End of changes. 14 change blocks. 
15 lines changed or deleted 19 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/