draft-ietf-kitten-sasl-oauth-07.txt		draft-ietf-kitten-sasl-oauth-08.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: March 17, 2013		Expires: March 21, 2013
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	September 13, 2012		September 17, 2012
	A set of SASL and GSS-API Mechanisms for OAuth		A set of SASL and GSS-API Mechanisms for OAuth
	draft-ietf-kitten-sasl-oauth-07		draft-ietf-kitten-sasl-oauth-08
	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 17, 2013.		This Internet-Draft will expire on March 21, 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 3, line 14		skipping to change at page 3, line 14
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3. OAuth SASL Mechanism Specifications . . . . . . . . . . . . . 8		3. OAuth SASL Mechanism Specifications . . . . . . . . . . . . . 8
	3.1. Initial Client Response . . . . . . . . . . . . . . . . . 9		3.1. Initial Client Response . . . . . . . . . . . . . . . . . 9
	3.1.1. Reserved Key/Values . . . . . . . . . . . . . . . . . 10		3.1.1. Reserved Key/Values . . . . . . . . . . . . . . . . . 10
	3.1.2. Use of the gs2-header . . . . . . . . . . . . . . . . 10		3.1.2. Use of the gs2-header . . . . . . . . . . . . . . . . 10
	3.2. Server's Response . . . . . . . . . . . . . . . . . . . . 10		3.2. Server's Response . . . . . . . . . . . . . . . . . . . . 10
	3.2.1. Mapping to SASL Identities . . . . . . . . . . . . . . 11		3.2.1. OAuth Identities in the SASL Context . . . . . . . . . 11
	3.2.2. Canonicalization . . . . . . . . . . . . . . . . . . . 11		3.2.2. Canonicalization . . . . . . . . . . . . . . . . . . . 11
	3.2.3. Server response to failed authentication. . . . . . . 11		3.2.3. Server response to failed authentication. . . . . . . 11
	3.2.4. Completing an error message sequence. . . . . . . . . 12		3.2.4. Completing an error message sequence. . . . . . . . . 12
	3.3. Use of Signature Type Authorization . . . . . . . . . . . 12		3.3. Use of Signature Type Authorization . . . . . . . . . . . 12
	3.4. Channel Binding . . . . . . . . . . . . . . . . . . . . . 13		3.4. Channel Binding . . . . . . . . . . . . . . . . . . . . . 13
	4. GSS-API OAuth Mechanism Specification . . . . . . . . . . . . 15		4. GSS-API OAuth Mechanism Specification . . . . . . . . . . . . 15
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	5.1. Successful Bearer Token Exchange . . . . . . . . . . . . . 17		5.1. Successful Bearer Token Exchange . . . . . . . . . . . . . 17
	5.2. OAuth 1.0a Authorization with Channel Binding . . . . . . 18		5.2. OAuth 1.0a Authorization with Channel Binding . . . . . . 18
	5.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 19		5.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 19
	skipping to change at page 11, line 9		skipping to change at page 11, line 9
	In a "-PLUS" mechanism the server examines the channel binding data,		In a "-PLUS" mechanism the server examines the channel binding data,
	extracts the channel binding unique prefix, and extracts the raw		extracts the channel binding unique prefix, and extracts the raw
	channel biding data based on the channel binding type used. It then		channel biding data based on the channel binding type used. It then
	computes it's own copy of the channel binding payload and compares		computes it's own copy of the channel binding payload and compares
	that to the payload sent by the client in the cbdata key/value.		that to the payload sent by the client in the cbdata key/value.
	Those two must be equal for channel binding to succeed.		Those two must be equal for channel binding to succeed.
	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 mechanism is the identity which the mechanism has securely		by the SASL mechanism is the identity securely established for the
	established for the client with the OAuth credential.		client with the OAuth credential. The application, not the SASL
			mechanism, based on local access policy determines whether the
	3.2.1. Mapping to SASL Identities		identity reported by the mechanism is allowed access to the requested
			resource. Note that the semantics of the authz-id is specified by
			the SASL framework [RFC4422].
	Note that the semantics of the authz-id are specified by the SASL		3.2.1. OAuth Identities in the SASL Context
	framework [RFC4422]. A SASL application is, of course, free to apply
	mappings of the OAuth authcid to authz-ids as per-SASL, and it is
	free to apply mappings common to non-SASL OAuth applications.
	Some OAuth schemes can carry both a user identity and a "proxy"		Some OAuth schemes can carry both an owner or resource identity and a
	identity, for example an OAuth 1.0a [RFC5849] mechanism where the		"proxy" identity, for example an OAuth 1.0a [RFC5849] mechanism where
	consumer key (oauth_consumer_key) identifies the entity using the		the consumer key (oauth_consumer_key) identifies the entity using the
	token and the token itself identifies the user. If both identities		token and the token itself identifies the owner or resouce. If both
	are needed by an application the developer will need to provide a way		identities are needed by an application the developer will need to
	to communicate that from the SASL mechanism back to the application		provide a way to communicate that from the SASL mechanism back to the
	such as a GS2 [RFC2473] named type like GSS_C_NT_USER_NAME or a		application such as a GSS-API [RFC2473] named type like
	comparable newly defined GS2 attribute.		GSS_C_NT_USER_NAME or a comparable newly defined GSS-API name type or
			name attribute [RFC6680].
	3.2.2. Canonicalization		3.2.2. Canonicalization
	The identity asserted by the OAuth authorization server is canonical		The identity asserted by the OAuth authorization server is canonical
	for display. The server MAY provide a different canonical form based		for display. The server MAY provide a different canonical form based
	on local data.		on local data.
	3.2.3. Server response to failed authentication.		3.2.3. Server response to failed authentication.
	For a failed authentication the server returns a JSON [RFC4627]		For a failed authentication the server returns a JSON [RFC4627]
	skipping to change at page 18, line 29		skipping to change at page 18, line 29
	5.2. OAuth 1.0a Authorization with Channel Binding		5.2. OAuth 1.0a Authorization with Channel Binding
	This example shows channel binding in the context of an OAuth 1.0a		This example shows channel binding in the context of an OAuth 1.0a
	signed authorization request. Note that line breaks are inserted for		signed authorization request. Note that line breaks are inserted for
	readability.		readability.
	S: * CAPABILITY IMAP4rev1 AUTH=OAUTH10A-PLUS SASL-IR IMAP4rev1 Server		S: * CAPABILITY IMAP4rev1 AUTH=OAUTH10A-PLUS SASL-IR IMAP4rev1 Server
	Ready		Ready
	S: t0 OK Completed		S: t0 OK Completed
	C: t1 AUTHENTICATE OAUTH10A-PLUS cCxhPXVzZXJAZXhhbXBsZS5jb20BaG9zdD1zZ		C: t1 AUTHENTICATE OAUTH10A-PLUS cD10bHMtdW5pcXVlLGE9dXNlckBleGFtcGxlL
	XJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xNDMBYXV0aD1PQXV0aCByZWFsbT0iRXhhb		mNvbQFob3N0PXNlcnZlci5leGFtcGxlLmNvbQFwb3J0PTE0MwFhdXRoPU9BdXRoI
	XBsZSIsb2F1dGhfY29uc3VtZXJfa2V5PSI5ZGpkajgyaDQ4ZGpzOWQyIixvYXV0a		HJlYWxtPSJFeGFtcGxlIixvYXV0aF9jb25zdW1lcl9rZXk9IjlkamRqODJoNDhka
	F90b2tlbj0ia2trOWQ3ZGgzazM5c2p2NyIsb2F1dGhfc2lnbmF0dXJlX21ldGhvZ		nM5ZDIiLG9hdXRoX3Rva2VuPSJra2s5ZDdkaDNrMzlzanY3IixvYXV0aF9zaWduY
	D0iSE1BQy1TSEExIixvYXV0aF90aW1lc3RhbXA9IjEzNzEzMTIwMSIsb2F1dGhfb		XR1cmVfbWV0aG9kPSJITUFDLVNIQTEiLG9hdXRoX3RpbWVzdGFtcD0iMTM3MTMxM
	m9uY2U9IjdkOGYzZTRhIixvYXV0aF9zaWduYXR1cmU9IlNTZHRJR0VnYkdsMGRHe		jAxIixvYXV0aF9ub25jZT0iN2Q4ZjNlNGEiLG9hdXRoX3NpZ25hdHVyZT0iU1Nkd
	GxJSFJsWVNCd2IzUXUiAXFzPWNiZGF0YT10bHMtdW5pcXVlOlNHOTNJR0pwWnlCc		ElHRWdiR2wwZEd4bElIUmxZU0J3YjNRdSIBcXM9Y2JkYXRhPXRscy11bmlxdWU6U
	GN5QmhJRlJNVXlCbWFXNWhiQ0J0WlhOellXZGxQd289AQE=		0c5M0lHSnBaeUJwY3lCaElGUk1VeUJtYVc1aGJDQnRaWE56WVdkbFB3bz0BAQ==
	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		decoded initial client response (with %x01 represented as ^A and
	lines wrapped for readability) is:		lines wrapped for readability) is:
	p,a=user@example.com^A		p=tls-unique,a=user@example.com^A
	host=server.example.com^A		host=server.example.com^A
	port=143^A		port=143^A
	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		oauth_signature="SSdtIGEgbGl0dGxlIHRlYSBwb3Qu"^A
	qs=cbdata=tls-unique:SG93IGJpZyBpcyBhIFRMUyBmaW5hbCBtZXNzYWdlPwo=^A^A		qs=cbdata=tls-unique:SG93IGJpZyBpcyBhIFRMUyBmaW5hbCBtZXNzYWdlPwo=^A^A
	skipping to change at page 19, line 35		skipping to change at page 19, line 35
	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=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 bixhPXVzZXJAZXhhbXBsZS5jb20BaG9zdD		C: t1 AUTHENTICATE OAUTHBEARER cD10bHMtdW5pcXVlLGE9dXNlckBleGFtcG
	1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xNDMBYXV0aD0BAQ==		xlLmNvbQFob3N0PXNlcnZlci5leGFtcGxlLmNvbQFwb3J0PTE0MwFhdXRoP
			QFjYmRhdGE9AQE=
	S: + ewoic3RhdHVzIjoiNDAxIgoic2NvcGUiOiJleGFtcGxlX3Njb3BlIgp9		S: + ewoic3RhdHVzIjoiNDAxIgoic2NvcGUiOiJleGFtcGxlX3Njb3BlIgp9
	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:
	skipping to change at page 20, line 29		skipping to change at page 20, line 29
	Ready		Ready
	S: t0 OK Completed		S: t0 OK Completed
	C: t1 AUTHENTICATE OAUTH10A-PLUS cCxhPXVzZXJAZXhhbXBsZS5jb20BaG9z		C: t1 AUTHENTICATE OAUTH10A-PLUS cCxhPXVzZXJAZXhhbXBsZS5jb20BaG9z
	dD1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xNDMBYXV0aD0BY2JkYXRhPQEB		dD1zZXJ2ZXIuZXhhbXBsZS5jb20BcG9ydD0xNDMBYXV0aD0BY2JkYXRhPQEB
	S: + ewoic3RhdHVzIjoiNDEyIiwKInNjb3BlIjoiZXhhbXBsZV9zY29wZSIKfQ==		S: + ewoic3RhdHVzIjoiNDEyIiwKInNjb3BlIjoiZXhhbXBsZV9zY29wZSIKfQ==
	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:
	p,a=user@example.com,^Ahost=server.example.com^A		p=tls-unique,a=user@example.com,^Ahost=server.example.com^A
	port=143^Aauth=^Acbdata=^A^A		port=143^Aauth=^Acbdata=^A^A
	The decoded server response is:		The decoded server response is:
	{		{
	"status":"412",		"status":"412",
	"scope":"example_scope"		"scope":"example_scope"
	}		}
	The client responds with the required dummy response.		The client responds with the required dummy response.
	skipping to change at page 26, line 28		skipping to change at page 26, line 28
	for TLS", RFC 5929, July 2010.		for TLS", RFC 5929, July 2010.
	[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.		[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
	[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and		[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
	Verification of Domain-Based Application Service Identity		Verification of Domain-Based Application Service Identity
	within Internet Public Key Infrastructure Using X.509		within Internet Public Key Infrastructure Using X.509
	(PKIX) Certificates in the Context of Transport Layer		(PKIX) Certificates in the Context of Transport Layer
	Security (TLS)", RFC 6125, March 2011.		Security (TLS)", RFC 6125, March 2011.
			[RFC6680] Williams, N., Johansson, L., Hartman, S., and S.
			Josefsson, "Generic Security Service Application
			Programming Interface (GSS-API) Naming Extensions",
			RFC 6680, August 2012.
	8.2. Informative References		8.2. Informative References
	[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.jones-appsawg-webfinger]		[I-D.jones-appsawg-webfinger]
	Jones, P., Salgueiro, G., and J. Smarr, "WebFinger",		Jones, P., Salgueiro, G., and J. Smarr, "WebFinger",
	draft-jones-appsawg-webfinger-06 (work in progress),		draft-jones-appsawg-webfinger-06 (work in progress),
	skipping to change at page 28, line 9		skipping to change at page 28, line 9
	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, and Nico Williams.		Lodderstadt, Ryan Troll, and Nico Williams.
	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 ]]
			-08
			o Fixed the channel binding examples for p=$cbtype
			o More tuning of the authcid language and edited and renamed 3.2.1.
	-07		-07
	o Struck the MUST langiage from authzid.		o Struck the MUST langiage from authzid.
	o		o
	-06		-06
	o Removed the user field. Fixed the examples again.		o Removed the user field. Fixed the examples again.
End of changes. 14 change blocks.
	33 lines changed or deleted		45 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/