< draft-birkholz-rats-architecture-00.txt		draft-birkholz-rats-architecture-01.txt >
	Network Working Group H. Birkholz		Network Working Group H. Birkholz
	Internet-Draft Fraunhofer SIT		Internet-Draft Fraunhofer SIT
	Intended status: Standards Track M. Wiseman		Intended status: Standards Track M. Wiseman
	Expires: April 27, 2019 GE Global Research		Expires: September 13, 2019 GE Global Research
	H. Tschofenig		H. Tschofenig
	ARM Ltd.		ARM Ltd.
	N. Smith		N. Smith
	Intel		Intel
	October 24, 2018		March 12, 2019
	Architecture and Reference Terminology for Remote Attestation Procedures		Architecture and Reference Terminology for Remote Attestation Procedures
	draft-birkholz-rats-architecture-00		draft-birkholz-rats-architecture-01
	Abstract		Abstract
	Remote ATtestation ProcedureS (RATS), such as Remote Integrity		Remote ATtestation ProcedureS (RATS) architecture facilitates the
	VERification (RIVER), the creation of Entity Attestation Tokens		attestation of device characteristics that, in general, are based on
	(EAT), software integrity Measurement And ATtestation (MAAT), or the		specific trustworthiness qualities intrinsic to a device or service.
	attestation of device characteristics, in general, are based on		It includes trusted computing functionality provided by device
	specific operations and qualities provided by hardware and software.		hardware and software that allows trustworthiness qualities to be
	The RATS architecture maps corresponding functions and operation		asserted and verified as part of, or pre-requisite to, the device's
	capabilities to specific RATS roles. The goal is to enable an		normal operation. The RATS architecture maps corresponding
	appropriate conveyance of believable evidence about device health or		attestation functions and capabilities to specific RATS Roles. The
	trusted claims about device capabilities via network protocols. The		goal is to enable an appropriate conveyance of evidence about device
	flows of data between these roles depend on the composition of RATS		trustworthiness via network protocols. RATS Roles provide the
	roles and their location with respect to devices or services. The		endpoint context for understanding the various interaction semantics
	RATS architecture provides these roles as building blocks to enable		of the attestation lifecycle. The RATS architecture provides the
	suitable composition, while remaining hardware-agnostic. This		building block concepts, semantics, syntax and framework for
	flexibility is intended to address a significant majority of use		interoperable attestation while remaining hardware-agnostic. This
	cases or usage scenarios in the domain of RATS. Examples include,		flexibility is intended to address a significant variety of use-cases
	but are not limited to: financial transactions, voting machines,		and scenarios involving interoperable attestation. Example usages
	critical safety systems, network equipment health, or trustworthy		include, but are not limited to: financial transactions, voting
	end-user device management.		machines, critical safety systems, network equipment health, or
			trustworthy end-user device management. Existing industry
			attestation efforts may be helpful toward informing RATS
			architecture. Such as: Remote Integrity VERification (RIVER), the
			creation of Entity Attestation Tokens (EAT), software integrity
			Measurement And ATtestation (MAAT)
	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 27, 2019.		This Internet-Draft will expire on September 13, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 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/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are 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
	1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3		1.1. What is Remote Attestation . . . . . . . . . . . . . . . 4
	2. RATS Architecture . . . . . . . . . . . . . . . . . . . . . . 3		1.2. The purpose of RATS Architecture and Terminology . . . . 4
	2.1. Roles, Devices, and Services . . . . . . . . . . . . . . 4		1.3. Requirements notation . . . . . . . . . . . . . . . . . . 4
	2.2. Trust and Trustworthiness . . . . . . . . . . . . . . . . 5		2. RATS Architecture . . . . . . . . . . . . . . . . . . . . . . 4
	2.3. Claims and Evidence . . . . . . . . . . . . . . . . . . . 6		3. Architectural Components . . . . . . . . . . . . . . . . . . 5
	2.4. RATS Roles . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. RATS Roles . . . . . . . . . . . . . . . . . . . . . . . 5
	2.5. Exemplary Composition of Roles . . . . . . . . . . . . . 8		4. RATS Actors . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.5.1. Conveyance of Trusted Claim Sets Validated by		4.1. RATS Duties . . . . . . . . . . . . . . . . . . . . . . . 7
	Signature . . . . . . . . . . . . . . . . . . . . . . 8		4.1.1. Attester Duties . . . . . . . . . . . . . . . . . . . 8
	2.5.2. Conveyance of Attestation Evidence Appraised by a		4.1.2. Verifier Duties . . . . . . . . . . . . . . . . . . . 8
	Verifier . . . . . . . . . . . . . . . . . . . . . . 9		4.1.3. Claimant Duties . . . . . . . . . . . . . . . . . . . 8
	2.6. The Scope of RATS . . . . . . . . . . . . . . . . . . . . 9		4.1.4. Relying Party Duties . . . . . . . . . . . . . . . . 8
	2.6.1. The Lying Endpoint Problem . . . . . . . . . . . . . 10		4.1.5. RATS Interactions . . . . . . . . . . . . . . . . . . 9
	2.6.2. How the RATS Architecture Addresses the Lying		5. Application of RATS . . . . . . . . . . . . . . . . . . . . . 10
	Endpoint Problem . . . . . . . . . . . . . . . . . . 11		5.1. Trust and Trustworthiness . . . . . . . . . . . . . . . . 11
	3. RATS Terminology . . . . . . . . . . . . . . . . . . . . . . 11		5.2. Claims and Evidence . . . . . . . . . . . . . . . . . . . 12
	3.1. Computing Context . . . . . . . . . . . . . . . . . . . . 12		5.3. RATS Information Flows . . . . . . . . . . . . . . . . . 12
	3.1.1. Characteristics of a Computing Context . . . . . . . 13		6. Exemplary Composition of Roles . . . . . . . . . . . . . . . 13
	3.1.2. Computing Context Semantic Relationships . . . . . . 14		6.1. Conveyance of Trusted Claim Sets Validated by Signature . 13
	3.1.3. Computing Context Identity . . . . . . . . . . . . . 16		6.2. Conveyance of Attestation Evidence Appraised by a
	3.2. Remote Attestation Concepts . . . . . . . . . . . . . . . 16		Verifier . . . . . . . . . . . . . . . . . . . . . . . . 14
	3.3. Core RATS Terminology . . . . . . . . . . . . . . . . . . 16		7. The Scope of RATS . . . . . . . . . . . . . . . . . . . . . . 14
	3.4. RATS Information Model Terminology . . . . . . . . . . . 17		7.1. The Lying Endpoint Problem . . . . . . . . . . . . . . . 15
	3.5. RATS Work-Flow Terminology . . . . . . . . . . . . . . . 18		7.1.1. How the RATS Architecture Addresses the Lying
	3.6. RATS Reference Use Cases . . . . . . . . . . . . . . . . 19		Endpoint Problem . . . . . . . . . . . . . . . . . . 16
	3.6.1. Use Case A . . . . . . . . . . . . . . . . . . . . . 19		8. RATS Terminology . . . . . . . . . . . . . . . . . . . . . . 17
	3.6.2. Use Case B . . . . . . . . . . . . . . . . . . . . . 19		8.1. Computing Context . . . . . . . . . . . . . . . . . . . . 18
	3.7. RATS Reference Terminology . . . . . . . . . . . . . . . 19		8.1.1. Characteristics of a Computing Context . . . . . . . 19
	3.8. Interpretations of RFC4949 Terminology for Attestation . 21		8.1.2. Computing Context Semantic Relationships . . . . . . 19
	3.9. Building Block Vocabulary (Not in RFC4949) . . . . . . . 23		8.1.3. Computing Context Identity . . . . . . . . . . . . . 21
	4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23		8.2. Remote Attestation Concepts . . . . . . . . . . . . . . . 21
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 23		8.3. Core RATS Terminology . . . . . . . . . . . . . . . . . . 22
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23		8.4. RATS Information Model Terminology . . . . . . . . . . . 22
	7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 24		8.5. RATS Work-Flow Terminology . . . . . . . . . . . . . . . 23
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24		8.6. RATS Reference Use Cases . . . . . . . . . . . . . . . . 24
	8.1. Normative References . . . . . . . . . . . . . . . . . . 24		8.6.1. Use Case A . . . . . . . . . . . . . . . . . . . . . 24
	8.2. Informative References . . . . . . . . . . . . . . . . . 24		8.6.2. Use Case B . . . . . . . . . . . . . . . . . . . . . 24
	8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24		8.7. RATS Reference Terminology . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24		8.8. Interpretations of RFC4949 Terminology for Attestation . 26
			8.9. Building Block Vocabulary (Not in RFC4949) . . . . . . . 28
			9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 28
			10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
			11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
			12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 29
			13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
			13.1. Normative References . . . . . . . . . . . . . . . . . . 29
			13.2. Informative References . . . . . . . . . . . . . . . . . 29
			13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
	1. Introduction		1. Introduction
	This document provides normative guidance how to use, create or adopt		In general, this document provides normative guidance how to use,
	network protocols that facilitate remote attestation procedures. The		create or adopt network protocols that facilitate remote attestation
	foundation of the RATS architecture are specific roles that can be		procedures. The RATS Architecture anticipates broad deployment
	chained and as a result compose remote attestation procedures. The		contexts that range from IoT to Cloud and Edge ecosystems. The
	term attestation, unfortunately, is an overloaded term. There are		foundation of the RATS architecture is the specification of RATS
	different interpretations, connotations and meanings to the term		Roles that can be chained via RATS Interactions and - as a result -
	attestation and therefore also to terms related to attestation. In		may be composed into use-case specific Remote Attestation Procedures.
	consequence, this document also provides a detailed definition of		RATS Actors establish an ecosystem neutral context where RATS Roles
	Attestation Terminology. The intent is to illustrate and remediate		are hosted and where a variety of Remote Attestation Procedure
	the impedance mismatch of terms related to Remote Attestation		interactions are defined independent of specific conveyance protocols
	Procedures used in different domains today. New terms defined by		or message formats. In summary, the goal of the RATS Architecture is
	this document provide a consolidated basis to support future work on		to enable interoperable interaction between the RATS Roles. Hence,
	RATS in the IETF and beyond.		the RATS Architecture is designed to enable interoperability via
			well-defined semantics of the information model (attestation
			assertions/claims), associated with RATS Roles following a conveyance
			model (RATS Interactions) that may be used to compose domain-specific
			remote attestation solutions.
	1.1. Requirements notation		1.1. What is Remote Attestation
			Unfortunately, the term Attestation itself is an overloaded term. In
			consequence, the term Remote Attestation covers a spectrum of
			meanings. The common denominator encompasses the creation,
			conveyance, and appraisal of evidence pertaining to the
			trustworthiness characteristics of the creator of the evidence. In
			essence, RATS are used to enable the assessment of the
			trustworthiness of a communication partner.
			1.2. The purpose of RATS Architecture and Terminology
			To consolidate the utilization of existing and emerging network
			protocols in the context of RATS, this document provides a detailed
			definition of Attestation Terminology that enables interoperability
			between different types pf RATS. Specifically, this document
			illustrates and remediates the impedance mismatch of terms related to
			Remote Attestation Procedures used in different domains today. As an
			additional contribution, new terms defined by this document provide a
			common basis that simplifies future work on RATS in the IETF and
			beyond.
			1.3. Requirements notation
	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 RFC		"OPTIONAL" in this document are to be interpreted as described in
	2119, BCP 14 [RFC2119].		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	2. RATS Architecture		2. RATS Architecture
	The goal of the RATS architecture is to provide the building blocks -		One of the goals of the RATS Architecture is to provide the building
	the roles defined by the RATS architecture - to enable the		blocks - the roles defined by the RATS Architecture - to enable the
	composition of service-chains and work-flows to create and appraise		composition of service-chains/hierarchies and work-flows that can
	evidence about the trustworthiness of devices and services.		create and appraise evidence about the trustworthiness of devices and
			services.
	The RATS architecture does not prescribe specific payload		The RATS Architecture is based on the use-cases defined in
	definitions, role composition, or protocol use. However, it imposes		[I-D.richardson-rats-usecases].
	requirements on payload definitions, interfaces, and network
	protocols with respect to proofs of freshness, attestation
	provenance, and required operational primitives that are available to
	devices and services taking on RATS roles. For brevity, the term
	"system" is a synonym for "device or service" in this document.
	2.1. Roles, Devices, and Services		The RATS architecture specifies:
	In the RATS architecture, devices or services can take on RATS roles.		o The building blocks to create remote attestation procedures
	In this context, devices are typically composite devices (in the case		applicable Actors, Roles, Duties, and Interactions,
	of atomically integrated devices that would result in a composite
	device with one component). Services are software components - e.g.
	a daemon, a virtual network function (vnf) or a network security
	function (nsf) - that can reside on one or more devices and are not
	necessarily bound to a specific set of devices.
	Devices or Services (Systems) can take on one or more RATS roles		o Mandatory and optional trust relationships between its Roles, that
	either by separate functions or via a collapsed functions that take		may assume a Root-of-Trust context,
	on multiple RATS roles. Systems that take on RATS roles:
	o are consumer and/or producer of role-specific information, and		o The interaction between Roles that reside on separate Actors and
			interact via network protocols,
	o can be chained to compose specific work-flows.		o Protocol/message framing that allows for well-defined and opaque
			payloads,
	Systems can be distinguished on the management plane via identity		o The means to prove, preserve and convey trust properties, such as
	documents (which includes specific claim sets about device		identity, varacity, freshness, or provenance, and
	characteristics, see RFC4949) or via trusted claim sets (e.g. the
	Entity Attestation Token) and can be addressed by network protocols		o Primitives necessary for the construction of interoperable
	via IP addresses. RATS can be used in environments without network		attestation payloads.
	protocols and RATS roles can be used to design work-flows in these
	domains, correspondingly. However, the primary focus of the RATS		3. Architectural Components
	architecture is to facilitate network protocols between RATS roles
	that convey information via the Internet Protocol.		The basic architectural components defined in this document are:
			o RATS Roles
			o RATS Actors
			o RATS Duties
			o RATS Interactions
			The following sub-section define and elaborate on these terms:
			3.1. RATS Roles
			A Role in the context of usage scenarios for remote attestation
			procedures is providing a service to other Roles. Roles are building
			blocks that can be providers and consumers of information. In the
			RATS architecture, devices or services can take on RATS roles. They
			are composites of internal functions (RATS Duties) and external
			functions (RATS Interactions) that facilitate a required (sometimes
			optional) task in a remote attestation procedure.
			The base set of RATS roles is:
			Claimant: The producer of trustworthiness assertions pertaining to
			an Attester; that may or not have a root-of-trust for measurement.
			It is not guaranteed that a Verifier Role can appraise the output
			of a Claimant via reference values (in contrast to the output of
			an Attester).
			Examples of Claimant assertions include: * The hardware, firmware
			and software components of the Attester. * The manufactuer of
			Attester components. * The Attester's current configuration. *
			The Attester's current location - e.g. GPS coordinates. * The
			method by which binding of an attester to an RTR. * The
			identifier(s) available for identifying and authenticating the
			Attester - e.g. Universal Entity ID (UEID).
			Typically, claimant role are taken on by RATS Actors that supply
			chain entities (SCE). Various assertions (often represented as
			Claims or Trusted Claims Sets, e.g. [I-D.mandyam-eat] or
			[I-D.tschofenig-rats-psa-token]).
			Attester: The producer of attestation evidence that has a root of
			trust for reporting (RTR) and implements a conveyance protocol,
			authenticates using an attestation credential, consumes assertions
			about itself and presents it to a consumer of evidence (e.g. a
			relying party or a verifier). Every output of an attester can be
			appraised via reference values.
			Authentication Checker: The consumer of signed assertions such as
			trusted claim sets or attestation evidence that assesses the
			trustworthiness or other trust relationships of the information
			consumed via trusted third parties or external trust authorities,
			such as a privacy certificate authority. In certain environments,
			an Authentication Checker can assess a system's trustworthiness
			via external trust anchors, implicitly.
			Verifier: The consumer of attestation evidence that has a root of
			trust for verification (RTV), implements conveyance protocols,
			appraises attestation evidence against reference values or
			policies, and makes verification results available to relying
			parties.
			Relying Party: The consumer and assessor of verifier or
			Authentication Checker results for the purpose of improved risk
			management, operational efficiency, security, privacy (natural or
			legal person) or safety. The verifier and/or authentication
			checker roles and the relying party role may be tightly
			integrated.
			4. RATS Actors
			RATS Actors may be any entity, such as an user, organization,
			execution environment, device or service provider, that takes on
			(implements) one or more RATS Roles and performs RATS Duties and/or
			RATS Interactions. RATS Interactions occur between RATS Actors. The
			methods whereby RATS Actors are identified, discovered, and
			connectivity established are out-of-scope for this architecture. In
			contrast, if multiple RATS Roles reside on a single RATS Actor, the
			definition of RATS Interactions is out-of-scope of the RATS
			architecture, if no network protocols are required.
			+------------------+ +------------------+
			| Actor 1 | | Actor 2 |
			| +------------+ | | +------------+ |
			| | | | | | | |
			| | Role 1 |<-|---|->| Role 2 | |
			| | | | | | | |
			| +------------+ | | +------------+ |
			| | | |
			| +-----+------+ | | +-----+------+ |
			| | | | | | | |
			| | Role 2 |<-|---|->| Role 3 | |
			| | | | | | | |
			| +------------+ | | +------------+ |
			| | | |
			+------------------+ +------------------+
			Figure 1: RATS Actor-Role Interactions
			RATS Actors have the following properties: * Multiplicity - Multiple
			instances of RATS Actors that possess the same RATS Roles can exist.
			* Decomposability - A singleton RATS Actor possessing multiple RATS
			Roles can be separated into multiple RATS Actors. RATS Interactions
			may occur between them. * Composablility - RATS Actors possessing
			different RATS Roles can be combined into a singleton RATS Actor
			possessing the union of RATS Roles. RATS Interactions between
			combined RATS Actors ceases.
			Interactions between RATS Roles belonging to the same RATS Actor are
			generally believed to be uninteresting. Actor operations that apply
			resiliency, scaling, load balancing or replication are generally
			believed to be uninteresting.
			4.1. RATS Duties
			A RATS Role can take on one ore more duties. RATS Duties are role-
			internal functions that do not require interaction with other RATS
			Roles. In general, and RATS Duties are typically associated with a
			RATS Role. The list presented in this document is exhaustive. Also,
			there can be usage scenario where RATS Duties are associated with
			other RATS Roles than illustrated below:
			4.1.1. Attester Duties
			o Acquisition or collection of assertions about itself
			o Provide or create proof that an assertion is bound to the Attester
			o Create Evidence from assertion bundles via roots-of-trust
			4.1.2. Verifier Duties
			o Acquisition and storage of assertion semantics
			o Acquisition and storage of appraisal policies
			o Verification of Attester Identity (attestation provenance)
			o Comparing assertions or evidence with reference values according
			to appraisal policies
			o Validate authentication information based on public keys,
			signatures, secrets that are shielded, or secrets that are access
			restricted via protection profiles
			4.1.3. Claimant Duties
			o Hardens the device or service that implements the Attester role
			o Provisions device identities and/or key material accessible to the
			Attester role
			o Evaluates trustworthiness during manufacturing, supply chain and
			onboarding
			o Produces trustworthiness assertions applicable to the Attestor
			role
			o Embeds trustworthiness assertions about the Attester role in the
			device or service during manufacturing, supply chain or onboarding
			4.1.4. Relying Party Duties
			o Evaluate assertions/evidence locally as far as possible
			o Compare trust policies to attestation-results based on assertions
			or evidence
			o Enforce policies or create input for risk engines
			4.1.5. RATS Interactions
			The flow of information between RATS Roles located on RATS Actors
			compose individual remote attestation procedures. The RATS
			Architecture provides a set of standard interactions between the RATS
			Roles defined in this document in order to enable this composability.
			In this section, common interactions between roles are specified.
			This list of interactions is not exhaustive, but provides the basis
			to create various standard RATS.
			Every RATS Interaction specified below is based on the information
			flow between two RATS Roles defined above. Every RATS Interaction is
			conducted via an Interconnect between corresponding RATS Roles that
			RATS Actors take on. If more than one RATS Role resides on the same
			RATS Actor, a network protocol might not be required. If RATS Roles
			are collapsed into a singular RATS Actor in this way, the method of
			conveying information is out-of-scope of this document. If network
			protocols are used to convey corresponding information between RATS
			Roles (collapsed on a singular RATS Actor or not), the definitions
			and requirements defined in this document apply.
			In essence, an Interconnect is an abstract "distance-less" channel
			between RATS Actors that can range from General Purpose Input Output
			(GPIO) interfaces to the Internet.
			Attester/Verifier: The most basic RATS interaction is between the
			creator of evidence (Attester) and its complementary remote
			attestation service (Verifier). In order to convey evidence (or
			assertions that are not accompanied by a proof of their validity)
			this RATS Interaction is required.
			Attester/Relying-Party: A Relying Party typically requires external
			help to either validate authentication information or to appraise
			evidence presented by an Attester. In most cases, a Relying Party
			requires a corresponding Verifier to process the assertions/
			evidence received. In consequence, (a subset of) the information
			received by an Attester must be relayed securely to a Verifier.
			Relying-Party/Verifier: Typically, trusted assertions or evidence
			are conveyed from an Attester to a Relying Party. In an open
			ecosystem, such as the Internet, the appraisal of the evidence
			presented by an Attester provided in order to assess its
			trustworthiness requires a remote attestation service. Hence,
			either the RATS roles of Verifier and Relying Party are collapsed
			and compose a single RATS Actor, or - if they reside on separate
			RATS Actors - a Relying Party requires appropriate configuration
			or a discovery/join/rendezvous service to initiate a RATS
			Interaction with an appropriate and trusted Verifier.
			Attestation information originating from an Attester that is
			relayed via a Relying Party must be protected from replay or relay
			attacks, accordingly. In a closed ecosystem, trustworthiness with
			respect to the Attester can be achieved via a simply query to the
			Verifier. In an open ecosystem, the information conveyed in this
			interaction can include integrity measurements of every
			distinguishable software component that has been executed since
			its last boot cycle.
			In the scope of RATS, this interaction encompasses the largest
			variety of information conveyed.
			Claimant/Verifier: The intended operational state an Attester is
			intended to be in, is defined by the supply chain entities that
			manufacture and maintain the Attestor. In order to appraise
			trusted assertions or evidence conveyed by the Attester, every
			distinguishable system component the Attester is composed of can
			provide trusted assertions or evidence about its trustworthiness.
			A corresponding verifier that is tasked with assessing the
			trustworthiness of the Attester potentially requires a multitude
			of sources of reference values according to policies and the
			information provided. As Relying Parties often have to discover
			an appropriate Verifier, a Verifier has to obtain and potentially
			store appropriate reference values in order to asses assertions or
			evidence about trustworthiness.
			Claimant/Attester: To enable RATS, trustworthy assertions have to be
			embedded in an Attester by its manufactorer. In some cases this
			involves various types of roots of trust. In other cases shielded
			pre-master secrets in combination with key derivation functions
			(KDF) provide this binding of trusted information to an Attester.
			A supply chain entity can embed additional trusted assertions to
			an Attester. These assertion can also be used to assert the
			trustworthiness on behalf of a separate RATS Actor or they can
			originate from an external entity (e.g. a security certification
			authority).
			5. Application of RATS
			Attester are typically composite devices (in the case of atomically
			integrated devices that would result in a composite device with one
			component) or services. Services are software components - e.g. a
			daemon, a virtual network function (vnf) or a network security
			function (nsf) - that can reside on one or more Attester and are not
			necessarily bound to a specific set of hardware devices.
	Relevant decision-factors that influence the composition of RATS		Relevant decision-factors that influence the composition of RATS
	roles on systems and resulting work-flows are (amongst others):		Roles on RATS Actors, which result in specific work-flows are
			(amongst others):
	o which role (or correspondingly, which system that is taking on		o which RATS Role (or correspondingly, which RATS Actore that is
	specific RATS roles) is triggering a Remote Attestation Procedure		taking on specific RATS roles) is triggering a Remote Attestation
			Procedure
	o which entities are involved in a Remote Attestation Procedure		o which entities are involved in a Remote Attestation Procedure
	(e.g. the attester itself, trusted third parties, specific trust		(e.g. the Attester itself, trusted third parties, specific trust
	anchors, or other sources of assertions)		anchors, or other sources of assertions)
	o the capabilities of the protocols used (e.g. challenge-response		o the capabilities of the protocols used (e.g. challenge-response
	based, RESTful, uni-directional)		based, RESTful, or uni-directional)
	o the security requirements and security capabilities of systems in		o the security requirements and security capabilities of systems in
	a domain of application		a domain of application
	o the risks and corresponding threats that are intended to be		o the risks and corresponding threats that are intended to be
	mitigated		mitigated
	2.2. Trust and Trustworthiness		5.1. Trust and Trustworthiness
	[RFC4949] provides definitions that highlight the difference between		[RFC4949] provides definitions that highlight the difference between
	a "trusted system" and a "trustworthy system". The following		a "trusted system" and a "trustworthy system". The following
	definitions exclude the explicit specialization of concepts that are		definitions exclude the explicit specialization of concepts that are
	"environmental disruption" as well as "human user and operator		"environmental disruption" as well as "human user and operator
	errors".		errors".
	A trusted system in the context of RATS "operates as expected,		A trusted system in the context of RATS "operates as expected,
	according to design and policy, doing what is required and not doing		according to design and policy, doing what is required and not doing
	other things" [RFC4949]. A trustworthy system is a system "that not		other things" [RFC4949]. A trustworthy system is a system "that not
	skipping to change at page 6, line 4 ¶		skipping to change at page 12, line 22 ¶
	roots of trust.		roots of trust.
	Roots of trust are defined by the NIST special publication 800-164		Roots of trust are defined by the NIST special publication 800-164
	draft as "security primitives composed of hardware, firmware and/or		draft as "security primitives composed of hardware, firmware and/or
	software that provide a set of trusted, security-critical functions.		software that provide a set of trusted, security-critical functions.
	They must always behave in an expected manner because their		They must always behave in an expected manner because their
	misbehavior cannot be detected. As such, RoTs need to be secured by		misbehavior cannot be detected. As such, RoTs need to be secured by
	their design. Hardware RoTs are preferred over software RoTs due to		their design. Hardware RoTs are preferred over software RoTs due to
	their immutability, smaller attack surface, and more reliable		their immutability, smaller attack surface, and more reliable
	behavior."		behavior."
	If the root of trust involved is a root of trust for measurement		If the root of trust involved is a root of trust for measurement
	(RTM), the producer of information takes on the role of a asserter.		(RTM), the producer of information takes on the role of a asserter.
	An asserter can also make use of a root of trust for integrity (RTI)		An asserter can also make use of a root of trust for integrity (RTI)
	in order to increase the level of assurance in the assertions		in order to increase the level of assurance in the assertions
	produced. If the root of trust involved is a root of trust for		produced. If the root of trust involved is a root of trust for
	reporting (RTR), the producer of information takes on the role of an		reporting (RTR), the producer of information takes on the role of an
	attester.		attester.
	2.3. Claims and Evidence		5.2. Claims and Evidence
	The RATS asserter role produces measurements about the system's		The RATS asserter role produces measurements about the system's
	characteristics in the form of signed (sometimes un-signed) claim		characteristics in the form of signed (sometimes un-signed) claim
	sets in order to convey information. A secret signing key is		sets in order to convey information. A secret signing key is
	required for this procedure, which is typically stored in a shielded		required for this procedure, which is typically stored in a shielded
	location that can be trusted, for example, via a root of trust for		location that can be trusted, for example, via a root of trust for
	storage (RTS).		storage (RTS).
	The RATS attester role produces signed attestation evidence in order		The RATS attester role produces signed attestation evidence in order
	to convey information. The secret key required for this procedure is		to convey information. The secret key required for this procedure is
	stored in a shielded location that only allows access to that key, if		stored in a shielded location that only allows access to that key, if
	a specific operational state of the system is met. The trust with		a specific operational state of the system is met. The trust with
	respect to this origination is based on a root of trust for		respect to this origination is based on a root of trust for
	reporting.		reporting.
	2.4. RATS Roles		5.3. RATS Information Flows
	There are six roles defined in the RATS architecture. iFigure 1		There are six roles defined in the RATS architecture. iFigure 2
	provides a simplified overview of the roles defined in this section.		provides a simplified overview of the RATS Roles defined above,
			illustrating a general Interconnect in the center that facilitates
			all RATS Interactions.
	+------------+ +------------------+		+------------+ +------------------+
	| | | |		| | | |
	| Attester | +->| Verifier |		| Attester | +->| Verifier |
	| | | | |		| | | | |
	+------------+ | +------------------+		+------------+ | +------------------+
	^ |		^ |
	| | +------------------+		| |
	| +----------------+ | | |		| +----------------+ |
	+---->| |<-+ | Authentication |		+---->| |<-+
	| Interconnect |<--->| Checker |		| Interconnect |
	+---->| |<-+ | |		+---->| |<-+
	| +----------------+ | +------------------+		| +----------------+ |
	v |		v |
	+------------+ | +------------------+		+------------+ | +------------------+
	| | | | |		| | | | |
	| Claimant | +->| Relying Party |		| Claimant | +->| Relying Party |
	| | | |		| | | |
	+------------+ +------------------+		+------------+ +------------------+
	Figure 1: Overall Relationships of Roles in the RATS Architecture		Figure 2: Overall Relationships of Roles in the RATS Architecture
	Attester: The producer of attestation evidence that has a root of
	trust for reporting (RTR) and implements a conveyance protocol,
	authenticates using an attestation credential, consumes assertions
	about itself and presents it to a consumer of evidence (e.g. a
	relying party or a verifier). Every output of an attester can be
	appraised via reference values.
	Claimant: The producer of measurements or assertions to certain
	properties regarding the trustworthiness of a system's
	characteristics that has a root of trust for measurement. It is
	not guaranteed that a verifier can appraise the output of a
	claimant via reference values. Examples of claim output include:
	the binding of an attester to an RTR, GPS coordinates set of
	integrity measurements, or an Universal Entity ID (UEID).
	Interconnect: A communication channel or secure path between systems
	that take on RATS roles. Attestation evidence, for example, can
	be conveyed from an attester to a verifier via an interconnect.
	Examples include: GPIO pins, an USB link, or the Internet.
	Relying Party: The consumer and assessor of verifier or
	Authentication Checker results for the purpose of improved risk
	management, operational efficiency, security, privacy (natural or
	legal person) or safety. The verifier and/or authentication
	checker roles and the relying party role may be tightly
	integrated.
	Authentication Checker: The consumer of signed assertions such as
	trusted claim sets or attestation evidence that assesses the
	trustworthiness or other trust relationships of the information
	consumed via trusted third parties or external trust authorities,
	such as a privacy certificate authority. In certain environments,
	an Authentication Checker can assess a system's trustworthiness
	via external trust anchors, implicitly.
	Verifier: The consumer of attestation evidence that has a root of
	trust for verification and implements a conveyance protocol,
	appraises attestation evidence against reference values or
	policies and makes verification results available to relying
	parties.
	2.5. Exemplary Composition of Roles		6. Exemplary Composition of Roles
	In order to provide an intuitive understanding how the roles used in		In order to provide an intuitive understanding how the roles used in
	RATS can be composed into work-flows, this document provides a few		RATS can be composed into work-flows, this document provides a few
	example work-flows. Boxes in the following examples that include		example work-flows. Boxes in the following examples that include
	more than one role are systems that take on more than one role.		more than one role are systems that take on more than one role.
	2.5.1. Conveyance of Trusted Claim Sets Validated by Signature		6.1. Conveyance of Trusted Claim Sets Validated by Signature
	If there is a trust relationship between a trusted third party that		If there is a trust relationship between a trusted third party that
	can assert that signed claims created by a claimant guarantee a		can assert that signed claims created by a claimant guarantee a
	trustworthy origination of claim, the work-flow depicted in Figure 2		trustworthy origination of claim, the work-flow depicted in Figure 3
	can facilitate a trust-based implicit remote attestation procedure.		can facilitate a trust-based implicit remote attestation procedure.
	The information conveyed are signed claim sets that are trusted via		The information conveyed are signed claim sets that are trusted via
	an authoritative third party. In this work-flow claim emission is		an authoritative third party. In this work-flow claim emission is
	triggered by the claimant. Variations based on requests emitted by		triggered by the claimant. Variations based on requests emitted by
	the relying party can be easily facilitated by the same set of roles.		the relying party can be easily facilitated by the same set of roles.
	+---------------------------------------+		+-----------+
	| |		+------------+ +----------------+ | |
	| +------------------+ +-----------+ |		| | | | | Relying |
	+------------+ +----------------+ | | | | | |		| Claimant |->| Interconnect |--->| Party |
	| | | | | | Authentication | | Relying | |		| | | | | |
	| Claimant |->| Interconnect |--+->| Checker |->| Party | |		+------------+ +----------------+ +-----------+
	| | | | | | | | | |
	+------------+ +----------------+ | +------------------+ +-----------+ |
	| |
	+---------------------------------------+
	Figure 2: Conveyance of Trusted Claim Sets Validated by Signature		Figure 3: Conveyance of Trusted Claim Sets Validated by Signature
	2.5.2. Conveyance of Attestation Evidence Appraised by a Verifier		6.2. Conveyance of Attestation Evidence Appraised by a Verifier
	If there is trust in the root of trust for reporting based on the		If there is trust in the root of trust for reporting based on the
	assertions of a trusted third party, the work-flow depicted in		assertions of a trusted third party, the work-flow depicted in
	Figure 3 can facilitate an evidence-based explicit remote attestation		Figure 4 can facilitate an evidence-based explicit remote attestation
	procedure. The information conveyed is signed attestation evidence		procedure. The information conveyed is signed attestation evidence
	that is created by the trusted verifier. In this work-flow claims do		that is created by the trusted verifier. In this work-flow claims do
	not necessarily have to be signed and the work-flow is triggered by		not necessarily have to be signed and the work-flow is triggered by
	the attestor that aggregates claims from a root of trust of		the attestor that aggregates claims from a root of trust of
	measurement. Variations based on requests emitted by the verifier		measurement. Variations based on requests emitted by the verifier
	can be easily facilitated by the same set of roles.		can be easily facilitated by the same set of roles.
	+------------------+ +------------------------+		+------------------+ +----------------------+
	| | | +------------------+ |		| | | +----------------+ |
	| +------------+ | +----------------+ | | | |		| +------------+ | +----------------+ | | | |
	| | | | | | | | Authentication | |		| | | | | | | | | |
	| | Attester |--+->| Interconnect |--+->| Checker | |		| | Attester |--+->| Interconnect |--+->| Verifier | |
	| | | | | | | | | |		| | | | | | | | | |
	| +------------+ | +----------------+ | +------------------+ |		| +------------+ | +----------------+ | +----------------+ |
	| ^ | +-------------------+ | |		| ^ | | | |
	| | | | | |		| | | | v |
	| | | | +-----------+ v |		| | | | +-----------+ |
	| +-----+------+ | | | | +------------+ |		| +-----+------+ | | | | |
	| | | | | | Relying | | | |		| | | | | | Relying | |
	| | Claimant | | | | Party |<---------| Verifier | |		| | Claimant | | | | Party | |
	| | | | | | | | | |		| | | | | | | |
	| +------------+ | | +-----------+ +------------+ |		| +------------+ | | +-----------+ |
	| | | |		| | | |
	+------------------+ +--------------------------------------------+		+------------------+ +----------------------+
	Figure 3: Conveyance of Attestation Evidence Appraised by a Verifier		Figure 4: Conveyance of Attestation Evidence Appraised by a Verifier
	2.6. The Scope of RATS		7. The Scope of RATS
	During its evolution, the term Remote Attestation has been used in		During its evolution, the term Remote Attestation has been used in
	multiple contexts and multiple scopes and in consequence accumulated		multiple contexts and multiple scopes and in consequence accumulated
	various connotations with slightly different semantic meaning.		various connotations with slightly different semantic meaning.
	Correspondingly, Remote Attestation Procedures (RATS) are employed in		Correspondingly, Remote Attestation Procedures (RATS) are employed in
	various usage scenarios and different environments.		various usage scenarios and different environments.
	In order to better understand and grasp the intent and meaning of		In order to better understand and grasp the intent and meaning of
	specific RATS in the scope of the security area - including the		specific RATS in the scope of the security area - including the
	requirements that are addressed by them - this document provides an		requirements that are addressed by them - this document provides an
	overview of existing work, its background, and common terminology.		overview of existing work, its background, and common terminology.
	As the contribution, from that state-of-the-art a set of terms that		As the contribution, from that state-of-the-art a set of terms that
	provides a stable basis for future work on RATS in the IETF is		provides a stable basis for future work on RATS in the IETF is
	derived.		derived.
	skipping to change at page 10, line 23 ¶		skipping to change at page 15, line 34 ¶
	in more complementary definitions from other SDO (e.g. Global		in more complementary definitions from other SDO (e.g. Global
	Platform, TCG, etc.) and a general structure template to highlight		Platform, TCG, etc.) and a general structure template to highlight
	semantic relationships and capable of resolving potential		semantic relationships and capable of resolving potential
	discrepancies will be introduced. A section of context awareness		discrepancies will be introduced. A section of context awareness
	will provide further insight on how Attestation procedures are vital		will provide further insight on how Attestation procedures are vital
	to ongoing work in the IETF (e.g. I2NSF & tokbind). The definitions		to ongoing work in the IETF (e.g. I2NSF & tokbind). The definitions
	in the section about RATS are still self-describing in this version.		in the section about RATS are still self-describing in this version.
	Additional explanatory text will be added to provide more context and		Additional explanatory text will be added to provide more context and
	coherence.		coherence.
	2.6.1. The Lying Endpoint Problem		7.1. The Lying Endpoint Problem
	A very prominent goal of RATS is to address the "lying endpoint		A very prominent goal of RATS is to address the "lying endpoint
	problem". The lying endpoint problem is characterized as a condition		problem". The lying endpoint problem is characterized as a condition
	of a Computing Context where the information or behavior embedded,		of a Computing Context where the information or behavior embedded,
	created, relayed, stored, or emitted by the Computing Context is not		created, relayed, stored, or emitted by the Computing Context is not
	"correct" according to expectations of the authorized system		"correct" according to expectations of the authorized system
	designers, operators and users. There can be multiple reasons why		designers, operators and users. There can be multiple reasons why
	these expectations are incorrect, either from malicious Activity,		these expectations are incorrect, either from malicious Activity,
	unanticipated conditions or accidental means. The observed behavior,		unanticipated conditions or accidental means. The observed behavior,
	nevertheless, appears to be a compromised Computing Context.		nevertheless, appears to be a compromised Computing Context.
	skipping to change at page 11, line 11 ¶		skipping to change at page 16, line 20 ¶
	installed involved in the activity of creating the emitted		installed involved in the activity of creating the emitted
	information in question, the emitted information can be considered		information in question, the emitted information can be considered
	valid and integer.		valid and integer.
	In contrast, such Evidence has to be impossible to create if the		In contrast, such Evidence has to be impossible to create if the
	software instances used in a Computing Context are compromised.		software instances used in a Computing Context are compromised.
	Attestation activities that are intended to create this Evidence		Attestation activities that are intended to create this Evidence
	therefore also provide guarantees about the validity of the Evidence		therefore also provide guarantees about the validity of the Evidence
	they can create.		they can create.
	2.6.2. How the RATS Architecture Addresses the Lying Endpoint Problem		7.1.1. How the RATS Architecture Addresses the Lying Endpoint Problem
	RATS imply the involvement of at least two players (roles) who seek		RATS imply the involvement of at least two players (roles) who seek
	to overcome the lying endpoint problem. The Verifier wishes to		to overcome the lying endpoint problem. The Verifier wishes to
	consume application data supplied by a Computing Context. But before		consume application data supplied by a Computing Context. But before
	application data is consumed, the Verifier obtains Attestation		application data is consumed, the Verifier obtains Attestation
	Evidence about the Computing Context to assess likelihood of poisoned		Evidence about the Computing Context to assess likelihood of poisoned
	data due to endpoint compromise or failure. Remote Attestation		data due to endpoint compromise or failure. Remote Attestation
	argues that a systems's integrity characteristics should not be		argues that a systems's integrity characteristics should not be
	believed until rationale for believability is presented to the		believed until rationale for believability is presented to the
	relying party seeking to interact with the system.		relying party seeking to interact with the system.
	skipping to change at page 11, line 42 ¶		skipping to change at page 17, line 5 ¶
	Attestation evidence can be thought of as the topics of the exchange		Attestation evidence can be thought of as the topics of the exchange
	that is created the operational primitives of a root of trust for		that is created the operational primitives of a root of trust for
	reporting. Evidence may be structured in an interoperable format		reporting. Evidence may be structured in an interoperable format
	called claims that may include references to the claimants which are		called claims that may include references to the claimants which are
	asserting the claims. RATS aims to define "interoperable Remote		asserting the claims. RATS aims to define "interoperable Remote
	Attestation" such that evidence can be created and consumed by		Attestation" such that evidence can be created and consumed by
	different ecosystem systems and can be securely exchanged by a broad		different ecosystem systems and can be securely exchanged by a broad
	set of network protocols.		set of network protocols.
	3. RATS Terminology		8. RATS Terminology
	This document relies on terminology found in [RFC4949]. This		This document relies on terminology found in [RFC4949]. This
	document presumes the reader is familiar with the following terms.		document presumes the reader is familiar with the following terms.
	o Cryptography		o Cryptography
	o Entity (System entity)		o Entity (System entity)
	o Identity		o Identity
	o Object		o Object
	o Principal		o Principal
	o Proof-of-possession protocol		o Proof-of-possession protocol
	o Security environment (Environment)		o Security environment (Environment)
	o Security perimeter		o Security perimeter
	skipping to change at page 12, line 38 ¶		skipping to change at page 18, line 5 ¶
	o Verification		o Verification
	Terminology defined by this document is preceded by a dollar sign ($)		Terminology defined by this document is preceded by a dollar sign ($)
	to distinguish it from terms defined elsewhere and as a way to		to distinguish it from terms defined elsewhere and as a way to
	disambiguate term definition from explanatory text.		disambiguate term definition from explanatory text.
	Terms defined by this document that are subsequently used by this		Terms defined by this document that are subsequently used by this
	document are distinguished by capitalizing the first letter of the		document are distinguished by capitalizing the first letter of the
	term (e.g. Term or First_word Second_word).		term (e.g. Term or First_word Second_word).
	3.1. Computing Context		8.1. Computing Context
	This section introduces the term Computing Context in order to		This section introduces the term Computing Context in order to
	specialize the notions of environment and endpoint to terminology		specialize the notions of environment and endpoint to terminology
	that has relevance to trusted computing. Attestation is a discipline		that has relevance to trusted computing. Attestation is a discipline
	of trusted computing.		of trusted computing.
	A Computing Context could refer to a large variety of endpoints.		A Computing Context could refer to a large variety of endpoints.
	Examples include but are not limited to: the compartmentalization of		Examples include but are not limited to: the compartmentalization of
	physical resources, the separation of software instances with		physical resources, the separation of software instances with
	different dependencies in dedicated containers, and the nesting of		different dependencies in dedicated containers, and the nesting of
	skipping to change at page 13, line 40 ¶		skipping to change at page 19, line 7 ¶
	long-term.		long-term.
	$ Computing Context : An umbrella term that combines the scope of		$ Computing Context : An umbrella term that combines the scope of
	the definitions of endpoint [ref NEA], device [ref 1ar], and thing		the definitions of endpoint [ref NEA], device [ref 1ar], and thing
	[ref t2trg], including hardware-based and software-based sub-		[ref t2trg], including hardware-based and software-based sub-
	contexts that constitute independent, isolated and distinguishable		contexts that constitute independent, isolated and distinguishable
	slices of a Computing Context created by compartmentalization		slices of a Computing Context created by compartmentalization
	mechanisms, such as Trusted Execution Environments (TEE), Hardware		mechanisms, such as Trusted Execution Environments (TEE), Hardware
	Security Modules (HSM) or Virtual Network Function (VNF) contexts.		Security Modules (HSM) or Virtual Network Function (VNF) contexts.
	3.1.1. Characteristics of a Computing Context		8.1.1. Characteristics of a Computing Context
	While the semantic relationships highlighted above constitute the		While the semantic relationships highlighted above constitute the
	fundamental basis to provide a define Computing Context, the		fundamental basis to provide a define Computing Context, the
	following list of object characteristics is intended to improve the		following list of object characteristics is intended to improve the
	application of the term and provide a better understanding of its		application of the term and provide a better understanding of its
	meaning:		meaning:
	$ Computing Context Characteristics: A representation of the		$ Computing Context Characteristics: A representation of the
	identity, composition, configuration and state of a Computing		identity, composition, configuration and state of a Computing
	Context.		Context.
	skipping to change at page 14, line 29 ¶		skipping to change at page 19, line 43 ¶
	[ref docker, find a more general term here] context is not a		[ref docker, find a more general term here] context is not a
	distinguishable isolated slice of an information system and therefore		distinguishable isolated slice of an information system and therefore
	is not an independent Computing Context. [more feedback on this		is not an independent Computing Context. [more feedback on this
	statement is required as the capabilities of docker-like functions		statement is required as the capabilities of docker-like functions
	evolve continuously]		evolve continuously]
	Examples include: a smart phone, a nested virtual machine, a		Examples include: a smart phone, a nested virtual machine, a
	virtualized firewall function running distributed on a cluster of		virtualized firewall function running distributed on a cluster of
	physical and virtual nodes, or a trust-zone.		physical and virtual nodes, or a trust-zone.
	3.1.2. Computing Context Semantic Relationships		8.1.2. Computing Context Semantic Relationships
	Computing Contexts may relate to other Computing Contexts that are		Computing Contexts may relate to other Computing Contexts that are
	decomposable in a variety of ways.		decomposable in a variety of ways.
	o Singleton,		o Singleton,
	o Tuples (e.g. 2-tuple, n-tuple),		o Tuples (e.g. 2-tuple, n-tuple),
	o Nested,		o Nested,
	o Clustered (homogeneous),		o Clustered (homogeneous),
	o Grouped (heterogenous).		o Grouped (heterogenous).
	The scope of Computing Context encompasses a broad spectrum of		The scope of Computing Context encompasses a broad spectrum of
	systems including, but not limited to:		systems including, but not limited to:
	o An information system,		o An information system,
	skipping to change at page 16, line 15 ¶		skipping to change at page 21, line 27 ¶
	A formal semantic relationship is therefore expressed using an		A formal semantic relationship is therefore expressed using an
	information model that captures interactions, relationships, bindings		information model that captures interactions, relationships, bindings
	and interfaces among systems, subsystems, system components, system		and interfaces among systems, subsystems, system components, system
	entities or objects.		entities or objects.
	[Issue: A tangible relationship to an information model is required		[Issue: A tangible relationship to an information model is required
	here] An information model that richly captures Computing Context		here] An information model that richly captures Computing Context
	semantics is therefore believed to be relevant if not fundamental to		semantics is therefore believed to be relevant if not fundamental to
	Remote Attestation.		Remote Attestation.
	3.1.3. Computing Context Identity		8.1.3. Computing Context Identity
	The identity of a Computing Context implies there is a binding		The identity of a Computing Context implies there is a binding
	operation between an identifier and the Computing Context.		operation between an identifier and the Computing Context.
	$ Computing Context Identity: Computing Context Identity provides		$ Computing Context Identity: Computing Context Identity provides
	the basis for associating attestation Evidence about a particular		the basis for associating attestation Evidence about a particular
	Computing Context to create believable knowledge about attestation		Computing Context to create believable knowledge about attestation
	provenance.		provenance.
	Confidence in the identity assurance level [NIST SP-800-63-3] or the		Confidence in the identity assurance level [NIST SP-800-63-3] or the
	assurance levels for identity authentication [RFC4949] is a property		assurance levels for identity authentication [RFC4949] is a property
	of the identifier uniqueness properties and binding operation		of the identifier uniqueness properties and binding operation
	veracity. Such properties impact the trustworthiness of associated		veracity. Such properties impact the trustworthiness of associated
	attestation Evidence.		attestation Evidence.
	3.2. Remote Attestation Concepts		8.2. Remote Attestation Concepts
	Attestation Evidence created by RATS is a form of telemetry about a		Attestation Evidence created by RATS is a form of telemetry about a
	computing environment that enables better security risk management		computing environment that enables better security risk management
	through disclosure of security properties of the environment.		through disclosure of security properties of the environment.
	Attestation may be performed locally (within the same computing		Attestation may be performed locally (within the same computing
	environment) or remotely (between different computing environments).		environment) or remotely (between different computing environments).
	The exchange of attestation evidence can be formalized to include		The exchange of attestation evidence can be formalized to include
	well-defined protocol, message syntax and semantics.		well-defined protocol, message syntax and semantics.
	3.3. Core RATS Terminology		8.3. Core RATS Terminology
	$ Attestation: The creation of evidence by the Attester based on		$ Attestation: The creation of evidence by the Attester based on
	measurements or other claimant output.		measurements or other claimant output.
	A form of telemetry involving the delivery of Claims describing		A form of telemetry involving the delivery of Claims describing
	various security properties of a Computing Context by an Attester,		various security properties of a Computing Context by an Attester,
	such that the Claims can be used as Evidence toward convincing a		such that the Claims can be used as Evidence toward convincing a
	Verifier regarding trustworthiness of the Computing Context.		Verifier regarding trustworthiness of the Computing Context.
	$ Conveyance: The transfer of Evidence from the Attester to the		$ Conveyance: The transfer of Evidence from the Attester to the
	Verifier.		Verifier.
	$ Verification: The appraisal of Evidence by the Verifier who		$ Verification: The appraisal of Evidence by the Verifier who
	evaluates it against a reference policy. See also RFC4949 [1].		evaluates it against a reference policy. See also RFC4949 [1].
	$ Remote Attestation: A procedure involving Attestation, Conveyance		$ Remote Attestation: A procedure involving Attestation, Conveyance
	and Verification.		and Verification.
	3.4. RATS Information Model Terminology		8.4. RATS Information Model Terminology
	Evidence conveyed to a Verifier by an Attester is structured to		Evidence conveyed to a Verifier by an Attester is structured to
	facilitate syntactic and semantic interoperability. An information		facilitate syntactic and semantic interoperability. An information
	model defines the tag namespaces used to create tag-value pairs		model defines the tag namespaces used to create tag-value pairs
	containing discrete bits of Evidence.		containing discrete bits of Evidence.
	$ Evidence: A set of Measurements, quality metrics, quality		$ Evidence: A set of Measurements, quality metrics, quality
	procedures or assurance criteria about an Computing Context's		procedures or assurance criteria about an Computing Context's
	behavioral, operational and intrinsic characteristics.		behavioral, operational and intrinsic characteristics.
	skipping to change at page 18, line 15 ¶		skipping to change at page 23, line 26 ¶
	$ Evidence (Claims) Creation: Instantiation of Attested Claims by a		$ Evidence (Claims) Creation: Instantiation of Attested Claims by a
	Claimant.		Claimant.
	$ Evidence (Claims) Collection: Assembling of Attested Claims by an		$ Evidence (Claims) Collection: Assembling of Attested Claims by an
	Attester for the purpose of Conveyance.		Attester for the purpose of Conveyance.
	$ Verified (Valid) Claim: An Attested Claim where the proof elements		$ Verified (Valid) Claim: An Attested Claim where the proof elements
	have been verified by a Verifier according to a policy that		have been verified by a Verifier according to a policy that
	identifies trusted Claimants and/or trusted Evidence values.		identifies trusted Claimants and/or trusted Evidence values.
	3.5. RATS Work-Flow Terminology		8.5. RATS Work-Flow Terminology
	This section introduces terms and definitions that are required to		This section introduces terms and definitions that are required to
	illustrate the scope and the granularity of RATS workflows in the		illustrate the scope and the granularity of RATS workflows in the
	domain of security automation. Terms defined in the following		domain of security automation. Terms defined in the following
	sections will be based on this workflow-related definitions.		sections will be based on this workflow-related definitions.
	In general, RATS are composed of iterative activities that can be		In general, RATS are composed of iterative activities that can be
	conducted in intervals. It is neither a generic set of actions nor		conducted in intervals. It is neither a generic set of actions nor
	simply a task, because the actual actions to be conducted by RATS can		simply a task, because the actual actions to be conducted by RATS can
	vary significantly depending on the protocols employed and types of		vary significantly depending on the protocols employed and types of
	skipping to change at page 19, line 17 ¶		skipping to change at page 24, line 30 ¶
	$ Procedure: A series of actions that are done in a certain way or		$ Procedure: A series of actions that are done in a certain way or
	order.		order.
	In the scope of RATS, a procedure is a composition of activities		In the scope of RATS, a procedure is a composition of activities
	(sequences of actions) that is intended to create a well specified		(sequences of actions) that is intended to create a well specified
	result with a well established semantic context. Example: The		result with a well established semantic context. Example: The
	activities of Attestation, Conveyance and Verification compose a		activities of Attestation, Conveyance and Verification compose a
	Remote Attestation procedure.		Remote Attestation procedure.
	3.6. RATS Reference Use Cases		8.6. RATS Reference Use Cases
	A "lying endpoint" is not trustworthy.		A "lying endpoint" is not trustworthy.
	This document provides NNN prominent examples of use cases		This document provides NNN prominent examples of use cases
	Attestation procedures are intended to address:		Attestation procedures are intended to address:
	o Verification of the source integrity of a Computing Context via		o Verification of the source integrity of a Computing Context via
	data integrity proofing of installed software instances that are		data integrity proofing of installed software instances that are
	executed, and		executed, and
	o Verification of the identity proofing of a Computing Context.		o Verification of the identity proofing of a Computing Context.
	3.6.1. Use Case A		8.6.1. Use Case A
	3.6.2. Use Case B		8.6.2. Use Case B
	3.7. RATS Reference Terminology		8.7. RATS Reference Terminology
	$ Attestable Computing Context: A Computing Context where a Claimant		$ Attestable Computing Context: A Computing Context where a Claimant
	is able to create Claims, an Attester is able to Attest those		is able to create Claims, an Attester is able to Attest those
	Claims and a Verifier is able to verify the Claims.		Claims and a Verifier is able to verify the Claims.
	$ Attestation Identity: An identity that refers to an Attester.		$ Attestation Identity: An identity that refers to an Attester.
	$ Attestation Identity Credential: A credential used to authenticate		$ Attestation Identity Credential: A credential used to authenticate
	an Attestation Identity.		an Attestation Identity.
	skipping to change at page 21, line 5 ¶		skipping to change at page 26, line 14 ¶
	$ Trustworthy Computing Context: A Computing Context that guarantees		$ Trustworthy Computing Context: A Computing Context that guarantees
	trustworthy behavior and/or composition (with respect to certain		trustworthy behavior and/or composition (with respect to certain
	declarative guidance and a scope of confidence). A trustworthy		declarative guidance and a scope of confidence). A trustworthy
	Computing Context is a trustworthy system.		Computing Context is a trustworthy system.
	<NMS: is this necessary?> Trustworthy Statement: Evidence conveyed		<NMS: is this necessary?> Trustworthy Statement: Evidence conveyed
	by a Computing Context that is not necessarily trustworthy.		by a Computing Context that is not necessarily trustworthy.
	[update with tamper related terms]		[update with tamper related terms]
	3.8. Interpretations of RFC4949 Terminology for Attestation		8.8. Interpretations of RFC4949 Terminology for Attestation
	Assurance: An attribute of an information system that provides		Assurance: An attribute of an information system that provides
	grounds for having confidence that the system operates such that		grounds for having confidence that the system operates such that
	the system's security policy is enforced [RFC4949] (see Trusted		the system's security policy is enforced [RFC4949] (see Trusted
	System below).		System below).
	In common criteria, assurance is the basis for the metric level of		In common criteria, assurance is the basis for the metric level of
	assurance, which represents the "confidence that a system's		assurance, which represents the "confidence that a system's
	principal security features are reliably implemented".		principal security features are reliably implemented".
	skipping to change at page 22, line 42 ¶		skipping to change at page 28, line 4 ¶
	of a principal.		of a principal.
	Subsystem: A collection of related system components that together		Subsystem: A collection of related system components that together
	perform a system function or deliver a system service.		perform a system function or deliver a system service.
	System Component: An instance of a system resource that (a) forms a		System Component: An instance of a system resource that (a) forms a
	physical or logical part of the system, (b) has specified		physical or logical part of the system, (b) has specified
	functions and interfaces, and (c) is extant (e.g., by policies or		functions and interfaces, and (c) is extant (e.g., by policies or
	specifications) outside of other parts of the system. (See:		specifications) outside of other parts of the system. (See:
	subsystem.)		subsystem.)
	An identifiable and self-contained part of a $Target-of-		An identifiable and self-contained part of a $Target-of-
	Evaluation.		Evaluation.
	Token: A data structure suitable for containing Claims.		Token: A data structure suitable for containing Claims.
	Trusted (Trustworthy) System: A system that operates as expected,		Trusted (Trustworthy) System: A system that operates as expected,
	according to design and policy, doing what is required - despite		according to design and policy, doing what is required - despite
	environmental disruption, human user and operator errors, and		environmental disruption, human user and operator errors, and
	attacks by hostile parties - and not doing other things.		attacks by hostile parties - and not doing other things.
	Verification: (a) The process of examining information to establish		Verification: (a) The process of examining information to establish
	the truth of a claimed fact or value.		the truth of a claimed fact or value.
	(b) The process of comparing two levels of system specification		(b) The process of comparing two levels of system specification
	for proper correspondence, such as comparing a security model with		for proper correspondence, such as comparing a security model with
	a top-level specification, a top-level specification with source		a top-level specification, a top-level specification with source
	code, or source code with object code.		code, or source code with object code.
	3.9. Building Block Vocabulary (Not in RFC4949)		8.9. Building Block Vocabulary (Not in RFC4949)
	[working title, pulled from various sources, vital]		[working title, pulled from various sources, vital]
	Attribute: TBD		Attribute: TBD
	Characteristic: TBD		Characteristic: TBD
	Context: TBD		Context: TBD
	Endpoint: TBD		Endpoint: TBD
	skipping to change at page 23, line 35 ¶		skipping to change at page 28, line 44 ¶
	Environment: TBD		Environment: TBD
	Manifest: TBD		Manifest: TBD
	Telemetry: An automated communications process by which data,		Telemetry: An automated communications process by which data,
	readings, Measurements and Evidence are collected at remote points		readings, Measurements and Evidence are collected at remote points
	and transmitted to receiving equipment for monitoring and		and transmitted to receiving equipment for monitoring and
	analysis. Derived from the Greek roots tele = remote, and metron		analysis. Derived from the Greek roots tele = remote, and metron
	= measure.		= measure.
	4. IANA considerations		9. IANA considerations
	This document will include requests to IANA:		This document will include requests to IANA:
	o first item		o first item
	o second item		o second item
	5. Security Considerations		10. Security Considerations
	There are always some.		There are always some.
	6. Acknowledgements		11. Acknowledgements
	Maybe.		Maybe.
	7. Change Log		12. Change Log
	No changes yet.		No changes yet.
	8. References		13. References
	8.1. Normative References		13.1. Normative References
	[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>.
	8.2. Informative References		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			13.2. Informative References
	[I-D.ietf-sacm-terminology]		[I-D.ietf-sacm-terminology]
	Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and		Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and
	A. Montville, "Security Automation and Continuous		A. Montville, "Security Automation and Continuous
	Monitoring (SACM) Terminology", draft-ietf-sacm-		Monitoring (SACM) Terminology", draft-ietf-sacm-
	terminology-15 (work in progress), June 2018.		terminology-16 (work in progress), December 2018.
			[I-D.mandyam-eat]
			Mandyam, G., Lundblade, L., Lundblade, L., Ballesteros,
			M., and J. O'Donoghue, "The Entity Attestation Token
			(EAT)", draft-mandyam-eat-01 (work in progress), November
			2018.
			[I-D.richardson-rats-usecases]
			Richardson, M., "Use cases for Remote Attestation common
			encodings", draft-richardson-rats-usecases-00 (work in
			progress), March 2019.
			[I-D.tschofenig-rats-psa-token]
			Tschofenig, H., Frost, S., Brossard, M., and A. Shaw,
			"Arm's Platform Security Architecture (PSA) Attestation
			Token", draft-tschofenig-rats-psa-token-00 (work in
			progress), March 2019.
	[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",		[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
	FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,		FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
	<https://www.rfc-editor.org/info/rfc4949>.		<https://www.rfc-editor.org/info/rfc4949>.
	[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,		(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
	<https://www.rfc-editor.org/info/rfc7519>.		<https://www.rfc-editor.org/info/rfc7519>.
	8.3. URIs		13.3. URIs
	[1] https://tools.ietf.org/html/rfc4949		[1] https://tools.ietf.org/html/rfc4949
	Authors' Addresses		Authors' Addresses
	Henk Birkholz		Henk Birkholz
	Fraunhofer SIT		Fraunhofer SIT
	Rheinstrasse 75		Rheinstrasse 75
	Darmstadt 64295		Darmstadt 64295
	Germany		Germany
End of changes. 69 change blocks.
	232 lines changed or deleted		513 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/