draft-ietf-kitten-sasl-oauth-02.txt		draft-ietf-kitten-sasl-oauth-03.txt
	KITTEN W. Mills		KITTEN W. Mills
	Internet-Draft Yahoo! Inc.		Internet-Draft Yahoo! Inc.
	Intended status: Standards Track T. Showalter		Intended status: Standards Track T. Showalter
	Expires: February 5, 2013		Expires: February 7, 2013
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	August 4, 2012		August 6, 2012
	A SASL and GSS-API Mechanism for OAuth		A SASL and GSS-API Mechanism for OAuth
	draft-ietf-kitten-sasl-oauth-02		draft-ietf-kitten-sasl-oauth-03
	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 OAuth over the		This document defines how an application client uses OAuth over the
	Simple Authentication and Security Layer (SASL) or the Generic		Simple Authentication and Security Layer (SASL) or the Generic
	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 February 5, 2013.		This Internet-Draft will expire on February 7, 2013.
	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 10, line 19		skipping to change at page 10, line 19
	For a failed authentication the server returns a JSON [RFC4627]		For a failed authentication the server returns a JSON [RFC4627]
	formatted error result, and fails the authentication. The error		formatted error result, and fails the authentication. The error
	result consists of the following values:		result consists of the following values:
	status (REQUIRED): The authorization error code. Valid error		status (REQUIRED): The authorization error code. Valid error
	codes are defined in the IANA [[need registry name]] registry		codes are defined in the IANA [[need registry name]] registry
	specified in the OAuth 2 core specification.		specified in the OAuth 2 core specification.
	schemes (REQUIRED): A space separated list of the OAuth		schemes (REQUIRED): A space separated list of the OAuth
	authroization schemes supported by the server, i.e. "bearer" or		authorization schemes supported by the server, i.e. "bearer" or
	"bearer mac".		"bearer mac".
	scope (OPTIONAL): The OAuth scope required to access the service.		scope (OPTIONAL): The OAuth scope required to access the service.
	If the resource server provides a scope the client SHOULD always		If the resource server provides a scope the client SHOULD always
	request scoped tokens from the token endpoint. The client MAY use a		request scoped tokens from the token endpoint. The client MAY use a
	scope other than the one provided by the resource server. Scopes		scope other than the one provided by the resource server. Scopes
	other than those advertised by the resource server are be defined by		other than those advertised by the resource server are be defined by
	the resource owner and provided in service documentation or discovery		the resource owner and provided in service documentation or discovery
	information (which is beyond the scope of this memo). If not present		information (which is beyond the scope of this memo). If not present
	skipping to change at page 11, line 11		skipping to change at page 11, line 11
	request which allow the signature base string to be constructed		request which allow the signature base string to be constructed
	properly. The default HTTP path is "/" and the default post body is		properly. The default HTTP path is "/" and the default post body is
	empty. These atoms are defined as extension points so that no		empty. These atoms are defined as extension points so that no
	changes are needed if there is a revision of SASL which supports more		changes are needed if there is a revision of SASL which supports more
	specific resource authorization, e.g. IMAP access to a specific		specific resource authorization, e.g. IMAP access to a specific
	folder or FTP access limited to a specific directory.		folder or FTP access limited to a specific directory.
	Using the example in the MAC specification		Using the example in the MAC specification
	[I-D.ietf-oauth-v2-http-mac] as a starting point, on an IMAP server		[I-D.ietf-oauth-v2-http-mac] as a starting point, on an IMAP server
	running on port 143 and given the MAC style authorization request		running on port 143 and given the MAC style authorization request
	(with %x01 shown as ^A and long lines wrapped for readability) below:		(with %x01 shown as ^A and line breaks added for readability) below:
	host=server.example.com^A		host=server.example.com^A
			user=user@example.com^A
	port=143^A		port=143^A
	auth=MAC token="h480djs93hd8",timestamp="137131200",nonce="dj83hs9s",		auth=MAC token="h480djs93hd8",timestamp="137131200",nonce="dj83hs9s",
	signature="YTVjyNSujYs1WsDurFnvFi4JK6o="^A^A		signature="YTVjyNSujYs1WsDurFnvFi4JK6o="^A^A
	The normalized request string would be constructed per the MAC		The normalized request string would be constructed per the MAC
	specification [I-D.ietf-oauth-v2-http-mac]. In this example the		specification [I-D.ietf-oauth-v2-http-mac]. In this example the
	normalized request string with the new line separator character is		normalized request string with the new line separator character is
	represented by "\n" for display purposes only would be:		represented by "\n" for display purposes only would be:
	h480djs93hi8\n		h480djs93hi8\n
	skipping to change at page 14, line 10		skipping to change at page 14, line 10
	Section 4). The exported name token does, of course, conform to		Section 4). The exported name token does, of course, conform to
	[RFC2743], Section 3.2, but the "NAME" part of the token should be		[RFC2743], Section 3.2, but the "NAME" part of the token should be
	treated as a potential input string to the OAuth name normalization		treated as a potential input string to the OAuth name normalization
	rules.		rules.
	5. Examples		5. Examples
	These example illustrate exchanges between an IMAP client and an IMAP		These example illustrate exchanges between an IMAP client and an IMAP
	server.		server.
			Note to implementers: Authorization scheme names are case
			insensitive. One example uses "Bearer" but that could as easily be
			"bearer", "BEARER", or "BeArEr".
	5.1. Successful Bearer Token Exchange		5.1. Successful Bearer Token Exchange
	This example shows a successful OAuth 2.0 bearer token exchange with		This example shows a successful OAuth 2.0 bearer token exchange with
	an initial client response. Note that line breaks are inserted for		an initial client response. Note that line breaks are inserted for
	readability.		readability.
	S: * IMAP4rev1 Server Ready		S: * IMAP4rev1 Server Ready
	C: t0 CAPABILITY		C: t0 CAPABILITY
	S: * CAPABILITY IMAP4rev1 AUTH=OAUTH		S: * CAPABILITY IMAP4rev1 AUTH=OAUTH
	S: t0 OK Completed		S: t0 OK Completed
	C: t1 AUTHENTICATE OAUTH aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xNDMB		C: t1 AUTHENTICATE OAUTH aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xNDMB
	YXV0aD1CRUFSRVIgdkY5ZGZ0NHFtVGMyTnZiM1JsY2tCaGJIUmhkbWx6ZEdFdVk		dXNlcj11c2VyQGV4YW1wbGUuY29tAWF1dGg9QmVhcmVyIHZGOWRmdDRxbVRjMk5
	yOXRDZz09AQE=		2YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB
	S: +		S: +
	S: t1 OK SASL authentication succeeded		S: t1 OK SASL authentication succeeded
	As required by IMAP [RFC3501], the payloads are base64-encoded. The		As required by IMAP [RFC3501], the payloads are base64-encoded. The
	decoded initial client response (with %x01 represented as ^A and long		decoded initial client response (with %x01 represented as ^A and long
	lines wrapped for readability) is:		lines wrapped for readability) is:
	host=server.example.com^Aport=143^A		host=server.example.com^Aport=143^Auser=user@example.com^A
	auth=BEARER "vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=="^A^A		auth=Bearer vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg==^A^A
	The line containing just a "+" and a space is an empty response from		The line containing just a "+" and a space is an empty response from
	the server. This response contains error information, and in the		the server. This response contains error information, and in the
	success case the error response is empty. Like other messages, and		success case the error response is empty. Like other messages, and
	in accordance with the IMAP SASL binding, the empty response is		in accordance with the IMAP SASL binding, the empty response is
	base64-encoded.		base64-encoded.
	5.2. MAC Authentication with Channel Binding		5.2. MAC Authentication with Channel Binding
	This example shows a channel binding failure. The example sends the		This example shows a channel binding failure. The example sends the
	same request as above, but in the context of an OAUTH-PLUS exchange		same request as above, but in the context of an OAUTH-PLUS exchange
	the channel binding information is missing. Note that line breaks		the channel binding information is missing. Note that line breaks
	are inserted for readability.		are inserted for readability.
	S: * CAPABILITY IMAP4rev1 AUTH=OAUTH SASL-IR IMAP4rev1 Server Ready		S: * CAPABILITY IMAP4rev1 AUTH=OAUTH SASL-IR IMAP4rev1 Server Ready
	S: t0 OK Completed		S: t0 OK Completed
	C: t1 AUTHENTICATE MAC aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xNDMBYXV0a		C: t1 AUTHENTICATE OAUTH-PLUS aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BdXNlcj11c2
	D1NQUMgdG9rZW49Img0ODBkanM5M2hkOCIsdGltZXN0YW1wPSIxMzcxMzEyMDAiLG5vbm		VyQGV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9TUFDIHRva2VuPSJoNDgwZGpzOTNo
	NlPSJkajgzaHM5cyIsc2lnbmF0dXJlPSJZVFZqeU5TdWpZczFXc0R1ckZudkZpNEpLNm8		ZDgiLHRpbWVzdGFtcD0iMTM3MTMxMjAwIixub25jZT0iZGo4M2hzOXMiLHNpZ25hdH
	9IgFjYmRhdGE9U0c5M0lHSnBaeUJwY3lCaElGUk1VeUJtYVc1aGJDQnRaWE56WVdkbFB3		VyZT0iWVRWanlOU3VqWXMxV3NEdXJGbnZGaTRKSzZvPSIBY2JkYXRhPVNHOTNJR0pw
	bz0BAQ==		WnlCcGN5QmhJRlJNVXlCbWFXNWhiQ0J0WlhOellXZGxQd289AQE=
	S: +		S: +
	S: t1 OK SASL authentication succeeded		S: t1 OK SASL authentication succeeded
	As required by IMAP [RFC3501], the payloads are base64-encoded. The		As required by IMAP [RFC3501], the payloads are base64-encoded. The
	decoded initial client response (with %x01 represented as ^A and long		decoded initial client response (with %x01 represented as ^A and long
	lines wrapped for readability) is:		lines wrapped for readability) is:
	-		-
	host=server.example.com^A		host=server.example.com^A
			user=user@example.com^A
	port=143^A		port=143^A
	auth=MAC token="h480djs93hd8",timestamp="137131200",nonce="dj83hs9s",		auth=MAC token="h480djs93hd8",timestamp="137131200",nonce="dj83hs9s",
	signature="YTVjyNSujYs1WsDurFnvFi4JK6o="^A		signature="YTVjyNSujYs1WsDurFnvFi4JK6o="^A
	cbdata=SG93IGJpZyBpcyBhIFRMUyBmaW5hbCBtZXNzYWdlPwo=^A^A		cbdata=SG93IGJpZyBpcyBhIFRMUyBmaW5hbCBtZXNzYWdlPwo=^A^A
	The line containing just a "+" and a space is an empty response from		The line containing just a "+" and a space is an empty response from
	the server. This response contains discovery information, and in the		the server. This response contains discovery information, and in the
	success case no discovery information is necessary so the response is		success case no discovery information is necessary so the response is
	empty. Like other messages, and in accordance with the IMAP SASL		empty. Like other messages, and in accordance with the IMAP SASL
	binding, the empty response is base64-encoded.		binding, the empty response is base64-encoded.
	5.3. Failed Exchange		5.3. Failed Exchange
	This example shows a failed exchange because of the empty		This 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: * CAPABILITY IMAP4rev1 AUTH=OAUTH SASL-IR IMAP4rev1 Server Ready		S: * CAPABILITY IMAP4rev1 AUTH=OAUTH SASL-IR IMAP4rev1 Server Ready
	S: t0 OK Completed		S: t0 OK Completed
	C: t1 AUTHENTICATE OAUTH aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xND		C: t1 AUTHENTICATE OAUTH aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BdXNlcj11
	MBYXV0aD0BAQ==		c2VyQGV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE=
	S: + ewoic3RhdHVzIjoiNDAxIiwKInNjb3BlIjoiZXhhbXBsZV9zY29wZSIKfQo=		S: + eyJzdGF0dXMiOiI0MDEiLCJzY2hlbWVzIjoiYmVhcmVyIG1hYyIsInNjb3Bl
			IjoiZXhhbXBsZV9zY29wZSJ9
	S: t1 NO SASL authentication failed		S: t1 NO SASL authentication failed
	The decoded initial client response is:		The decoded initial client response is:
	host=server.example.com^Aport=143^Aauth=^A^A		host=server.example.com^Auser=user@example.com^Aport=143^Aauth=^A^A
	The decoded server error response is:		The decoded server error response is:
	{		{
	"status":"401",		"status":"401",
			"schemes":"bearer mac",
	"scope":"example_scope"		"scope":"example_scope"
	}		}
	5.4. Failed Channel Binding		5.4. Failed Channel Binding
	This example shows a channel binding failure in an empty request.		This example shows a channel binding failure in an empty request.
	The channel binding information is empty. Note that line breaks are		The channel binding information is empty. Note that line breaks are
	inserted for readability.		inserted for readability.
	S: * CAPABILITY IMAP4rev1 AUTH=OAUTH SASL-IR IMAP4rev1 Server Ready		S: * CAPABILITY IMAP4rev1 AUTH=OAUTH SASL-IR IMAP4rev1 Server Ready
	S: t0 OK Completed		S: t0 OK Completed
	C: t1 AUTHENTICATE OAUTH aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xND		C: t1 AUTHENTICATE OAUTH aG9zdD1zZXJ2ZXIuZXhhbXBsZS5jb20BdXNlcj11
	MBYXV0aD0BY2JkYXRhPQEB		c2VyQGV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AWNiZGF0YT0BAQ==
	S: + ewoic3RhdHVzIjoiNDEyIiwKInNjb3BlIjoiZXhhbXBsZV9zY29wZSIKfQ==		S: + eyJzdGF0dXMiOiI0MTIiLCJzY2hlbWVzIjoiYmVhcmVyIG1hYyIsInNjb3Bl
			IjoiZXhhbXBsZV9zY29wZSJ9
	S: t1 NO SASL authentication failed		S: t1 NO SASL authentication failed
	The decoded initial client response is:		The decoded initial client response is:
	host=server.example.com^Aport=143^Aauth=^Acbdata=^A^A		host=server.example.com^Auser=user@example.com^Aport=143^A
			auth=^Acbdata=^A^A
	The decoded server response is:		The decoded server response is:
	{		{
	"status":"412",		"status":"412",
			"schemes":"bearer mac",
	"scope":"example_scope"		"scope":"example_scope"
	}		}
	6. Security Considerations		6. Security Considerations
	This mechanism does not provide a security layer, but does provide a		This mechanism does not provide a security layer, but does provide a
	provision for channel binding. The OAuth 2 specification		provision for channel binding. The OAuth 2 specification
	[I-D.ietf-oauth-v2] allows for a variety of usages, and the security		[I-D.ietf-oauth-v2] allows for a variety of usages, and the security
	properties of these profiles vary. The usage of bearer tokens, for		properties of these profiles vary. The usage of bearer tokens, for
	example, provide security features similar to cookies. Applications		example, provide security features similar to cookies. Applications
	skipping to change at page 21, line 9		skipping to change at page 21, line 9
	draft-jones-appsawg-webfinger-06 (work in progress),		draft-jones-appsawg-webfinger-06 (work in progress),
	June 2012.		June 2012.
	[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION		[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
	4rev1", RFC 3501, March 2003.		4rev1", RFC 3501, March 2003.
	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 ]]
			-03
			o Added user field into examples and fixed egregious errors there as
			well.
			o Added text reminding developers that Authorization scheme names
			are case insensitive.
	-02		-02
	o Added the user data element back in.		o Added the user data element back in.
	o Minor editorial changes.		o Minor editorial changes.
	-01		-01
	o Ripping out discovery. Changed to refer to I-D.jones-appsawg-		o Ripping out discovery. Changed to refer to I-D.jones-appsawg-
	webfinger instead of WF and SWD older drafts.		webfinger instead of WF and SWD older drafts.
End of changes. 19 change blocks.
	24 lines changed or deleted		42 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/