< draft-mandyam-tokbind-attest-04.txt		draft-mandyam-tokbind-attest-05.txt >
	Token Binding Working Group G. Mandyam		Token Binding Working Group G. Mandyam
	Internet-Draft L. Lundblade		Internet-Draft L. Lundblade
	Intended status: Standards Track J. Azen		Intended status: Standards Track J. Azen
	Expires: December 13, 2018 Qualcomm Technologies Inc.		Expires: January 18, 2019 Qualcomm Technologies Inc.
	June 11, 2018		July 17, 2018
	Attested TLS Token Binding		Attested TLS Token Binding
	draft-mandyam-tokbind-attest-04		draft-mandyam-tokbind-attest-05
	Abstract		Abstract
	Token binding allows HTTP servers to bind bearer tokens to TLS		Token binding allows HTTP servers to bind bearer tokens to TLS
	connections. In order to do this, clients or user agents must prove		connections. In order to do this, clients or user agents must prove
	possession of a private key. However, proof-of-possession of a		possession of a private key. However, proof-of-possession of a
	private key becomes truly meaningful to a server when accompanied by		private key becomes truly meaningful to a server when accompanied by
	an attestation statement. This specification describes extensions to		an attestation statement. This specification describes extensions to
	the existing token binding protocol to allow for attestation		the existing token binding protocol to allow for attestation
	statements to be sent along with the related token binding messages.		statements to be sent along with the related token binding messages.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 December 13, 2018.		This Internet-Draft will expire on January 18, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Attestation Enhancement to TLS Token Binding Message . . . . 3		2. Attestation Enhancement to TLS Token Binding Message . . . . 3
	2.1. KeyStore Attestation . . . . . . . . . . . . . . . . . . 3		2.1. Token Binding Attestation Registry . . . . . . . . . . . 4
	2.1.1. Verification Procedures . . . . . . . . . . . . . . . 4		2.2. KeyStore Attestation . . . . . . . . . . . . . . . . . . 4
	2.2. TPMv2 Attestation . . . . . . . . . . . . . . . . . . . . 4
	2.2.1. Verification Procedures . . . . . . . . . . . . . . . 5		2.2.1. Verification Procedures . . . . . . . . . . . . . . . 5
	3. Extension Support Negotiation . . . . . . . . . . . . . . . . 5		2.3. TPMv2 Attestation . . . . . . . . . . . . . . . . . . . . 5
	3.1. Negotiating Token Binding Protocol Extensions . . . . . . 6		2.3.1. Verification Procedures . . . . . . . . . . . . . . . 5
			3. Extension Support Negotiation . . . . . . . . . . . . . . . . 6
			3.1. Negotiating Token Binding Protocol Extensions . . . . . . 7
	4. Example - Platform Attestation for Anomaly Detection . . . . 7		4. Example - Platform Attestation for Anomaly Detection . . . . 7
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		5.1. TLS Extensions Registry . . . . . . . . . . . . . . . . . 8
	6.1. Normative References . . . . . . . . . . . . . . . . . . 7		5.2. Token Binding Extension for Attestation . . . . . . . . . 8
	6.2. Informative References . . . . . . . . . . . . . . . . . 8		5.3. Token Binding Attestation Type Registry . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
			7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
			7.1. Normative References . . . . . . . . . . . . . . . . . . 9
			7.2. Informative References . . . . . . . . . . . . . . . . . 9
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	[I-D.ietf-tokbind-protocol] and [I-D.ietf-tokbind-negotiation]		[I-D.ietf-tokbind-protocol] and [I-D.ietf-tokbind-negotiation]
	describe a framework whereby servers can leverage cryptographically-		describe a framework whereby servers can leverage cryptographically-
	bound authentication tokens to verify TLS connections. This is		bound authentication tokens to verify TLS connections. This is
	useful for prevention of man-in-the-middle attacks on TLS sessions,		useful for prevention of man-in-the-middle attacks on TLS sessions,
	and provides a mechanism by which identity federation systems can be		and provides a mechanism by which identity federation systems can be
	leveraged by a relying party to verify a client based on proof-of-		leveraged by a relying party to verify a client based on proof-of-
	possession of a private key.		possession of a private key.
	skipping to change at page 3, line 24 ¶		skipping to change at page 3, line 29 ¶
	additional mechanism for binding the TLS connection to an		additional mechanism for binding the TLS connection to an
	authentication operation by the client.		authentication operation by the client.
	2. Attestation Enhancement to TLS Token Binding Message		2. Attestation Enhancement to TLS Token Binding Message
	The attestation statement can be processed 'in-band' as part of the		The attestation statement can be processed 'in-band' as part of the
	Token Binding Message itself. This document leverages the		Token Binding Message itself. This document leverages the
	TokenBinding.extensions field of the Token Binding Message as		TokenBinding.extensions field of the Token Binding Message as
	described in Section 3.4 of [I-D.ietf-tokbind-protocol], where the		described in Section 3.4 of [I-D.ietf-tokbind-protocol], where the
	extension data conforms to the guidelines of Section 6.3 of the same		extension data conforms to the guidelines of Section 6.3 of the same
	document. The extension data takes the form of a CBOR (compact		document. The value of the extension, as required by this same
	binary object representation) Data Definition Language construct,		section, is TBD. The extension data takes the form of a CBOR
	i.e. CDDL.		(compact binary object representation) Data Definition Language
			construct, i.e. CDDL.
	extension_data = {attestation}		extension_data = {attestation}
	attestation = (		attestation = (
	attestation_type: tstr,		attestation_type: tstr,
	attestation_data: bstr,		attestation_data: bstr,
	)		)
	The attestation data is determined according to the attestation type.		The attestation data is determined according to the attestation type.
	In this document, the following types are defined: "KeyStore" (where		In this document, the following types are defined: "KeyStore" (where
	the corresponding attestation data defined in [Keystore]) and "TPMv2"		the corresponding attestation data defined in [Keystore]) and "TPMv2"
	(where the corresponding attestation data defined in [TPMv2]).		(where the corresponding attestation data defined in [TPMv2]).
	Additional attestation types may be accepted by the token binding		Additional attestation types may be accepted by the token binding
	implementation (for instance, see Section 8 of [webauthn]).		implementation (for instance, see Section 8 of [webauthn]).
	2.1. KeyStore Attestation		2.1. Token Binding Attestation Registry
			It is recommended that a registry be created for additional
			attestation types, with corresponding specifications required to
			define the attestation data.
			Entries in this registry must include the following fields:
			o Value: The text string that uniquely identifies the attestation
			type, e.g. "TPMv2"
			o Description: A human-readable description of the attestation, e.g.
			"TCG TPM Version 2 compliant attestation"
			o Specification: A reference to a specification that defines the
			attestation data.
			2.2. KeyStore Attestation
	KeyStore attestation is relevant to the Android operating system.		KeyStore attestation is relevant to the Android operating system.
	The Android Keystore mechanism allows for an application (such as a		The Android Keystore mechanism allows for an application (such as a
	browser implementing the Token Binding stack) to create a key pair,		browser implementing the Token Binding stack) to create a key pair,
	export the public key, and protect the private key in a hardware-		export the public key, and protect the private key in a hardware-
	backed keystore. The Android Keystore can then be used to verify a		backed keystore. The Android Keystore can then be used to verify a
	keypair using the Keystore Attestation mechanism, which involves		keypair using the Keystore Attestation mechanism, which involves
	signing a payload according to a public key that chains to a root		signing a payload according to a public key that chains to a root
	certificate signed by an attestation root key that is specific to the		certificate signed by an attestation root key that is specific to the
	device manufacturer.		device manufacturer.
	skipping to change at page 4, line 20 ¶		skipping to change at page 5, line 5 ¶
	Material (EKM) corresponding to the current TLS connection (see		Material (EKM) corresponding to the current TLS connection (see
	Section 3.3 of [I-D.ietf-tokbind-protocol]). Then the attestation		Section 3.3 of [I-D.ietf-tokbind-protocol]). Then the attestation
	takes the form of a signature accompanies by a chain of DER-encoded		takes the form of a signature accompanies by a chain of DER-encoded
	x.509 certificates:		x.509 certificates:
	attestation_data = (		attestation_data = (
	sig: bytes,		sig: bytes,
	x5c: [credCert: bytes, *(caCert: bytes)]		x5c: [credCert: bytes, *(caCert: bytes)]
	)		)
	2.1.1. Verification Procedures		2.2.1. Verification Procedures
	The steps at the server for verifying a Token Binding KeyStore		The steps at the server for verifying a Token Binding KeyStore
	Attestation are:		Attestation are:
	o Extract EKM for current TLS connection.		o Extract EKM for current TLS connection.
	o Verify that attestation_data is in the expected CBOR format.		o Verify that attestation_data is in the expected CBOR format.
	o Parse the first certificate listed in x5c and extract the public		o Parse the first certificate listed in x5c and extract the public
	key, algorithm and challenge. If the challenge does not match the		key, algorithm and challenge. If the challenge does not match the
	EKM then the attestation is invalid.		EKM then the attestation is invalid.
	o If the challenge matches the EKM, verify the sig with respect to		o If the challenge matches the EKM, verify the sig with respect to
	the extracted public key and algorithm from the previous step.		the extracted public key and algorithm from the previous step.
	o Verify the rest of the certificate chain up to the root. The root		o Verify the rest of the certificate chain up to the root. The root
	certificate must match the expected root for the device.		certificate must match the expected root for the device.
	2.2. TPMv2 Attestation		2.3. TPMv2 Attestation
	Version 2 of the Trusted Computing Group's Trusted Platform Module		Version 2 of the Trusted Computing Group's Trusted Platform Module
	(TPM) specification provides for an attestation generated within the		(TPM) specification provides for an attestation generated within the
	context of a TPM. The attestation then is defined as		context of a TPM. The attestation then is defined as
	attestation_data = (		attestation_data = (
	tpmt_sig: bytes,		tpmt_sig: bytes,
	tpms_attest: bytes,		tpms_attest: bytes,
	x5c: [credCert: bytes, *(caCert: bytes)]		x5c: [credCert: bytes, *(caCert: bytes)]
	)		)
	The tpmt_sig is generated over a tpms_attest structure signed with		The tpmt_sig is generated over a tpms_attest structure signed with
	respect to the certificate chain provided in the x5c array. It is		respect to the certificate chain provided in the x5c array. It is
	derived from the TPMT_SIGNATURE data structure defined in		derived from the TPMT_SIGNATURE data structure defined in
	Section 11.3.4 of [TPMv2]. tpms_attest is derived from the		Section 11.3.4 of [TPMv2]. tpms_attest is derived from the
	TPMS_ATTEST data structure in Section 10.2.8 of [TPMv2], specifically		TPMS_ATTEST data structure in Section 10.2.8 of [TPMv2], specifically
	with the extraData field being set to a SHA-256 hash of the EKM.		with the extraData field being set to a SHA-256 hash of the EKM.
	2.2.1. Verification Procedures		2.3.1. Verification Procedures
	The steps for verifying a Token Binding TPMv2 Attestation are:		The steps for verifying a Token Binding TPMv2 Attestation are:
	o Extract EKM for current TLS connection.		o Extract EKM for current TLS connection.
	o Verify that attestation_data is in the expected CBOR format.		o Verify that attestation_data is in the expected CBOR format.
	o Parse the first certificate listed in x5c and extract the public		o Parse the first certificate listed in x5c and extract the public
	key.		key.
	skipping to change at page 6, line 31 ¶		skipping to change at page 7, line 12 ¶
	TokenBindingExtensions supported_extensions_list<1..2^8-1>		TokenBindingExtensions supported_extensions_list<1..2^8-1>
	} TokenBindingParameters;		} TokenBindingParameters;
	The "supported_extensions_list" contains the list of identifiers of		The "supported_extensions_list" contains the list of identifiers of
	all token binding message extensions supported by the client. A		all token binding message extensions supported by the client. A
	server supporting token binding extensions will respond in the server		server supporting token binding extensions will respond in the server
	hello with an appropriate "token_binding" extension that includes a		hello with an appropriate "token_binding" extension that includes a
	"supported_extensions_list". This list must be a subset of the the		"supported_extensions_list". This list must be a subset of the the
	extensions provided in the client hello.		extensions provided in the client hello.
			Since a TLS extension cannot itself be extended, the "token_binding"
			TLS extension cannot be reused. Therefore it is proposed that a new
			TLS extension be defined - "token_binding_with_extensions". This TLS
			extension codepoint is identical to the existing "token_binding"
			extension except for the additional data structures defined above.
	3.1. Negotiating Token Binding Protocol Extensions		3.1. Negotiating Token Binding Protocol Extensions
	The negotation described in Section 4 of		The negotation described in Section 4 of
	[I-D.ietf-tokbind-negotiation] still applies. In addition, a client		[I-D.ietf-tokbind-negotiation] still applies, except now the
	can receive a "supported_extensions_list" from the server as part of		"token_binding_with_extensions" codepoint would be used if the client
	the server hello. The client must terminate the handshake if the		supports any token binding extension. In addition, a client can
			receive a "supported_extensions_list" from the server as part of the
			server hello. The client must terminate the handshake if the
	"supported_extensions_list" received from the server is not a subset		"supported_extensions_list" received from the server is not a subset
	of the "supported_extensions_list" sent by the client in the client		of the "supported_extensions_list" sent by the client in the client
	hello. If the server hello list of supported extensions is a subset		hello. If the server hello list of supported extensions is a subset
	of the client supported extensions, then the client must only send		of the client supported extensions, then the client must only send
	those extensions specified in the server hello in the Token Binding		those extensions specified in the server hello in the Token Binding
	protocol. If the server hello does not include a		protocol. If the server hello does not include a
	"supported_extensions_list", then the client must not send any		"supported_extensions_list", then the client must not send any
	extensions along with the Token Binding Message.		extensions along with the Token Binding Message.
	4. Example - Platform Attestation for Anomaly Detection		4. Example - Platform Attestation for Anomaly Detection
	skipping to change at page 7, line 23 ¶		skipping to change at page 8, line 7 ¶
	may be desirable for a client-enhanced attestation reflecting for		may be desirable for a client-enhanced attestation reflecting for
	instance that an expected offered cipher suite in the client hello		instance that an expected offered cipher suite in the client hello
	message is present or the originating browser integrity is intact		message is present or the originating browser integrity is intact
	(e.g. through a hash over the browser application package). If the		(e.g. through a hash over the browser application package). If the
	network traffic monitor can interpret the atttestation included in		network traffic monitor can interpret the atttestation included in
	the token binding message, then it can verify the attestation and		the token binding message, then it can verify the attestation and
	potentially emit alerts based on an unexpected attestation.		potentially emit alerts based on an unexpected attestation.
	5. IANA Considerations		5. IANA Considerations
	This memo includes no request to IANA.		This memo includes the following requests to IANA.
	6. References		5.1. TLS Extensions Registry
	6.1. Normative References		This document proposes an update of the TLS "ExtensionType Values"
			registry. The following addition to the registry is requested:
			Value: TBD
			Extension name: token_binding_with_extensions
			Reference: this document
			Recommended: Yes
			5.2. Token Binding Extension for Attestation
			This document proposes an extension conformant with Section 6.3 of
			[I-D.ietf-tokbind-protocol], with the following specifics:
			o Value: TBD, an octet value between 0 and 255
			o Description: Token binding attestation extension
			o Specification: This document
			5.3. Token Binding Attestation Type Registry
			This document proposes the establishment of an attestation registry
			for a Token Binding extension focused on attestation. Entries in
			this registry must include the following fields:
			o Value: The text string that uniquely identifies the attestation
			type
			o Description: A human-readable description of the attestation
			o Specification: A reference to a specification that defines the
			attestation data.
			6. Acknowledgments
			Thanks to Andrei Popov for his detailed review and recommendations.
			7. References
			7.1. Normative References
	[I-D.greevenbosch-appsawg-cbor-cddl]		[I-D.greevenbosch-appsawg-cbor-cddl]
	Birkholz, H., Vigano, C., and C. Bormann, "Concise data		Birkholz, H., Vigano, C., and C. Bormann, "Concise data
	definition language (CDDL): a notational convention to		definition language (CDDL): a notational convention to
	express CBOR data structures", draft-greevenbosch-appsawg-		express CBOR data structures", draft-greevenbosch-appsawg-
	cbor-cddl-11 (work in progress), July 2017.		cbor-cddl-11 (work in progress), July 2017.
	[I-D.ietf-tokbind-https]		[I-D.ietf-tokbind-https]
	Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper,		Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper,
	N., and J. Hodges, "Token Binding over HTTP", draft-ietf-		N., and J. Hodges, "Token Binding over HTTP", draft-ietf-
	skipping to change at page 8, line 21 ¶		skipping to change at page 9, line 47 ¶
	[TPMv2] The Trusted Computing Group, "Trusted Platform Module		[TPMv2] The Trusted Computing Group, "Trusted Platform Module
	Library, Part 2: Structures", September 2016,		Library, Part 2: Structures", September 2016,
	<http://www.trustedcomputinggroup.org/wp-content/uploads/		<http://www.trustedcomputinggroup.org/wp-content/uploads/
	TPM-Rev-2.0-Part-2-Structures-01.38.pdf>.		TPM-Rev-2.0-Part-2-Structures-01.38.pdf>.
	[webauthn]		[webauthn]
	The Worldwide Web Consortium, "Web Authentication: An API		The Worldwide Web Consortium, "Web Authentication: An API
	for accessing Scoped Credentials",		for accessing Scoped Credentials",
	<https://www.w3.org/TR/webauthn/>.		<https://www.w3.org/TR/webauthn/>.
	6.2. Informative References		7.2. Informative References
	[I-D.birkholz-tuda]		[I-D.birkholz-tuda]
	Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,		Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,
	"Time-Based Uni-Directional Attestation", draft-birkholz-		"Time-Based Uni-Directional Attestation", draft-birkholz-
	tuda-02 (work in progress), July 2016.		tuda-02 (work in progress), July 2016.
	Authors' Addresses		Authors' Addresses
	Giridhar Mandyam		Giridhar Mandyam
	Qualcomm Technologies Inc.		Qualcomm Technologies Inc.
End of changes. 18 change blocks.
	28 lines changed or deleted		102 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/