draft-ietf-kitten-sasl-oauth-15.txt		draft-ietf-kitten-sasl-oauth-16.txt
	KITTEN W. Mills		KITTEN W. Mills
	Internet-Draft Skype		Internet-Draft Microsoft
	Intended status: Standards Track T. Showalter		Intended status: Standards Track T. Showalter
	Expires: January 23, 2015		Expires: March 20, 2015
	H. Tschofenig		H. Tschofenig
	ARM Ltd.		ARM Ltd.
	July 22, 2014		September 16, 2014
	A set of SASL Mechanisms for OAuth		A set of SASL Mechanisms for OAuth
	draft-ietf-kitten-sasl-oauth-15.txt		draft-ietf-kitten-sasl-oauth-16.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 January 23, 2015.		This Internet-Draft will expire on March 20, 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 32		skipping to change at page 2, line 32
	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 . . . . . . . . 9
	3.3. OAuth Access Token Types using Keyed Message Digests . . 9		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 . . . . . . . . . . 13		4.4. SMTP Example of a Failed Negotiation . . . . . . . . . . 14
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 14		5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	6. Internationalization Considerations . . . . . . . . . . . . . 15		6. Internationalization Considerations . . . . . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 16		7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 16
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.1. Normative References . . . . . . . . . . . . . . . . . . 16		8.1. Normative References . . . . . . . . . . . . . . . . . . 17
	8.2. Informative References . . . . . . . . . . . . . . . . . 17		8.2. Informative References . . . . . . . . . . . . . . . . . 18
	Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 18		Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 18
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 18		Appendix B. Document History . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	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
	skipping to change at page 3, line 36		skipping to change at page 3, line 36
	integrates OAuth 1.0a and OAuth 2.0 into non-HTTP-based applications		integrates OAuth 1.0a and OAuth 2.0 into non-HTTP-based applications
	using the integration into SASL. Hence, this document takes		using the integration into SASL. Hence, this document takes
	advantage of the OAuth protocol and its deployment base to provide a		advantage of the OAuth protocol and its deployment base to provide a
	way to use the Simple Authentication and Security Layer (SASL)		way to use the Simple Authentication and Security Layer (SASL)
	[RFC4422] to gain access to resources when using non-HTTP-based		[RFC4422] to gain access to resources when using non-HTTP-based
	protocols, such as the Internet Message Access Protocol (IMAP)		protocols, such as the Internet Message Access Protocol (IMAP)
	[RFC3501] and the Simple Mail Transfer Protocol (SMTP) [RFC5321],		[RFC3501] and the Simple Mail Transfer Protocol (SMTP) [RFC5321],
	which is what this memo uses in the examples.		which is what this memo uses in the examples.
	To illustrate the impact of integrating this specification into an		To illustrate the impact of integrating this specification into an
	OAuth-enabled application environment Figure 1 shows the abstract		OAuth-enabled application environment, Figure 1 shows the abstract
	message flow of OAuth 2.0 [RFC6749]. As indicated in the figure,		message flow of OAuth 2.0 [RFC6749]. As indicated in the figure,
	this document impacts the exchange of messages (E) and (F) since SASL		this document impacts the exchange of messages (E) and (F) since SASL
	is used for interaction between the client and the resource server		is used for interaction between the client and the resource server
	instead of HTTP.		instead of HTTP.
	----+		----+
	+--------+ +---------------+ |		+--------+ +---------------+ |
	| |--(A)-- Authorization Request --->| Resource | |		| |--(A)-- Authorization Request --->| Resource | |
	| | | Owner | |Plain		| | | Owner | |Plain
	| |<-(B)------ Access Grant ---------| | |OAuth		| |<-(B)------ Access Grant ---------| | |OAuth
	skipping to change at page 4, line 37		skipping to change at page 4, line 37
	Figure 1: OAuth 2.0 Protocol Flow		Figure 1: OAuth 2.0 Protocol Flow
	The Simple Authentication and Security Layer (SASL) is a framework		The Simple Authentication and Security Layer (SASL) is a framework
	for providing authentication and data security services in		for providing authentication and data security services in
	connection-oriented protocols via replaceable authentication		connection-oriented protocols via replaceable authentication
	mechanisms. It provides a structured interface between protocols and		mechanisms. It provides a structured interface between protocols and
	mechanisms. The resulting framework allows new protocols to reuse		mechanisms. The resulting framework allows new protocols to reuse
	existing authentication protocols and allows old protocols to make		existing authentication protocols and allows old protocols to make
	use of new authentication mechanisms. The framework also provides a		use of new authentication mechanisms. The framework also provides a
	protocol for securing subsequent protocol exchanges within a data		protocol for securing subsequent exchanges within a data security
	security layer.		layer.
	When OAuth is integrated into SASL the high-level steps are as		When OAuth is integrated into SASL the high-level steps are as
	follows:		follows:
	(A) The client requests authorization from the resource owner.		(A) The client requests authorization from the resource owner.
	The authorization request can be made directly to the resource		The authorization request can be made directly to the resource
	owner (as shown), or preferably indirectly via the authorization		owner (as shown), or preferably indirectly via the authorization
	server as an intermediary.		server as an intermediary.
	(B) The client receives an authorization grant which is a		(B) The client receives an authorization grant which is a
	skipping to change at page 5, line 30		skipping to change at page 5, line 30
	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 and
	authorization server endpoints is outside the scope of this		authorization server endpoints is outside the scope of this
	specification. The client must discover those endpoints using a		specification. The client must discover those endpoints using a
	discovery mechanisms, such as Webfinger using host-meta [RFC7033].		discovery mechanism, such as Webfinger using host-meta [RFC7033]. In
	In band discovery is not tenable if clients support the OAuth 2.0		band discovery is not tenable if clients support the OAuth 2.0
	password grant. Once credentials are obtained the client proceeds to		password grant. Once credentials are obtained the client proceeds to
	steps (E) and (F) defined in this specification.		steps (E) and (F) defined in this specification.
	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",
	skipping to change at page 7, line 7		skipping to change at page 7, line 7
	1. Client sends an invalid initial client response.		1. Client sends an invalid initial client response.
	2. Server responds with an error message.		2. Server responds with an error message.
	3. Client sends a dummy client response.		3. Client sends a dummy client response.
	4. Server fails the authentication.		4. Server fails the authentication.
	3.1. Initial Client Response		3.1. Initial Client Response
	Client responses are a GS2 [RFC5801] header followed by a key/value		Client responses are a GS2 [RFC5801] header followed by zero or more
	pair sequence, or may be empty. The gs2-header is defined here for		key/value pairs, or may be empty. The gs2-header is defined here for
	compatibility with GS2 if a GS2 mechanism is formally defined, but		compatibility with GS2 if a GS2 mechanism is formally defined, but
	this document does not define one. These key/value pairs carry the		this document does not define one. These key/value pairs take the
	equivalent values from an HTTP context in order to be able to		place of the corresponding HTTP headers and values to convey the
	complete an OAuth style HTTP authorization. Unknown key/value pairs		information necessary to complete an OAuth style HTTP authorization.
	MUST be ignored by the server. The ABNF [RFC5234] syntax is:		Unknown key/value pairs MUST be ignored by the server. The ABNF
			[RFC5234] syntax is:
	kvsep = %x01		kvsep = %x01
	key = 1*(ALPHA / ",")		key = 1*(ALPHA / ",")
	value = *(VCHAR / SP / HTAB / CR / LF )		value = *(VCHAR / SP / HTAB / CR / LF )
	kvpair = key "=" value kvsep		kvpair = key "=" value kvsep
	;;gs2-header = See RFC 5801		;;gs2-header = See RFC 5801
	client_resp = (gs2-header kvsep 0*kvpair kvsep) / kvsep		client_resp = (gs2-header kvsep 0*kvpair kvsep) / kvsep
	The GS2 header MAY include the user name associated with the resource		The GS2 header MAY include the user name associated with the resource
	being accessed, the "authzid". It is worth noting that application		being accessed, the "authzid". It is worth noting that application
	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 key/value pairs are defined in the client response:		The following keys and corresponding values are defined in the client
			response:
	auth (REQUIRED): The payload of the HTTP Authorization header for		auth (REQUIRED): The payload that would be in the HTTP
	an equivalent HTTP OAuth authorization.		Authorization header if this OAuth exchange was being carried
			out over HTTP.
	host: Contains the host name to which the client connected.		host: Contains the host name to which the client connected, in 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.
	qs: The HTTP query string. This is reserved for future use, the		For OAuth token types such as OAuth 1.0a that use keyed message
	client SHOUD NOT send it, and has the default value of "".		digests the client MUST send host and port number key/values, and the
			server MUST fail an authorization request requiring keyed message
	For OAuth token types that use keyed message digests the client MUST		digests that are not accompanied by host and port values. In OAuth
	send host and port number key/values, and the server MUST fail an		1.0a for example, the so-called "signature base string calculation"
	authorization request requiring keyed message digests that do not		includes the reconstructed HTTP URL.
	have host and port values. In OAuth 1.0a for example, the so-called
	"signature base string calculation" includes the reconstructed HTTP
	URL.
	3.1.1. Reserved Key/Values		3.1.1. Reserved Key/Values
	In these mechanisms values for path, query string and post body are		In these mechanisms values for path, query string and post body are
	assigned default values. OAuth authorization schemes MAY define		assigned default values. OAuth authorization schemes MAY define
	usage of these in the SASL context and extend this specification.		usage of these in the SASL context and extend this specification.
	For OAuth Access Token Types that use request keyed message digest		For OAuth Access Token Types that use request keyed message digest
	the default values MUST be used unless explicit values are provided		the default values MUST be used unless explicit values are provided
	in the client response. The following key values are reserved for		in the client response. The following key values are reserved for
	future use:		future use:
	mthd (RESERVED): HTTP method, the default value is "POST".		mthd (RESERVED): HTTP method, the default value is "POST".
	path (RESERVED): HTTP path data, the default value is "/".		path (RESERVED): HTTP path data, the default value is "/".
	post (RESERVED): HTTP post data, the default value is "".		post (RESERVED): HTTP post data, the default value is "".
			qs (RESERVED): The HTTP query string, the default value is "".
	3.2. Server's Response		3.2. Server's Response
	The server validates the response per the specification for the OAuth		The server validates the response according the specification for the
	Access Token Types used. If the OAuth Access Token Type utilizes a		OAuth Access Token Types used. If the OAuth Access Token Type
	keyed message digest of the request parameters then the client must		utilizes a keyed message digest of the request parameters then the
	provide a client response that satisfies the data requirements for		client must provide a client response that satisfies the data
	the scheme in use.		requirements for the scheme in use.
	The server responds to a successfully verified client message by		The server responds to a successfully verified client message by
	completing the SASL negotiation. The authenticated identity reported		completing the SASL negotiation. The authenticated identity reported
	by the SASL mechanism is the identity securely established for the		by the SASL mechanism is the identity securely established for the
	client with the OAuth credential. The application, not the SASL		client with the OAuth credential. The application, not the SASL
	mechanism, based on local access policy determines whether the		mechanism, based on local access policy determines whether the
	identity reported by the mechanism is allowed access to the requested		identity reported by the mechanism is allowed access to the requested
	resource. Note that the semantics of the authz-id is specified by		resource. Note that the semantics of the authz-id is specified by
	the SASL framework [RFC4422].		the SASL framework [RFC4422].
	skipping to change at page 9, line 33		skipping to change at page 9, line 37
	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.
	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 needed.		an empty scope (unscoped token) is required to access the resource.
	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.
	skipping to change at page 11, line 7		skipping to change at page 11, line 11
	In this example the signature base string with line breaks added for		In this example the signature base string with line breaks added for
	readability would be:		readability would be:
	POST&http%3A%2F%2Fexample.com:143%2F&oauth_consumer_key%3D9djdj82h4		POST&http%3A%2F%2Fexample.com:143%2F&oauth_consumer_key%3D9djdj82h4
	8djs9d2%26oauth_nonce%3D7d8f3e4a%26oauth_signature_method%3DHMAC-SH		8djs9d2%26oauth_nonce%3D7d8f3e4a%26oauth_signature_method%3DHMAC-SH
	A1%26oauth_timestamp%3D137131201%26oauth_token%3Dkkk9d7dh3k39sjv7		A1%26oauth_timestamp%3D137131201%26oauth_token%3Dkkk9d7dh3k39sjv7
	4. Examples		4. Examples
	These examples illustrate exchanges between an IMAP and SMTP clients		These examples illustrate exchanges between IMAP and SMTP clients and
	and servers.		servers.
	Note to implementers: The SASL OAuth method names are case		Note to implementers: The SASL OAuth method names are case
	insensitive. One example uses "Bearer" but that could as easily be		insensitive. One example uses "Bearer" but that could as easily be
	"bearer", "BEARER", or "BeArEr".		"bearer", "BEARER", or "BeArEr".
	4.1. Successful Bearer Token Exchange		4.1. Successful Bearer Token Exchange
	This example shows a successful OAuth 2.0 bearer token exchange.		This example shows a successful OAuth 2.0 bearer token exchange in
	Note that line breaks are inserted for readability and the underlying		IMAP. Note that line breaks are inserted for readability and the
	TLS establishment is not shown either.		underlying TLS establishment is not shown either.
	S: * OK IMAP4rev1 Server Ready		S: * OK IMAP4rev1 Server Ready
	C: t0 CAPABILITY		C: t0 CAPABILITY
	S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR		S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR
	S: t0 OK Completed		S: t0 OK Completed
	C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c2		C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c2
	VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9QmVhcmVyIHZGOWRmdDRxb		VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9QmVhcmVyIHZGOWRmdDRxb
	VRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB		VRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB
	S: t1 OK SASL authentication succeeded		S: t1 OK SASL authentication succeeded
	skipping to change at page 12, line 22		skipping to change at page 12, line 22
	S: 250-ENHANCEDSTATUSCODES		S: 250-ENHANCEDSTATUSCODES
	S: 250 PIPELINING		S: 250 PIPELINING
	C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c		C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c
	2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9QmVhcmVyIHZGOWRmdDR		2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9QmVhcmVyIHZGOWRmdDR
	xbVRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB		xbVRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB
	S: 235 Authentication successful.		S: 235 Authentication successful.
	[connection continues...]		[connection continues...]
	4.2. Successful OAuth 1.0a Token Exchange		4.2. Successful OAuth 1.0a Token Exchange
	This example shows a successful OAuth 1.0a token exchange. Note that		This IMAP example shows a successful OAuth 1.0a token exchange. Note
	line breaks are inserted for readability and the underlying TLS		that line breaks are inserted for readability and the underlying TLS
	establishment is not shown. Signature computation is discussed in		establishment is not shown. Signature computation is discussed in
	Section 3.3.		Section 3.3.
	S: * OK IMAP4rev1 Server Ready		S: * OK IMAP4rev1 Server Ready
	C: t0 CAPABILITY		C: t0 CAPABILITY
	S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER OAUTH10A SASL-IR		S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER OAUTH10A SASL-IR
	S: t0 OK Completed		S: t0 OK Completed
	C: t1 AUTHENTICATE OAUTH10A bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9ZXhhb		C: t1 AUTHENTICATE OAUTH10A bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9ZXhhb
	XBsZS5jb20BcG9ydD0xNDMBYXV0aD1PQXV0aCByZWFsbT0iRXhhbXBsZSIsb2F1		XBsZS5jb20BcG9ydD0xNDMBYXV0aD1PQXV0aCByZWFsbT0iRXhhbXBsZSIsb2F1
	dGhfY29uc3VtZXJfa2V5PSI5ZGpkajgyaDQ4ZGpzOWQyIixvYXV0aF90b2tlbj0		dGhfY29uc3VtZXJfa2V5PSI5ZGpkajgyaDQ4ZGpzOWQyIixvYXV0aF90b2tlbj0
	skipping to change at page 13, line 18		skipping to change at page 13, line 18
	auth=OAuth realm="Example",		auth=OAuth realm="Example",
	oauth_consumer_key="9djdj82h48djs9d2",		oauth_consumer_key="9djdj82h48djs9d2",
	oauth_token="kkk9d7dh3k39sjv7",		oauth_token="kkk9d7dh3k39sjv7",
	oauth_signature_method="HMAC-SHA1",		oauth_signature_method="HMAC-SHA1",
	oauth_timestamp="137131201",		oauth_timestamp="137131201",
	oauth_nonce="7d8f3e4a",		oauth_nonce="7d8f3e4a",
	oauth_signature="SSdtIGEgbGl0dGxlIHRlYSBwb3Qu"^A^A		oauth_signature="SSdtIGEgbGl0dGxlIHRlYSBwb3Qu"^A^A
	4.3. Failed Exchange		4.3. Failed Exchange
	This example shows a failed exchange because of the empty		This IMAP example shows a failed exchange because of the empty
	Authorization header, which is how a client can query for the needed		Authorization header, which is how a client can query for the needed
	scope. Note that line breaks are inserted for readability.		scope. Note that line breaks are inserted for readability.
			S: * OK IMAP4rev1 Server Ready
			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
			X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4
			YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u
			In0=
	S: + eyJzdGF0dXMiOiI0MDEiLCJzY29wZSI6ImV4YW1wbGVfc2NvcGUiLCJv		S: + eyJzdGF0dXMiOiI0MDEiLCJzY29wZSI6ImV4YW1wbGVfc2NvcGUiLCJv
	cGVuaWQtY29uZmlndXJhdGlvbiI6Imh0dHBzOi8vZXhhbXBsZS5jb20v		cGVuaWQtY29uZmlndXJhdGlvbiI6Imh0dHBzOi8vZXhhbXBsZS5jb20v
	LndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24ifQ==		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":"401",		"status":"invalid_token",
	"scope":"example_scope",		"scope":"example_scope",
	"openid-configuration":"https://example.com/.well-known/openid-configuration"		"openid-configuration":"https://example.com/.well-known/openid-configuration"
	}		}
			The client responds with the required dummy response, "AQ==" is the
	The client responds with the required dummy response.		base64 encoding of the ASCII value 0x01.
	4.4. SMTP Example of a Failed Negotiation		4.4. SMTP Example of a Failed Negotiation
	This example shows an authorization failure in an SMTP exchange.		This example shows an authorization failure in an SMTP exchange.
	Note that line breaks are inserted for readability, and that the SMTP		Note that line breaks are inserted for readability, and that the SMTP
	protocol terminates lines with CR and LF characters (ASCII values		protocol terminates lines with CR and LF characters (ASCII values
	0x0D and 0x0A), these are not displayed explicitly in the example.		0x0D and 0x0A), these are not displayed explicitly in the example.
	[connection begins]		[connection begins]
	S: 220 mx.example.com ESMTP 12sm2095603fks.9		S: 220 mx.example.com ESMTP 12sm2095603fks.9
	skipping to change at page 15, line 39		skipping to change at page 15, line 46
	application protocols where connections are long-lived, and not a		application protocols where connections are long-lived, and not a
	problem with this mechanism per se. Resource servers may		problem with this mechanism per se. Resource servers may
	unilaterally disconnect clients in accordance with the application		unilaterally disconnect clients in accordance with the application
	protocol.		protocol.
	Access tokens have a lifetime.		Access tokens have a lifetime.
	Reducing the lifetime of an access token provides security		Reducing the lifetime of an access token provides security
	benefits and OAuth 2.0 introduces refresh tokens to obtain new		benefits and OAuth 2.0 introduces refresh tokens to obtain new
	access token on the fly without any need for a human interaction.		access token on the fly without any need for a human interaction.
	Additionally, a previously obtained access token may be revoked or		Additionally, a previously obtained access token might be revoked
	rendered invalid at any time. The client may request a new access		or rendered invalid at any time. The client MAY request a new
	token for each connection to a resource server, but it SHOULD		access token for each connection to a resource server, but it
	cache and re-use valid credentials.		SHOULD cache and re-use valid credentials.
	6. Internationalization Considerations		6. Internationalization Considerations
	The identifer asserted by the OAuth authorization server about the		The identifer asserted by the OAuth authorization server about the
	resource owner inside the access token may be displayed to a human.		resource owner inside the access token may be displayed to a human.
	For example, when SASL is used in the context of IMAP the resource		For example, when SASL is used in the context of IMAP the client may
	server may assert the resource owner's email address to the IMAP		assert the resource owner's email address to the IMAP server for
	server for usage in an email-based application. The identifier may		usage in an email-based application. The identifier may therefore
	therefore contain internationalized characters and an application		contain internationalized characters and an application needs to
	needs to ensure that the mapping between the identifier provided by		ensure that the mapping between the identifier provided by OAuth is
	OAuth is suitable for use with the application layer protocol SASL is		suitable for use with the application layer protocol SASL is
	incorporated into.		incorporated into.
	At the time of writing the standardization of the various claims in		At the time of writing the standardization of the various claims in
	the access token (in JSON format) is still ongoing, see		the access token (in JSON format) is still ongoing, see
	[I-D.ietf-oauth-json-web-token]. Once completed it will provide a		[I-D.ietf-oauth-json-web-token]. Once completed it will provide a
	standardized format for exchanging identity information between the		standardized format for exchanging identity information between the
	authorization server and the resource server.		authorization server and the resource server.
	7. IANA Considerations		7. IANA Considerations
	skipping to change at page 18, line 30		skipping to change at page 18, line 42
	January 2013.		January 2013.
	[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr,		[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
	"WebFinger", RFC 7033, September 2013.		"WebFinger", RFC 7033, September 2013.
	Appendix A. Acknowlegements		Appendix A. Acknowlegements
	The authors would like to thank the members of the Kitten working		The authors would like to thank the members of the Kitten working
	group, and in addition and specifically: Simon Josefson, Torsten		group, and in addition and specifically: Simon Josefson, Torsten
	Lodderstadt, Ryan Troll, Alexey Melnikov, Jeffrey Hutzelman, Nico		Lodderstadt, Ryan Troll, Alexey Melnikov, Jeffrey Hutzelman, Nico
	Williams, and Matt Miller.		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 ]]
			-16
			o Last call feedback again. Primarily editorial changes. Corrected
			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
	-10.		-10.
	o Added an OAuth 1.0A example explicitly.		o Added an OAuth 1.0A example explicitly.
	skipping to change at page 21, line 28		skipping to change at page 21, line 45
	-00		-00
	o Renamed draft into proper IETF naming format now that it's		o Renamed draft into proper IETF naming format now that it's
	adopted.		adopted.
	o Minor fixes.		o Minor fixes.
	Authors' Addresses		Authors' Addresses
	William Mills		William Mills
	Skype		Microsoft
	Email: wmills_92105@yahoo.com		Email: wimills@microsoft.com
	Tim Showalter		Tim Showalter
	Email: tjs@psaux.com		Email: tjs@psaux.com
	Hannes Tschofenig		Hannes Tschofenig
	ARM Ltd.		ARM Ltd.
	110 Fulbourn Rd		110 Fulbourn Rd
	Cambridge CB1 9NJ		Cambridge CB1 9NJ
	Great Britain		Great Britain
	Email: Hannes.tschofenig@gmx.net		Email: Hannes.tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at		URI: http://www.tschofenig.priv.at
End of changes. 36 change blocks.
	66 lines changed or deleted		78 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/