rfc9683v1.txt		rfc9683.txt
	Internet Engineering Task Force (IETF) G. C. Fedorkow, Ed.		Internet Engineering Task Force (IETF) G. C. Fedorkow, Ed.
	Request for Comments: 9683 Juniper Networks, Inc.		Request for Comments: 9683 Juniper Networks, Inc.
	Category: Informational E. Voit		Category: Informational E. Voit
	ISSN: 2070-1721 Cisco		ISSN: 2070-1721 Cisco
	J. Fitzgerald-McKay		J. Fitzgerald-McKay
	National Security Agency		National Security Agency
	September 2024		September 2024
	TPM-based Network Device Remote Integrity Verification		Remote Integrity Verification of Network Devices Containing Trusted
			Platform Modules
	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 (TPMs), as defined by the Trusted		contain Trusted Platform Modules (TPMs), as defined by the Trusted
	Computing Group (TCG), or equivalent hardware implementations that		Computing Group (TCG), or equivalent hardware implementations that
	include the protected capabilities, as provided by TPMs.		include the protected capabilities, as provided by TPMs.
	Status of This Memo		Status of This Memo
	skipping to change at line 149 ¶		skipping to change at line 150 ¶
	Additionally, this document defines the following term:		Additionally, this document defines the following term:
	Attestation: The process of generating, conveying, and appraising		Attestation: The process of generating, conveying, and appraising
	claims, backed by evidence, about device trustworthiness		claims, backed by evidence, about device trustworthiness
	characteristics, including supply chain trust, identity, device		characteristics, including supply chain trust, identity, device
	provenance, software configuration, device composition, compliance		provenance, software configuration, device composition, compliance
	to test suites, functional and assurance evaluations, etc.		to test suites, functional and assurance evaluations, etc.
	The goal of attestation is simply to assure an administrator or		The goal of attestation is simply to assure an administrator or
	auditor that the device configuration and software that was launched		auditor that the device's configuration and software are authentic
	when the device was last started is authentic and untampered-with.		and has been unaltered since the device started. The determination
	The determination of software authenticity is not prescribed in this		of software authenticity is not prescribed in this document, but it's
	document, but it's typically taken to mean a software image generated		typically taken to mean a software image generated by an authority
	by an authority trusted by the administrator, such as the device		trusted by the administrator, such as the device manufacturer.
	manufacturer.
	Within the context of the Trusted Computing Group (TCG), the scope of		Within the context of the Trusted Computing Group (TCG), the scope of
	attestation is typically narrowed to describe the process by which an		attestation is typically narrowed to describe the process by which an
	independent Verifier can obtain cryptographic proof as to the		independent Verifier can obtain cryptographic proof as to the
	identity of the device in question, evidence of the integrity of the		identity of the device in question, evidence of the integrity of the
	device's software that was loaded upon startup, and verification that		device's software that was loaded upon startup, and verification that
	the current configuration matches the intended configuration. For		the current configuration matches the intended configuration. For
	network equipment, a Verifier capability can be embedded in a Network		network equipment, a Verifier capability can be embedded in a Network
	Management Station, a posture collection server, or other network		Management Station, a posture collection server, or other network
	analytics tool (such as a software asset management solution, or a		analytics tool (such as a software asset management solution, or a
	skipping to change at line 268 ¶		skipping to change at line 268 ¶
	By using these two interlocking mechanisms, RIV, which is a component		By using these two interlocking mechanisms, RIV, which is a component
	in a chain of procedures, can assure a network operator that the		in a chain of procedures, can assure a network operator that the
	equipment in their network can be reliably identified and that		equipment in their network can be reliably identified and that
	authentic software of a known version is installed on each device.		authentic software of a known version is installed on each device.
	Equipment in the network includes devices that make up the network		Equipment in the network includes devices that make up the network
	itself, such as routers, switches, and firewalls.		itself, such as routers, switches, and firewalls.
	Software used to boot a device can be identified by a chain of		Software used to boot a device can be identified by a chain of
	measurements, anchored at the start by a Root of Trust for		measurements, anchored at the start by a Root of Trust for
	Measurement (RTM) (see Appendix A.2), each measuring the next stage		Measurement (RTM) (see Appendix A.2). An attestation function
	and recording the result in tamper-resistant storage, normally ending		embedded in each stage, verified by the previous stage, measures the
	when the system software is fully loaded. A measurement signifies		next stage and records the result in tamper-resistant storage. A
	the identity, integrity, and version of each software component		measurement signifies the identity, integrity, and version of each
	registered with an Attester's TPM [TPM-1.2] [TPM-2.0] so that a		software component registered with an Attester's TPM [TPM-1.2]
	subsequent verification stage can determine if the software installed		[TPM-2.0] so that a subsequent verification stage can determine if
	is authentic, up-to-date, and free of tampering.		the software installed is authentic, up-to-date, and free of
			tampering.
	RIV includes several major processes, which are split between the		RIV includes several major processes, which are split between the
	Attester and Verifier:		Attester and Verifier:
	1. Generation of Evidence is the process whereby an Attester		1. Generation of Evidence is the process whereby an Attester
	generates cryptographic proof (Evidence) of claims about device		generates cryptographic proof (Evidence) of claims about device
	properties. In particular, the device identity and its software		properties. In particular, the device identity and its software
	configuration are both of critical importance.		configuration are both of critical importance.
	2. Device Identification refers to the mechanism assuring the		2. Device Identification refers to the mechanism assuring the
	skipping to change at line 340 ¶		skipping to change at line 341 ¶
	was started on the device through the boot cycle. Successful		was started on the device through the boot cycle. Successful
	attestation requires an unbroken chain from a boot-time Root of		attestation requires an unbroken chain from a boot-time Root of
	Trust through all layers of software needed to bring the device		Trust through all layers of software needed to bring the device
	to an operational state, in which each stage computes the hash of		to an operational state, in which each stage computes the hash of
	components of the next stage, then updates the attestation log		components of the next stage, then updates the attestation log
	and the TPM. The TPM can then report the hashes of all the		and the TPM. The TPM can then report the hashes of all the
	measured hashes as signed evidence called a Quote (see		measured hashes as signed evidence called a Quote (see
	Appendix A.1 for an overview of TPM operation or [TPM-1.2] and		Appendix A.1 for an overview of TPM operation or [TPM-1.2] and
	[TPM-2.0] for many more details).		[TPM-2.0] for many more details).
	3. Signed Reference Values (aka Reference Integrity Measurements)		3. Signed Reference Values (aka reference integrity measurements)
	must be conveyed from the Reference Value Provider (the entity		must be conveyed from the Reference Value Provider (the entity
	accepted as the software authority, often the manufacturer of the		accepted as the software authority, often the manufacturer of the
	network device) to the Verifier.		network device) to the Verifier.
	1.6. Solution Requirements		1.6. Solution Requirements
	RIV must address the "Lying Endpoint" problem, in which malicious		RIV must address the "Lying Endpoint" problem, in which malicious
	software on an endpoint may subvert the intended function and also		software on an endpoint may subvert the intended function and also
	prevent the endpoint from reporting its compromised status. (See		prevent the endpoint from reporting its compromised status. (See
	Section 5 for further Security Considerations.)		Section 5 for further Security Considerations.)
	skipping to change at line 449 ¶		skipping to change at line 450 ¶
	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 [RFC9684] facilitates this		TPM. The YANG model described in [RFC9684] facilitates this
	operation.		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 subject [RFC5280] and signature of the certificate		checking the subject [RFC5280] and signature of the certificate
	containing the TPM's attestation public key, and can validate the		containing the TPM's attestation public key. The Verifier can then
	software that was launched by verifying the correctness of the logs		verify the log's correctness by accumulating all the hashes in the
	by comparing with the signed digests from the TPM, and comparing		log and comparing that to the signed digests from the TPM. From
	digests in the log with Reference Values.		there, the Verifier can validate the launched software by comparing
			the 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.
	+-------------------------------------------------------+		+-------------------------------------------------------+
	| +---------+ +--------+ +--------+ +---------+ |		| +---------+ +--------+ +--------+ +---------+ |
	| |UEFI BIOS|--->| Loader |-->| Kernel |--->|Userland | |		| |UEFI BIOS|--->| Loader |-->| Kernel |--->|Userland | |
	| +---------+ +--------+ +--------+ +---------+ |		| +---------+ +--------+ +--------+ +---------+ |
	skipping to change at line 664 ¶		skipping to change at line 666 ¶
	Device Identity and Attestation" document [PLATFORM-DEVID-TPM-2.0].		Device Identity and Attestation" document [PLATFORM-DEVID-TPM-2.0].
	The "TPM 2.0 Keys for Device Identity and Attestation" document		The "TPM 2.0 Keys for Device Identity and Attestation" document
	[PLATFORM-DEVID-TPM-2.0] specifies further conventions for these		[PLATFORM-DEVID-TPM-2.0] specifies further conventions for these
	keys:		keys:
	* When separate Identity and Attestation keys are used, the AK and		* When separate Identity and Attestation keys are used, the AK and
	its X.509 certificate should parallel the DevID, with the same		its X.509 certificate should parallel the DevID, with the same
	unique device identification as the DevID certificate (that is,		unique device identification as the DevID certificate (that is,
	the same subject and subjectAltName (if present), even though the		the same subject and subjectAltName (if present), even though the
	key pairs are different). This allows a quote from the device,		key pairs are different). By examining the corresponding AK
	signed by an AK, to be linked directly to the device that provided		certificate, the Verifier can directly link a device's quote,
	it, by examining the corresponding AK certificate. If the subject		which was signed by an AK, to the device that provided it. If the
	in the AK certificate doesn't match the corresponding DevID		subject in the AK certificate doesn't match the corresponding
	certificate, or if they're signed by different authorities, the		DevID certificate, or if they're signed by different authorities,
	Verifier may signal the detection of an Asokan-style person-in-		the Verifier may signal the detection of an Asokan-style person-
	the-middle attack (see Section 5.2).		in-the-middle attack (see Section 5.2).
	* Network devices that are expected to use SZTP as specified in		* Network devices that are expected to use SZTP as specified in
	[RFC8572] MUST be shipped by the manufacturer with pre-provisioned		[RFC8572] MUST be shipped by the manufacturer with pre-provisioned
	keys (Initial DevID and Initial AK, called IDevID and IAK,		keys (Initial DevID and Initial AK, called IDevID and IAK,
	respectively). IDevID and IAK certificates MUST both be signed by		respectively). IDevID and IAK certificates MUST both be signed by
	the Endorser (typically the device manufacturer). Inclusion of an		the Endorser (typically the device manufacturer). Inclusion of an
	IDevID and IAK by a vendor does not preclude a mechanism whereby		IDevID and IAK by a vendor does not preclude a mechanism whereby
	an administrator can define LDevID and Local Attestation Keys		an administrator can define LDevID and Local Attestation Keys
	(LAK) if desired.		(LAK) if desired.
	skipping to change at line 779 ¶		skipping to change at line 781 ¶
	the Challenge-Response-based Remote Attestation (CHARRA) YANG		the Challenge-Response-based Remote Attestation (CHARRA) YANG
	model [RFC9684]. While the TAP IM gives a protocol-independent		model [RFC9684]. While the TAP IM gives a protocol-independent
	description of the data elements involved, it's important to note		description of the data elements involved, it's important to note
	that quotes from the TPM are signed inside the TPM and MUST be		that quotes from the TPM are signed inside the TPM and MUST be
	retrieved in a way that does not invalidate the signature, to		retrieved in a way that does not invalidate the signature, to
	preserve the trust model. The CHARRA YANG model [RFC9684] is		preserve the trust model. The CHARRA YANG model [RFC9684] is
	used for this purpose. (See Section 5, Security Considerations).		used for this purpose. (See Section 5, Security Considerations).
	6. Reference Values MUST be encoded as defined in the TCG RIM		6. Reference Values MUST be encoded as defined in the TCG RIM
	document [RIM], typically using Software Identification (SWID)		document [RIM], typically using Software Identification (SWID)
	[SWID], [NIST-IR-8060], or Concise SWID (CoSWID) tags [RFC9393].		tags [SWID] [NIST-IR-8060] or Concise SWID (CoSWID) tags
			[RFC9393].
	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 a DevID as specified by IEEE Std 802.1AR and an IAK,		with both a DevID as specified by IEEE Std 802.1AR and an IAK,
	with certificates in place. The IAK certificate must contain the		with certificates in place. The IAK certificate must contain the
	same identity information as the DevID (specifically, the same		same identity information as the DevID (specifically, the same
	skipping to change at line 1182 ¶		skipping to change at line 1185 ¶
	Trustworthiness of RIV attestation depends strongly on the validity		Trustworthiness of RIV attestation depends strongly on the validity
	of keys used for identity and attestation reports. RIV takes full		of keys used for identity and attestation reports. RIV takes full
	advantage of TPM capabilities to ensure that evidence can be trusted.		advantage of TPM capabilities to ensure that evidence can be trusted.
	Two sets of key pairs are relevant to RIV attestation:		Two sets of key pairs are relevant to RIV attestation:
	* A DevID key pair is used to certify the identity of the device in		* A DevID key pair is used to certify the identity of the device in
	which the TPM is installed.		which the TPM is installed.
	* An Attestation Key pair (AK) key is used to certify attestation		* An AK key pair is used to certify attestation Evidence (i.e.,
	Evidence (called "quotes" in TCG documents), used to provide		quotes) and to provide evidence for integrity of the device
	evidence for integrity of the software on the device		software.
	TPM practices usually require that these keys be different to ensure		TPM practices usually require that these keys be different to ensure
	that a general-purpose signing key cannot be used to spoof an		that a general-purpose signing key cannot be used to spoof an
	attestation quote.		attestation quote.
	In each case, the private half of the key is known only to the TPM		In each case, the private half of the key is known only to the TPM
	and cannot be retrieved externally, even by a trusted party. To		and cannot be retrieved externally, even by a trusted party. To
	ensure that's the case, specification-compliant private/public key		ensure that's the case, specification-compliant private/public key
	pairs are generated inside the TPM, where they are never exposed and		pairs are generated inside the TPM, where they are never exposed and
	cannot be extracted (see [PLATFORM-DEVID-TPM-2.0]).		cannot be extracted (see [PLATFORM-DEVID-TPM-2.0]).
	skipping to change at line 1255 ¶		skipping to change at line 1258 ¶
	Because the contents of the quote are signed inside the TPM, any		Because the contents of the quote are signed inside the TPM, any
	external modification (including reformatting to a different data		external modification (including reformatting to a different data
	format) after measurements have been taken will be detected as		format) after measurements have been taken will be detected as
	tampering. An unbroken chain of trust is essential for ensuring that		tampering. An unbroken chain of trust is essential for ensuring that
	blocks of code that are taking measurements have been verified before		blocks of code that are taking measurements have been verified before
	execution (see Figure 1).		execution (see Figure 1).
	Requiring measurements of the operating software to be signed by a		Requiring measurements of the operating software to be signed by a
	key known only to the TPM also removes the need to trust the device's		key known only to the TPM also removes the need to trust the device's
	operating software (beyond the first measurement in the RTM; see		operating software (beyond the first measurement in the RTM; see
	below). Any changes to the quote, generated and signed by the TPM		below). If malicious software makes any changes to a quote in the
	itself, made by malicious device software, or in the path back to the		device itself, or in the path back to the Verifier, the signature on
	Verifier, will invalidate the signature on the quote.		the quote will be invalidated.
	A critical feature of the YANG model described in [RFC9684] is the		A critical feature of the YANG model described in [RFC9684] is the
	ability to carry TPM data structures in their TCG-defined format,		ability to carry TPM data structures in their TCG-defined format,
	without requiring any changes to the structures as they were signed		without requiring any changes to the structures as they were signed
	and delivered by the TPM. While alternate methods of conveying TPM		and delivered by the TPM. While alternate methods of conveying TPM
	quotes could compress out redundant information, or add another layer		quotes could reduce redundant information, or add another layer of
	of signing using external keys, the implementation MUST preserve the		signing using external keys, the implementation MUST preserve the TPM
	TPM signing so that tampering anywhere in the path between the TPM		signing so that tampering anywhere in the path between the TPM itself
	itself and the Verifier can be detected.		and the Verifier can be detected.
	5.2. Prevention of Spoofing and Person-in-the-Middle Attacks		5.2. Prevention of Spoofing and Person-in-the-Middle Attacks
	Prevention of spoofing attacks against attestation systems is also		Prevention of spoofing attacks against attestation systems is also
	important. There are several cases to consider:		important. There are several cases to consider:
	* The entire device could be spoofed. If the Verifier goes to		* The entire device could be spoofed. If the Verifier goes to
	appraise a specific Attester, it might be redirected to a		appraise a specific Attester, it might be redirected to a
	different Attester.		different Attester.
	skipping to change at line 1715 ¶		skipping to change at line 1718 ¶
	0.20, July 2018, <https://trustedcomputinggroup.org/wp-		0.20, July 2018, <https://trustedcomputinggroup.org/wp-
	content/uploads/		content/uploads/
	TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf>.		TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf>.
	[TPM-1.2] Trusted Computing Group, "TPM 1.2 Main Specification",		[TPM-1.2] Trusted Computing Group, "TPM 1.2 Main Specification",
	Level 2, Version 1.2, Revision 116, March 2011,		Level 2, Version 1.2, Revision 116, March 2011,
	<https://trustedcomputinggroup.org/resource/tpm-main-		<https://trustedcomputinggroup.org/resource/tpm-main-
	specification/>.		specification/>.
	[TPM-2.0] Trusted Computing Group, "Trusted Platform Module		[TPM-2.0] Trusted Computing Group, "Trusted Platform Module
	Library", Family "2.0", Level 00, Revision 01.59, November		Library", Family "2.0", Level 00, Revision 01.83, March
	2019, <https://trustedcomputinggroup.org/resource/tpm-		2024, <https://trustedcomputinggroup.org/resource/tpm-
	library-specification/>.		library-specification/>.
	Appendix A. Supporting Materials		Appendix A. Supporting Materials
	A.1. Using a TPM for Attestation		A.1. Using a TPM for Attestation
	The TPM and surrounding ecosystem provide three interlocking		The TPM and surrounding ecosystem provide three interlocking
	capabilities to enable secure collection of evidence from a remote		capabilities to enable secure collection of evidence from a remote
	device: PCRs, a Quote mechanism, and a standardized Event Log.		device: PCRs, a Quote mechanism, and a standardized Event Log.
	skipping to change at line 1844 ¶		skipping to change at line 1847 ¶
	| | | | |		| | | | |
	+-----------------------+ | +-------------------------+		+-----------------------+ | +-------------------------+
	|		|
	-------------------- --------------------		-------------------- --------------------
	| |		| |
	------------------------------- ---------------------------------		------------------------------- ---------------------------------
	| Reference Values | | Attestation |		| Reference Values | | Attestation |
	------------------------------- ---------------------------------		------------------------------- ---------------------------------
	********************************************************************		********************************************************************
	* IETF Attestation Reference Interaction Diagram *		* IETF Remote Attestation Conceptual Data Flow *
			* RFC9334, Figure 1 *
	********************************************************************		********************************************************************
	......................... .........................		......................... .........................
	. Reference Integrity . . TAP (PTS2.0) Info .		. Reference Integrity . . TAP Info .
	. Manifest . . Model and Canonical .		. Manifest . . Model and Canonical .
	. . . Log Format .		. . . Log Format .
	......................... .........................		......................... .........................
	************************* *************************		************************* *************************
	* YANG SWID Module * * YANG Attestation *		* YANG SWID Module * * YANG Attestation *
	* RFC9393 * * Module *		* RFC9393 * * Module *
	* * * RFC9684 *		* * * RFC9684 *
	* * * *		* * * *
	************************* *************************		************************* *************************
	skipping to change at line 1951 ¶		skipping to change at line 1955 ¶
	+----------------------------------------+--------------------------+		+----------------------------------------+--------------------------+
	| Use PC Client measurement definitions | [PC-CLIENT-BIOS-TPM-2.0] |		| Use PC Client measurement definitions | [PC-CLIENT-BIOS-TPM-2.0] |
	| to define the use of PCRs (although | |		| to define the use of PCRs (although | |
	| Windows OS is rare on Networking | |		| Windows OS is rare on Networking | |
	| Equipment, UEFI BIOS is not). | |		| Equipment, UEFI BIOS is not). | |
	+----------------------------------------+--------------------------+		+----------------------------------------+--------------------------+
	| Use TAP to retrieve measurements: | [RFC9684] |		| Use TAP to retrieve measurements: | [RFC9684] |
	| | |		| | |
	| * Map to YANG. | [CEL] |		| * Map to YANG. | [CEL] |
	| | |		| | |
	| Use Canonical Log Format. | |		| * Use Canonical Log Format. | |
	+----------------------------------------+--------------------------+		+----------------------------------------+--------------------------+
	| A Posture Collection Server (as | |		| A Posture Collection Server (as | |
	| described in IETF SACMs ECP) should | |		| described in IETF SACMs ECP) should | |
	| request the attestation and analyze | |		| request the attestation and analyze | |
	| the result. The Management | |		| the result. The Management | |
	| application might be broken down to | |		| application might be broken down to | |
	| several more components: | |		| several more components: | |
	| | |		| | |
	| * A Posture Manager Server that | |		| * A Posture Manager Server that | |
	| collects reports and stores them | |		| collects reports and stores them | |
End of changes. 14 change blocks.
	42 lines changed or deleted		46 lines changed or added
This html diff was produced by rfcdiff 1.48.