draft-ietf-rats-tpm-based-network-device-attest-09.txt		draft-ietf-rats-tpm-based-network-device-attest-10.txt
	RATS Working Group G.C. Fedorkow, Ed.		RATS Working Group G.C. Fedorkow, Ed.
	Internet-Draft Juniper Networks, Inc.		Internet-Draft Juniper Networks, Inc.
	Intended status: Informational E. Voit		Intended status: Informational E. Voit
	Expires: 22 May 2022 Cisco		Expires: 3 July 2022 Cisco
	J. Fitzgerald-McKay		J. Fitzgerald-McKay
	National Security Agency		National Security Agency
	18 November 2021		30 December 2021
	TPM-based Network Device Remote Integrity Verification		TPM-based Network Device Remote Integrity Verification
	draft-ietf-rats-tpm-based-network-device-attest-09		draft-ietf-rats-tpm-based-network-device-attest-10
	Abstract		Abstract
	This document describes a workflow for remote attestation of the		This document describes a workflow for remote attestation of the
	integrity of firmware and software installed on network devices that		integrity of firmware and software installed on network devices that
	contain Trusted Platform Modules [TPM1.2], [TPM2.0], as defined by		contain Trusted Platform Modules [TPM1.2], [TPM2.0], as defined by
	the Trusted Computing Group (TCG).		the Trusted Computing Group (TCG).
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 22 May 2022.		This Internet-Draft will expire on 3 July 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 10, line 45 ¶		skipping to change at page 10, line 45 ¶
	* Once the device is running and has operational network		* Once the device is running and has operational network
	connectivity, verification can take place. A separate Verifier,		connectivity, verification can take place. A separate Verifier,
	running in its own trusted environment, will interrogate the		running in its own trusted environment, will interrogate the
	network device to retrieve the logs and a copy of the digests		network device to retrieve the logs and a copy of the digests
	collected by hashing each software object, signed by an		collected by hashing each software object, signed by an
	attestation private key secured by, but never released by, the		attestation private key secured by, but never released by, the
	TPM. The YANG model described in [I-D.ietf-rats-yang-tpm-charra]		TPM. The YANG model described in [I-D.ietf-rats-yang-tpm-charra]
	facilitates this operation.		facilitates this operation.
	The result is that the Verifier can verify the device's identity by		The result is that the Verifier can verify the device's identity by
	checking the subjectName and signature of the certificate containing		checking the subject attribute of the distinguished name and
	the TPM's attestation public key, and can validate the software that		signature of the certificate containing the TPM's attestation public
	was launched by verifying the correctness of the logs by comparing		key, and can validate the software that was launched by verifying the
	with the signed digests from the TPM, and comparing digests in the		correctness of the logs by comparing with the signed digests from the
	log with Reference Values.		TPM, and comparing digests in the log with Reference Values.
	It should be noted that attestation and identity are inextricably		It should be noted that attestation and identity are inextricably
	linked; signed Evidence that a particular version of software was		linked; signed Evidence that a particular version of software was
	loaded is of little value without cryptographic proof of the identity		loaded is of little value without cryptographic proof of the identity
	of the Attester producing the Evidence.		of the Attester producing the Evidence.
	+-------------------------------------------------------+		+-------------------------------------------------------+
	| +--------+ +--------+ +--------+ +---------+ |		| +---------+ +--------+ +--------+ +---------+ |
	| | BIOS |--->| Loader |-->| Kernel |--->|Userland | |		| |UEFI BIOS|--->| Loader |-->| Kernel |--->|Userland | |
	| +--------+ +--------+ +--------+ +---------+ |		| +---------+ +--------+ +--------+ +---------+ |
	| | | | |		| | | | |
	| | | | |		| | | | |
	| +------------+-----------+-+ |		| +------------+-----------+-+ |
	| Boot Phase | |		| Boot Phase | |
	| V |		| V |
	| +--------+ |		| +--------+ |
	| | TPM | |		| | TPM | |
	| +--------+ |		| +--------+ |
	| Router | |		| Router | |
	+--------------------------------|----------------------+		+--------------------------------|----------------------+
	skipping to change at page 15, line 32 ¶		skipping to change at page 15, line 32 ¶
	configuration procedures, the two keys are likely be different; some		configuration procedures, the two keys are likely be different; some
	of the considerations are outlined in TCG "TPM 2.0 Keys for Device		of the considerations are outlined in TCG "TPM 2.0 Keys for Device
	Identity and Attestation" [Platform-DevID-TPM-2.0].		Identity and Attestation" [Platform-DevID-TPM-2.0].
	The TCG TPM 2.0 Keys document [Platform-DevID-TPM-2.0] specifies		The TCG TPM 2.0 Keys document [Platform-DevID-TPM-2.0] specifies
	further conventions for these keys:		further conventions for these keys:
	* When separate Identity and Attestation keys are used, the		* When separate Identity and Attestation keys are used, the
	Attestation Key (AK) and its X.509 certificate should parallel the		Attestation Key (AK) and its X.509 certificate should parallel the
	DevID, with the same device ID information as the DevID		DevID, with the same device ID information as the DevID
	certificate (that is, the same subjectName and subjectAltName (if		certificate (that is, the same subject and subjectAltName (if
	present), even though the key pairs are different). This allows a		present), even though the key pairs are different). This allows a
	quote from the device, signed by an AK, to be linked directly to		quote from the device, signed by an AK, to be linked directly to
	the device that provided it, by examining the corresponding AK		the device that provided it, by examining the corresponding AK
	certificate. If the subjectName in the AK certificate doesn't		certificate. If the subject in the AK certificate doesn't match
	match the corresponding DevID certificate, or they're signed by		the corresponding DevID certificate, or they're signed by
	differing authorities the Verifier may signal the detection of an		differing authorities the Verifier may signal the detection of an
	Asokan-style person-in-the-middle attack (see Section 5.2).		Asokan-style person-in-the-middle attack (see Section 5.2).
	* Network devices that are expected to use secure zero touch		* Network devices that are expected to use secure zero touch
	provisioning as specified in [RFC8572]) MUST be shipped by the		provisioning as specified in [RFC8572]) MUST be shipped by the
	manufacturer with pre-provisioned keys (Initial DevID and Initial		manufacturer with pre-provisioned keys (Initial DevID and Initial
	AK, called IDevID and IAK). IDevID and IAK certificates MUST both		AK, called IDevID and IAK). IDevID and IAK certificates MUST both
	be signed by the Endorser (typically the device manufacturer).		be signed by the Endorser (typically the device manufacturer).
	Inclusion of an IDevID and IAK by a vendor does not preclude a		Inclusion of an IDevID and IAK by a vendor does not preclude a
	mechanism whereby an administrator can define Local Identity and		mechanism whereby an administrator can define Local Identity and
	skipping to change at page 18, line 18 ¶		skipping to change at page 18, line 18 ¶
	2.4. RIV Simplifying Assumptions		2.4. RIV Simplifying Assumptions
	This document makes the following simplifying assumptions to reduce		This document makes the following simplifying assumptions to reduce
	complexity:		complexity:
	* The product to be attested MUST be shipped by the equipment vendor		* The product to be attested MUST be shipped by the equipment vendor
	with both an IEEE 802.1AR Device Identity and an Initial		with both an IEEE 802.1AR Device Identity and an Initial
	Attestation Key (IAK) with certificate in place. The IAK		Attestation Key (IAK) with certificate in place. The IAK
	certificate MUST contain the same identity information as the		certificate MUST contain the same identity information as the
	DevID (specifically, the same subjectName and subjectAltName (if		DevID (specifically, the same subject and subjectAltName (if
	used), signed by the manufacturer), but it's a type of key that		used), signed by the manufacturer), but it's a type of key that
	can be used to sign a TPM Quote, but not other objects (i.e., it's		can be used to sign a TPM Quote, but not other objects (i.e., it's
	marked as a TCG "Restricted" key; this convention is described in		marked as a TCG "Restricted" key; this convention is described in
	"TPM 2.0 Keys for Device Identity and Attestation"		"TPM 2.0 Keys for Device Identity and Attestation"
	[Platform-DevID-TPM-2.0]). For network equipment, which is		[Platform-DevID-TPM-2.0]). For network equipment, which is
	generally non-privacy-sensitive, shipping a device with both an		generally non-privacy-sensitive, shipping a device with both an
	IDevID and an IAK already provisioned substantially simplifies		IDevID and an IAK already provisioned substantially simplifies
	initial startup.		initial startup.
	* IEEE 802.1AR does not require a product serial number as part of		* IEEE 802.1AR does not require a product serial number as part of
	the subjectName, but RIV-compliant devices MUST include their		the subject, but RIV-compliant devices MUST include their serial
	serial numbers in the DevID/IAK certificates to simplify tracking		numbers in the DevID/IAK certificates to simplify tracking
	logistics for network equipment users. All other optional 802.1AR		logistics for network equipment users. All other optional 802.1AR
	fields remain optional in RIV		fields remain optional in RIV
	* The product MUST be equipped with a Root of Trust for Measurement		* The product MUST be equipped with a Root of Trust for Measurement
	(RTM), Root of Trust for Storage and Root of Trust for Reporting		(RTM), Root of Trust for Storage and Root of Trust for Reporting
	(as defined in [SP800-155]) which together are capable of		(as defined in [SP800-155]) which together are capable of
	conforming to TCG Trusted Attestation Protocol Information Model		conforming to TCG Trusted Attestation Protocol Information Model
	[TAP].		[TAP].
	* The authorized software supplier MUST make available Reference		* The authorized software supplier MUST make available Reference
	skipping to change at page 36, line 51 ¶		skipping to change at page 36, line 51 ¶
	--------------------------------------------------------------------		--------------------------------------------------------------------
	| Connect the TPM to the TLS stack | Vendor TLS |		| Connect the TPM to the TLS stack | Vendor TLS |
	| o Use the DevID in the TPM to authenticate | stack (This |		| o Use the DevID in the TPM to authenticate | stack (This |
	| TAP connections, identifying the device | action is |		| TAP connections, identifying the device | action is |
	| | simply |		| | simply |
	| | configuring TLS|		| | configuring TLS|
	| | to use the DevID |		| | to use the DevID |
	| | as its client |		| | as its client |
	| | certificate) |		| | certificate) |
	--------------------------------------------------------------------		--------------------------------------------------------------------
	| Make CoSWID tags for BIOS/LoaderLKernel objects | IETF CoSWID |		| Make CoSWID tags for BIOS/Loader/Kernel objects | IETF CoSWID |
	| o Add reference measurements into SWID tags | ISO/IEC 19770-2|		| o Add reference measurements into SWID tags | ISO/IEC 19770-2|
	| o Manufacturer should sign the SWID tags | NIST IR 8060 |		| o Manufacturer should sign the SWID tags | NIST IR 8060 |
	| o The TCG RIM-IM identifies further | |		| o The TCG RIM-IM identifies further | |
	| procedures to create signed RIM | |		| procedures to create signed RIM | |
	| documents that provide the necessary | |		| documents that provide the necessary | |
	| reference information | |		| reference information | |
	--------------------------------------------------------------------		--------------------------------------------------------------------
	| Package the SWID tags with a vendor software | Retrieve tags |		| Package the SWID tags with a vendor software | Retrieve tags |
	| release | with |		| release | with |
	| o A tag-generator plugin such | I-D.ietf-sacm-coswid|		| o A tag-generator plugin such | I-D.ietf-sacm-coswid|
	skipping to change at page 41, line 9 ¶		skipping to change at page 41, line 9 ¶
	Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann,		Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann,
	"Time-Based Uni-Directional Attestation", Work in		"Time-Based Uni-Directional Attestation", Work in
	Progress, Internet-Draft, draft-birkholz-rats-tuda-05, 12		Progress, Internet-Draft, draft-birkholz-rats-tuda-05, 12
	July 2021, <https://www.ietf.org/archive/id/draft-		July 2021, <https://www.ietf.org/archive/id/draft-
	birkholz-rats-tuda-05.txt>.		birkholz-rats-tuda-05.txt>.
	[I-D.ietf-rats-architecture]		[I-D.ietf-rats-architecture]
	Birkholz, H., Thaler, D., Richardson, M., Smith, N., and		Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
	W. Pan, "Remote Attestation Procedures Architecture", Work		W. Pan, "Remote Attestation Procedures Architecture", Work
	in Progress, Internet-Draft, draft-ietf-rats-architecture-		in Progress, Internet-Draft, draft-ietf-rats-architecture-
	13, 8 November 2021, <https://www.ietf.org/archive/id/		14, 9 December 2021, <https://www.ietf.org/archive/id/
	draft-ietf-rats-architecture-13.txt>.		draft-ietf-rats-architecture-14.txt>.
	[I-D.ietf-rats-eat]		[I-D.ietf-rats-eat]
	Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity		Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity
	Attestation Token (EAT)", Work in Progress, Internet-		Attestation Token (EAT)", Work in Progress, Internet-
	Draft, draft-ietf-rats-eat-11, 24 October 2021,		Draft, draft-ietf-rats-eat-11, 24 October 2021,
	<https://www.ietf.org/archive/id/draft-ietf-rats-eat-		<https://www.ietf.org/archive/id/draft-ietf-rats-eat-
	11.txt>.		11.txt>.
	[I-D.richardson-rats-usecases]		[I-D.richardson-rats-usecases]
	Richardson, M., Wallace, C., and W. Pan, "Use cases for		Richardson, M., Wallace, C., and W. Pan, "Use cases for
End of changes. 12 change blocks.
	21 lines changed or deleted		21 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/