< draft-ietf-kitten-sasl-oauth-16.txt		draft-ietf-kitten-sasl-oauth-17.txt >
	KITTEN W. Mills		KITTEN W. Mills
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track T. Showalter		Intended status: Standards Track T. Showalter
	Expires: March 20, 2015		Expires: May 16, 2015
	H. Tschofenig		H. Tschofenig
	ARM Ltd.		ARM Ltd.
	September 16, 2014		November 12, 2014
	A set of SASL Mechanisms for OAuth		A set of SASL Mechanisms for OAuth
	draft-ietf-kitten-sasl-oauth-16.txt		draft-ietf-kitten-sasl-oauth-17.txt
	Abstract		Abstract
	OAuth enables a third-party application to obtain limited access to a		OAuth enables a third-party application to obtain limited access to a
	protected resource, either on behalf of a resource owner by		protected resource, either on behalf of a resource owner by
	orchestrating an approval interaction, or by allowing the third-party		orchestrating an approval interaction, or by allowing the third-party
	application to obtain access on its own behalf.		application to obtain access on its own behalf.
	This document defines how an application client uses credentials		This document defines how an application client uses credentials
	obtained via OAuth over the Simple Authentication and Security Layer		obtained via OAuth over the Simple Authentication and Security Layer
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 March 20, 2015.		This Internet-Draft will expire on May 16, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 2, line 31 ¶		skipping to change at page 2, line 31 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. OAuth SASL Mechanism Specifications . . . . . . . . . . . . . 6		3. OAuth SASL Mechanism Specifications . . . . . . . . . . . . . 6
	3.1. Initial Client Response . . . . . . . . . . . . . . . . . 7		3.1. Initial Client Response . . . . . . . . . . . . . . . . . 7
	3.1.1. Reserved Key/Values . . . . . . . . . . . . . . . . . 8		3.1.1. Reserved Key/Values . . . . . . . . . . . . . . . . . 8
	3.2. Server's Response . . . . . . . . . . . . . . . . . . . . 8		3.2. Server's Response . . . . . . . . . . . . . . . . . . . . 8
	3.2.1. OAuth Identifiers in the SASL Context . . . . . . . . 8		3.2.1. OAuth Identifiers in the SASL Context . . . . . . . . 8
	3.2.2. Server Response to Failed Authentication . . . . . . 9		3.2.2. Server Response to Failed Authentication . . . . . . 9
	3.2.3. Completing an Error Message Sequence . . . . . . . . 9		3.2.3. Completing an Error Message Sequence . . . . . . . . 10
	3.3. OAuth Access Token Types using Keyed Message Digests . . 10		3.3. OAuth Access Token Types using Keyed Message Digests . . 10
	4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11		4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.1. Successful Bearer Token Exchange . . . . . . . . . . . . 11		4.1. Successful Bearer Token Exchange . . . . . . . . . . . . 11
	4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 12		4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 12
	4.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 13		4.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 13
	4.4. SMTP Example of a Failed Negotiation . . . . . . . . . . 14		4.4. SMTP Example of a Failed Negotiation . . . . . . . . . . 14
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 14		5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	6. Internationalization Considerations . . . . . . . . . . . . . 16		6. Internationalization Considerations . . . . . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 16		7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 16
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.1. Normative References . . . . . . . . . . . . . . . . . . 17		8.1. Normative References . . . . . . . . . . . . . . . . . . 17
	8.2. Informative References . . . . . . . . . . . . . . . . . 18		8.2. Informative References . . . . . . . . . . . . . . . . . 18
	Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 18		Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 19
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 18		Appendix B. Document History . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	OAuth 1.0a [RFC5849] and OAuth 2.0 [RFC6749] are protocol frameworks		OAuth 1.0a [RFC5849] and OAuth 2.0 [RFC6749] are protocol frameworks
	that enable a third-party application to obtain limited access to a		that enable a third-party application to obtain limited access to a
	protected resource, either on behalf of a resource owner by		protected resource, either on behalf of a resource owner by
	orchestrating an approval interaction, or by allowing the third-party		orchestrating an approval interaction, or by allowing the third-party
	application to obtain access on its own behalf.		application to obtain access on its own behalf.
	The core OAuth 2.0 specification [RFC6749] specifies the interaction		The core OAuth 2.0 specification [RFC6749] specifies the interaction
	skipping to change at page 5, line 27 ¶		skipping to change at page 5, line 27 ¶
	(F) The resource server validates the access token, and if valid,		(F) The resource server validates the access token, and if valid,
	indicates a successful authentication.		indicates a successful authentication.
	Again, steps (E) and (F) are not defined in [RFC6749] (but are		Again, steps (E) and (F) are not defined in [RFC6749] (but are
	described in, for example, [RFC6750] for the OAuth Bearer Token		described in, for example, [RFC6750] for the OAuth Bearer Token
	instead) and are the main functionality specified within this		instead) and are the main functionality specified within this
	document. Consequently, the message exchange shown in Figure 1 is		document. Consequently, the message exchange shown in Figure 1 is
	the result of this specification. The client will generally need to		the result of this specification. The client will generally need to
	determine the authentication endpoints (and perhaps the service		determine the authentication endpoints (and perhaps the service
	endpoints) before the OAuth 2.0 protocol exchange messages in steps		endpoints) before the OAuth 2.0 protocol exchange messages in steps
	(A)-(D) are executed. The discovery of the resource owner and		(A)-(D) are executed. The discovery of the resource owner,
	authorization server endpoints is outside the scope of this		authorization server endpoints, and client registration are outside
	specification. The client must discover those endpoints using a		the scope of this specification. The client must discover the
	discovery mechanism, such as Webfinger using host-meta [RFC7033]. In		authorization endpoints using a discovery mechanism such as OpenID
	band discovery is not tenable if clients support the OAuth 2.0		Connect Discovery [OpenID.Discovery] or Webfinger using host-meta
	password grant. Once credentials are obtained the client proceeds to		[RFC7033]. Once credentials are obtained the client proceeds to
	steps (E) and (F) defined in this specification.		steps (E) and (F) defined in this specification. Authorization
			endpoints MAY require client registration and generic clients SHOULD
			support the Dynamic Client Registration protocol
			[I-D.ietf-oauth-dyn-reg].
	OAuth 1.0 follows a similar model but uses a different terminology		OAuth 1.0 follows a similar model but uses a different terminology
	and does not separate the resource server from the authorization		and does not separate the resource server from the authorization
	server.		server.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	skipping to change at page 7, line 35 ¶		skipping to change at page 7, line 37 ¶
	protocols are allowed to require an authzid, as are specific server		protocols are allowed to require an authzid, as are specific server
	implementations.		implementations.
	The following keys and corresponding values are defined in the client		The following keys and corresponding values are defined in the client
	response:		response:
	auth (REQUIRED): The payload that would be in the HTTP		auth (REQUIRED): The payload that would be in the HTTP
	Authorization header if this OAuth exchange was being carried		Authorization header if this OAuth exchange was being carried
	out over HTTP.		out over HTTP.
	host: Contains the host name to which the client connected, in an		host: Contains the host name to which the client connected. In
	HTTP context this is the value of the HTTP Host header.		an HTTP context this is the value of the HTTP Host header.
	port: Contains the port number represented as a decimal positive		port: Contains the port number represented as a decimal positive
	integer string without leading zeros to which the client		integer string without leading zeros to which the client
	connected.		connected.
	For OAuth token types such as OAuth 1.0a that use keyed message		For OAuth token types such as OAuth 1.0a that use keyed message
	digests the client MUST send host and port number key/values, and the		digests the client MUST send host and port number key/values, and the
	server MUST fail an authorization request requiring keyed message		server MUST fail an authorization request requiring keyed message
	digests that are not accompanied by host and port values. In OAuth		digests that are not accompanied by host and port values. In OAuth
	1.0a for example, the so-called "signature base string calculation"		1.0a for example, the so-called "signature base string calculation"
	skipping to change at page 9, line 32 ¶		skipping to change at page 9, line 32 ¶
	single scope is preferred, use of a space separated list of		single scope is preferred, use of a space separated list of
	scopes is NOT RECOMMENDED.		scopes is NOT RECOMMENDED.
	oauth-configuration (OPTIONAL): The URL for for a document		oauth-configuration (OPTIONAL): The URL for for a document
	following the OpenID Provider Configuration Information schema		following the OpenID Provider Configuration Information schema
	as described in OpenID Connect Discovery [OpenID.Discovery]		as described in OpenID Connect Discovery [OpenID.Discovery]
	section 3 that is appropriate for the user. This document MUST		section 3 that is appropriate for the user. This document MUST
	have all OAuth related data elements populated. The server MAY		have all OAuth related data elements populated. The server MAY
	return different URLs for users in different domains and the		return different URLs for users in different domains and the
	client SHOULD NOT cache a single returned value and assume it		client SHOULD NOT cache a single returned value and assume it
	applies for all users/domains that the server suports.		applies for all users/domains that the server suports. The
			returned discovery document SHOULD have all data elements
			required by the OpenID Connect Discovery specification
			populated. In addition, the discovery document SHOULD contain
			the 'registration_endpoint' element to learn about the endpoint
			to be used with the Dynamic Client Registration protocol
			[I-D.ietf-oauth-dyn-reg] to obtain the minimum number of
			parameters necessary for the OAuth protocol exchange to
			function. Another comparable discovery or client registration
			mechanism MAY be used if available.
			The use of the 'offline_access' scope, as defined in
			[OpenID.Core] is RECOMMENDED to give clients the capability to
			explicitly request a refresh token.
	If the resource server provides a scope then the client MUST always		If the resource server provides a scope then the client MUST always
	request scoped tokens from the token endpoint. If the resource		request scoped tokens from the token endpoint. If the resource
	server provides no scope to the client then the client SHOULD presume		server provides no scope to the client then the client SHOULD presume
	an empty scope (unscoped token) is required to access the resource.		an empty scope (unscoped token) is required to access the resource.
			Since clients may interact with a number of application servers, such
			as email servers and XMPP servers, they need to have a way to
			determine whether dynamic client registration has been performed
			already and whether an already available refresh token can be re-used
			to obtain an access token for the desired resource server. This
			specification RECOMMENDs that a client uses the information in the
			'issue' element to make this determination.
	3.2.3. Completing an Error Message Sequence		3.2.3. Completing an Error Message Sequence
	Section 3.6 of [RFC4422] explicitly prohibits additional information		Section 3.6 of [RFC4422] explicitly prohibits additional information
	in an unsuccessful authentication outcome. Therefore, the error		in an unsuccessful authentication outcome. Therefore, the error
	message is sent in a normal message. The client MUST then send an		message is sent in a normal message. The client MUST then send an
	additional client response consisting of a single %x01 (control A)		additional client response consisting of a single %x01 (control A)
	character to the server in order to allow the server to finish the		character to the server in order to allow the server to finish the
	exchange.		exchange.
	3.3. OAuth Access Token Types using Keyed Message Digests		3.3. OAuth Access Token Types using Keyed Message Digests
	skipping to change at page 13, line 33 ¶		skipping to change at page 13, line 50 ¶
	C: t0 CAPABILITY		C: t0 CAPABILITY
	S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR IMAP4rev1 Server		S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR IMAP4rev1 Server
	Ready		Ready
	S: t0 OK Completed		S: t0 OK Completed
	C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW		C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW
	hvc3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE=		hvc3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE=
	S: + eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJleGFtcGxl		S: + eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJleGFtcGxl
	X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4		X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4
	YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u		YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u
	In0=		In0=
	S: + eyJzdGF0dXMiOiI0MDEiLCJzY29wZSI6ImV4YW1wbGVfc2NvcGUiLCJv
	cGVuaWQtY29uZmlndXJhdGlvbiI6Imh0dHBzOi8vZXhhbXBsZS5jb20v
	LndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24ifQ==
	C: + AQ==		C: + AQ==
	S: t1 NO SASL authentication failed		S: t1 NO SASL authentication failed
	The decoded initial client response is:		The decoded initial client response is:
	n,a=user@example.com,^Ahost=server.example.com^A		n,a=user@example.com,^Ahost=server.example.com^A
	port=143^Aauth=^A^A		port=143^Aauth=^A^A
	The decoded server error response is:		The decoded server error response is:
	{		{
	"status":"invalid_token",		"status":"invalid_token",
	"scope":"example_scope",		"scope":"example_scope",
	skipping to change at page 17, line 4 ¶		skipping to change at page 17, line 17 ¶
	SASL mechanism profile: OAUTH10A		SASL mechanism profile: OAUTH10A
	Security Considerations: See this document		Security Considerations: See this document
	Published Specification: See this document		Published Specification: See this document
	For further information: Contact the authors of this document.		For further information: Contact the authors of this document.
	Owner/Change controller: the IETF		Owner/Change controller: the IETF
	Note: None		Note: None
	8. References		8. References
	8.1. Normative References		8.1. Normative References
			[OpenID.Core]
			Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
			C. Mortimore, "OpenID Connect Core 1.0", February 2014.
	[OpenID.Discovery]		[OpenID.Discovery]
	Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID		Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
	Connect Discovery 1.0", July 2011.		Connect Discovery 1.0", July 2011.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1		[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
	(SHA1)", RFC 3174, September 2001.		(SHA1)", RFC 3174, September 2001.
	skipping to change at page 18, line 7 ¶		skipping to change at page 18, line 21 ¶
	April 2010.		April 2010.
	[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC		[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
	6749, October 2012.		6749, October 2012.
	[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization		[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
	Framework: Bearer Token Usage", RFC 6750, October 2012.		Framework: Bearer Token Usage", RFC 6750, October 2012.
	8.2. Informative References		8.2. Informative References
			[I-D.ietf-oauth-dyn-reg]
			Richer, J., Jones, M., Bradley, J., Machulak, M., and P.
			Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
			draft-ietf-oauth-dyn-reg-20 (work in progress), August
			2014.
	[I-D.ietf-oauth-json-web-token]		[I-D.ietf-oauth-json-web-token]
	Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	(JWT)", draft-ietf-oauth-json-web-token-25 (work in		(JWT)", draft-ietf-oauth-json-web-token-30 (work in
	progress), July 2014.		progress), October 2014.
	[I-D.ietf-oauth-v2-http-mac]		[I-D.ietf-oauth-v2-http-mac]
	Richer, J., Mills, W., Tschofenig, H., and P. Hunt, "OAuth		Richer, J., Mills, W., Tschofenig, H., and P. Hunt, "OAuth
	2.0 Message Authentication Code (MAC) Tokens", draft-ietf-		2.0 Message Authentication Code (MAC) Tokens", draft-ietf-
	oauth-v2-http-mac-05 (work in progress), January 2014.		oauth-v2-http-mac-05 (work in progress), January 2014.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	skipping to change at page 18, line 52 ¶		skipping to change at page 19, line 23 ¶
	Williams, Matt Miller, and Benjamin Kaduk.		Williams, Matt Miller, and Benjamin Kaduk.
	This document was produced under the chairmanship of Alexey Melnikov,		This document was produced under the chairmanship of Alexey Melnikov,
	Tom Yu, Shawn Emery, Josh Howlett, Sam Hartman. The supervising area		Tom Yu, Shawn Emery, Josh Howlett, Sam Hartman. The supervising area
	director was Stephen Farrell.		director was Stephen Farrell.
	Appendix B. Document History		Appendix B. Document History
	[[ to be removed by RFC editor before publication as an RFC ]]		[[ to be removed by RFC editor before publication as an RFC ]]
			-17
			o Last call feedback again. eradicated comma splicing. Removed
			extra server message in example 4.3.
	-16		-16
	o Last call feedback again. Primarily editorial changes. Corrected		o Last call feedback again. Primarily editorial changes. Corrected
	examples.		examples.
	-15		-15
	o Last call feedack on the GS2 stuff being ripped out completely.		o Last call feedack on the GS2 stuff being ripped out completely.
	o Removed the "user" parameter and put stuff back into the		o Removed the "user" parameter and put stuff back into the
	gs2-header. Call out that the authzid goes in the gs2-header with		gs2-header. Call out that the authzid goes in the gs2-header with
	some prose about when it might be required. Very comparable to		some prose about when it might be required. Very comparable to
End of changes. 19 change blocks.
	25 lines changed or deleted		62 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/