< draft-mandyam-tokbind-attest-05.txt		draft-mandyam-tokbind-attest-06.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: January 18, 2019 Qualcomm Technologies Inc.		Expires: January 25, 2019 Qualcomm Technologies Inc.
	July 17, 2018		July 24, 2018
	Attested TLS Token Binding		Attested TLS Token Binding
	draft-mandyam-tokbind-attest-05		draft-mandyam-tokbind-attest-06
	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 January 18, 2019.		This Internet-Draft will expire on January 25, 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. Token Binding Attestation Registry . . . . . . . . . . . 4		2.1. KeyStore Attestation . . . . . . . . . . . . . . . . . . 4
	2.2. KeyStore Attestation . . . . . . . . . . . . . . . . . . 4		2.1.1. Verification Procedures . . . . . . . . . . . . . . . 4
			2.2. TPMv2 Attestation . . . . . . . . . . . . . . . . . . . . 5
	2.2.1. Verification Procedures . . . . . . . . . . . . . . . 5		2.2.1. Verification Procedures . . . . . . . . . . . . . . . 5
	2.3. TPMv2 Attestation . . . . . . . . . . . . . . . . . . . . 5
	2.3.1. Verification Procedures . . . . . . . . . . . . . . . 5
	3. Extension Support Negotiation . . . . . . . . . . . . . . . . 6		3. Extension Support Negotiation . . . . . . . . . . . . . . . . 6
	3.1. Negotiating Token Binding Protocol Extensions . . . . . . 7		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 . . . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	5.1. TLS Extensions Registry . . . . . . . . . . . . . . . . . 8		5.1. TLS Extensions Registry . . . . . . . . . . . . . . . . . 8
	5.2. Token Binding Extension for Attestation . . . . . . . . . 8		5.2. Token Binding Extensions for Attestation . . . . . . . . 8
	5.3. Token Binding Attestation Type Registry . . . . . . . . . 8		6. Security and Privacy Considerations . . . . . . . . . . . . . 9
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		6.1. Attestation Privacy Considerations . . . . . . . . . . . 9
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	7.1. Normative References . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	7.2. Informative References . . . . . . . . . . . . . . . . . 9		8.1. Normative References . . . . . . . . . . . . . . . . . . 9
			8.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		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 in part to create uniquely-identifiable
	useful for prevention of man-in-the-middle attacks on TLS sessions,		TLS bindings that can span multiple connections between a client and
	and provides a mechanism by which identity federation systems can be		a server. Once the use of token binding is negotiated as part of the
	leveraged by a relying party to verify a client based on proof-of-		TLS handshake, an application layer message (the Token Binding
	possession of a private key.		message) may be sent from the client to the relying party whose
			primary purpose is to encapsulate a signature over a value associated
	Once the use of token binding is negotiated as part of the TLS		with the current TLS session. The payload used for the signature is
	handshake, an application layer message (the Token Binding message)		the token binding public key (see [I-D.ietf-tokbind-protocol]). Use
	may be sent from the client to the relying party whose primary		of the token binding public key allows for generation of the
	purpose is to encapsulate a signature over a value associated with		attestation signature once over the lifetime of the public key.
	the current TLS session (Exported Key Material, i.e. EKM - see
	[I-D.ietf-tokbind-protocol]).
	Proof-of-possession of a private key is useful to a relying party,		Proof-of-possession of a private key is useful to a relying party,
	but the associated signature in the Token Binding message does not		but the associated signature in the Token Binding message does not
	provide an indication as to how the private key is stored and in what		provide an indication as to how the private key is stored and in what
	kind of environment the associated cryptographic operation takes		kind of environment the associated cryptographic operation takes
	place. This information may be required by a relying party in order		place. This information may be required by a relying party in order
	to satisfy requirements regarding client platform integrity.		to satisfy requirements regarding client platform integrity.
	Therefore, attestations are sometimes required by relying parties in		Therefore, attestations are sometimes required by relying parties in
	order for them to accept signatures from clients. As per the		order for them to accept signatures from clients. As per the
	definition in [I-D.birkholz-tuda], "remote attestation describes the		definition in [I-D.birkholz-tuda], "remote attestation describes the
	skipping to change at page 3, line 30 ¶		skipping to change at page 3, line 28 ¶
	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 value of the extension, as required by this same		document. The value of the extension, as required by this same
	section, is TBD. The extension data takes the form of a CBOR		section, is assigned per attestation type. The extension data takes
	(compact binary object representation) Data Definition Language		the form of a CBOR (compact binary object representation) Data
	construct, i.e. CDDL.		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. Token Binding Attestation Registry		The attestation data will likely include a signature over a challenge
			(depenting on the attestation type). The challenge can be used to
	It is recommended that a registry be created for additional		prevent replay of the attestation. However since the attestation is
	attestation types, with corresponding specifications required to		itself part of the token binding message (which has its own anti-
	define the attestation data.		replay protection mechanism), the attestation signature need only be
			generated over a known payload associated with the TLS token binding
	Entries in this registry must include the following fields:		session - the token binding public key. As a result, the token
			binding client only needs to send the attestation once during the
	o Value: The text string that uniquely identifies the attestation		lifetime of the token binding public key. In other words, if an
	type, e.g. "TPMv2"		attestation is included in the token binding message, it should only
			be sent in the initial token binding message following the creation
	o Description: A human-readable description of the attestation, e.g.		of the token binding key pair.
	"TCG TPM Version 2 compliant attestation"
	o Specification: A reference to a specification that defines the
	attestation data.
	2.2. KeyStore Attestation		2.1. 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.
			The octet value of the token binding extension that serves as
			identifiaction for the Keystore attestation type is requested to be
			0.
	KeyStore attestation provides a signature over a payload generated by		KeyStore attestation provides a signature over a payload generated by
	the application. Since in this case the application is the Token		the application. The payload is a SHA-256 hash of the token binding
	Binding stack resident on the device, the payload is the Exported Key		public key 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, a signature-generation algorithmic
	x.509 certificates:		identifier corresponding to the COSE algorithm registry
			([cose_iana]), and a chain of DER-encoded x.509 certificates:
	attestation_data = (		attestation_data = (
			alg: int,
	sig: bytes,		sig: bytes,
	x5c: [credCert: bytes, *(caCert: bytes)]		x5c: [credCert: bytes, *(caCert: bytes)]
	)		)
	2.2.1. Verification Procedures		2.1.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 Retrieve token binding public key for the current TLS connection,
			and compute is SHA-256 hash.
	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 and challenge. If the challenge does not match the SHA-256
	EKM then the attestation is invalid.		hash of the token binding public key then the attestation is
			invalid.
	o If the challenge matches the EKM, verify the sig with respect to		o If the challenge matches the expected hash of the token binding
	the extracted public key and algorithm from the previous step.		public key, verify the sig with respect to 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.3. TPMv2 Attestation		2.2. 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 = (
			alg: int,
	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, and the
	derived from the TPMT_SIGNATURE data structure defined in		algorithmic identifier corresponding to the COSE algorithm registry
	Section 11.3.4 of [TPMv2]. tpms_attest is derived from the		([cose_iana]). It is derived from the TPMT_SIGNATURE data structure
			defined in 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 token
			binding public key.
	2.3.1. Verification Procedures		The octet value of the token binding extension that serves as
			identifiaction for the TPMv2 attestation type is requested to be 1.
			2.2.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 the token binding public key for the 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.
	o Verify the tpms_attest structure,which includes		o Verify the tpms_attest structure,which includes
	* Verify that the type field is set to TPM_ST_ATTEST_CERTIFY.		* Verify that the type field is set to TPM_ST_ATTEST_CERTIFY.
	* Verify that extraData is equivalent to the EKM.		* Verify that extraData is equivalent to the SHA-256 hash of the
			token binding public key for the current TLS connection.
	* Verify that magic is set to the expected TPM_GENERATED_VALUE		* Verify that magic is set to the expected TPM_GENERATED_VALUE
	for the expected command sequence used to generate the		for the expected command sequence used to generate the
	attestation.		attestation.
	* Verification of additonal TPMS_ATTEST data fields is optional.		* Verification of additonal TPMS_ATTEST data fields is optional.
	o Verify tpmt_sig with respect to the public key provided in the		o Verify tpmt_sig with respect to the public key provided in the
	first certifcate in x5c, using the algorithm as specified in the		first certifcate in x5c, using the algorithm as specified in the
	sigAlg field (see Sections 11.3.4, 11.2.1.5 and 9.29 of [TPMv2]).		sigAlg field (see Sections 11.3.4, 11.2.1.5 and 9.29 of [TPMv2]).
	skipping to change at page 8, line 22 ¶		skipping to change at page 8, line 30 ¶
	registry. The following addition to the registry is requested:		registry. The following addition to the registry is requested:
	Value: TBD		Value: TBD
	Extension name: token_binding_with_extensions		Extension name: token_binding_with_extensions
	Reference: this document		Reference: this document
	Recommended: Yes		Recommended: Yes
	5.2. Token Binding Extension for Attestation		5.2. Token Binding Extensions for Attestation
	This document proposes an extension conformant with Section 6.3 of		This document proposes two extensions conformant with Section 6.3 of
	[I-D.ietf-tokbind-protocol], with the following specifics:		[I-D.ietf-tokbind-protocol], with the following specifics:
	o Value: TBD, an octet value between 0 and 255		Androoid Keystore Attestation:
	o Description: Token binding attestation extension		o Value: 0
			o Description: Android Keystore Attestation
	o Specification: This document		o Specification: This document
	5.3. Token Binding Attestation Type Registry		TPM v2 Attestation:
	This document proposes the establishment of an attestation registry		o Value: 1
	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		o Description: TPMv2 Attestation
	type
	o Description: A human-readable description of the attestation		o Specification: This document
	o Specification: A reference to a specification that defines the		6. Security and Privacy Considerations
	attestation data.
	6. Acknowledgments		The security and privacy considerations provided in Section 7 of
			[I-D.ietf-tokbind-protocol] are applicable to the attestation
			extensions proposed in this document. Additional considerations are
			provided in this section.
			6.1. Attestation Privacy Considerations
			The root signing key for the certificate chain used in verifying an
			attestation can be unique to the device. As a result, this can be
			used to track a device and/or end user. This potential privacy issue
			can be mitigated by the use of batch keys as an alternative to unique
			keys, or by generation of origin-specific attestation keys.
			The attestation data may also contain device-specific identifiers, or
			information that can be used to fingerprint a device. Sensitive
			information can be excluded from the attestation data when this is a
			concern.
			7. Acknowledgments
	Thanks to Andrei Popov for his detailed review and recommendations.		Thanks to Andrei Popov for his detailed review and recommendations.
	7. References		8. References
	7.1. Normative References		8.1. Normative References
			[cose_iana]
			Internet Assigned Numbers Authority, "COSE Algorithms",
			<https://www.iana.org/assignments/cose/
			cose.xhtml#algorithms>.
	[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 9, line 47 ¶		skipping to change at page 10, line 32 ¶
	[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/>.
	7.2. Informative References		8.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. 38 change blocks.
	82 lines changed or deleted		113 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/