< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/