draft-ietf-rats-reference-interaction-models-01.txt		draft-ietf-rats-reference-interaction-models-02.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: April 26, 2021 C. Newton		Expires: 28 October 2021 W. Pan
	L. Chen		Huawei Technologies
	University of Surrey		E. Voit
	October 23, 2020		Cisco
			26 April 2021
	Reference Interaction Models for Remote Attestation Procedures		Reference Interaction Models for Remote Attestation Procedures
	draft-ietf-rats-reference-interaction-models-01		draft-ietf-rats-reference-interaction-models-02
	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. Privacy preserving conveyance of Evidence via Direct		highlighted.
	Anonymous Attestation is elaborated on in the context of the
	Attester, Endorser, and Verifier role.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 April 26, 2021.		This Internet-Draft will expire on 28 October 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Disambiguation . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Disambiguation . . . . . . . . . . . . . . . . . . . . . 4
	4. Scope and Intent . . . . . . . . . . . . . . . . . . . . . . 4		3. Scope and Intent . . . . . . . . . . . . . . . . . . . . . . 4
	5. Direct Anonymous Attestation . . . . . . . . . . . . . . . . 5		4. Essential Requirements . . . . . . . . . . . . . . . . . . . 5
	5.1. Endorsers . . . . . . . . . . . . . . . . . . . . . . . . 5		4.1. Endorsement of Attesting Environments . . . . . . . . . . 5
	5.2. Endorsers for Direct Anonymous Attestation . . . . . . . 6		5. Normative Prerequisites . . . . . . . . . . . . . . . . . . . 6
	6. Normative Prerequisites . . . . . . . . . . . . . . . . . . . 6		6. Generic Information Elements . . . . . . . . . . . . . . . . 7
	7. Generic Information Elements . . . . . . . . . . . . . . . . 7		7. Interaction Models . . . . . . . . . . . . . . . . . . . . . 9
	8. Interaction Models . . . . . . . . . . . . . . . . . . . . . 9		7.1. Challenge/Response Remote Attestation . . . . . . . . . . 9
	8.1. Challenge/Response Remote Attestation . . . . . . . . . . 10		7.2. Uni-Directional Remote Attestation . . . . . . . . . . . 11
	8.2. Uni-Directional Remote Attestation . . . . . . . . . . . 12		7.3. Streaming Remote Attestation . . . . . . . . . . . . . . 13
	8.3. Streaming Remote Attestation . . . . . . . . . . . . . . 13		8. Additional Application-Specific Requirements . . . . . . . . 15
	9. Additional Application-Specific Requirements . . . . . . . . 15		8.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 15
	9.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 15		8.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 15
	9.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 15		8.3. Hardware-Enforcement/Support . . . . . . . . . . . . . . 15
	9.3. Hardware-Enforcement/Support . . . . . . . . . . . . . . 15		9. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
	10. Implementation Status . . . . . . . . . . . . . . . . . . . . 15		9.1. Implementer . . . . . . . . . . . . . . . . . . . . . . . 16
	10.1. Implementer . . . . . . . . . . . . . . . . . . . . . . 16		9.2. Implementation Name . . . . . . . . . . . . . . . . . . . 16
	10.2. Implementation Name . . . . . . . . . . . . . . . . . . 16		9.3. Implementation URL . . . . . . . . . . . . . . . . . . . 16
	10.3. Implementation URL . . . . . . . . . . . . . . . . . . . 16		9.4. Maturity . . . . . . . . . . . . . . . . . . . . . . . . 16
	10.4. Maturity . . . . . . . . . . . . . . . . . . . . . . . . 16		9.5. Coverage and Version Compatibility . . . . . . . . . . . 16
	10.5. Coverage and Version Compatibility . . . . . . . . . . . 16		9.6. License . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.6. License . . . . . . . . . . . . . . . . . . . . . . . . 16		9.7. Implementation Dependencies . . . . . . . . . . . . . . . 17
	10.7. Implementation Dependencies . . . . . . . . . . . . . . 16		9.8. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.8. Contact . . . . . . . . . . . . . . . . . . . . . . . . 17		10. Security and Privacy Considerations . . . . . . . . . . . . . 17
	11. Security and Privacy Considerations . . . . . . . . . . . . . 17		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17		12.1. Normative References . . . . . . . . . . . . . . . . . . 17
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		12.2. Informative References . . . . . . . . . . . . . . . . . 18
	14.1. Normative References . . . . . . . . . . . . . . . . . . 19		Appendix A. CDDL Specification for a simple CoAP Challenge/
	14.2. Informative References . . . . . . . . . . . . . . . . . 20		Response Interaction . . . . . . . . . . . . . . . . . . 19
	Appendix A. CDDL Specification for a simple CoAP		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	Challenge/Response Interaction . . . . . . . . . . . 21
	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
	Attester. The roles _Attester_ and _Verifier_, as well as the		Attester. The roles _Attester_ and _Verifier_, as well as the
	Conceptual Messages _Evidence_ and _Attestation Results_ are concepts		Conceptual Messages _Evidence_ and _Attestation Results_ are concepts
	defined by the RATS Architecture [I-D.ietf-rats-architecture]. This		defined by the RATS Architecture [I-D.ietf-rats-architecture]. This
	document defines interaction models that can be used in specific		document defines interaction models that can be used in specific
	RATS-related solution documents. The primary focus of this document		RATS-related solution documents. The primary focus of this document
	is the conveyance of attestation Evidence. The reference models		is the conveyance of attestation Evidence. The reference models
	defined can also be applied to the conveyance of other Conceptual		defined can also be applied to the conveyance of other Conceptual
	Messages in RATS. Specific goals of this document are to:		Messages in RATS. Specific goals of this document are to:
	o prevent inconsistencies in descriptions of interaction models in		1.) prevent inconsistencies in descriptions of interaction models in
	other documents (due to text cloning and evolution over time),		other documents (due to text cloning and evolution over time), and to
			2.) enable to highlight an exact delta/divergence between the core
	o enable to highlight an exact delta/divergence between the core set		set of characteristics captured here in this document and variants of
	of characteristics captured here in this document and variants of		these interaction models used in other specifications or solutions.
	these interaction models used in other specifications or
	solutions, and to
	o illustrate the application of Direct Anonymous Attestation (DAA)
	for the defined set of reference models.
	In summary, this document enables the specification and design of		In summary, this document enables the specification and design of
	trustworthy and privacy preserving conveyance methods for attestation		trustworthy and privacy preserving conveyance methods for attestation
	Evidence from an Attester to a Verifier. While the conveyance of		Evidence from an Attester to a Verifier. While the conveyance of
	other Conceptual Messages is out-of-scope the methods described can		other Conceptual Messages is out-of-scope the methods described can
	also be applied to the conveyance of, for example, Endorsements or		also be applied to the conveyance of, for example, Endorsements or
	Attestation Results.		Attestation Results.
	2. Terminology		2. Terminology
	This document uses the following set of terms, roles, and concepts as		This document uses the following set of terms, roles, and concepts as
	defined in [I-D.ietf-rats-architecture]:		defined in [I-D.ietf-rats-architecture]: Attester, Verifier, Relying
			Party, Conceptual Message, Evidence, Endorsement, Attestation Result,
	Attester, Verifier, Relying Party, Conceptual Message, Evidence,		Appraisal Policy, Attesting Environment, Target Environment
	Endorsement, Attestation Result, Appraisal Policy, Attesting
	Environment, Target Environment
	A PKIX Certificate is an X.509v3 format certificate as specified by		A PKIX Certificate is an X.509v3 format certificate as specified by
	[RFC5280].		[RFC5280].
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Disambiguation		2.1. Disambiguation
	The term "Remote Attestation" is a common expression and often		The term "Remote Attestation" is a common expression and often
	associated or connoted with certain properties. The term "Remote" in		associated or connoted with certain properties. The term "Remote" in
	this context does not necessarily refer to a remote entity in the		this context does not necessarily refer to a remote entity in the
	scope of network topologies or the Internet. It rather refers to a		scope of network topologies or the Internet. It rather refers to
	decoupled system or entities that exchange the payload of the		decoupled systems or entities that exchange the payload of the
	Conceptual Message type called Evidence [I-D.ietf-rats-architecture].		Conceptual Message type called Evidence [I-D.ietf-rats-architecture].
	This conveyance can also be "Local", if the Verifier role is part of		This conveyance can also be "Local", if the Verifier role is part of
	the same entity as the Attester role, e.g., separate system		the same entity as the Attester role, e.g., separate system
	components of the same Composite Device (a single RATS entity).		components of the same Composite Device (a single RATS entity). Even
	Examples of these types of co-located environments include: a Trusted		if an entity takes on two or more different roles, the functions they
	Execution Environment (TEE), Baseboard Management Controllers (BMCs),		provide typically reside in isolated environments that are components
	as well as other physical or logical protected/isolated/shielded		of the same entity. Examples of such isolated environments include:
	Computing Environments (e.g. embedded Secure Elements (eSE) or		a Trusted Execution Environment (TEE), Baseboard Management
	Trusted Platform Modules (TPM)). Readers of this document should be		Controllers (BMCs), as well as other physical or logical
	familiar with the concept of Layered Attestation as described in		protected/isolated/shielded Computing Environments (e.g. embedded
	Section 4.3 Two Types of Environments of an Attester in		Secure Elements (eSE) or Trusted Platform Modules (TPM)). Readers of
	[I-D.ietf-rats-architecture] and the definition of Attestation as		this document should be familiar with the concept of Layered
	described in [I-D.ietf-rats-tpm-based-network-device-attest].		Attestation as described in Section 3.1 Two Types of Environments of
			an Attester in [I-D.ietf-rats-architecture] and the definition of
			Attestation as described in
			[I-D.ietf-rats-tpm-based-network-device-attest].
	4. Scope and Intent		3. Scope and Intent
	This document focuses on generic interaction models between Attesters		This document focuses on generic interaction models between Attesters
	and Verifiers in order to convey Evidence. Complementary procedures,		and Verifiers in order to convey Evidence. Complementary procedures,
	functions, or services that are required for a complete semantic		functions, or services that are required for a complete semantic
	binding of the concepts defined in [I-D.ietf-rats-architecture] are		binding of the concepts defined in [I-D.ietf-rats-architecture] are
	out-of-scope of this document. Examples include: identity		out-of-scope of this document. Examples include: identity
	establishment, key distribution and enrollment, time synchronization,		establishment, key distribution and enrollment, time synchronization,
	as well as certificate revocation.		as well as certificate revocation.
	Furthermore, any processes and duties that go beyond carrying out		Furthermore, any processes and duties that go beyond carrying out
	remote attestation procedures are out-of-scope. For instance, using		remote attestation procedures are out-of-scope.
	the results of a remote attestation that are created by the Verifier,
	e.g., how to triggering remediation actions or recovery processes, as		For instance, using the results of a remote attestation procedure
	well as such remediation actions and recovery processes themselves,		that are created by the Verifier, e.g., how to triggering remediation
	are also out-of-scope.		actions or recovery processes, as well as such remediation actions
			and recovery processes themselves, are also out-of-scope.
	The interaction models illustrated in this document are intended to		The interaction models illustrated in this document are intended to
	provide a stable basis and reference for other solutions documents		provide a stable basis and reference for other solutions documents
	inside or outside the IETF. Solution documents of any kind can		inside or outside the IETF. Solution documents of any kind can
	reference the interaction models in order to avoid text clones and to		reference the interaction models in order to avoid text clones and to
	avoid the danger of subtle discrepancies. Analogously, deviations		avoid the danger of subtle discrepancies. Analogously, deviations
	from the generic model descriptions in this document can be		from the generic model descriptions in this document can be
	illustrated in solutions documents to highlight distinct		illustrated in solutions documents to highlight distinct
	contributions.		contributions.
	5. Direct Anonymous Attestation		4. Essential Requirements
	DAA [DAA] is a signature scheme used in RATS that allows preservation		In order to ensure appropriate conveyance of Evidence, there exist
	of the privacy of users that are associated with an Attester (e.g.		essential requirements which MUST be fulfilled:
	its owner). Essentially, DAA can be seen as a group signature scheme
	with the feature that given a DAA signature no-one can find out who
	the signer is, i.e., the anonymity is not revocable. To be able to
	sign anonymously an Attester has to obtain a credential from a DAA
	Issuer. The DAA Issuer uses a private/public key pair to generate a
	credential for an Attester and makes the public key (in the form of a
	public key certificate) available to the verifier in order to enable
	them to validate the DAA signature obtained as part of the Evidence.
	In order to support these DAA signatures, the DAA Issuer MUST		Integrity: Information provided by an Attester MUST be integral.
	associate a single key pair with each group of Attesters and use the		This may be achieved by means of a digital signature over
	same key pair when creating the credentials for all of the Attesters		Attestation Evidence. The signature may be symmetric, such as an
	in this group. The DAA Issuer's public key certificate used by a		HMAC, or asymmetric, such as ECDSA.
	group of Attesters replaces the individual Attester Identity
	documents during authenticity validation as a part of the appraisal
	of Evidence conducted by a Verifier. This is in contrast to
	intuition that there has to be a unique Attester Identity per device.
	This document extends the duties of the Endorser role as defined by		Authentication: The information provided by the Attester MUST be
	the RATS architecture with respect to the provision of these Attester		authentic. For that purpose, the Attester should authenticate
	Identity documents to Attesters. The existing duties of the Endorser		itself to the Verifier. This may be an implicit authentication by
	role and the duties of a DAA Issuer are quite similar as illustrated		means of a digital signature over the Attestation Evidence, which
	in the following subsections.		does not require additional protocol steps, or may be achieved by
			using a confidential channel by means of encryption.
	5.1. Endorsers		4.1. Endorsement of Attesting Environments
	Via its Attesting Environments, an Attester only generates Evidence		Via its Attesting Environments, an Attester only generates Evidence
	about its Target Environments. After being appraised to be		about its Target Environments. After being appraised to be
	trustworthy, a Target Environment may become a new Attesting		trustworthy, a Target Environment may become a new Attesting
	Environment in charge of generating Evidence for further Target		Environment in charge of generating Evidence for further Target
	Environments. [I-D.ietf-rats-architecture] explains this as Layered		Environments. [I-D.ietf-rats-architecture] explains this as Layered
	Attestation. Layered Attestation has to start with an initial		Attestation. Layered Attestation has to start with an initial
	Attesting Environment. In essence, there cannot be turtles all the		Attesting Environment. In essence, there cannot be turtles all the
	way down [turtles]. At this rock bottom of Layered Attestation, the		way down [turtles]. At this rock bottom of Layered Attestation, the
	Attesting Environments are always called Roots of Trust (RoT). An		Attesting Environments are always called Roots of Trust (RoT). An
	Attester cannot generate Evidence about its own RoTs by design. As a		Attester cannot generate Evidence about its own RoTs by design. As a
	consequence, a Verifier requires trustable statements about this		consequence, a Verifier requires trustable statements about this
	subset of Attesting Environments from a different source than the		subset of Attesting Environments from a different source than the
	Attester itself. The corresponding trustable statements are called		Attester itself. The corresponding trustable statements are called
	Endorsements and originate from external, trustable entities that		Endorsements and originate from external, trustable entities that
	take on the role of an Endorser (e.g., supply chain entities).		take on the role of an Endorser (e.g., supply chain entities).
	5.2. Endorsers for Direct Anonymous Attestation		5. Normative Prerequisites
	In order to enable the use of DAA, an Endorser role takes on the
	duties of a DAA Issuer in addition to its already defined duties.
	DAA Issuers offer zero-knowledge proofs based on public key
	certificates used for a group of Attesters [DAA]. Effectively, these
	certificates share the semantics of Endorsements, with the following
	exceptions:
	o The associated private keys are used by the DAA Issuer to provide
	an Attester with a credential that it can use to convince the
	Verifier that its Evidence is valid. To keep their anonymity the
	Attester randomizes this credential each time that it is used.
	o The Verifier can use the DAA Issuer's public key certificate,
	together with the randomized credential from the Attester, to
	confirm that the Evidence comes from a valid Attester.
	o A credential is conveyed from an Endorser to an Attester in
	combination with the conveyance of the public key certificates
	from Endorser to Verifier.
	The zero-knowledge proofs required cannot be created by an Attester
	alone - like the Endorsements of RoTs - and have to be created by a
	trustable third entity - like an Endorser. Due to that semantic
	overlap, the Endorser role is augmented via the definition of DAA
	duties as defined below. This augmentation enables the Endorser to
	convey trustable third party statements both to Verifier roles and
	Attester roles.
	6. Normative Prerequisites
	In order to ensure an appropriate conveyance of Evidence via		In order to ensure an appropriate conveyance of Evidence via
	interaction models in general, the following set of prerequisites		interaction models in general, the following set of prerequisites
	MUST be in place to support the implementation of interaction models:		MUST be in place to support the implementation of interaction models:
	Attester Identity: The provenance of Evidence with respect to a		Attester Identity: A statement about a distinguishable Attester made
	distinguishable Attesting Environment MUST be correct and		by an Endorser without accompanying evidence about its validity,
	unambiguous.		used as proof of identity.
	An Attester Identity MAY be a unique identity, it MAY be included		The provenance of Evidence with respect to a distinguishable
	in a zero-knowledge proof (ZKP), or it MAY be part of a group		Attesting Environment MUST be correct and unambiguous.
	signature, or it MAY be a randomised DAA credential.
			An Attester Identity MAY be a unique identity, MAY be included in
			a zero-knowledge proof (ZKP), MAY be part of a group signature, or
			it MAY be a randomized DAA credential [DAA].
	Attestation Evidence Authenticity: Attestation Evidence MUST be		Attestation Evidence Authenticity: Attestation Evidence MUST be
	correct and authentic.		authentic.
	In order to provide proofs of authenticity, Attestation Evidence		In order to provide proofs of authenticity, Attestation Evidence
	SHOULD be cryptographically associated with an identity document		SHOULD be cryptographically associated with an identity document
	(e.g. an PKIX certificate or trusted key material, or a randomised		(e.g. an PKIX certificate or trusted key material, or a randomized
	DAA credential), or SHOULD include a correct and unambiguous and		DAA credential [DAA]), or SHOULD include a correct and unambiguous
	stable reference to an accessible identity document.		and stable reference to an accessible identity document.
	Authentication Secret: An Authentication Secret MUST be available		Authentication Secret: An Authentication Secret MUST be available
	exclusively to an Attester's Attesting Environment.		exclusively to an Attester's Attesting Environment.
	The Attester MUST protect Claims with that Authentication Secret,		The Attester MUST protect Claims with that Authentication Secret,
	thereby proving the authenticity of the Claims included in		thereby proving the authenticity of the Claims included in
	Evidence. The Authentication Secret MUST be established before		Evidence. The Authentication Secret MUST be established before
	RATS can take place.		RATS can take place.
	Evidence Freshness: Evidence MUST include an indicator about its		Evidence Freshness: Evidence MUST include an indicator about its
	freshness that can be understood by a Verifier. Analogously,		freshness that can be understood by a Verifier. Analogously,
	interaction models MUST support the conveyance of proofs of		interaction models MUST support the conveyance of proofs of
	freshness in a way that is useful to Verifiers and their appraisal		freshness in a way that is useful to Verifiers and their appraisal
	procedures.		procedures.
	Evidence Protection: Evidence MUST be a set of well-formatted and		Evidence Protection: Evidence MUST be a set of well-formatted and
	well-protected Claims that an Attester can create and convey to a		well-protected Claims that an Attester can create and convey to a
	Verifier in a tamper-evident manner.		Verifier in a tamper-evident manner.
	7. Generic Information Elements		6. Generic Information Elements
	This section defines the information elements that are vital to all		This section defines the information elements that are vital to all
	kinds interaction models. Varying from solution to solution, generic		kinds interaction models. Varying from solution to solution, generic
	information elements can be either included in the scope of protocol		information elements can be either included in the scope of protocol
	messages (instantiating Conceptual Messages) or can be included in		messages (instantiating Conceptual Messages) or can be included in
	additional protocol parameters or payload. Ultimately, the following		additional protocol parameters or payload. Ultimately, the following
	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.
	Attester Identity ('attesterIdentity'): _mandatory_		Attester Identity ('attesterIdentity'): _mandatory_
	A statement about a distinguishable Attester made by an Endorser		A statement about a distinguishable Attester made by an Endorser
	without accompanying evidence about its validity - used as proof		without accompanying evidence about its validity - used as proof
	of identity.		of identity.
	In DAA, the Attester's identity is not revealed to the verifier.		Authentication Secret IDs ('authSecIDs'): _mandatory_
	The Attester is issued with a credential by the Endorser that is
	randomised and then used to anonymously confirm the validity of
	their evidence. The evidence is verified using the Endorser's
	public key.
	Authentication Secret IDs ('authSecID'): _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 Evidence.		protect Claims included in Evidence.
	In DAA, Authentication Secret IDs are represented by the Endorser
	(DAA issuer)'s public key that MUST be used to create DAA
	credentials for the corresponding Authentication Secrets used to
	protect Evidence.
	Each Authentication Secret is uniquely associated with a		Each Authentication Secret is uniquely associated with a
	distinguishable Attesting Environment. Consequently, an		distinguishable Attesting Environment. Consequently, an
	Authentication Secret ID also identifies an Attesting Environment.		Authentication Secret ID also identifies an Attesting Environment.
	In DAA, an Authentication Secret ID does not identify a unique
	Attesting Environment but associated with a group of Attesting
	Environments. This is because an Attesting Environment should not
	be distinguishable and the DAA credential which represents the
	Attesting Environment is randomised each time it used.
	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
	timestamps.		timestamps.
	Claims ('claims'): _mandatory_		Claims ('claims'): _mandatory_
	Claims are assertions that represent characteristics of an		Claims are assertions that represent characteristics of an
	Attester's Target Environment.		Attester's Target Environment.
	Claims are part Conceptual Message and are, for example, used to		Claims are part of a Conceptual Message and are, for example, used
	appraise the integrity of Attesters via a Verifiers. The other		to appraise the integrity of Attesters via Verifiers. The other
	information elements in this section can be expressed as Claims in		information elements in this section can be expressed as Claims in
	any type of Conceptional Messages.		any type of Conceptional Messages.
	Reference Claims ('refClaims') _mandatory_		Event Logs ('eventLogs'): _optional_
	Reference Claims are components of Reference Values as defined in
	[I-D.ietf-rats-architecture]. [Editor's Note: Definition might
	become obsolete, if replaced by Reference Values. Is there a
	difference between Claims and Values here? Analogously, why is
	not named Reference Claims in the RATS arch?]
	Reference Claims are used to appraise the Claims received from an		Event Logs accompany Claims by providing event trails of security-
	Attester via appraisal by direct comparison. For example,		critical events in a system. The primary purpose of Event Logs is
	Reference Claims MAY be Reference Integrity Measurements (RIM) or		to support Claim reproducibility by providing information on how
	assertions that are implicitly trusted because they are signed by		Claims originated.
	a trusted authority (see Endorsements in
	[I-D.ietf-rats-architecture]). Reference Claims typically		Reference Values ('refValues') _mandatory_
	represent (trusted) Claim sets about an Attester's intended
	platform operational state.		Reference Values as defined in [I-D.ietf-rats-architecture]. This
			specific type of Claims is used to appraise Claims incorporated in
			Evidence. For example, Reference Values MAY be Reference
			Integrity Measurements (RIM) or assertions that are implicitly
			trusted because they are signed by a trusted authority (see
			Endorsements in [I-D.ietf-rats-architecture]). Reference Values
			typically represent (trusted) Claim sets about an Attester's
			intended platform operational state.
	Claim Selection ('claimSelection'): _optional_		Claim Selection ('claimSelection'): _optional_
	A statement that represents a (sub-)set of Claims that can be		A (sub-)set of Claims which can be created by an Attester.
	created by an Attester.
	Claim Selections can act as filters that can specify the exact set		Claim Selections act as filters to specify the exact set of Claims
	of Claims to be included in Evidence. An Attester MAY decide		to be included in Evidence. In a remote attestation process, a
	whether or not to provide all Claims as requested via a Claim		Verifier sends a Claim Selection, among other elements, to an
	Selection.		Attester. An Attester MAY decide whether or not to provide all
			requested Claims from a Claim Selection to the Verifier.
	Evidence ('signedAttestationEvidence'): _mandatory_		Collected Claims ('collectedClaims'): _mandatory_
			Collected Claims represent a (sub-)set of Claims created by an
			Attester.
			Collected Claims are gathered based on the Claims selected in the
			Claim Selection. If a Verifier does not provide a Claim
			Selection, then all available Claims on the Attester are part of
			the Collected Claims.
			Evidence ('evidence'): _mandatory_
	A set of Claims that consists of a list of Authentication Secret		A set of Claims that consists of a list of Authentication Secret
	IDs that each identifies an Authentication Secret in a single		IDs that each identifies an Authentication Secret in a single
	Attesting Environment, the Attester Identity, Claims, and a		Attesting Environment, the Attester Identity, Claims, and a
	Handle. Attestation Evidence MUST cryptographically bind all of		Handle. Attestation Evidence MUST cryptographically bind all of
	these information elements. Evidence MUST be protected via an		these information elements. Evidence MUST be protected via an
	Authentication Secret. The Authentication Secret MUST be trusted		Authentication Secret. The Authentication Secret MUST be trusted
	by the Verifier as authoritative.		by the Verifier as authoritative.
	Attestation Result ('attestationResult'): _mandatory_		Attestation Result ('attestationResult'): _mandatory_
	An Attestation Result is produced by the Verifier as the output of		An Attestation Result is produced by the Verifier as the output of
	the appraisal of Evidence. Attestation Results include condensed		the appraisal of Evidence. Attestation Results include condensed
	assertions about integrity or other characteristics of the		assertions about integrity or other characteristics of the
	corresponding Attester that are digestable by Relying Parties.		corresponding Attester that are processible by Relying Parties.
	8. Interaction Models		7. Interaction Models
	The following subsections introduce and illustrate the interaction		The following subsections introduce and illustrate the interaction
	models:		models:
	1. Challenge/Response Remote Attestation		1. Challenge/Response Remote Attestation
	2. Uni-Directional Remote Attestation		2. Uni-Directional Remote Attestation
	3. Streaming Remote Attestation		3. Streaming Remote Attestation
	Each section starts with a sequence diagram illustrating the		Each section starts with a sequence diagram illustrating the
	interactions between Attester and Verifier. While the interaction		interactions between Attester and Verifier. While the presented
	models presented focus on the conveyance of Evidence, the intention		interaction models focus on the conveyance of Evidence, the intention
	of this document is in support of future work that applies the		of this document is in support of future work that applies the
	presented models to the conveyance of other Conceptual Messages,		presented models to the conveyance of other Conceptual Messages,
	namely Attestation Results, Endorsements, Reference Values, or		namely Attestation Results, Endorsements, Reference Values, or
	Appraisal Policies.		Appraisal Policies.
	All interaction models have a strong focus on the use of a handle to		All interaction models have a strong focus on the use of a handle to
	incorporate a type of proof of freshness. The ways these handles are		incorporate a type of proof of freshness and to prevent replay
	processed is the most prominent difference between the three		attacks. The way these handles are processed is the most prominent
	interaction models.		difference between the three interaction models.
	8.1. Challenge/Response Remote Attestation
			7.1. Challenge/Response Remote Attestation
	.----------. .----------.		.----------. .----------.
	| Attester | | Verifier |		| Attester | | Verifier |
	'----------' '----------'		'----------' '----------'
	| |		| |
			generateClaims(attestingEnvironment) |
			| => claims, eventLogs |
	| |		| |
	valueGeneration(targetEnvironment) |		| <-- requestAttestation(handle, authSecIDs, claimSelection) |
	| => claims |
	| |
	| <------requestEvidence(handle, authSecIDs, claimSelection) |
	| |		| |
	claimsCollection(claimSelection) |		collectClaims(claims, claimSelection) |
	| => collectedClaims |		| => collectedClaims |
	| |		| |
	evidenceGeneration(handle, authSecIDs, collectedClaims) |		generateEvidence(handle, authSecIDs, collectedClaims) |
	| => evidence |		| => evidence |
	| |		| |
	| returnEvidence-------------------------------------------> |		| evidence, eventLogs -------------------------------------> |
	| returnEventLog-------------------------------------------> |
	| |		| |
	| evidenceAppraisal(evidence, eventLog, refClaims)		| appraiseEvidence(evidence, eventLogs, refValues)
	| attestationResult <= |		| attestationResult <= |
	| |		| |
	This Challenge/Response Remote Attestation procedure is initiated by		The Attester boots up and thereby produces claims about its boot
	the Verifier, by sending a remote attestation request to the		state and its operational state. Event Logs accompany the produced
	Attester. A request includes a Handle, a list of Authentication		claims by providing an event trail of security-critical events in a
	Secret IDs, and a Claim Selection.		system. Claims are produced by all attesting Environments of an
			Attester system.
			The Challenge/Response remote attestation procedure is initiated by
			the Verifier by sending a remote attestation request to the Attester.
			A request includes a Handle, a list of Authentication Secret IDs, and
			a Claim Selection.
	In the Challenge/Response model, the handle is composed of qualifying		In the Challenge/Response model, the handle is composed of qualifying
	data in the form of a cryptographically strongly randomly generated,		data in the form of a practically infeasible to guess nonce, such as
	and therefore unpredictable, nonce. The Verifier-generated nonce is		a cryptographically strong random number. The Verifier-generated
	intended to guarantee Evidence freshness.		nonce is intended to guarantee Evidence freshness and to prevent
			replay attacks.
	The list of Authentication Secret IDs selects the attestation keys		The list of Authentication Secret IDs selects the attestation keys
	with which the Attester is requested to sign the Attestation		with which the Attester is requested to sign the Attestation
	Evidence. Each selected key is uniquely associated with an Attesting		Evidence. Each selected key is uniquely associated with an Attesting
	Environment of the Attester. As a result, a single Authentication		Environment of the Attester. As a result, a single Authentication
	Secret ID identifies a single Attesting Environment.		Secret ID identifies a single Attesting Environment.
			Correspondingly, a particular set of Evidence originating from a
	Analogously, a particular set of Evidence originating from a		particular Attesting Environment in a composite device can be
	particular Attesting Environments in a composite device can be
	requested via multiple Authentication Secret IDs. Methods to acquire		requested via multiple Authentication Secret IDs. Methods to acquire
	Authentication Secret IDs or mappings between Attesting Environments		Authentication Secret IDs or mappings between Attesting Environments
	to Authentication Secret IDs are out-of-scope of this document.		to Authentication Secret IDs are out-of-scope of this document.
	The Claim Selection narrows down the set of Claims collected and used		The Attester collects Claims based on the Claim Selection. With the
	to create Evidence to those that the Verifier requires. If the Claim		Claim Selection the Verifier defines the set of Claims it requires.
	Selection is omitted, then by default all Claims that are known and		Correspondingly, collected Claims can be a subset of the produced
	available on the Attester MUST be used to create corresponding		Claims. This could be all available Claims, depending on the Claim
	Evidence. For example when performing a boot integrity evaluation, a		Selection. If the Claim Selection is omitted, then by default all
	Verifier may only be requesting a particular subset of claims about		Claims that are known and available on the Attester MUST be used to
	the Attester, such as Evidence about BIOS and firmware the Attester		create corresponding Evidence. For example, when performing a boot
	booted up, and not include information about all currently running		integrity evaluation, a Verifier may only be requesting a particular
	software.		subset of claims about the Attester, such as Evidence about BIOS/UEFI
			and firmware that the Attester booted up, and not include information
			about all currently running software.
	While it is crucial that Claims, the Handle, as well as the Attester		With the Handle, the Authentication Secret IDs, and the collected
	Identity information MUST be cryptographically bound to the signature		Claims, the Attester produces signed Evidence. That is, it digitally
	of Evidence, they may be presented in an encrypted form.		signs the Handle and the collected Claims with a cryptographic secret
			identified by the Authentication Secret ID. This is done once per
			Attesting Environment which is identified by the particular
			Authentication Secret ID. The Attester communicates the signed
			Evidence as well as all accompanying Event Logs back to the Verifier.
	Cryptographic blinding MAY be used at this point. For further		While it is crucial that Claims, the Handle, and the Attester
	reference see section Section 11.		Identity information MUST be cryptographically bound to the signature
			of Evidence, they MAY be presented obfuscated, encrypted, or
			cryptographically blinded. For further reference see section
			Section 10.
	As soon as the Verifier receives signed Evidence, it validates the		As soon as the Verifier receives the signed Evidence and Event Logs,
	signature, the Attester Identity, as well as the Nonce, and appraises		it appraises the Evidence. For this purpose, it validates the
			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
	Claims, 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 Claims Sets about an Attester's properties and		constitute new Claim Sets about the properties and characteristics of
	characteristics that enables Relying Parties, for example, to assess		an Attester, which enables Relying Parties, for example, to assess an
	an Attester's trustworthiness.		Attester's trustworthiness.
	8.2. Uni-Directional Remote Attestation
	.----------. .----------.		7.2. Uni-Directional Remote Attestation
	| Attester | | Verifier |		.----------. .--------------------. .----------.
	'----------' '----------'		| Attester | | Handle Distributor | | Verifier |
	| |		'----------' '--------------------' '----------'
	valueGeneration(targetEnvironment) |		| | |
	| => claims |		| generateHandle() |
			| | => handle |
			| | |
			| <----------------------------- handle | handle ----------> |
			| | |
			generateClaims(attestingEnvironment) x |
			| => claims, eventLogs |
	| |		| |
	| .--------------------. |		collectClaims(claims, claimSelection) |
	| <----------handle | | |		| => collectedClaims |
	| | Handle Distributor | |
	| | | handle----------> |
	| '--------------------' |
	| |		| |
	evidenceGeneration(handle, authSecIDs, collectedClaims) |		generateEvidence(handle, authSecIDs, collectedClaims) |
	| => evidence |		| => evidence |
	| |		| |
	| pushEventLog---------------------------------------------> |		| evidence, eventLogs -------------------------------------> |
	| pushEvidence---------------------------------------------> |
	| |		| |
	| appraiseEvidence(evidence, eventLog, refClaims)		| appraiseEvidence(evidence, eventLogs, refValues)
	| attestationResult <= |		| attestationResult <= |
	~ ~		~ ~
	| |		| |
	valueGeneration(targetEnvironment) |		**********[loop]********************************************************
	| => claimsDelta |		* | | *
	| |		* generateClaims(attestingEnvironment) | *
	evidenceGeneration(handle, authSecIDs, collectedClaims) |		* | => claimsDelta, eventLogsDelta | *
	| => evidence |		* | | *
	| |		* collectClaims(claimsDelta, claimSelection) | *
	| pushEventLogDelta----------------------------------------> |		* | => collectedClaimsDelta | *
	| pushEvidence---------------------------------------------> |		* | | *
	| |		* generateEvidence(handle, authSecIDs, collectedClaimsDelta) | *
	| appraiseEvidence(evidence, eventLogDelta, refClaims)		* | => evidence | *
	| attestationResult <= |		* | | *
			* | evidence, eventLogsDelta --------------------------------> | *
			* | | *
			* | appraiseEvidence(evidence, eventLogsDelta, refValues) *
			* | attestationResult <= | *
			* | | *
			************************************************************************
	| |		| |
	Uni-Directional Remote Attestation procedures can be initiated both		Uni-Directional Remote Attestation procedures can be initiated both
	by the Attester and by the Verifier. Initiation by the Attester can		by the Attester and by the Verifier. Initiation by the Attester can
	result in unsolicited pushes of Evidence to the Verifier. Initiation		result in unsolicited pushes of Evidence to the Verifier. Initiation
	by the Verifier always results in solicited pushes to the Verifier.		by the Verifier always results in solicited pushes to the Verifier.
	The Uni-Directional model uses the same information elements as the		The Uni-Directional model uses the same information elements as the
	Challenge/Response model. In the sequence diagram above, the		Challenge/Response model. In the sequence diagram above, the
	Attester initiates the conveyance of Evidence (comparable with a		Attester initiates the conveyance of Evidence (comparable with a
	RESTful POST operation or the emission of a beacon). While a request		RESTful POST operation or the emission of a beacon). While a request
	of evidence from the Verifier would result in a sequence diagram more		of Evidence from the Verifier would result in a sequence diagram more
	similar to the Challenge/Response model (comparable with a RESTful		similar to the Challenge/Response model (comparable with a RESTful
	GET operation), the specific manner how handles are created and used		GET operation). The specific manner how Handles are created and used
	always remains as the distinguishing quality of this model. In the		always remains as the distinguishing quality of this model.
	Uni-Directional model, handles are composed of trustable signed
	timestamps as shown in [I-D.birkholz-rats-tuda], potentially
	including other qualifying data. The handles are created by an
	external 3rd entity - the Handle Distributor - that includes a
	trustworthy source of time and takes on the role of a Time Stamping
	Authority (TSA, as initially defined in [RFC3161]). Timstamps
	created from local clocks (absolute clocks using a global timescale,
	as well as relative clocks, such as tick-counters) of Attesters and
	Verifiers MUST be cryptographically bound to fresh Handles received
	from the Handle Distributor. This binding provides a proof of
	synchronization that MUST be included in every evidence created.
	Correspondingly, evidence created for conveyance via this model
	provides a proof that it was fresh at a certain point in time.
	Effectively, this allows for series of evidence to be pushed to
	multiple Verifiers, simultaniously. Methods to detect excessive time
	drift that would mandate a fresh Handle to be received by the Handle
	Distributor, as well as timing of handle distribution are out-of-
	scope of this document.
	8.3. Streaming Remote Attestation		In the Uni-Directional model, handles are composed of
			cryptographically signed trusted timestamps as shown in
			[I-D.birkholz-rats-tuda], potentially including other qualifying
			data. The Handles are created by an external 3rd entity -- the
			Handle Distributor -- which includes a trustworthy source of time,
			and takes on the role of a Time Stamping Authority (TSA, as initially
			defined in [RFC3161]). Timestamps created from local clocks
			(absolute clocks using a global timescale, as well as relative
			clocks, such as tick-counters) of Attesters and Verifiers MUST be
			cryptographically bound to fresh Handles received from the Handle
			Distributor. This binding provides a proof of synchronization that
			MUST be included in all produced Evidence. Correspondingly, conveyed
			Evidence in this model provides a proof that it was fresh at a
			certain point in time.
			While periodically pushing Evidence to the Verifier, the Attester
			only needs to generate and convey evidence generated from Claim
			values that have changed and new Event Logs entries since the
			previous conveyance. This updates reflecting the differences are
			called "delta" in the sequence diagram above.
			Effectively, the Uni-Directional model allows for a series of
			Evidence to be pushed to multiple Verifiers simultaneously. Methods
			to detect excessive time drift that would mandate a fresh Handle to
			be received by the Handle Distributor as well as timing of Handle
			distribution are out-of-scope of this document.
			7.3. Streaming Remote Attestation
	.----------. .----------.		.----------. .----------.
	| Attester | | Verifier |		| Attester | | Verifier |
	'----------' '----------'		'----------' '----------'
	| |		| |
	valueGeneration(targetEnvironment) |		generateClaims(attestingEnvironment) |
	| => claims |		| => claims, eventLogs |
	| |		| |
	| <----subscribeEvidence(handle, authSecIDs, claimSelection) |		| <----------- subscribe(handle, authSecIDs, claimSelection) |
	| subscriptionResult --------------------------------------> |		| subscriptionResult --------------------------------------> |
	| |		| |
	evidenceGeneration(handle, authSecIDs, collectedClaims) |		collectClaims(claims, claimSelection) |
			| => collectedClaims |
			| |
			generateEvidence(handle, authSecIDs, collectedClaims) |
	| => evidence |		| => evidence |
	| |		| |
	| pushEventLog---------------------------------------------> |		| evidence, eventLogs -------------------------------------> |
	| pushEvidence---------------------------------------------> |
	| |		| |
	| evidenceAppraisal(evidence, eventLog, refClaims)		| appraiseEvidence(evidence, eventLogs, refValues)
	| attestationResult <= |		| attestationResult <= |
	~ ~		~ ~
	| |		| |
	valueGeneration(targetEnvironment) |		**********[loop]********************************************************
	| => claimsDelta |		* | | *
	| |		* generateClaims(attestingEnvironment) | *
	evidenceGeneration(handle, authSecIDs, collectedClaims) |		* | => claimsDelta, eventLogsDelta | *
	| => evidence |		* | | *
	| |		* collectClaims(claimsDelta, claimSelection) | *
	| pushEventLogDelta----------------------------------------> |		* | => collectedClaimsDelta | *
	| pushEvidence---------------------------------------------> |		* | | *
	| |		* generateEvidence(handle, authSecIDs, collectedClaimsDelta) | *
	| evidenceAppraisal(evidence, eventLogDelta, refClaims)		* | => evidence | *
	| attestationResult <= |		* | | *
			* | evidence, eventLogsDelta --------------------------------> | *
			* | | *
			* | appraiseEvidence(evidence, eventLogsDelta, refValues) *
			* | attestationResult <= | *
			* | | *
			************************************************************************
	| |		| |
	Streaming Remote Attestation procedures require the setup of		Streaming Remote Attestation procedures require the setup of
	subscription state. Setting up subscription state between a Verifier		subscription state. Setting up subscription state between a Verifier
	and an Attester is conducted via a subscribe operation. This		and an Attester is conducted via a subscribe operation. The
	subscribe operation is used to convey the handles required for		subscribe operation is used to convey required Handles for producing
	Evidence generation. Effectively, this allows for series of evidence		Evidence. Effectively, this allows for a series of Evidence to be
	to be pushed to a Verifier similar to the Uni-Directional model.		pushed to a Verifier, similar to the Uni-Directional model. While a
	While a Handle Distributor is not required in this model, it is also		Handle Distributor is not required in this model, it is also limited
	limited to bi-lateral subscription relationships, in which each		to bi-lateral subscription relationships in which each Verifier has
	Verifier has to create and provide its individual handle. Handles		to create and provide its individual Handle. Handles provided by a
	provided by a specific subscribing Verifier MUST be used in Evidence		specific subscribing Verifier MUST be used in Evidence generation for
	generation for that specific Verifier. The Streaming model uses the		that specific Verifier. The Streaming model uses the same
	same information elements as the Challenge/Response and the Uni-		information elements as the Challenge/Response and the Uni-
	Directional model. Methods to detect excessive time drift that would		Directional model. Methods to detect excessive time drift that would
	mandate a refreshed Handle to be conveyed via another subscribe		mandate a refreshed Handle to be conveyed via another subscribe
	operation are out-of-scope of this document.		operation are out-of-scope of this document.
	9. Additional Application-Specific Requirements		8. Additional Application-Specific Requirements
	Depending on the use cases covered, there can be additional		Depending on the use cases covered, there can be additional
	requirements. An exemplary subset is illustrated in this section.		requirements. An exemplary subset is illustrated in this section.
	9.1. Confidentiality		8.1. Confidentiality
	Confidentiality of exchanged attestation information may be		Confidentiality of exchanged attestation information may be
	desirable. This requirement usually is present when communication		desirable. This requirement usually is present when communication
	takes place over insecure channels, such as the public Internet. In		takes place over insecure channels, such as the public Internet. In
	such cases, TLS may be uses as a suitable communication protocol that		such cases, TLS may be used as a suitable communication protocol
	preserves confidentiality. In private networks, such as carrier		which provides confidentiality protection. In private networks, such
	management networks, it must be evaluated whether or not the		as carrier management networks, it must be evaluated whether or not
	transport medium is considered confidential.		the transport medium is considered confidential.
	9.2. Mutual Authentication		8.2. Mutual Authentication
	In particular use cases mutual authentication may be desirable in		In particular use cases, mutual authentication may be desirable in
	such a way that a Verifier also needs to prove its identity to the		such a way that a Verifier also needs to prove its identity to the
	Attester, instead of only the Attester proving its identity to the		Attester, instead of only the Attester proving its identity to the
	Verifier.		Verifier.
	9.3. Hardware-Enforcement/Support		8.3. Hardware-Enforcement/Support
	Depending on given usage scenarios, hardware support for secure		Depending on given usage scenarios, hardware support for secure
	storage of cryptographic keys, crypto accelerators, as well as		storage of cryptographic keys, crypto accelerators, as well as
	protected or isolated execution environments can be mandatory		protected or isolated execution environments can be mandatory
	requirements. Well-known technologies in support of these		requirements. Well-known technologies in support of these
	requirements are roots of trusts, such as Hardware Security Modules		requirements are roots of trusts, such as Hardware Security Modules
	(HSM), Physically Unclonable Functions (PUFs), Shielded Secrets, or		(HSM), Physically Unclonable Functions (PUFs), Shielded Secrets, or
	Trusted Executions Environments (TEEs).		Trusted Executions Environments (TEEs).
	10. Implementation Status		9. Implementation Status
	Note to RFC Editor: Please remove this section as well as references		Note to RFC Editor: Please remove this section as well as references
	to [BCP205] before AUTH48.		to [BCP205] before AUTH48.
	This section records the status of known implementations of the		This section records the status of known implementations of the
	protocol defined by this specification at the time of posting of this		protocol defined by this specification at the time of posting of this
	Internet-Draft, and is based on a proposal described in [BCP205].		Internet-Draft, and is based on a proposal described in [BCP205].
	The description of implementations in this section is intended to		The description of implementations in this section is intended to
	assist the IETF in its decision processes in progressing drafts to		assist the IETF in its decision processes in progressing drafts to
	RFCs. Please note that the listing of any individual implementation		RFCs. Please note that the listing of any individual implementation
	skipping to change at page 16, line 14 ¶		skipping to change at page 16, line 25 ¶
	features. Readers are advised to note that other implementations may		features. Readers are advised to note that other implementations may
	exist.		exist.
	According to [BCP205], "this will allow reviewers and working groups		According to [BCP205], "this will allow reviewers and working groups
	to assign due consideration to documents that have the benefit of		to assign due consideration to documents that have the benefit of
	running code, which may serve as evidence of valuable experimentation		running code, which may serve as evidence of valuable experimentation
	and feedback that have made the implemented protocols more mature.		and feedback that have made the implemented protocols more mature.
	It is up to the individual working groups to use this information as		It is up to the individual working groups to use this information as
	they see fit".		they see fit".
	10.1. Implementer		9.1. Implementer
	The open-source implementation was initiated and is maintained by the		The open-source implementation was initiated and is maintained by the
	Fraunhofer Institute for Secure Information Technology - SIT.		Fraunhofer Institute for Secure Information Technology - SIT.
	10.2. Implementation Name		9.2. Implementation Name
	The open-source implementation is named "CHAllenge-Response based		The open-source implementation is named "CHAllenge-Response based
	Remote Attestation" or in short: CHARRA.		Remote Attestation" or in short: CHARRA.
	10.3. Implementation URL		9.3. Implementation URL
	The open-source implementation project resource can be located via:		The open-source implementation project resource can be located via:
	https://github.com/Fraunhofer-SIT/charra		https://github.com/Fraunhofer-SIT/charra
	10.4. Maturity		9.4. Maturity
	The code's level of maturity is considered to be "prototype".		The code's level of maturity is considered to be "prototype".
	10.5. Coverage and Version Compatibility		9.5. Coverage and Version Compatibility
	The current version ('1bcb469') implements a challenge/response		The current version ('1bcb469') implements a challenge/response
	interaction model and is aligned with the exemplary specification of		interaction model and is aligned with the exemplary specification of
	the CoAP FETCH bodies defined in Section Appendix A of this document.		the CoAP FETCH bodies defined in Section Appendix A of this document.
	10.6. License		9.6. License
	The CHARRA project and all corresponding code and data maintained on		The CHARRA project and all corresponding code and data maintained on
	github are provided under the BSD 3-Clause "New" or "Revised"		GitHub are provided under the BSD 3-Clause "New" or "Revised"
	license.		license.
	10.7. Implementation Dependencies		9.7. Implementation Dependencies
	The implementation requires the use of the official Trusted Computing		The implementation requires the use of the official Trusted Computing
	Group (TCG) open-source Trusted Software Stack (TSS) for the Trusted		Group (TCG) open-source Trusted Software Stack (TSS) for the Trusted
	Platform Module (TPM) 2.0. The corresponding code and data is also		Platform Module (TPM) 2.0. The corresponding code and data is also
	maintained on github and the project resources can be located via:		maintained on GitHub and the project resources can be located via:
	https://github.com/tpm2-software/tpm2-tss/		https://github.com/tpm2-software/tpm2-tss/
	The implementation uses the Constrained Application Protocol		The implementation uses the Constrained Application Protocol
	[RFC7252] (http://coap.technology/) and the Concise Binary Object		[RFC7252] (http://coap.technology/) and the Concise Binary Object
	Representation [RFC7049] (https://cbor.io/).		Representation [RFC7049] (https://cbor.io/).
	10.8. Contact		9.8. Contact
	Michael Eckel (michael.eckel@sit.fraunhofer.de)		Michael Eckel (michael.eckel@sit.fraunhofer.de)
	11. Security and Privacy Considerations		10. Security and Privacy Considerations
	In a remote attestation procedure the Verifier or the Attester MAY		In a remote attestation procedure the Verifier or the Attester MAY
	want to cryptographically blind several attributes. For instance,		want to cryptographically blind several attributes. For instance,
	information can be part of the signature after applying a one-way		information can be part of the signature after applying a one-way
	function (e. g. a hash function).		function (e. g. a hash function).
	There is also a possibility to scramble the Nonce or Attester		There is also a possibility to scramble the Nonce or Attester
	Identity with other information that is known to both the Verifier		Identity with other information that is known to both the Verifier
	and Attester. A prominent example is the IP address of the Attester		and Attester. A prominent example is the IP address of the Attester
	that usually is known by the Attester itself as well as the Verifier.		that usually is known by the Attester itself as well as the Verifier.
	This extra information can be used to scramble the Nonce in order to		This extra information can be used to scramble the Nonce in order to
	counter certain types of relay attacks.		counter certain types of relay attacks.
	12. Acknowledgments		11. Acknowledgments
	Olaf Bergmann, Michael Richardson, and Ned Smith		Olaf Bergmann, Michael Richardson, and Ned Smith
	13. Change Log		12. References
	o Initial draft -00
	o Changes from version 00 to version 01:
	* Added details to the flow diagram
	* Integrated comments from Ned Smith (Intel)
	* Reorganized sections and
	* Updated interaction model
	* Replaced "claims" with "assertions"
	* Added proof-of-concept CDDL for CBOR via CoAP based on a TPM
	2.0 quote operation
	o Changes from version 01 to version 02:
	* Revised the relabeling of "claims" with "assertion" in
	alignment with the RATS Architecture I-D.
	* Added Implementation Status section
	* Updated interaction model
	* Text revisions based on changes in [I-D.ietf-rats-architecture]
	and comments provided on rats@ietf.org.
	o Changes from version 02 to version 00 RATS related document
	* update of the challenge/response diagram
	* minor rephrasing of Prerequisites section
	* rephrasing to information elements and interaction model
	section
	o Changes from version 00 to version 01
	* added Attestation Authenticity, updated Identity and Secret
	* relabeled Secret ID to Authentication Secret ID + rephrasing
	* relabeled Claim Selection to Assertion Selection + rephrasing
	* relabeled Evidence to (Signed) Attestation Evidence
	* Added Attestation Result and Reference Assertions
	* update of the challenge/response diagram and expositional text
	* added CDDL spec for CoAP FETCH operation proof-of-concept
	o Changes from version 01 to version 02
	* prepared the inclusion of additional reference models
	* update to Introduction and Scope section
	* major update to (Normative) Prerequisites
	* relabeled Attestation Authenticity to Att. Evidence
	Authenticity
	* relabeled Assertion term back to Claim terms
	* added BCP205 Implementation Status section related to
	Appendix CDDL
	o Changes from version 02 to version 03
	* major refactoring to now accommodate three interaction models
	* updated existing and added two new diagrams for models
	* major refactoring of existing and adding of new diagram
	description
	* incorporated content about Direct Anonymous Attestation
	* integrated comments from Michael Richardson
	* updated roster
	14. References
	14.1. Normative References		12.1. Normative References
	[BCP205] Sheffer, Y. and A. Farrel, "Improving Awareness of Running		[BCP205] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
	Code: The Implementation Status Section", BCP 205,		Code: The Implementation Status Section", BCP 205,
	RFC 7942, DOI 10.17487/RFC7942, July 2016,		RFC 7942, DOI 10.17487/RFC7942, July 2016,
	<https://www.rfc-editor.org/info/rfc7942>.		<https://www.rfc-editor.org/info/rfc7942>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 20, line 20 ¶		skipping to change at page 18, line 40 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[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>.
	14.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", ACM Proceedings of the 11rd ACM		Anonymous Attestation", page 132-145, ACM Proceedings of
	conference on Computer and Communications Security ,		the 11rd ACM conference on Computer and Communications
	page 132-145, 2004.		Security, 2004.
	[I-D.birkholz-rats-tuda]		[I-D.birkholz-rats-tuda]
	Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,		Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann,
	"Time-Based Uni-Directional Attestation", draft-birkholz-		"Time-Based Uni-Directional Attestation", Work in
	rats-tuda-03 (work in progress), July 2020.		Progress, Internet-Draft, draft-birkholz-rats-tuda-04, 13
			January 2021, <https://www.ietf.org/archive/id/draft-
			birkholz-rats-tuda-04.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",		W. Pan, "Remote Attestation Procedures Architecture", Work
	draft-ietf-rats-architecture-07 (work in progress),		in Progress, Internet-Draft, draft-ietf-rats-architecture-
	October 2020.		12, 23 April 2021, <https://www.ietf.org/archive/id/draft-
			ietf-rats-architecture-12.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",		based Network Device Remote Integrity Verification", Work
	draft-ietf-rats-tpm-based-network-device-attest-04 (work		in Progress, Internet-Draft, draft-ietf-rats-tpm-based-
	in progress), September 2020.		network-device-attest-06, 7 December 2020,
			<https://www.ietf.org/archive/id/draft-ietf-rats-tpm-
			based-network-device-attest-06.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", The Faulkner		Edifice, and Ruin in Faulkner and McCarthy",
	Journal 25.2, DOI 10.1353/fau.2010.0002, 2010.		DOI 10.1353/fau.2010.0002, The Faulkner Journal 25.2,
			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
	illustrate a potential implementation of the Challenge/Response		illustrate a potential implementation of the Challenge/Response
	Interaction Model. The transfer protocol used is CoAP using the		Interaction Model. The transfer protocol used is CoAP using the
	FETCH operation. The actual resource operated on can be empty. Both		FETCH operation. The actual resource operated on can be empty. Both
	the Challenge Message and the Response Message are exchanged via the		the Challenge Message and the Response Message are exchanged via the
	FETCH operation and corresponding FETCH Request and FETCH Response		FETCH operation and corresponding FETCH Request and FETCH Response
	body.		body.
	In this example, evidence is created via the root-of-trust for		In this example, evidence is created via the root-of-trust for
	reporting primitive operation "quote" that is provided by a TPM 2.0.		reporting primitive operation "quote" that is provided by a TPM 2.0.
	RAIM-Bodies = CoAP-FETCH-Body / CoAP-FETCH-Response-Body		RAIM-Bodies = CoAP-FETCH-Body / CoAP-FETCH-Response-Body
	CoAP-FETCH-Body = [ hello: bool, ; if true, the AK-Cert is conveyed		CoAP-FETCH-Body = [ hello: bool, ; if true, the AK-Cert is conveyed
	nonce: bytes,		nonce: bytes,
	pcr-selection: [ + [ tcg-hash-alg-id: uint .size 2, ; TPM2_ALG_ID		pcr-selection: [ + [ tcg-hash-alg-id: uint .size 2, ; TPM2_ALG_ID
	[ + pcr: uint .size 1 ],		[ + pcr: uint .size 1 ],
	]		]
	],		],
	]		]
	CoAP-FETCH-Response-Body = [ attestation-evidence: TPMS_ATTEST-quote,		CoAP-FETCH-Response-Body = [ attestation-evidence: TPMS_ATTEST-quote,
	tpm-native-signature: bytes,		tpm-native-signature: bytes,
	? ak-cert: bytes, ; attestation key certificate		? ak-cert: bytes, ; attestation key certificate
	]		]
	TPMS_ATTEST-quote = [ qualifiediSigner: uint .size 2, ;TPM2B_NAME		TPMS_ATTEST-quote = [ qualifiediSigner: uint .size 2, ;TPM2B_NAME
	TPMS_CLOCK_INFO,		TPMS_CLOCK_INFO,
	firmwareVersion: uint .size 8		firmwareVersion: uint .size 8
	quote-responses: [ * [ pcr: uint .size 1,		quote-responses: [ * [ pcr: uint .size 1,
	+ [ pcr-value: bytes,		+ [ pcr-value: bytes,
	? hash-alg-id: uint .size 2,		? hash-alg-id: uint .size 2,
	],		],
	],		],
	? pcr-digest: bytes,		? pcr-digest: bytes,
	],		],
	]		]
	TPMS_CLOCK_INFO = [ clock: uint .size 8,		TPMS_CLOCK_INFO = [ clock: uint .size 8,
	resetCounter: uint .size 4,		resetCounter: uint .size 4,
	restartCounter: uint .size 4,		restartCounter: uint .size 4,
	save: bool,		save: bool,
	]		]
	Authors' Addresses		Authors' Addresses
	Henk Birkholz		Henk Birkholz
	Fraunhofer SIT		Fraunhofer SIT
	Rheinstrasse 75		Rheinstrasse 75
	Darmstadt 64295		64295 Darmstadt
	Germany		Germany
	Email: henk.birkholz@sit.fraunhofer.de		Email: henk.birkholz@sit.fraunhofer.de
	Michael Eckel		Michael Eckel
	Fraunhofer SIT		Fraunhofer SIT
	Rheinstrasse 75		Rheinstrasse 75
	Darmstadt 64295		64295 Darmstadt
	Germany		Germany
	Email: michael.eckel@sit.fraunhofer.de		Email: michael.eckel@sit.fraunhofer.de
	Christopher Newton		Wei Pan
	University of Surrey		Huawei Technologies
	Email: cn0016@surrey.ac.uk		Email: william.panwei@huawei.com
	Liqun Chen		Eric Voit
	University of Surrey		Cisco Systems
	Email: liqun.chen@surrey.ac.uk		Email: evoit@cisco.com
End of changes. 114 change blocks.
	485 lines changed or deleted		393 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/