draft-ietf-rats-tpm-based-network-device-attest-13.txt		draft-ietf-rats-tpm-based-network-device-attest-14.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: 2 September 2022 Cisco		Expires: 23 September 2022 Cisco
	J. Fitzgerald-McKay		J. Fitzgerald-McKay
	National Security Agency		National Security Agency
	1 March 2022		22 March 2022
	TPM-based Network Device Remote Integrity Verification		TPM-based Network Device Remote Integrity Verification
	draft-ietf-rats-tpm-based-network-device-attest-13		draft-ietf-rats-tpm-based-network-device-attest-14
	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)), or equivalent hardware		the Trusted Computing Group (TCG)), or equivalent hardware
	implementations that include the protected capabilities, as provided		implementations that include the protected capabilities, as provided
	by TPMs.		by TPMs.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 2 September 2022.		This Internet-Draft will expire on 23 September 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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 7, line 13 ¶		skipping to change at page 7, line 13 ¶
	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
	Relying Party (ultimately, a network administrator) of the		Relying Party (ultimately, a network administrator) of the
	identity of devices that make up their network, and that their		identity of devices that make up their network, and that their
	manufacturers are known.		manufacturers are known.
	3. Conveyance of Evidence reliably transports the collected Evidence		3. Conveyance of Evidence reliably transports the collected Evidence
	from Attester to a Verifier to allow a management station to		from Attester to a Verifier to allow a management station to
	perform a meaningful appraisal in Step 4. The transport is		perform a meaningful appraisal in Step 4. The transport is
	typically carried out via a management network. The channel must		typically carried out via a management network. While not
	provide integrity and authenticity, and, in some use cases, may		required for reliable attestation, an encrypted channel may be
	also require confidentiality. It should be noted that critical		used to provide integrity, authenticity, or confidentiality once
			attestation is complete. It should be noted that critical
	attestation evidence from the TPM is signed by a key known only		attestation evidence from the TPM is signed by a key known only
	to TPM, and is not dependent on encyption carried out as part of		to TPM, and is not dependent on encyption carried out as part of
	a reliable transport.		a reliable transport.
	4. Finally, Appraisal of Evidence occurs. This is the process of		4. Finally, Appraisal of Evidence occurs. This is the process of
	verifying the Evidence received by a Verifier from the Attester,		verifying the Evidence received by a Verifier from the Attester,
	and using an Appraisal Policy to develop an Attestation Result,		and using an Appraisal Policy to develop an Attestation Result,
	used to inform decision making. In practice, this means		used to inform decision-making. In practice, this means
	comparing the Attester's measurements reported as Evidence with		comparing the Attester's measurements reported as Evidence with
	the device configuration expected by the Verifier. Subsequently		the device configuration expected by the Verifier. Subsequently,
	the Appraisal Policy for Evidence might match Evidence found		the Appraisal Policy for Evidence might match Evidence found
	against Reference Values (aka Golden Measurements), which		against Reference Values (aka Golden Measurements), which
	represent the intended configured state of the connected device.		represent the intended configured state of the connected device.
	All implementations supporting this RIV specification require the		All implementations supporting this RIV specification require the
	support of the following three technologies:		support of the following three technologies:
	1. Identity: Device identity in RIV is based on IEEE 802.1AR Device		1. Identity: Device identity in RIV is based on IEEE 802.1AR Device
	Identity (DevID) [IEEE-802-1AR], coupled with careful supply-		Identity (DevID) [IEEE-802-1AR], coupled with careful supply-
	chain management by the manufacturer. The Initial DevID (IDevID)		chain management by the manufacturer. The Initial DevID (IDevID)
	skipping to change at page 13, line 28 ¶		skipping to change at page 13, line 28 ¶
	| each boot attempt, and an identifier for | | |		| each boot attempt, and an identifier for | | |
	| where the loader was found | | |		| where the loader was found | | |
	--------------------------------------------------------------------		--------------------------------------------------------------------
	| Vendor Specific Measurements during boot | 6 | 6 |		| Vendor Specific Measurements during boot | 6 | 6 |
	--------------------------------------------------------------------		--------------------------------------------------------------------
	| Secure Boot Policy. This PCR records keys | | 7 |		| Secure Boot Policy. This PCR records keys | | 7 |
	| and configuration used to validate the OS | | |		| and configuration used to validate the OS | | |
	| loader | | |		| loader | | |
	--------------------------------------------------------------------		--------------------------------------------------------------------
	| Measurements made by the OS Loader | 8 | 9 |		| Measurements made by the OS Loader | 8 | 9 |
	| (e.g GRUB2 for Linux) | | |		| (e.g. GRUB2 for Linux) | | |
	--------------------------------------------------------------------		--------------------------------------------------------------------
	| Measurements made by OS (e.g., Linux IMA) | 10 | 10 |		| Measurements made by OS (e.g., Linux IMA) | 10 | 10 |
	+------------------------------------------------------------------+		+------------------------------------------------------------------+
	Figure 2: Attested Objects		Figure 2: Attested Objects
	2.1.2. Notes on PCR Allocations		2.1.2. Notes on PCR Allocations
	It is important to recognize that PCR[0] is critical. The first		It is important to recognize that PCR[0] is critical. The first
	measurement into PCR[0] is taken by the Root of Trust for		measurement into PCR[0] is taken by the Root of Trust for
	skipping to change at page 20, line 38 ¶		skipping to change at page 20, line 38 ¶
	* TCG Canonical Event Log [Canonical-Event-Log]		* TCG Canonical Event Log [Canonical-Event-Log]
	3. Standards Components		3. Standards Components
	3.1. Prerequisites for RIV		3.1. Prerequisites for RIV
	The Reference Interaction Model for Challenge-Response-based Remote		The Reference Interaction Model for Challenge-Response-based Remote
	Attestation ([I-D.birkholz-rats-reference-interaction-model]) is		Attestation ([I-D.birkholz-rats-reference-interaction-model]) is
	based on the standard roles defined in [I-D.ietf-rats-architecture].		based on the standard roles defined in [I-D.ietf-rats-architecture].
	However additional prerequisites have been established to allow for		However, additional prerequisites have been established to allow for
	interoperable RIV use case implementations. These prerequisites are		interoperable RIV use case implementations. These prerequisites are
	intended to provide sufficient context information so that the		intended to provide sufficient context information so that the
	Verifier can acquire and evaluate measurements collected by the		Verifier can acquire and evaluate measurements collected by the
	Attester.		Attester.
	3.1.1. Unique Device Identity		3.1.1. Unique Device Identity
	A secure Device Identity (DevID) in the form of an IEEE 802.1AR DevID		A secure Device Identity (DevID) in the form of an IEEE 802.1AR DevID
	certificate [IEEE-802-1AR] must be provisioned in the Attester's		certificate [IEEE-802-1AR] must be provisioned in the Attester's
	TPMs.		TPMs.
	skipping to change at page 24, line 19 ¶		skipping to change at page 24, line 19 ¶
	negotiating a trust relationship, the two peers can each ask the		negotiating a trust relationship, the two peers can each ask the
	other to prove software integrity. In this application, the		other to prove software integrity. In this application, the
	information flow is the same, but each side plays a role both as an		information flow is the same, but each side plays a role both as an
	Attester and a Verifier. Each device issues a challenge, and each		Attester and a Verifier. Each device issues a challenge, and each
	device responds to the other's challenge, as shown in Figure 5.		device responds to the other's challenge, as shown in Figure 5.
	Peer-to-peer challenges, particularly if used to establish a trust		Peer-to-peer challenges, particularly if used to establish a trust
	relationship between routers, require devices to carry their own		relationship between routers, require devices to carry their own
	signed reference measurements (RIMs). Devices may also have to carry		signed reference measurements (RIMs). Devices may also have to carry
	Appraisal Policy for Evidence for each possible peer device so that		Appraisal Policy for Evidence for each possible peer device so that
	each device has everything needed for remote attestation, without		each device has everything needed for remote attestation, without
	having to resort to a central authority. Details of peer-to-peer		having to resort to a central authority.
	operation are out of scope for this document.
	+---------------+ +---------------+		+---------------+ +---------------+
	| RefVal | | RefVal |		| RefVal | | RefVal |
	| Provider A | | Provider B |		| Provider A | | Provider B |
	| Firmware | | Firmware |		| Firmware | | Firmware |
	| Configuration | | Configuration |		| Configuration | | Configuration |
	| Authority | | Authority |		| Authority | | Authority |
	| | | |		| | | |
	+---------------+ +---------------+		+---------------+ +---------------+
	| |		| |
	skipping to change at page 25, line 11 ¶		skipping to change at page 25, line 11 ¶
	+------------+ Step 3 +------------+ /		+------------+ Step 3 +------------+ /
	Figure 5: Peer-to-Peer Attestation Information Flow		Figure 5: Peer-to-Peer Attestation Information Flow
	In this application, each device may need to be equipped with signed		In this application, each device may need to be equipped with signed
	RIMs to act as an Attester, and also an Appraisal Policy for Evidence		RIMs to act as an Attester, and also an Appraisal Policy for Evidence
	and a selection of trusted X.509 root certificates, to allow the		and a selection of trusted X.509 root certificates, to allow the
	device to act as a Verifier. An existing link layer protocol such as		device to act as a Verifier. An existing link layer protocol such as
	802.1X [IEEE-802.1X] or 802.1AE [IEEE-802.1AE], with Evidence being		802.1X [IEEE-802.1X] or 802.1AE [IEEE-802.1AE], with Evidence being
	enclosed over a variant of EAP [RFC3748] or LLDP [LLDP] are suitable		enclosed over a variant of EAP [RFC3748] or LLDP [LLDP] are suitable
	methods for such an exchange.		methods for such an exchange. Details of peer-to-peer operation are
			out of scope for this document.
	4. Privacy Considerations		4. Privacy Considerations
	Network equipment, such as routers, switches and firewalls, has a key		Network equipment, such as routers, switches and firewalls, has a key
	role to play in guarding the privacy of individuals using the		role to play in guarding the privacy of individuals using the
	network. Network equipment generally adheres to several rules to		network. Network equipment generally adheres to several rules to
	protect privacy:		protect privacy:
	* Packets passing through the device must not be sent to		* Packets passing through the device must not be sent to
	unauthorized destinations. For example:		unauthorized destinations. For example:
	skipping to change at page 28, line 30 ¶		skipping to change at page 28, line 30 ¶
	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); any changes to the quote, generated and signed by the TPM
	itself, made by malicious device software, or in the path back to the		itself, made by malicious device software, or in the path back to the
	Verifier, will invalidate the signature on the quote.		Verifier, will invalidate the signature on the quote.
	A critical feature of the YANG model described in		A critical feature of the YANG model described in
	[I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data		[I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data
	structures in their native format, without requiring any changes to		structures in their TCG-defined format, without requiring any changes
	the structures as they were signed and delivered by the TPM. While		to the structures as they were signed and delivered by the TPM.
	alternate methods of conveying TPM quotes could compress out		While alternate methods of conveying TPM quotes could compress out
	redundant information, or add an additional layer of signing using		redundant information, or add another layer of signing using external
	external keys, the implementation MUST preserve the TPM signing, so		keys, the implementation MUST preserve the TPM signing, so that
	that tampering anywhere in the path between the TPM itself and the		tampering anywhere in the path between the TPM itself and the
	Verifier can be detected.		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 page 39, line 17 ¶		skipping to change at page 39, line 17 ¶
	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-
	15, 8 February 2022, <https://www.ietf.org/archive/id/		15, 8 February 2022, <https://www.ietf.org/archive/id/
	draft-ietf-rats-architecture-15.txt>.		draft-ietf-rats-architecture-15.txt>.
	[I-D.ietf-rats-yang-tpm-charra]		[I-D.ietf-rats-yang-tpm-charra]
	Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen,		Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen,
	B., (Frank), L. X., Laffey, T., and G. C. Fedorkow, "A		B., (Frank), L. X., Laffey, T., and G. C. Fedorkow, "A
	YANG Data Model for Challenge-Response-based Remote		YANG Data Model for Challenge-Response-based Remote
	Attestation Procedures using TPMs", Work in Progress,		Attestation Procedures using TPMs", Work in Progress,
	Internet-Draft, draft-ietf-rats-yang-tpm-charra-15, 28		Internet-Draft, draft-ietf-rats-yang-tpm-charra-18, 20
	February 2022, <https://www.ietf.org/archive/id/draft-		March 2022, <https://www.ietf.org/archive/id/draft-ietf-
	ietf-rats-yang-tpm-charra-15.txt>.		rats-yang-tpm-charra-18.txt>.
	[I-D.ietf-sacm-coswid]		[I-D.ietf-sacm-coswid]
	Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.		Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
	Waltermire, "Concise Software Identification Tags", Work		Waltermire, "Concise Software Identification Tags", Work
	in Progress, Internet-Draft, draft-ietf-sacm-coswid-20, 26		in Progress, Internet-Draft, draft-ietf-sacm-coswid-21, 7
	January 2022, <https://www.ietf.org/archive/id/draft-ietf-		March 2022, <https://www.ietf.org/archive/id/draft-ietf-
	sacm-coswid-20.txt>.		sacm-coswid-21.txt>.
	[IEEE-802-1AR]		[IEEE-802-1AR]
	Seaman, M., "802.1AR-2018 - IEEE Standard for Local and		Seaman, M., "802.1AR-2018 - IEEE Standard for Local and
	Metropolitan Area Networks - Secure Device Identity, IEEE		Metropolitan Area Networks - Secure Device Identity, IEEE
	Computer Society", August 2018.		Computer Society", August 2018.
	[IMA] dsafford, kds_etu, mzohar, reinersailer, and serge_hallyn,		[IMA] dsafford, kds_etu, mzohar, reinersailer, and serge_hallyn,
	"Integrity Measurement Architecture", June 2019,		"Integrity Measurement Architecture", June 2019,
	<https://sourceforge.net/p/linux-ima/wiki/Home/>.		<https://sourceforge.net/p/linux-ima/wiki/Home/>.
End of changes. 14 change blocks.
	26 lines changed or deleted		27 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/