draft-ietf-rats-reference-interaction-models-04.txt		draft-ietf-rats-reference-interaction-models-05.txt
	RATS Working Group H. Birkholz		RATS Working Group H. Birkholz
	Internet-Draft M. Eckel		Internet-Draft M. Eckel
	Intended status: Informational Fraunhofer SIT		Intended status: Informational Fraunhofer SIT
	Expires: 27 January 2022 W. Pan		Expires: 30 July 2022 W. Pan
	Huawei Technologies		Huawei Technologies
	E. Voit		E. Voit
	Cisco		Cisco
	26 July 2021		26 January 2022
	Reference Interaction Models for Remote Attestation Procedures		Reference Interaction Models for Remote Attestation Procedures
	draft-ietf-rats-reference-interaction-models-04		draft-ietf-rats-reference-interaction-models-05
	Abstract		Abstract
	This document describes interaction models for remote attestation		This document describes interaction models for remote attestation
	procedures (RATS). Three conveying mechanisms -- Challenge/Response,		procedures (RATS). Three conveying mechanisms -- Challenge/Response,
	Uni-Directional, and Streaming Remote Attestation -- are illustrated		Uni-Directional, and Streaming Remote Attestation -- are illustrated
	and defined. Analogously, a general overview about the information		and defined. Analogously, a general overview about the information
	elements typically used by corresponding conveyance protocols are		elements typically used by corresponding conveyance protocols are
	highlighted.		highlighted.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 27 January 2022.		This Internet-Draft will expire on 30 July 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 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
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Revised BSD License text as
	as described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Disambiguation . . . . . . . . . . . . . . . . . . . . . 4		2.1. Disambiguation . . . . . . . . . . . . . . . . . . . . . 4
	3. Scope and Intent . . . . . . . . . . . . . . . . . . . . . . 4		3. Scope and Intent . . . . . . . . . . . . . . . . . . . . . . 4
	4. Essential Requirements . . . . . . . . . . . . . . . . . . . 5		4. Essential Requirements . . . . . . . . . . . . . . . . . . . 5
	4.1. Endorsement of Attesting Environments . . . . . . . . . . 5		4.1. Endorsement of Attesting Environments . . . . . . . . . . 5
	5. Normative Prerequisites . . . . . . . . . . . . . . . . . . . 6		5. Normative Prerequisites . . . . . . . . . . . . . . . . . . . 6
	6. Generic Information Elements . . . . . . . . . . . . . . . . 7		6. Generic Information Elements . . . . . . . . . . . . . . . . 7
	7. Interaction Models . . . . . . . . . . . . . . . . . . . . . 9		7. Interaction Models . . . . . . . . . . . . . . . . . . . . . 9
	7.1. Challenge/Response Remote Attestation . . . . . . . . . . 9		7.1. Challenge/Response Remote Attestation . . . . . . . . . . 9
	7.2. Uni-Directional Remote Attestation . . . . . . . . . . . 11		7.1.1. Models and example sequences of Challenge/Response
	7.3. Streaming Remote Attestation . . . . . . . . . . . . . . 13		Remote Attestation . . . . . . . . . . . . . . . . . 11
	8. Additional Application-Specific Requirements . . . . . . . . 15		7.2. Uni-Directional Remote Attestation . . . . . . . . . . . 13
	8.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 15		7.3. Streaming Remote Attestation . . . . . . . . . . . . . . 15
	8.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 15		8. Additional Application-Specific Requirements . . . . . . . . 17
	8.3. Hardware-Enforcement/Support . . . . . . . . . . . . . . 15		8.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 17
	9. Implementation Status . . . . . . . . . . . . . . . . . . . . 15		8.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 17
	9.1. Implementer . . . . . . . . . . . . . . . . . . . . . . . 16		8.3. Hardware-Enforcement/Support . . . . . . . . . . . . . . 17
	9.2. Implementation Name . . . . . . . . . . . . . . . . . . . 16		9. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
	9.3. Implementation URL . . . . . . . . . . . . . . . . . . . 16		9.1. Implementer . . . . . . . . . . . . . . . . . . . . . . . 18
	9.4. Maturity . . . . . . . . . . . . . . . . . . . . . . . . 16		9.2. Implementation Name . . . . . . . . . . . . . . . . . . . 18
	9.5. Coverage and Version Compatibility . . . . . . . . . . . 16		9.3. Implementation URL . . . . . . . . . . . . . . . . . . . 18
	9.6. License . . . . . . . . . . . . . . . . . . . . . . . . . 17		9.4. Maturity . . . . . . . . . . . . . . . . . . . . . . . . 18
	9.7. Implementation Dependencies . . . . . . . . . . . . . . . 17		9.5. Coverage and Version Compatibility . . . . . . . . . . . 18
	9.8. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 17		9.6. License . . . . . . . . . . . . . . . . . . . . . . . . . 19
	10. Security and Privacy Considerations . . . . . . . . . . . . . 17		9.7. Implementation Dependencies . . . . . . . . . . . . . . . 19
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		9.8. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 19
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. Security and Privacy Considerations . . . . . . . . . . . . . 19
	12.1. Normative References . . . . . . . . . . . . . . . . . . 17		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
	12.2. Informative References . . . . . . . . . . . . . . . . . 18		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
			12.1. Normative References . . . . . . . . . . . . . . . . . . 19
			12.2. Informative References . . . . . . . . . . . . . . . . . 20
	Appendix A. CDDL Specification for a simple CoAP Challenge/		Appendix A. CDDL Specification for a simple CoAP Challenge/
	Response Interaction . . . . . . . . . . . . . . . . . . 19		Response Interaction . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	Remote ATtestation procedureS (RATS, [I-D.ietf-rats-architecture])		Remote ATtestation procedureS (RATS, [I-D.ietf-rats-architecture])
	are workflows composed of roles and interactions, in which Verifiers		are workflows composed of roles and interactions, in which Verifiers
	create Attestation Results about the trustworthiness of an Attester's		create Attestation Results about the trustworthiness of an Attester's
	system component characteristics. The Verifier's assessment in the		system component characteristics. The Verifier's assessment in the
	form of Attestation Results is created based on Attestation Policies		form of Attestation Results is created based on Attestation Policies
	and Evidence -- trustable and tamper-evident Claims Sets about an		and Evidence -- trustable and tamper-evident Claims Sets about an
	Attester's system component characteristics -- generated by an		Attester's system component characteristics -- generated by an
	skipping to change at page 11, line 42 ¶		skipping to change at page 11, line 42 ¶
	appraises the Evidence. For this purpose, it validates the		appraises the Evidence. For this purpose, it validates the
	signature, the Attester Identity, and the Handle, and then appraises		signature, the Attester Identity, and the Handle, and then appraises
	the Claims. Appraisal procedures are application-specific and can be		the Claims. Appraisal procedures are application-specific and can be
	conducted via comparison of the Claims with corresponding Reference		conducted via comparison of the Claims with corresponding Reference
	Values, such as Reference Integrity Measurements. The final output		Values, such as Reference Integrity Measurements. The final output
	of the Verifier are Attestation Results. Attestation Results		of the Verifier are Attestation Results. Attestation Results
	constitute new Claim Sets about the properties and characteristics of		constitute new Claim Sets about the properties and characteristics of
	an Attester, which enables Relying Parties, for example, to assess an		an Attester, which enables Relying Parties, for example, to assess an
	Attester's trustworthiness.		Attester's trustworthiness.
			7.1.1. Models and example sequences of Challenge/Response Remote
			Attestation
			According to the RATS Architecture, two reference models for
			Challenge/Response Attestation have been proposed. This section
			highlights the information flows bewteen the Attester, Verifier and
			Relying Party undergoing Remote Attestation Procedure, using these
			models.
			1. Passport Model
			The passport model is so named because of its resemblance to how
			nations issue passports to their citizens. In this model, the
			attestation sequence is a two step procedure. In the first step, an
			Attester conveys Evidence to a Verifier which compares the Evidence
			against its appraisal policy. The Verifier then gives back an
			Attestation Result to the Attester, which simply caches it. In the
			second step, the Attester presents the Attestation Result (and
			possibly additional Claims/evidence) to a Relying Party, which then
			compares this information against its own appraisal policy to
			establish the trustworthiness of the Attester.
			.----------. .----------. .----------.
			| Attester | | Verifier | | R. P. |
			'----------' '----------' '----------'
			| | |
			generateClaims(attestingEnvironment) | |
			| => claims, eventLogs | |
			| | |
			| <-- requestAttestation(handle, authSecIDs, claimSelection) | |
			| | |
			collectClaims(claims, claimSelection) | |
			| => collectedClaims | |
			| | |
			generateEvidence(handle, authSecIDs, collectedClaims) | |
			| => evidence | |
			| | |
			| evidence, eventLogs -------------------------------------> | |
			| | |
			| appraiseEvidence(evidence, eventLogs, refValues) |
			| | |
			| attestationResults <----------------------------------- | |
			| | |
			| attestationResults(evidence, results) ----------------------------------------------------------> | | | |
			| | | | | | appraiseResult()
			| | |
			1. BackGround Check Model
			The background-check model is so named because of the resemblance of
			how employers and volunteer organizations perform background checks.
			In this model, the attestation sequence is initiated by a Relying
			Party. The Attester conveys Evidence to the Relying Party, which
			does not process its payload, but realys the message and optionally
			check its signature against a policed trust anchor store. Upon
			receiving the evidence the Relying Party initiates a session with the
			Verifier. Once session is established, it forwards the received
			Evidence to the Verfier. The Verifier, appraises the received
			Evidence according to its appraisal policy for Evidence and returns a
			corresponding Attestation Result to the Relying Party. The Relying
			Party then checks the Attestation Result against its own appraisal
			policy to conclude attestation.
			.----------. .----------. .----------.
			| Attester | | R. P. | | Verifier |
			'----------' '----------' '----------'
			| | |
			generateClaims(attestingEnvironment) | |
			| => claims, eventLogs | |
			| | |
			| <-- requestAttestation(handle, authSecIDs, claimSelection) | |
			| | |
			collectClaims(claims, claimSelection) | |
			| => collectedClaims | |
			| | |
			generateEvidence(handle, authSecIDs, collectedClaims) | |
			| => evidence | |
			| | |
			| evidence, eventLogs -------------------------------------> | |
			| | |
			| | handle, evidence, eventLogs -------> |
			| | |appraiseEvidenc()
			| | |
			| | attestationResults <--------------- |
			| | (evidence, results) |
			| | |
			| appraiseResults(evidence, results) | |
			| | |
	7.2. Uni-Directional Remote Attestation		7.2. Uni-Directional Remote Attestation
	.----------. .--------------------. .----------.		.----------. .--------------------. .----------.
	| Attester | | Handle Distributor | | Verifier |		| Attester | | Handle Distributor | | Verifier |
	'----------' '--------------------' '----------'		'----------' '--------------------' '----------'
	| | |		| | |
	| generateHandle() |		| generateHandle() |
	| | => handle |		| | => handle |
	| | |		| | |
	| <----------------------------- handle | handle ----------> |		| <----------------------------- handle | handle ----------> |
	| | |		| | |
	skipping to change at page 18, line 50 ¶		skipping to change at page 20, line 50 ¶
	12.2. Informative References		12.2. Informative References
	[DAA] Brickell, E., Camenisch, J., and L. Chen, "Direct		[DAA] Brickell, E., Camenisch, J., and L. Chen, "Direct
	Anonymous Attestation", page 132-145, ACM Proceedings of		Anonymous Attestation", page 132-145, ACM Proceedings of
	the 11th ACM conference on Computer and Communications		the 11th ACM conference on Computer and Communications
	Security, 2004.		Security, 2004.
	[I-D.birkholz-rats-tuda]		[I-D.birkholz-rats-tuda]
	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-06, 12
	July 2021, <https://www.ietf.org/archive/id/draft-		January 2022, <https://www.ietf.org/archive/id/draft-
	birkholz-rats-tuda-05.txt>.		birkholz-rats-tuda-06.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-
	12, 23 April 2021, <https://www.ietf.org/archive/id/draft-		14, 9 December 2021, <https://www.ietf.org/archive/id/
	ietf-rats-architecture-12.txt>.		draft-ietf-rats-architecture-14.txt>.
	[I-D.ietf-rats-tpm-based-network-device-attest]		[I-D.ietf-rats-tpm-based-network-device-attest]
	Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM-		Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM-
	based Network Device Remote Integrity Verification", Work		based Network Device Remote Integrity Verification", Work
	in Progress, Internet-Draft, draft-ietf-rats-tpm-based-		in Progress, Internet-Draft, draft-ietf-rats-tpm-based-
	network-device-attest-07, 10 June 2021,		network-device-attest-10, 30 December 2021,
	<https://www.ietf.org/archive/id/draft-ietf-rats-tpm-		<https://www.ietf.org/archive/id/draft-ietf-rats-tpm-
	based-network-device-attest-07.txt>.		based-network-device-attest-10.txt>.
	[turtles] Rudnicki, R., "Turtles All the Way Down: Foundation,		[turtles] Rudnicki, R., "Turtles All the Way Down: Foundation,
	Edifice, and Ruin in Faulkner and McCarthy",		Edifice, and Ruin in Faulkner and McCarthy",
	DOI 10.1353/fau.2010.0002, The Faulkner Journal 25.2,		DOI 10.1353/fau.2010.0002, The Faulkner Journal 25.2,
	2010, <https://doi.org/10.1353/fau.2010.0002>.		2010, <https://doi.org/10.1353/fau.2010.0002>.
	Appendix A. CDDL Specification for a simple CoAP Challenge/Response		Appendix A. CDDL Specification for a simple CoAP Challenge/Response
	Interaction		Interaction
	The following CDDL specification is an exemplary proof-of-concept to		The following CDDL specification is an exemplary proof-of-concept to
End of changes. 13 change blocks.
	37 lines changed or deleted		127 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/