draft-ietf-rats-reference-interaction-models-03.txt		draft-ietf-rats-reference-interaction-models-04.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: 14 January 2022 W. Pan		Expires: 27 January 2022 W. Pan
	Huawei Technologies		Huawei Technologies
	E. Voit		E. Voit
	Cisco		Cisco
	13 July 2021		26 July 2021
	Reference Interaction Models for Remote Attestation Procedures		Reference Interaction Models for Remote Attestation Procedures
	draft-ietf-rats-reference-interaction-models-03		draft-ietf-rats-reference-interaction-models-04
	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 14 January 2022.		This Internet-Draft will expire on 27 January 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 7, line 22 ¶		skipping to change at page 7, line 22 ¶
	information elements are required by any kind of scalable remote		information elements are required by any kind of scalable remote
	attestation procedure using one or more of the interaction models		attestation procedure using one or more of the interaction models
	provided.		provided.
	Authentication Secret IDs ('authSecIDs'): _mandatory_		Authentication Secret IDs ('authSecIDs'): _mandatory_
	A statement representing an identifier list that MUST be		A statement representing an identifier list that MUST be
	associated with corresponding Authentication Secrets used to		associated with corresponding Authentication Secrets used to
	protect Claims included in Evidence.		protect Claims included in Evidence.
	Each Authentication Secret is uniquely associated with a		Each distinguishable Attesting Environment has access to a
	distinguishable Attesting Environment. Consequently, an		protected capability that provides an Authentication Secret
	Authentication Secret ID also identifies an Attesting Environment.		associated with that Attesting Environment. Consequently, an
			Authentication Secret ID can also identify an Attesting
			Environment.
	Handle ('handle'): _mandatory_		Handle ('handle'): _mandatory_
	A statement that is intended to uniquely distinguish received		A statement that is intended to uniquely distinguish received
	Evidence and/or determine the freshness of Evidence.		Evidence and/or determine the freshness of Evidence.
	A Verifier can also use a Handle as an indicator for authenticity		A Verifier can also use a Handle as an indicator for authenticity
	or attestation provenance, as only Attesters and Verifiers that		or attestation provenance, as only Attesters and Verifiers that
	are intended to exchange Evidence should have knowledge of the		are intended to exchange Evidence should have knowledge of the
	corresponding Handles. Examples include Nonces or signed		corresponding Handles. Examples include Nonces or signed
	skipping to change at page 13, line 32 ¶		skipping to change at page 13, line 32 ¶
	clocks, such as tick-counters) of Attesters and Verifiers MUST be		clocks, such as tick-counters) of Attesters and Verifiers MUST be
	cryptographically bound to fresh Handles received from the Handle		cryptographically bound to fresh Handles received from the Handle
	Distributor. This binding provides a proof of synchronization that		Distributor. This binding provides a proof of synchronization that
	MUST be included in all produced Evidence. Correspondingly, conveyed		MUST be included in all produced Evidence. Correspondingly, conveyed
	Evidence in this model provides a proof that it was fresh at a		Evidence in this model provides a proof that it was fresh at a
	certain point in time.		certain point in time.
	While periodically pushing Evidence to the Verifier, the Attester		While periodically pushing Evidence to the Verifier, the Attester
	only needs to generate and convey evidence generated from Claim		only needs to generate and convey evidence generated from Claim
	values that have changed and new Event Logs entries since the		values that have changed and new Event Logs entries since the
	previous conveyance. This updates reflecting the differences are		previous conveyance. These updates reflecting the differences are
	called "delta" in the sequence diagram above.		called "delta" in the sequence diagram above.
	Effectively, the Uni-Directional model allows for a series of		Effectively, the Uni-Directional model allows for a series of
	Evidence to be pushed to multiple Verifiers simultaneously. Methods		Evidence to be pushed to multiple Verifiers simultaneously. Methods
	to detect excessive time drift that would mandate a fresh Handle to		to detect excessive time drift that would mandate a fresh Handle to
	be received by the Handle Distributor as well as timing of Handle		be received by the Handle Distributor as well as timing of Handle
	distribution are out-of-scope of this document.		distribution are out-of-scope of this document.
	7.3. Streaming Remote Attestation		7.3. Streaming Remote Attestation
	.----------. .----------.		.----------. .----------.
	skipping to change at page 18, line 44 ¶		skipping to change at page 18, line 44 ¶
	[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data		[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
	Definition Language (CDDL): A Notational Convention to		Definition Language (CDDL): A Notational Convention to
	Express Concise Binary Object Representation (CBOR) and		Express Concise Binary Object Representation (CBOR) and
	JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,		JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
	June 2019, <https://www.rfc-editor.org/info/rfc8610>.		June 2019, <https://www.rfc-editor.org/info/rfc8610>.
	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 11rd 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-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]
End of changes. 7 change blocks.
	9 lines changed or deleted		11 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/