< draft-tschofenig-oauth-hotk-00.txt		draft-tschofenig-oauth-hotk-01.txt >
	Network Working Group H. Tschofenig		Network Working Group J. Bradley
	Internet-Draft Nokia Siemens Networks		Internet-Draft Ping Identity
	Intended status: Standards Track July 9, 2012		Intended status: Standards Track P. Hunt
	Expires: January 10, 2013		Expires: January 17, 2013 Oracle Corporation
			T. Nadalin
			Microsoft
			H. Tschofenig
			Nokia Siemens Networks
			July 16, 2012
	The OAuth 2.0 Authorization Framework: Holder-of-the-Key Token Usage		The OAuth 2.0 Authorization Framework: Holder-of-the-Key Token Usage
	draft-tschofenig-oauth-hotk-00.txt		draft-tschofenig-oauth-hotk-01.txt
	Abstract		Abstract
	OAuth 2.0 deployments currently rely on bearer tokens for securing		OAuth 2.0 deployments currently rely on bearer tokens for securing
	access to protected resources. Bearer tokens require Transport Layer		access to protected resources. Bearer tokens require Transport Layer
	Security to be used between an OAuth client and the resource server		Security to be used between an OAuth client and the resource server
	when presenting the access token in order to get access. The		when presenting the access token. The security model is based on
	security model is based on proof-of-possession of the access token:		proof-of-possession: access token storage and transfer has to be done
	access token storage and transfer has to be done with care to prevent		with care to prevent leakage.
	leakage.
	There are, however, use cases that require a more active involvement		There are, however, use cases that require a more active involvement
	of the OAuth client to offer increased security, particularly against		of the OAuth client for an increased level of security, particularly
	token leakage. This document specifies an OAuth security framework		to secure against token leakage. This document specifies an OAuth
	using ephemeral asymmetric credentials that are bound to the access		security framework using the holder-of-the-key concept, which
	token. A client can create these key pairs dynamically and use them,		requires the OAuth client when presenting an OAuth access token to
	after they are bound to an access token by the authorization server,		also demonstrate knowledge of keying material that is bound to the
	in communication interactions with resource servers.		token.
	This document is discussed at
	https://www.ietf.org/mailman/listinfo/oauth. This initial version of
	the specification shall serve as a discussion starter.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 10, 2013.		This Internet-Draft will expire on January 17, 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 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 5		3. Protocol Specification . . . . . . . . . . . . . . . . . . . . 5
	3.1. Binding a Public Key to an Access Token . . . . . . . . . 5		3.1. Binding a Key to an Access Token . . . . . . . . . . . . . 5
	3.2. Accessing a Protected Resource . . . . . . . . . . . . . . 8		3.1.1. Symmetric Keys . . . . . . . . . . . . . . . . . . . . 6
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 9		3.1.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . 8
	4.1. Security Threats . . . . . . . . . . . . . . . . . . . . . 9		3.2. Accessing a Protected Resource . . . . . . . . . . . . . . 10
	4.2. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 9		3.2.1. Symmetric Keys . . . . . . . . . . . . . . . . . . . . 10
	4.3. Summary of Recommendations . . . . . . . . . . . . . . . . 10		3.2.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . 12
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	5.1. OAuth Parameters Registration . . . . . . . . . . . . . . 11		4.1. Security Threats . . . . . . . . . . . . . . . . . . . . . 13
	5.2. The 'hotk' JSON Web Token Claims . . . . . . . . . . . . . 11		4.2. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 13
	5.3. The 'hotk' OAuth Access Token Type . . . . . . . . . . . . 11		4.3. Summary of Recommendations . . . . . . . . . . . . . . . . 14
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		5.1. OAuth Parameters Registration . . . . . . . . . . . . . . 16
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 13		5.2. The 'hotk' JSON Web Token Claims . . . . . . . . . . . . . 17
	7.2. Informative References . . . . . . . . . . . . . . . . . . 13		5.3. The 'hotk' OAuth Access Token Type . . . . . . . . . . . . 17
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15		5.4. Profile Registry . . . . . . . . . . . . . . . . . . . . . 17
			6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
			7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
			7.1. Normative References . . . . . . . . . . . . . . . . . . . 20
			7.2. Informative References . . . . . . . . . . . . . . . . . . 20
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	At the time of writing the OAuth 2.0 [1] and accompanying protocols		At the time of writing the OAuth 2.0 [1] and accompanying protocols
	offer one main security mechanism to access protected resources,		offer one main security mechanism to access protected resources,
	namely the bearer token. In [8] a bearer token is defined as		namely the bearer token. In [11] a bearer token is defined as
	A security token with the property that any party in possession of		A security token with the property that any party in possession of
	the token (a "bearer") can use the token in any way that any other		the token (a "bearer") can use the token in any way that any other
	party in possession of it can. Using a bearer token does not		party in possession of it can. Using a bearer token does not
	require a bearer to prove possession of cryptographic key material		require a bearer to prove possession of cryptographic key
	(proof-of-possession).		material.
	The bearer token provides sufficient security properties for a number
	of use cases OAuth had been designed for, if certain conditions are
	met (which are documented in [8]). Some usage scenarios, however,
	require stronger security guarantees and ask for active participation
	of the client software in form of cryptographic computations when
	presenting an access token.
	In addition to the bearer token a MAC token has been specified, see		The bearer token meets the security needs of number of use cases
	[9]. The design of the MAC token was inspired by features in the		OAuth had been designed for. There are, however, scenarios that
	OAuth 1.0 [10]. Unfortunately, the MAC token has not received a lot		require stronger security properties and ask for active participation
	of deployment attention.		of the OAuth client software in form of cryptographic computations
			when presenting an access token to a resource server.
	This specification defines a new security mechanism for usage with		This specification defines a new security mechanism for usage with
	OAuth that combines various existing specifications to offer enhanced		OAuth that combines various existing specifications to offer enhanced
	security properties for OAuth. The incredients for this security		security properties for OAuth. The incredients for this security
	solution are:		solution are:
	1. A mechanism for on-the-fly provisioning of ephemeral asymmetric		1. A mechanism for dynamic key distribution.
	credentials using the JSON Web Key (JWK) format [2].
	2. The ability to access a protected resource using this ephemeral		2. Data elements to bind emphemeral keying material to an access
	asymmetric credentials for client authentication using a		token. For the access token we assume a JSON Web Token (JWT) [2]
	transport layer extension that allows out-of-band key validation		in this specification to specify a complete solution. Future
	[3].		specifications may make this functionality available to other
			access token formats as well.
	3. A data structure to bind the emphemeral asymmetric credential to		3. A mechanism to allow the OAuth client to demonstrate a proof of
	an access token. The structure uses the JSON Web Token (JWT)		possession.
	[4].
	The rest of the document describes how these different components		The rest of the document describes how these different components
	work together.		work together.
	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
	specification are to be interpreted as described in [5].		specification are to be interpreted as described in [3].
	3. Protocol Specification		3. Protocol Specification
	To describe the architecture of the proposed security mechanism it is		To describe the architecture of the proposed security mechanism it is
	best to start by looking at the main OAuth 2.0 protocol exchange		best to start by looking at the main OAuth 2.0 protocol exchange
	sequence. Figure 1 shows the abstract OAuth 2.0 protocol exchanges		sequence. Figure 1 shows the abstract OAuth 2.0 protocol exchanges
	graphically. The exchange in this document will focus on two		graphically. The exchange in this document will focus on two
	interactions, namely		interactions, namely
	1. to allow the client to obtain the ephemeral asymmetric		1. to allow the client to obtain the ephemeral asymmetric
	skipping to change at page 5, line 39 ¶		skipping to change at page 5, line 39 ¶
	| | +---------------+		| | +---------------+
	| |		| |
	| | +---------------+		| | +---------------+
	| |--(E)----- Access Token ------>| Resource |		| |--(E)----- Access Token ------>| Resource |
	| | | Server |		| | | Server |
	| |<-(F)--- Protected Resource ---| |		| |<-(F)--- Protected Resource ---| |
	+--------+ +---------------+		+--------+ +---------------+
	Figure 1: Abstract OAuth 2.0 Protocol Flow		Figure 1: Abstract OAuth 2.0 Protocol Flow
	3.1. Binding a Public Key to an Access Token		3.1. Binding a Key to an Access Token
	OAuth 2.0 offers different ways to obtain an access token, namely		OAuth 2.0 offers different ways to obtain an access token, namely
	using authorization grants and using a refresh token. The core OAuth		using authorization grants and using a refresh token. The core OAuth
	specification defines four authorization grants, see Section 1.3 of		specification defines four authorization grants, see Section 1.3 of
	[1], and [11] adds an assertion-based authorization grant to that		[1], and [12] adds an assertion-based authorization grant to that
	list.		list.
	This document extends the communication with the token endpoint. The		This document extends the communication with the token endpoint. The
	token endpoint, which is described in Section 3.2 of [1], is used		token endpoint, which is described in Section 3.2 of [1], is used
	with every authorization grant except for the implicit grant type		with every authorization grant except for the implicit grant type.
	since an access token is issued directly. The request contains		In the implicit grant type the access token is issued directly.
	information about the public key the client would like to bind to the
	access token in the JSON Web Key format. This parameter also		Two types of keying material can be bound to an access token, namely
	provides an indication to the authorization servers about the support		symmetric keys and asymmetric keys, and we explain them in separate
	by the client for this specification. Since the client makes a		sub-sections.
	request to the token endpoint by adding a new of parameters using the
	"application/x-www-form-urlencoded" format in the HTTP request		3.1.1. Symmetric Keys
	entity-body the public key information must be encoded into a new
	parameter, called 'pk-info'. A new token type, called 'hotk', is		In case a symmetric key shall be bound to an access token then the
	also defined by this specification.		following procedure is applicable. In the request message from the
			OAuth client to the authorization server the following parameters
			MUST be included:
			token_type: REQUIRED. For the symmetric holder-of-the-key variant
			the value MUST be set to "hotk-sk".
			profile: REQUIRED. The profile parameter provides information about
			what mechanisms the client supports to provide proof of
			possession of the key towards a resource server. The value
			MUST be taken from the algorithm registry created in
			Section 5.4. Algorithm names are case-sensitive. If the
			client supports more than one profile then each individual
			value MUST be separated by a comma.
	For example, the client makes the following HTTP request using TLS		For example, the client makes the following HTTP request using TLS
	(extra line breaks are for display purposes only):		(extra line breaks are for display purposes only):
	POST /token HTTP/1.1		POST /token HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW		Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
	Content-Type: application/x-www-form-urlencoded;charset=UTF-8		Content-Type: application/x-www-form-urlencoded;charset=UTF-8
	grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA		grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
	&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb		&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
	&pk-info=eZQQYbYS6WxS...lxlOB		&token_type=hotk-sk
			&profile=jws,mac
	whereby the content of the pk-info field represents the following		Example Request to the Authorization Server
			If the access token request is valid and authorized, the
			authorization server issues an access token and optionally a refresh
			token. If the request client authentication failed or is invalid,
			the authorization server returns an error response as described in
			Section 5.2 of [1].
			The authorization server MUST include the following parameters in a
			successful response, if it supports any of the profiles listed by the
			client.
			id: REQUIRED. An ephemeral and unique key identifier. The
			authorization server MUST NOT select the same key identifier
			twice within the lifetime of the access token, which is
			indicated by the 'expires_in' parameter.
			key: REQUIRED. A fresh and unique shared symmetric secret with
			sufficient entrophy.
			profile: REQUIRED. The profile parameter provides further
			information about how the client has to provide proof of
			possession of the key with the resource server. The
			authorization server chooses a value from the list of supported
			mechanisms supported by the client.
			For example:
			HTTP/1.1 200 OK
			Content-Type: application/json
			Cache-Control: no-store
			{
			"access_token":"SlAV.....32hkKG",
			"token_type":"hotk-sk",
			"expires_in":3600,
			"refresh_token":"8xLOxBtZp8",
			"id":"client12345@example.com",
			"key":"adijq39jdlaska9asud",
			"profile":"jws"
			}
			The content of the 'access_token' MUST contain
			the key identifier value in the 'hotk' element,
			as shown in the example below.
			{"typ":"JWT",
			"alg":"HS256"
			}
			.
			{"iss":"authorization-server-id",
			"exp":1300819380,
			"hotk":"client12345@example.com"
			}
			.
			bbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZC
			DISCUSSION: Should we put the encrypted key into the access token?
			This would make the mechanism more similar to a Kerberos-based
			scheme.
			The key identifier, the key, and the profile name MUST NOT include
			characters other than:
			%x20-21 / %x23-5B / %x5D-7E
			; Any printable ASCII character except for <"> and <\>
			3.1.2. Asymmetric Keys
			In case an asymmetric key shall be bound to an access token then the
			following procedure is applicable. In the request message from the
			OAuth client to the authorization server the following parameters
			MUST be included:
			token_type: REQUIRED. For the asymmetric holder-of-the-key variant
			the value MUST be set to "hotk-pk".
			pk_info: REQUIRED. This field contains information about the public
			key the client would like to bind to the access token in the
			JSON Web Key format. The public key is "application/
			x-www-form-urlencoded" encoded.
			For example, the client makes the following HTTP request using TLS
			(extra line breaks are for display purposes only):
			POST /token HTTP/1.1
			Host: server.example.com
			Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
			Content-Type: application/x-www-form-urlencoded;charset=UTF-8
			grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
			&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
			&token_type=hotk-pk
			&pk_info=eZQQYbYS6WxS...lxlOB
			whereby the content of the pk_info field represents the following
	structure:		structure:
	{"keys":		{"keys":
	[		[
	{"alg":"RSA",		{"alg":"RSA",
	"mod": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx		"mod": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
	4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs		4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
	tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2		tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
	QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI		QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
	SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb		SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
	skipping to change at page 7, line 5 ¶		skipping to change at page 9, line 42 ¶
	Example Request to the Authorization Server		Example Request to the Authorization Server
	If the access token request is valid and authorized, the		If the access token request is valid and authorized, the
	authorization server issues an access token and optionally a refresh		authorization server issues an access token and optionally a refresh
	token. If the request client authentication failed or is invalid,		token. If the request client authentication failed or is invalid,
	the authorization server returns an error response as described in		the authorization server returns an error response as described in
	Section 5.2 of [1].		Section 5.2 of [1].
	The authorization server also places information about the public key		The authorization server also places information about the public key
	used by the client into the access token to create the binding		used by the client into the access token to create the binding
	between the two.		between the two. The new token type, called 'hotk-pk', is placed
			into the 'token_type' parameter.
	An example successful response:		An example of a successful response is shown below:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/json;charset=UTF-8		Content-Type: application/json;charset=UTF-8
	Cache-Control: no-store		Cache-Control: no-store
	Pragma: no-cache		Pragma: no-cache
	{		{
	"access_token":"2YotnFZFE....jr1zCsicMWpAA",		"access_token":"2YotnFZFE....jr1zCsicMWpAA",
	"token_type":"hotk",		"token_type":"hotk-pk",
	"expires_in":3600,		"expires_in":3600,
	"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"		"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
	}		}
	whereby the content of the 'access_token' field, for example,		whereby the content of the 'access_token' field, for example,
	contains an encoded JWT with the following raw structure:		contains an encoded JWT with the following raw structure:
	{"typ":"JWT",		{"typ":"JWT",
	"alg":"HS256"}		"alg":"HS256"}
	.		.
	skipping to change at page 8, line 7 ¶		skipping to change at page 10, line 46 ¶
	]		]
	}		}
	}		}
	.		.
	bbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZC		bbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZC
	Example Response from the Authorization Server		Example Response from the Authorization Server
	3.2. Accessing a Protected Resource		3.2. Accessing a Protected Resource
			Accessing a protected resource depends on the chosen credential type.
			3.2.1. Symmetric Keys
			When a symmetric key was used as a holder-of-the-key then the client
			has to demonstrate possession of the key that corresponds to the key
			identifier found in the access token.
			This specification defines three ways for providing this proof of
			possession, which are indicated as profiles in Section 3.1.1:
			jws: When the 'jws' profile is chosen then the client MUST compute
			the following string by concatenating together, in order, the
			following HTTP request elements:
			1. The HTTP request method in upper case. For example: "HEAD",
			"GET", "POST", etc.
			2. The HTTP request-URI as defined by Section 5.1.2 of [4].
			3. The hostname included in the HTTP request using the "Host"
			request header field in lower case.
			4. The port as included in the HTTP request using the "Host"
			request header field. If the header field does not include a
			port, the default value for the scheme MUST be used (e.g., 80
			for HTTP and 443 for HTTPS).
			5. The value of the "ext" "Authorization" request header field
			attribute if one was included in the request, otherwise, an
			empty string.
			Each element is followed by a new line character (%x0A) including
			the last element and even when an element value is an empty
			string. The resulting value MUST be put into the "request"
			element of a JSON document that is then subject to JWS processing
			[5]. The resulting JWS structure is put into the body of the HTTP
			request. A receiving authorization server MUST use the value in
			the 'kid' structure to identify the shared key and then use that
			key to verify the keyed message digest. Additionally, the content
			of the 'request' field needs to be verified against the HTTP
			header information. If any of these verification steps fail then
			the request to the protected resource MUST fail with a "401
			Unauthorized" error message back to the OAuth client.
			The following example shows and the corresponding encoding in a
			JWS structure:
			1) HTTP Request
			POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b&c2&a3=2+q HTTP/1.1
			Host: example.com
			2) JWS Document
			{"typ":"HOTK-SK",
			"alg":"HS256",
			"kid":"client12345@example.com",
			"timestamp":"2012-07-15T10:20:00.000-05:00" }
			.
			{"request":"POST/request?b5=%3D%253D&a3=a&c%40=&a2=r%20b&c2&a3=
			2+qexample.com80"}
			.
			dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
			JWS Example
			mac: When the 'mac' profile is chosen then the client MUST follow
			the description in [6].
			3.2.2. Asymmetric Keys
	The client accesses protected resources by presenting the access		The client accesses protected resources by presenting the access
	token to the resource server. It does so via a Transport Layer		token to the resource server. It does so via a Transport Layer
	Security (TLS) secured channel. Since the client had previously		Security (TLS) secured channel. Since the client had previously
	bound a public key to an access token it selects this key for usage		bound a public key to an access token it selects this key for usage
	with TLS as described in [3].		with TLS as described in [7].
	The resource server validates the access token and ensure it has not		The resource server validates the access token and ensure it has not
	expired and that its scope covers the requested resource.		expired and that its scope covers the requested resource.
	Additionally, the resource server verifies that the public key		Additionally, the resource server verifies that the public key
	presented during the TLS handshake corresponds to the public key that		presented during the TLS handshake corresponds to the public key that
	is contained in the access token.		is contained in the access token.
	Note that this step confirms that the client is in possession of the		Note that this step confirms that the client is in possession of the
	private key corresponding to the public key previously bound to the		private key corresponding to the public key previously bound to the
	access token. Information about the client authentication may be		access token. Information about the client authentication may be
	contained in the token in case the authorization server added this		contained in the token in case the authorization server added this
	information when it authenticated the client.		information when it authenticated the client.
	4. Security Considerations		4. Security Considerations
	4.1. Security Threats		4.1. Security Threats
	The following list presents several common threats against protocols		The following list presents several common threats against protocols
	utilizing some form of tokens. This list of threats is based on NIST		utilizing some form of tokens. This list of threats is based on NIST
	Special Publication 800-63 [12]. We exclude a discussion of threats		Special Publication 800-63 [13]. We exclude a discussion of threats
	related to any form of registration and authentication.		related to any form of registration and authentication.
	Token manufacture/modification: An attacker may craft a fake token		Token manufacture/modification: An attacker may craft a fake token
	or modify the token content (such as the authentication or		or modify the token content (such as the authentication or
	attribute statements), causing a resource server to grant		attribute statements), causing a resource server to grant
	inappropriate access to the attacker. For example, an attacker		inappropriate access to the attacker. For example, an attacker
	may modify the token to extend the validity period or the scope to		may modify the token to extend the validity period or the scope to
	have extended access to information.		have extended access to information.
	Token disclosure: Tokens may contain authentication and attribute		Token disclosure: Tokens may contain authentication and attribute
	skipping to change at page 9, line 45 ¶		skipping to change at page 13, line 45 ¶
	Authentication Code (MAC). Consequently, the token integrity		Authentication Code (MAC). Consequently, the token integrity
	protection MUST be sufficient to prevent the token from being		protection MUST be sufficient to prevent the token from being
	modified.		modified.
	To deal with token redirect, it is important for the authorization		To deal with token redirect, it is important for the authorization
	server to include the identity of the intended recipients (the		server to include the identity of the intended recipients (the
	audience), typically a single resource server (or a list of resource		audience), typically a single resource server (or a list of resource
	servers), in the token. Restricting the use of the token to a		servers), in the token. Restricting the use of the token to a
	specific scope is also RECOMMENDED.		specific scope is also RECOMMENDED.
	The authorization server MUST implement TLS. Which version(s) ought		The authorization server MUST implement and use TLS. Which
	to be implemented will vary over time, and depend on the widespread		version(s) ought to be implemented will vary over time, and depend on
	deployment and known security vulnerabilities at the time of		the widespread deployment and known security vulnerabilities at the
	implementation. At the time of this writing, TLS version 1.2 [6] is		time of implementation. At the time of this writing, TLS version 1.2
	the most recent version. The client MUST validate the TLS		[8] is the most recent version. The client MUST validate the TLS
	certificate chain when making requests to protected resources,		certificate chain when making requests to protected resources,
	including checking the Certificate Revocation List (CRL) [7]. In		including checking the Certificate Revocation List (CRL) [9].
	addition, this specificatio requires a TLS extension for usage with
	out-of-band validation [3] to be used that allows clients to present		For the interaction between the client and the resource server this
	raw public keys.		specification requires a TLS extension for usage with out-of-band
			validation [7] to be used that allows clients to present raw public
			keys for asymmetric holder-of-the-key usage.
	With the usage of the holder-of-the-key concept it is not possible		With the usage of the holder-of-the-key concept it is not possible
	for any party other than the legitimate client to use a token and to		for any party other than the legitimate client to use an access token
	re-use it without knowing the corresponding asymmetric key pair.		and to re-use it without knowing the corresponding asymmetric key
	This mechanism prevents against token disclosure. In some		pair. This mechanism prevents against token disclosure.
	deployments, including those utilizing load balancers, the TLS
	connection to the resource server terminates prior to the actual		With the usage of the asymmetric holder-of-the-key concept the
	server that provides the resource. This could leave the token		following deployment consideration needs to be taken into
	unprotected between the front end server where the TLS connection		consideration. In some deployments, including those utilizing load
	terminates and the back end server that provides the resource. Even		balancers, the TLS connection to the resource server terminates prior
	in such deployments, token leakage is not a problem.		to the actual server that provides the resource. This could leave
			the token unprotected between the front end server where the TLS
			connection terminates and the back end server that provides the
			resource.
	Client implementations must be carefully implemented to avoid leaking		Client implementations must be carefully implemented to avoid leaking
	the ephemeral asymmetric key pair.		the ephemeral credentials (either the private key from the asymmetric
			credential or the shared secret).
	Token replay is also not possible since an eavesdropper will also		Token replay is also not possible since an eavesdropper will also
	have to obtain the corresponding asymmetric key pair that corresponds		have to obtain the corresponding private key or shared secret that is
	to the access token. Nevertheless, it is good practice to limit the		bound to the access token. Nevertheless, it is good practice to
	lifetime of the and therefore the lifetime of the ephemeral		limit the lifetime of the access token and therefore the lifetime of
	asymmetric key associated with it.		associated key.
	4.3. Summary of Recommendations		4.3. Summary of Recommendations
	The following three items represent the main recommendations:		The following three items represent the main recommendations:
	Safeguard the private key: Client implementations MUST ensure that		Safeguard the private key/shared secret: Client implementations MUST
	the ephemeral private key is not leaked to third parties, since		ensure that the ephemeral private key / shared secret is not
	those will be able to use the access together with the key pair to		leaked to third parties, since those will be able to use the
	gain access to protected resources.		access token together with the keying material to gain access to
			protected resources.
	Switch keying material regularly: Clients can at any time create a		Switch keying material regularly: Clients can at any time create a
	new ephemeral key pair and request the public key to be associated		new ephemeral credential and associate it with an access token.
	with the access token. For example, a client presents a new		For example, a client presents a new public key when requesting an
	public key when requesting an access token with the help of a		access token with the help of a refresh token. Nevertheless, the
	refresh token. Nevertheless, the lifetime of these access token		lifetime of these access token may be longer than the lifetime of
	may be longer than the lifetime of bearer tokens.		bearer tokens.
	Issue scoped bearer tokens: Token servers SHOULD issue bearer tokens		Issue scoped bearer tokens: Token servers SHOULD issue bearer tokens
	that contain an audience restriction, scoping their use to the		that contain an audience restriction, scoping their use to the
	intended relying party or set of relying parties.		intended relying party or set of relying parties.
	5. IANA Considerations		5. IANA Considerations
	This document requires IANA to take the following actions.		This document requires IANA to take the following actions.
	5.1. OAuth Parameters Registration		5.1. OAuth Parameters Registration
	This specification registers the 'pk-info' parameter in the OAuth		This specification registers the following parameters in the OAuth
	Parameters Registry established by [1].		Parameters Registry established by [1].
	Parameter name: pk-info		Parameter name: pk_info
	Parameter usage location: token request		Parameter usage location: token request
	Change controller: IETF		Change controller: IETF
	Specification document(s): [[ this document ]]		Specification document(s): [[ this document ]]
	Related information: None		Related information: None
			Parameter name: token_type
			Parameter usage location: token request, token response,
			authorization response
			Change controller: IETF
			Specification document(s): [[ this document ]]
			Related information: None
			Parameter name: profile
			Parameter usage location: token request, token response,
			authorization response
			Change controller: IETF
			Specification document(s): [[ this document ]]
			Related information: None
			Parameter name: id
			Parameter usage location: token response, authorization response
			Change controller: IETF
			Specification document(s): [[ this document ]]
			Related information: None
			Parameter name: key
			Parameter usage location: token response, authorization response
			Change controller: IETF
			Specification document(s): [[ this document ]]
			Related information: None
	5.2. The 'hotk' JSON Web Token Claims		5.2. The 'hotk' JSON Web Token Claims
	[4] established the IANA JSON Web Token Claims registry for reserved		[2] established the IANA JSON Web Token Claims registry for reserved
	JWT Claim Names and this document adds the 'hotk' name to that		JWT Claim Names and this document adds the 'hotk' name to that
	registry.		registry.
	5.3. The 'hotk' OAuth Access Token Type		5.3. The 'hotk' OAuth Access Token Type
	Section 11.1 of [1] defines the OAuth Access Token Type Registry and		Section 11.1 of [1] defines the OAuth Access Token Type Registry and
	this document adds another token type to this registry.		this document adds another token type to this registry.
	Type name: hotk		Type name: hotk
	Additional Token Endpoint Response Parameters: (none)		Additional Token Endpoint Response Parameters: (none)
	HTTP Authentication Scheme(s): Holder of the key confirmation using		HTTP Authentication Scheme(s): Holder of the key confirmation using
	TLS		TLS
	Change controller: IETF		Change controller: IETF
	Specification document(s): [[ this document ]]		Specification document(s): [[ this document ]]
			5.4. Profile Registry
			This document asks IANA to create a registry for profiles of
			symmetric key-based holder-of-the-key mechanisms. The policy for
			adding new entries to the registry is "Specification Required". IANA
			is asked to populate the registry with the following values:
			o Profile name: jws
			o Change controller: IETF
			o Specification document(s): [[ this document ]]
			o Profile name: mac
			o Change controller: IETF
			o Specification document(s): [[ this document ]]
	6. Acknowledgements		6. Acknowledgements
	The author would like to thank the OAuth working group and		The author would like to thank the OAuth working group and
	participants of the Internet Identity Workshop for their discussion		participants of the Internet Identity Workshop for their discussion
	input that lead to this document.		input that lead to this document.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[1] Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 2.0		[1] Hardt, D. and D. Recordon, "The OAuth 2.0 Authorization
	Authorization Framework", draft-ietf-oauth-v2-28 (work in		Framework", draft-ietf-oauth-v2-30 (work in progress),
	progress), June 2012.		July 2012.
	[2] Jones, M., "JSON Web Key (JWK)",
	draft-ietf-jose-json-web-key-03 (work in progress), July 2012.
	[3] Wouters, P., Gilmore, J., Weiler, S., Kivinen, T., and H.
	Tschofenig, "TLS Out-of-Band Public Key Validation",
	draft-ietf-tls-oob-pubkey-03 (work in progress), April 2012.
	[4] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		[2] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	(JWT)", draft-ietf-oauth-json-web-token-01 (work in progress),		(JWT)", draft-ietf-oauth-json-web-token-01 (work in progress),
	July 2012.		July 2012.
	[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)		[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
			Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
			HTTP/1.1", RFC 2616, June 1999.
			[5] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature
			(JWS)", draft-ietf-jose-json-web-signature-03 (work in
			progress), July 2012.
			[6] Hammer-Lahav, E., "HTTP Authentication: MAC Access
			Authentication", draft-ietf-oauth-v2-http-mac-01 (work in
			progress), February 2012.
			[7] Wouters, P., Gilmore, J., Weiler, S., Kivinen, T., and H.
			Tschofenig, "TLS Out-of-Band Public Key Validation",
			draft-ietf-tls-oob-pubkey-03 (work in progress), April 2012.
			[8] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
	Protocol Version 1.2", RFC 5246, August 2008.		Protocol Version 1.2", RFC 5246, August 2008.
	[7] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley,		[9] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley,
	R., and W. Polk, "Internet X.509 Public Key Infrastructure		R., and W. Polk, "Internet X.509 Public Key Infrastructure
	Certificate and Certificate Revocation List (CRL) Profile",		Certificate and Certificate Revocation List (CRL) Profile",
	RFC 5280, May 2008.		RFC 5280, May 2008.
			[10] Jones, M., "JSON Web Key (JWK)",
			draft-ietf-jose-json-web-key-03 (work in progress), July 2012.
	7.2. Informative References		7.2. Informative References
	[8] Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0		[11] Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0
	Authorization Framework: Bearer Token Usage",		Authorization Framework: Bearer Token Usage",
	draft-ietf-oauth-v2-bearer-21 (work in progress), June 2012.		draft-ietf-oauth-v2-bearer-22 (work in progress), July 2012.
	[9] Hammer-Lahav, E., "HTTP Authentication: MAC Access
	Authentication", draft-ietf-oauth-v2-http-mac-01 (work in
	progress), February 2012.
	[10] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
	April 2010.
	[11] Campbell, B., Mortimore, C., Jones, M., and Y. Goland,		[12] Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
	"Assertion Framework for OAuth 2.0",		"Assertion Framework for OAuth 2.0",
	draft-ietf-oauth-assertions-04 (work in progress), July 2012.		draft-ietf-oauth-assertions-04 (work in progress), July 2012.
	[12] Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S., and E.		[13] Burr, W., Dodson, D., Perlner, R., Polk, T., Gupta, S., and E.
	Nabbus, "NIST Special Publication 800-63-1, INFORMATION		Nabbus, "NIST Special Publication 800-63-1, INFORMATION
	SECURITY", December 2008.		SECURITY", December 2008.
	Author's Address		[14] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
			April 2010.
			Authors' Addresses
			John Bradley
			Ping Identity
			Email: ve7jtb@ve7jtb.com
			Phil Hunt
			Oracle Corporation
			Email: phil.hunt@yahoo.com
			Tony Nadalin
			Microsoft
			Email: tonynad@microsoft.com
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Linnoitustie 6		Linnoitustie 6
	Espoo 02600		Espoo 02600
	Finland		Finland
	Phone: +358 (50) 4871445		Phone: +358 (50) 4871445
	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. 47 change blocks.
	141 lines changed or deleted		409 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/