< draft-ietf-kitten-sasl-oauth-21.txt		draft-ietf-kitten-sasl-oauth-22.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: October 19, 2015		Expires: November 1, 2015
	H. Tschofenig		H. Tschofenig
	ARM Ltd.		ARM Ltd.
	April 17, 2015		April 30, 2015
	A set of SASL Mechanisms for OAuth		A set of SASL Mechanisms for OAuth
	draft-ietf-kitten-sasl-oauth-21.txt		draft-ietf-kitten-sasl-oauth-22.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 October 19, 2015.		This Internet-Draft will expire on November 1, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 . . . . . . . . 9		3.2.1. OAuth Identifiers in the SASL Context . . . . . . . . 9
	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 . . . . . . . . 10		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 . . 11
	4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11		4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.1. Successful Bearer Token Exchange . . . . . . . . . . . . 12		4.1. Successful Bearer Token Exchange . . . . . . . . . . . . 12
	4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 13		4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 13
	4.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 13		4.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 14
	4.4. SMTP Example of a Failed Negotiation . . . . . . . . . . 14		4.4. SMTP Example of a Failed Negotiation . . . . . . . . . . 15
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 15		5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	6. Internationalization Considerations . . . . . . . . . . . . . 16		6. Internationalization Considerations . . . . . . . . . . . . . 17
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 17		7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 17
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	8.1. Normative References . . . . . . . . . . . . . . . . . . 18		8.1. Normative References . . . . . . . . . . . . . . . . . . 18
	8.2. Informative References . . . . . . . . . . . . . . . . . 19		8.2. Informative References . . . . . . . . . . . . . . . . . 19
	Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 19		Appendix A. Acknowlegements . . . . . . . . . . . . . . . . . . 20
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 20		Appendix B. Document History . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	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.
	skipping to change at page 6, line 30 ¶		skipping to change at page 6, line 30 ¶
	resource server.		resource server.
	OAUTH10A: OAuth 1.0a MAC tokens (using the HMAC-SHA1 keyed		OAUTH10A: OAuth 1.0a MAC tokens (using the HMAC-SHA1 keyed
	message digest), as described in Section 3.4.2 of [RFC5849].		message digest), as described in Section 3.4.2 of [RFC5849].
	New extensions may be defined to add additional OAuth Access Token		New extensions may be defined to add additional OAuth Access Token
	Types. Such a new SASL OAuth mechanism can be added by simply		Types. Such a new SASL OAuth mechanism can be added by simply
	registering the new name(s) and citing this specification for the		registering the new name(s) and citing this specification for the
	further definition.		further definition.
			SASL mechanisms using this document as their definition do not
			provide a data security layer; that is, they cannot provide integrity
			or confidentiality protection for application messages after the
			initial authentication. If such protection is needed, TLS or some
			similar solution should be used. Additionally, for the two
			mechanisms specified in this document, TLS MUST be used for
			OAUTHBEARER to protect the bearer token; for OAUTH10A the use of TLS
			is RECOMMENDED.
	These mechanisms are client initiated and lock-step, the server		These mechanisms are client initiated and lock-step, the server
	always replying to a client message. In the case where the client		always replying to a client message. In the case where the client
	has and correctly uses a valid token the flow is:		has and correctly uses a valid token the flow is:
	1. Client sends a valid and correct initial client response.		1. Client sends a valid and correct initial client response.
	2. Server responds with a successful authentication.		2. Server responds with a successful authentication.
	In the case where authentication fails the server sends an error		In the case where authentication fails the server sends an error
	result, then client MUST then send an additional message to the		result, then client MUST then send an additional message to the
	skipping to change at page 8, line 38 ¶		skipping to change at page 8, line 49 ¶
	qs (RESERVED): The HTTP query string, 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 according the specification for the		The server validates the response according the specification for the
	OAuth Access Token Types used. If the OAuth Access Token Type		OAuth Access Token Types used. If the OAuth Access Token Type
	utilizes a keyed message digest of the request parameters then the		utilizes a keyed message digest of the request parameters then the
	client must provide a client response that satisfies the data		client must provide a client response that satisfies the data
	requirements for the scheme in use.		requirements for the scheme in use.
			The server fully validates the client response before generating a
			server response; this will necessarily include the validation steps
			listed in the specification for the OAuth Access Token Type used.
			However, additional validation steps may be needed, depending on the
			particular application protocol making use of SASL. In particular,
			values included as kvpairs in the client response (such as host and
			port) which correspond to values known to the application by some
			other mechanism (such as an application protocol data unit or pre-
			configured values) MUST be validated to match between the initial
			client response and the the other source(s) of such information. As
			a concrete example, when SASL is used over IMAP to an IMAP server for
			a single domain the hostname can be vaialble via configuration; this
			hostname must be validated to match the value sent in the 'host'
			kvpair.
	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 authzid is specified by the		resource. Note that the semantics of the authzid is specified by the
	SASL framework [RFC4422].		SASL framework [RFC4422].
	3.2.1. OAuth Identifiers in the SASL Context		3.2.1. OAuth Identifiers in the SASL Context
End of changes. 9 change blocks.
	11 lines changed or deleted		35 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/