idnits 2.17.1 draft-birkholz-rats-architecture-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 12, 2019) is 1871 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'NIST SP-800-63-3' is mentioned on line 976, but not defined -- Looks like a reference, but probably isn't: '1' on line 1385 == Outdated reference: A later version (-08) exists of draft-richardson-rats-usecases-00 == Outdated reference: A later version (-22) exists of draft-tschofenig-rats-psa-token-00 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Standards Track M. Wiseman 5 Expires: September 13, 2019 GE Global Research 6 H. Tschofenig 7 ARM Ltd. 8 N. Smith 9 Intel 10 March 12, 2019 12 Architecture and Reference Terminology for Remote Attestation Procedures 13 draft-birkholz-rats-architecture-01 15 Abstract 17 Remote ATtestation ProcedureS (RATS) architecture facilitates the 18 attestation of device characteristics that, in general, are based on 19 specific trustworthiness qualities intrinsic to a device or service. 20 It includes trusted computing functionality provided by device 21 hardware and software that allows trustworthiness qualities to be 22 asserted and verified as part of, or pre-requisite to, the device's 23 normal operation. The RATS architecture maps corresponding 24 attestation functions and capabilities to specific RATS Roles. The 25 goal is to enable an appropriate conveyance of evidence about device 26 trustworthiness via network protocols. RATS Roles provide the 27 endpoint context for understanding the various interaction semantics 28 of the attestation lifecycle. The RATS architecture provides the 29 building block concepts, semantics, syntax and framework for 30 interoperable attestation while remaining hardware-agnostic. This 31 flexibility is intended to address a significant variety of use-cases 32 and scenarios involving interoperable attestation. Example usages 33 include, but are not limited to: financial transactions, voting 34 machines, critical safety systems, network equipment health, or 35 trustworthy end-user device management. Existing industry 36 attestation efforts may be helpful toward informing RATS 37 architecture. Such as: Remote Integrity VERification (RIVER), the 38 creation of Entity Attestation Tokens (EAT), software integrity 39 Measurement And ATtestation (MAAT) 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on September 13, 2019. 58 Copyright Notice 60 Copyright (c) 2019 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. What is Remote Attestation . . . . . . . . . . . . . . . 4 77 1.2. The purpose of RATS Architecture and Terminology . . . . 4 78 1.3. Requirements notation . . . . . . . . . . . . . . . . . . 4 79 2. RATS Architecture . . . . . . . . . . . . . . . . . . . . . . 4 80 3. Architectural Components . . . . . . . . . . . . . . . . . . 5 81 3.1. RATS Roles . . . . . . . . . . . . . . . . . . . . . . . 5 82 4. RATS Actors . . . . . . . . . . . . . . . . . . . . . . . . . 6 83 4.1. RATS Duties . . . . . . . . . . . . . . . . . . . . . . . 7 84 4.1.1. Attester Duties . . . . . . . . . . . . . . . . . . . 8 85 4.1.2. Verifier Duties . . . . . . . . . . . . . . . . . . . 8 86 4.1.3. Claimant Duties . . . . . . . . . . . . . . . . . . . 8 87 4.1.4. Relying Party Duties . . . . . . . . . . . . . . . . 8 88 4.1.5. RATS Interactions . . . . . . . . . . . . . . . . . . 9 89 5. Application of RATS . . . . . . . . . . . . . . . . . . . . . 10 90 5.1. Trust and Trustworthiness . . . . . . . . . . . . . . . . 11 91 5.2. Claims and Evidence . . . . . . . . . . . . . . . . . . . 12 92 5.3. RATS Information Flows . . . . . . . . . . . . . . . . . 12 93 6. Exemplary Composition of Roles . . . . . . . . . . . . . . . 13 94 6.1. Conveyance of Trusted Claim Sets Validated by Signature . 13 95 6.2. Conveyance of Attestation Evidence Appraised by a 96 Verifier . . . . . . . . . . . . . . . . . . . . . . . . 14 97 7. The Scope of RATS . . . . . . . . . . . . . . . . . . . . . . 14 98 7.1. The Lying Endpoint Problem . . . . . . . . . . . . . . . 15 99 7.1.1. How the RATS Architecture Addresses the Lying 100 Endpoint Problem . . . . . . . . . . . . . . . . . . 16 101 8. RATS Terminology . . . . . . . . . . . . . . . . . . . . . . 17 102 8.1. Computing Context . . . . . . . . . . . . . . . . . . . . 18 103 8.1.1. Characteristics of a Computing Context . . . . . . . 19 104 8.1.2. Computing Context Semantic Relationships . . . . . . 19 105 8.1.3. Computing Context Identity . . . . . . . . . . . . . 21 106 8.2. Remote Attestation Concepts . . . . . . . . . . . . . . . 21 107 8.3. Core RATS Terminology . . . . . . . . . . . . . . . . . . 22 108 8.4. RATS Information Model Terminology . . . . . . . . . . . 22 109 8.5. RATS Work-Flow Terminology . . . . . . . . . . . . . . . 23 110 8.6. RATS Reference Use Cases . . . . . . . . . . . . . . . . 24 111 8.6.1. Use Case A . . . . . . . . . . . . . . . . . . . . . 24 112 8.6.2. Use Case B . . . . . . . . . . . . . . . . . . . . . 24 113 8.7. RATS Reference Terminology . . . . . . . . . . . . . . . 24 114 8.8. Interpretations of RFC4949 Terminology for Attestation . 26 115 8.9. Building Block Vocabulary (Not in RFC4949) . . . . . . . 28 116 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 28 117 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 118 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 119 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 29 120 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 121 13.1. Normative References . . . . . . . . . . . . . . . . . . 29 122 13.2. Informative References . . . . . . . . . . . . . . . . . 29 123 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 126 1. Introduction 128 In general, this document provides normative guidance how to use, 129 create or adopt network protocols that facilitate remote attestation 130 procedures. The RATS Architecture anticipates broad deployment 131 contexts that range from IoT to Cloud and Edge ecosystems. The 132 foundation of the RATS architecture is the specification of RATS 133 Roles that can be chained via RATS Interactions and - as a result - 134 may be composed into use-case specific Remote Attestation Procedures. 135 RATS Actors establish an ecosystem neutral context where RATS Roles 136 are hosted and where a variety of Remote Attestation Procedure 137 interactions are defined independent of specific conveyance protocols 138 or message formats. In summary, the goal of the RATS Architecture is 139 to enable interoperable interaction between the RATS Roles. Hence, 140 the RATS Architecture is designed to enable interoperability via 141 well-defined semantics of the information model (attestation 142 assertions/claims), associated with RATS Roles following a conveyance 143 model (RATS Interactions) that may be used to compose domain-specific 144 remote attestation solutions. 146 1.1. What is Remote Attestation 148 Unfortunately, the term Attestation itself is an overloaded term. In 149 consequence, the term Remote Attestation covers a spectrum of 150 meanings. The common denominator encompasses the creation, 151 conveyance, and appraisal of evidence pertaining to the 152 trustworthiness characteristics of the creator of the evidence. In 153 essence, RATS are used to enable the assessment of the 154 trustworthiness of a communication partner. 156 1.2. The purpose of RATS Architecture and Terminology 158 To consolidate the utilization of existing and emerging network 159 protocols in the context of RATS, this document provides a detailed 160 definition of Attestation Terminology that enables interoperability 161 between different types pf RATS. Specifically, this document 162 illustrates and remediates the impedance mismatch of terms related to 163 Remote Attestation Procedures used in different domains today. As an 164 additional contribution, new terms defined by this document provide a 165 common basis that simplifies future work on RATS in the IETF and 166 beyond. 168 1.3. Requirements notation 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 172 "OPTIONAL" in this document are to be interpreted as described in 173 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 174 capitals, as shown here. 176 2. RATS Architecture 178 One of the goals of the RATS Architecture is to provide the building 179 blocks - the roles defined by the RATS Architecture - to enable the 180 composition of service-chains/hierarchies and work-flows that can 181 create and appraise evidence about the trustworthiness of devices and 182 services. 184 The RATS Architecture is based on the use-cases defined in 185 [I-D.richardson-rats-usecases]. 187 The RATS architecture specifies: 189 o The building blocks to create remote attestation procedures 190 applicable Actors, Roles, Duties, and Interactions, 192 o Mandatory and optional trust relationships between its Roles, that 193 may assume a Root-of-Trust context, 195 o The interaction between Roles that reside on separate Actors and 196 interact via network protocols, 198 o Protocol/message framing that allows for well-defined and opaque 199 payloads, 201 o The means to prove, preserve and convey trust properties, such as 202 identity, varacity, freshness, or provenance, and 204 o Primitives necessary for the construction of interoperable 205 attestation payloads. 207 3. Architectural Components 209 The basic architectural components defined in this document are: 211 o RATS Roles 213 o RATS Actors 215 o RATS Duties 217 o RATS Interactions 219 The following sub-section define and elaborate on these terms: 221 3.1. RATS Roles 223 A Role in the context of usage scenarios for remote attestation 224 procedures is providing a service to other Roles. Roles are building 225 blocks that can be providers and consumers of information. In the 226 RATS architecture, devices or services can take on RATS roles. They 227 are composites of internal functions (RATS Duties) and external 228 functions (RATS Interactions) that facilitate a required (sometimes 229 optional) task in a remote attestation procedure. 231 The base set of RATS roles is: 233 Claimant: The producer of trustworthiness assertions pertaining to 234 an Attester; that may or not have a root-of-trust for measurement. 236 It is not guaranteed that a Verifier Role can appraise the output 237 of a Claimant via reference values (in contrast to the output of 238 an Attester). 240 Examples of Claimant assertions include: * The hardware, firmware 241 and software components of the Attester. * The manufactuer of 242 Attester components. * The Attester's current configuration. * 243 The Attester's current location - e.g. GPS coordinates. * The 244 method by which binding of an attester to an RTR. * The 245 identifier(s) available for identifying and authenticating the 246 Attester - e.g. Universal Entity ID (UEID). 248 Typically, claimant role are taken on by RATS Actors that supply 249 chain entities (SCE). Various assertions (often represented as 250 Claims or Trusted Claims Sets, e.g. [I-D.mandyam-eat] or 251 [I-D.tschofenig-rats-psa-token]). 253 Attester: The producer of attestation evidence that has a root of 254 trust for reporting (RTR) and implements a conveyance protocol, 255 authenticates using an attestation credential, consumes assertions 256 about itself and presents it to a consumer of evidence (e.g. a 257 relying party or a verifier). Every output of an attester can be 258 appraised via reference values. 260 Authentication Checker: The consumer of signed assertions such as 261 trusted claim sets or attestation evidence that assesses the 262 trustworthiness or other trust relationships of the information 263 consumed via trusted third parties or external trust authorities, 264 such as a privacy certificate authority. In certain environments, 265 an Authentication Checker can assess a system's trustworthiness 266 via external trust anchors, implicitly. 268 Verifier: The consumer of attestation evidence that has a root of 269 trust for verification (RTV), implements conveyance protocols, 270 appraises attestation evidence against reference values or 271 policies, and makes verification results available to relying 272 parties. 274 Relying Party: The consumer and assessor of verifier or 275 Authentication Checker results for the purpose of improved risk 276 management, operational efficiency, security, privacy (natural or 277 legal person) or safety. The verifier and/or authentication 278 checker roles and the relying party role may be tightly 279 integrated. 281 4. RATS Actors 283 RATS Actors may be any entity, such as an user, organization, 284 execution environment, device or service provider, that takes on 285 (implements) one or more RATS Roles and performs RATS Duties and/or 286 RATS Interactions. RATS Interactions occur between RATS Actors. The 287 methods whereby RATS Actors are identified, discovered, and 288 connectivity established are out-of-scope for this architecture. In 289 contrast, if multiple RATS Roles reside on a single RATS Actor, the 290 definition of RATS Interactions is out-of-scope of the RATS 291 architecture, if no network protocols are required. 293 +------------------+ +------------------+ 294 | Actor 1 | | Actor 2 | 295 | +------------+ | | +------------+ | 296 | | | | | | | | 297 | | Role 1 |<-|---|->| Role 2 | | 298 | | | | | | | | 299 | +------------+ | | +------------+ | 300 | | | | 301 | +-----+------+ | | +-----+------+ | 302 | | | | | | | | 303 | | Role 2 |<-|---|->| Role 3 | | 304 | | | | | | | | 305 | +------------+ | | +------------+ | 306 | | | | 307 +------------------+ +------------------+ 309 Figure 1: RATS Actor-Role Interactions 311 RATS Actors have the following properties: * Multiplicity - Multiple 312 instances of RATS Actors that possess the same RATS Roles can exist. 313 * Decomposability - A singleton RATS Actor possessing multiple RATS 314 Roles can be separated into multiple RATS Actors. RATS Interactions 315 may occur between them. * Composablility - RATS Actors possessing 316 different RATS Roles can be combined into a singleton RATS Actor 317 possessing the union of RATS Roles. RATS Interactions between 318 combined RATS Actors ceases. 320 Interactions between RATS Roles belonging to the same RATS Actor are 321 generally believed to be uninteresting. Actor operations that apply 322 resiliency, scaling, load balancing or replication are generally 323 believed to be uninteresting. 325 4.1. RATS Duties 327 A RATS Role can take on one ore more duties. RATS Duties are role- 328 internal functions that do not require interaction with other RATS 329 Roles. In general, and RATS Duties are typically associated with a 330 RATS Role. The list presented in this document is exhaustive. Also, 331 there can be usage scenario where RATS Duties are associated with 332 other RATS Roles than illustrated below: 334 4.1.1. Attester Duties 336 o Acquisition or collection of assertions about itself 338 o Provide or create proof that an assertion is bound to the Attester 340 o Create Evidence from assertion bundles via roots-of-trust 342 4.1.2. Verifier Duties 344 o Acquisition and storage of assertion semantics 346 o Acquisition and storage of appraisal policies 348 o Verification of Attester Identity (attestation provenance) 350 o Comparing assertions or evidence with reference values according 351 to appraisal policies 353 o Validate authentication information based on public keys, 354 signatures, secrets that are shielded, or secrets that are access 355 restricted via protection profiles 357 4.1.3. Claimant Duties 359 o Hardens the device or service that implements the Attester role 361 o Provisions device identities and/or key material accessible to the 362 Attester role 364 o Evaluates trustworthiness during manufacturing, supply chain and 365 onboarding 367 o Produces trustworthiness assertions applicable to the Attestor 368 role 370 o Embeds trustworthiness assertions about the Attester role in the 371 device or service during manufacturing, supply chain or onboarding 373 4.1.4. Relying Party Duties 375 o Evaluate assertions/evidence locally as far as possible 377 o Compare trust policies to attestation-results based on assertions 378 or evidence 380 o Enforce policies or create input for risk engines 382 4.1.5. RATS Interactions 384 The flow of information between RATS Roles located on RATS Actors 385 compose individual remote attestation procedures. The RATS 386 Architecture provides a set of standard interactions between the RATS 387 Roles defined in this document in order to enable this composability. 388 In this section, common interactions between roles are specified. 389 This list of interactions is not exhaustive, but provides the basis 390 to create various standard RATS. 392 Every RATS Interaction specified below is based on the information 393 flow between two RATS Roles defined above. Every RATS Interaction is 394 conducted via an Interconnect between corresponding RATS Roles that 395 RATS Actors take on. If more than one RATS Role resides on the same 396 RATS Actor, a network protocol might not be required. If RATS Roles 397 are collapsed into a singular RATS Actor in this way, the method of 398 conveying information is out-of-scope of this document. If network 399 protocols are used to convey corresponding information between RATS 400 Roles (collapsed on a singular RATS Actor or not), the definitions 401 and requirements defined in this document apply. 403 In essence, an Interconnect is an abstract "distance-less" channel 404 between RATS Actors that can range from General Purpose Input Output 405 (GPIO) interfaces to the Internet. 407 Attester/Verifier: The most basic RATS interaction is between the 408 creator of evidence (Attester) and its complementary remote 409 attestation service (Verifier). In order to convey evidence (or 410 assertions that are not accompanied by a proof of their validity) 411 this RATS Interaction is required. 413 Attester/Relying-Party: A Relying Party typically requires external 414 help to either validate authentication information or to appraise 415 evidence presented by an Attester. In most cases, a Relying Party 416 requires a corresponding Verifier to process the assertions/ 417 evidence received. In consequence, (a subset of) the information 418 received by an Attester must be relayed securely to a Verifier. 420 Relying-Party/Verifier: Typically, trusted assertions or evidence 421 are conveyed from an Attester to a Relying Party. In an open 422 ecosystem, such as the Internet, the appraisal of the evidence 423 presented by an Attester provided in order to assess its 424 trustworthiness requires a remote attestation service. Hence, 425 either the RATS roles of Verifier and Relying Party are collapsed 426 and compose a single RATS Actor, or - if they reside on separate 427 RATS Actors - a Relying Party requires appropriate configuration 428 or a discovery/join/rendezvous service to initiate a RATS 429 Interaction with an appropriate and trusted Verifier. 431 Attestation information originating from an Attester that is 432 relayed via a Relying Party must be protected from replay or relay 433 attacks, accordingly. In a closed ecosystem, trustworthiness with 434 respect to the Attester can be achieved via a simply query to the 435 Verifier. In an open ecosystem, the information conveyed in this 436 interaction can include integrity measurements of every 437 distinguishable software component that has been executed since 438 its last boot cycle. 440 In the scope of RATS, this interaction encompasses the largest 441 variety of information conveyed. 443 Claimant/Verifier: The intended operational state an Attester is 444 intended to be in, is defined by the supply chain entities that 445 manufacture and maintain the Attestor. In order to appraise 446 trusted assertions or evidence conveyed by the Attester, every 447 distinguishable system component the Attester is composed of can 448 provide trusted assertions or evidence about its trustworthiness. 449 A corresponding verifier that is tasked with assessing the 450 trustworthiness of the Attester potentially requires a multitude 451 of sources of reference values according to policies and the 452 information provided. As Relying Parties often have to discover 453 an appropriate Verifier, a Verifier has to obtain and potentially 454 store appropriate reference values in order to asses assertions or 455 evidence about trustworthiness. 457 Claimant/Attester: To enable RATS, trustworthy assertions have to be 458 embedded in an Attester by its manufactorer. In some cases this 459 involves various types of roots of trust. In other cases shielded 460 pre-master secrets in combination with key derivation functions 461 (KDF) provide this binding of trusted information to an Attester. 462 A supply chain entity can embed additional trusted assertions to 463 an Attester. These assertion can also be used to assert the 464 trustworthiness on behalf of a separate RATS Actor or they can 465 originate from an external entity (e.g. a security certification 466 authority). 468 5. Application of RATS 470 Attester are typically composite devices (in the case of atomically 471 integrated devices that would result in a composite device with one 472 component) or services. Services are software components - e.g. a 473 daemon, a virtual network function (vnf) or a network security 474 function (nsf) - that can reside on one or more Attester and are not 475 necessarily bound to a specific set of hardware devices. 477 Relevant decision-factors that influence the composition of RATS 478 Roles on RATS Actors, which result in specific work-flows are 479 (amongst others): 481 o which RATS Role (or correspondingly, which RATS Actore that is 482 taking on specific RATS roles) is triggering a Remote Attestation 483 Procedure 485 o which entities are involved in a Remote Attestation Procedure 486 (e.g. the Attester itself, trusted third parties, specific trust 487 anchors, or other sources of assertions) 489 o the capabilities of the protocols used (e.g. challenge-response 490 based, RESTful, or uni-directional) 492 o the security requirements and security capabilities of systems in 493 a domain of application 495 o the risks and corresponding threats that are intended to be 496 mitigated 498 5.1. Trust and Trustworthiness 500 [RFC4949] provides definitions that highlight the difference between 501 a "trusted system" and a "trustworthy system". The following 502 definitions exclude the explicit specialization of concepts that are 503 "environmental disruption" as well as "human user and operator 504 errors". 506 A trusted system in the context of RATS "operates as expected, 507 according to design and policy, doing what is required and not doing 508 other things" [RFC4949]. A trustworthy system is a system "that not 509 only is trusted, but also warrants that trust because the system's 510 behavior can be validated in some convincing way, such as through 511 formal analysis or code review" [RFC4949]. 513 The goal of RATS is to convey information about system component 514 characteristics, such as integrity or authenticity, that can be 515 appraised in a convincing way. 517 RATS require trust relationships with third parties that qualify 518 assertions about, for example, origin of data, the manufacturer or 519 the capabilities of a system, or the origination of attestation 520 evidence (attestation provenance). Without trusted authorities (e.g. 521 a certificate authority) it is virtually impossible to assess the 522 level of assurance (or resulting level of confidence, 523 correspondingly) of information produced by RATS. Trusting a system 524 does not make it trustworthy. Assessing trustworthiness requires the 525 conveyance of evidence that a system is a trustworthy system, which 526 has to originate from the system itself and has to be convincing. If 527 the convincing information is not originating from the system itself, 528 it comprises trusted claim sets and not evidence. In essence, the 529 attestation provenance of attestation evidence is the system that 530 intends to present its trustworthiness in a believable manner. 532 The essential basis for trust in the information created via RATS are 533 roots of trust. 535 Roots of trust are defined by the NIST special publication 800-164 536 draft as "security primitives composed of hardware, firmware and/or 537 software that provide a set of trusted, security-critical functions. 538 They must always behave in an expected manner because their 539 misbehavior cannot be detected. As such, RoTs need to be secured by 540 their design. Hardware RoTs are preferred over software RoTs due to 541 their immutability, smaller attack surface, and more reliable 542 behavior." 544 If the root of trust involved is a root of trust for measurement 545 (RTM), the producer of information takes on the role of a asserter. 546 An asserter can also make use of a root of trust for integrity (RTI) 547 in order to increase the level of assurance in the assertions 548 produced. If the root of trust involved is a root of trust for 549 reporting (RTR), the producer of information takes on the role of an 550 attester. 552 5.2. Claims and Evidence 554 The RATS asserter role produces measurements about the system's 555 characteristics in the form of signed (sometimes un-signed) claim 556 sets in order to convey information. A secret signing key is 557 required for this procedure, which is typically stored in a shielded 558 location that can be trusted, for example, via a root of trust for 559 storage (RTS). 561 The RATS attester role produces signed attestation evidence in order 562 to convey information. The secret key required for this procedure is 563 stored in a shielded location that only allows access to that key, if 564 a specific operational state of the system is met. The trust with 565 respect to this origination is based on a root of trust for 566 reporting. 568 5.3. RATS Information Flows 570 There are six roles defined in the RATS architecture. iFigure 2 571 provides a simplified overview of the RATS Roles defined above, 572 illustrating a general Interconnect in the center that facilitates 573 all RATS Interactions. 575 +------------+ +------------------+ 576 | | | | 577 | Attester | +->| Verifier | 578 | | | | | 579 +------------+ | +------------------+ 580 ^ | 581 | | 582 | +----------------+ | 583 +---->| |<-+ 584 | Interconnect | 585 +---->| |<-+ 586 | +----------------+ | 587 v | 588 +------------+ | +------------------+ 589 | | | | | 590 | Claimant | +->| Relying Party | 591 | | | | 592 +------------+ +------------------+ 594 Figure 2: Overall Relationships of Roles in the RATS Architecture 596 6. Exemplary Composition of Roles 598 In order to provide an intuitive understanding how the roles used in 599 RATS can be composed into work-flows, this document provides a few 600 example work-flows. Boxes in the following examples that include 601 more than one role are systems that take on more than one role. 603 6.1. Conveyance of Trusted Claim Sets Validated by Signature 605 If there is a trust relationship between a trusted third party that 606 can assert that signed claims created by a claimant guarantee a 607 trustworthy origination of claim, the work-flow depicted in Figure 3 608 can facilitate a trust-based implicit remote attestation procedure. 609 The information conveyed are signed claim sets that are trusted via 610 an authoritative third party. In this work-flow claim emission is 611 triggered by the claimant. Variations based on requests emitted by 612 the relying party can be easily facilitated by the same set of roles. 614 +-----------+ 615 +------------+ +----------------+ | | 616 | | | | | Relying | 617 | Claimant |->| Interconnect |--->| Party | 618 | | | | | | 619 +------------+ +----------------+ +-----------+ 621 Figure 3: Conveyance of Trusted Claim Sets Validated by Signature 623 6.2. Conveyance of Attestation Evidence Appraised by a Verifier 625 If there is trust in the root of trust for reporting based on the 626 assertions of a trusted third party, the work-flow depicted in 627 Figure 4 can facilitate an evidence-based explicit remote attestation 628 procedure. The information conveyed is signed attestation evidence 629 that is created by the trusted verifier. In this work-flow claims do 630 not necessarily have to be signed and the work-flow is triggered by 631 the attestor that aggregates claims from a root of trust of 632 measurement. Variations based on requests emitted by the verifier 633 can be easily facilitated by the same set of roles. 635 +------------------+ +----------------------+ 636 | | | +----------------+ | 637 | +------------+ | +----------------+ | | | | 638 | | | | | | | | | | 639 | | Attester |--+->| Interconnect |--+->| Verifier | | 640 | | | | | | | | | | 641 | +------------+ | +----------------+ | +----------------+ | 642 | ^ | | | | 643 | | | | v | 644 | | | | +-----------+ | 645 | +-----+------+ | | | | | 646 | | | | | | Relying | | 647 | | Claimant | | | | Party | | 648 | | | | | | | | 649 | +------------+ | | +-----------+ | 650 | | | | 651 +------------------+ +----------------------+ 653 Figure 4: Conveyance of Attestation Evidence Appraised by a Verifier 655 7. The Scope of RATS 657 During its evolution, the term Remote Attestation has been used in 658 multiple contexts and multiple scopes and in consequence accumulated 659 various connotations with slightly different semantic meaning. 661 Correspondingly, Remote Attestation Procedures (RATS) are employed in 662 various usage scenarios and different environments. 664 In order to better understand and grasp the intent and meaning of 665 specific RATS in the scope of the security area - including the 666 requirements that are addressed by them - this document provides an 667 overview of existing work, its background, and common terminology. 668 As the contribution, from that state-of-the-art a set of terms that 669 provides a stable basis for future work on RATS in the IETF is 670 derived. 672 In essence, a prerequisite for providing an adequate set of terms and 673 definitions for the RATS architecute is a general understanding and a 674 common definitions of "what" RATS can accomplish "how" RATS can to be 675 used. 677 Please note that this section is still missing various references and 678 is considered "under construction". The majority of definitions is 679 still only originating from IETF work. Future iterations will pull 680 in more complementary definitions from other SDO (e.g. Global 681 Platform, TCG, etc.) and a general structure template to highlight 682 semantic relationships and capable of resolving potential 683 discrepancies will be introduced. A section of context awareness 684 will provide further insight on how Attestation procedures are vital 685 to ongoing work in the IETF (e.g. I2NSF & tokbind). The definitions 686 in the section about RATS are still self-describing in this version. 687 Additional explanatory text will be added to provide more context and 688 coherence. 690 7.1. The Lying Endpoint Problem 692 A very prominent goal of RATS is to address the "lying endpoint 693 problem". The lying endpoint problem is characterized as a condition 694 of a Computing Context where the information or behavior embedded, 695 created, relayed, stored, or emitted by the Computing Context is not 696 "correct" according to expectations of the authorized system 697 designers, operators and users. There can be multiple reasons why 698 these expectations are incorrect, either from malicious Activity, 699 unanticipated conditions or accidental means. The observed behavior, 700 nevertheless, appears to be a compromised Computing Context. 702 Attempts to "scrub" the data or "proxy" control elements implies the 703 existence of a more fundamental trusted endpoint that is operating 704 correctly. Therefore, Remote Attestation - the technology designed 705 to detect and mitigate the "lying endpoint problem" - must be trusted 706 to behave correctly independent of other controls. 708 Consequently, a "lying endpoint" cannot also be a "trusted system". 710 Remote Attestation procedures are intended to enable the consumer of 711 information emitted by a Computing Context to assess the validity and 712 integrity of the information transferred. The approach is based, for 713 example, on the assumption that if attestation evidence can be 714 provided in order to prove the integrity of every software instance 715 installed involved in the activity of creating the emitted 716 information in question, the emitted information can be considered 717 valid and integer. 719 In contrast, such Evidence has to be impossible to create if the 720 software instances used in a Computing Context are compromised. 721 Attestation activities that are intended to create this Evidence 722 therefore also provide guarantees about the validity of the Evidence 723 they can create. 725 7.1.1. How the RATS Architecture Addresses the Lying Endpoint Problem 727 RATS imply the involvement of at least two players (roles) who seek 728 to overcome the lying endpoint problem. The Verifier wishes to 729 consume application data supplied by a Computing Context. But before 730 application data is consumed, the Verifier obtains Attestation 731 Evidence about the Computing Context to assess likelihood of poisoned 732 data due to endpoint compromise or failure. Remote Attestation 733 argues that a systems's integrity characteristics should not be 734 believed until rationale for believability is presented to the 735 relying party seeking to interact with the system. 737 An Interconnect defines an untrusted channel between subject and 738 object wherein the rationale for believability is securely exchanged. 739 The type of interconnect technology could vary widely, ranging from 740 GPIO pins, to a PC peripheral IO bus, to the Internet, to a direct 741 physical connection, to a wireless radio-receiver association, or to 742 a world wide mesh of peers. In other words, virtually every kind 743 communication path could be used as the "Interconnect" in RATS. In 744 fact, a single party could take on all roles at the same time (e.g. 745 Self Encrypting Devices). 747 Attestation evidence can be thought of as the topics of the exchange 748 that is created the operational primitives of a root of trust for 749 reporting. Evidence may be structured in an interoperable format 750 called claims that may include references to the claimants which are 751 asserting the claims. RATS aims to define "interoperable Remote 752 Attestation" such that evidence can be created and consumed by 753 different ecosystem systems and can be securely exchanged by a broad 754 set of network protocols. 756 8. RATS Terminology 758 This document relies on terminology found in [RFC4949]. This 759 document presumes the reader is familiar with the following terms. 761 o Cryptography 763 o Entity (System entity) 765 o Identity 767 o Object 769 o Principal 771 o Proof-of-possession protocol 773 o Security environment (Environment) 775 o Security perimeter 777 o Subject 779 o Subsystem 781 o System 783 o Target-of-Evaluation (TOE) 785 o Trusted Computing Base (TCB) 787 o Trusted Platform Module (TPM) 789 o Trusted (Trustworthy) system 791 o Verification 793 Terminology defined by this document is preceded by a dollar sign ($) 794 to distinguish it from terms defined elsewhere and as a way to 795 disambiguate term definition from explanatory text. 797 Terms defined by this document that are subsequently used by this 798 document are distinguished by capitalizing the first letter of the 799 term (e.g. Term or First_word Second_word). 801 8.1. Computing Context 803 This section introduces the term Computing Context in order to 804 specialize the notions of environment and endpoint to terminology 805 that has relevance to trusted computing. Attestation is a discipline 806 of trusted computing. 808 A Computing Context could refer to a large variety of endpoints. 809 Examples include but are not limited to: the compartmentalization of 810 physical resources, the separation of software instances with 811 different dependencies in dedicated containers, and the nesting of 812 virtual components via hardware-based and software-based solutions. 813 The number of approaches and techniques to construct an endpoint 814 continuously changes with new innovation. Hence, it isn't a goal of 815 this document to define remote attestation for a fixed set of 816 endpoints. Rather, it attempts to define endpoints conceptually and 817 rely on Claims management as a way to clarify the details and 818 specific attributes of conceptual endpoints. 820 Computing Contexts may be recursive in nature in that it could be 821 composed of a system that is itself a composite of subsystems. In 822 consequence, a system may be composed of other systems that may be 823 further composed of one or more Computing Contexts capable of taking 824 on the RATS roles. The scope and application of these roles can 825 range from: 827 o Continuous mutual Attestation procedures of every subsystem inside 828 a composite device, to 830 o Sporadic Remote Attestation of unknown parties via heterogeneous 831 Interconnects. 833 Analogously, the increasing number of features and functions that 834 constitute components of a device start to blur the lines that are 835 required to categorize each solution and approach precisely. To 836 address this increasingly challenging categorization, the term 837 Computing Context defines the characteristics of the (sub)systems 838 that can take on the role of an Attester and/or the role of a 839 Verifier. This approach is intended to provide a stable basis of 840 definitions for future solutions that continuous to remain viable 841 long-term. 843 $ Computing Context : An umbrella term that combines the scope of 844 the definitions of endpoint [ref NEA], device [ref 1ar], and thing 845 [ref t2trg], including hardware-based and software-based sub- 846 contexts that constitute independent, isolated and distinguishable 847 slices of a Computing Context created by compartmentalization 848 mechanisms, such as Trusted Execution Environments (TEE), Hardware 849 Security Modules (HSM) or Virtual Network Function (VNF) contexts. 851 8.1.1. Characteristics of a Computing Context 853 While the semantic relationships highlighted above constitute the 854 fundamental basis to provide a define Computing Context, the 855 following list of object characteristics is intended to improve the 856 application of the term and provide a better understanding of its 857 meaning: 859 $ Computing Context Characteristics: A representation of the 860 identity, composition, configuration and state of a Computing 861 Context. 863 Computing context characteristics provide the following: * An 864 independent environment in regard to executing and running 865 software, * An isolated control plane state (by potentially 866 interacting with other Computing Contexts), * A dedicated 867 management interface by which control plane behavior can be 868 effected, * Unique identification towards reliable disambiguation 869 within a given scope. 871 Computing context characteristics do not necessarily include a 872 network interface with associated network addresses (as required by 873 the definition of an endpoint) - although it is very likely to have 874 (access to) one. 876 [Issue: This conclusion could be incorrect] In contrast, a container 877 [ref docker, find a more general term here] context is not a 878 distinguishable isolated slice of an information system and therefore 879 is not an independent Computing Context. [more feedback on this 880 statement is required as the capabilities of docker-like functions 881 evolve continuously] 883 Examples include: a smart phone, a nested virtual machine, a 884 virtualized firewall function running distributed on a cluster of 885 physical and virtual nodes, or a trust-zone. 887 8.1.2. Computing Context Semantic Relationships 889 Computing Contexts may relate to other Computing Contexts that are 890 decomposable in a variety of ways. 892 o Singleton, 894 o Tuples (e.g. 2-tuple, n-tuple), 895 o Nested, 897 o Clustered (homogeneous), 899 o Grouped (heterogenous). 901 The scope of Computing Context encompasses a broad spectrum of 902 systems including, but not limited to: 904 o An information system, 906 o An object, 908 o A composition of objects, 910 o A system component, 912 o A system sub-component, 914 o A composition of system sub-components, 916 o A system entity, 918 o A composition of system entities. 920 A Computing Context may be realized in a variety of ways including, 921 but not limited to: 923 o A process, thread or task as defined by an operating system, 925 o A privileged operating system task, interrupt handler or event 926 handler, 928 o A virtual machine, 930 o A virtual machine monitor, 932 o A processor mode (e.g. system management mode), 934 o A co-processor, 936 o A peripheral device, 938 o A secure element, 940 o A trusted execution environment, 942 o A controller, sensor, actutor, switch, router or gateway, 943 o An FPGA, 945 o An ASIC, 947 o A memory resource, 949 o A storage resource. 951 Analogously, a computing sub-context is a decomposition of a 952 Computing Context; a subsystem is a decomposition of a system; a sub- 953 component is a decomposition of a component; and a peer node is a 954 decomposition of a node cluster. 956 A formal semantic relationship is therefore expressed using an 957 information model that captures interactions, relationships, bindings 958 and interfaces among systems, subsystems, system components, system 959 entities or objects. 961 [Issue: A tangible relationship to an information model is required 962 here] An information model that richly captures Computing Context 963 semantics is therefore believed to be relevant if not fundamental to 964 Remote Attestation. 966 8.1.3. Computing Context Identity 968 The identity of a Computing Context implies there is a binding 969 operation between an identifier and the Computing Context. 971 $ Computing Context Identity: Computing Context Identity provides 972 the basis for associating attestation Evidence about a particular 973 Computing Context to create believable knowledge about attestation 974 provenance. 976 Confidence in the identity assurance level [NIST SP-800-63-3] or the 977 assurance levels for identity authentication [RFC4949] is a property 978 of the identifier uniqueness properties and binding operation 979 veracity. Such properties impact the trustworthiness of associated 980 attestation Evidence. 982 8.2. Remote Attestation Concepts 984 Attestation Evidence created by RATS is a form of telemetry about a 985 computing environment that enables better security risk management 986 through disclosure of security properties of the environment. 987 Attestation may be performed locally (within the same computing 988 environment) or remotely (between different computing environments). 989 The exchange of attestation evidence can be formalized to include 990 well-defined protocol, message syntax and semantics. 992 8.3. Core RATS Terminology 994 $ Attestation: The creation of evidence by the Attester based on 995 measurements or other claimant output. 997 A form of telemetry involving the delivery of Claims describing 998 various security properties of a Computing Context by an Attester, 999 such that the Claims can be used as Evidence toward convincing a 1000 Verifier regarding trustworthiness of the Computing Context. 1002 $ Conveyance: The transfer of Evidence from the Attester to the 1003 Verifier. 1005 $ Verification: The appraisal of Evidence by the Verifier who 1006 evaluates it against a reference policy. See also RFC4949 [1]. 1008 $ Remote Attestation: A procedure involving Attestation, Conveyance 1009 and Verification. 1011 8.4. RATS Information Model Terminology 1013 Evidence conveyed to a Verifier by an Attester is structured to 1014 facilitate syntactic and semantic interoperability. An information 1015 model defines the tag namespaces used to create tag-value pairs 1016 containing discrete bits of Evidence. 1018 $ Evidence: A set of Measurements, quality metrics, quality 1019 procedures or assurance criteria about an Computing Context's 1020 behavioral, operational and intrinsic characteristics. 1022 $ Claim: Structured Evidence asserted about a Computing Context. It 1023 contains metadata that informs regarding the type, class, 1024 representation and semantics of Evidence information. A Claim is 1025 represented as a name-value pair consisting of a Claim Name and a 1026 Claim Value [RFC7519]. In the context of SACM, a Claim is also 1027 specialized as an attribute-value pair that is intended to be 1028 related to a statement [I-D.ietf-sacm-terminology]. 1030 $ Attestable Claim: Structured Evidence including one or more Claims 1031 that are asserted by a Claimant (Note: an Attester role doubles as 1032 a Claimant role). An Attestable Claim has the following 1033 structure: 1035 1. A Claim or Claims. 1037 2. A Claimant identity. 1039 3. Proof of Claimant identity. 1041 4. Proof the Claimant intended to make these Claims. 1043 Note: Proofs of Claims assertions may be separated from the Claim 1044 itself. For example, a secure transport over which Claims are 1045 conveyed where Claimant's signing key integrity protects the 1046 transport payload could be used as proof of Claim assertion. 1047 Alternatively, each Claim could be separately signed by a Claimant. 1049 $ Attested (Asserted) Claim: An Attestable Claim where the proof 1050 elements are populated. 1052 $ Evidence (Claims) Creation: Instantiation of Attested Claims by a 1053 Claimant. 1055 $ Evidence (Claims) Collection: Assembling of Attested Claims by an 1056 Attester for the purpose of Conveyance. 1058 $ Verified (Valid) Claim: An Attested Claim where the proof elements 1059 have been verified by a Verifier according to a policy that 1060 identifies trusted Claimants and/or trusted Evidence values. 1062 8.5. RATS Work-Flow Terminology 1064 This section introduces terms and definitions that are required to 1065 illustrate the scope and the granularity of RATS workflows in the 1066 domain of security automation. Terms defined in the following 1067 sections will be based on this workflow-related definitions. 1069 In general, RATS are composed of iterative activities that can be 1070 conducted in intervals. It is neither a generic set of actions nor 1071 simply a task, because the actual actions to be conducted by RATS can 1072 vary significantly depending on the protocols employed and types of 1073 Computing Contexts involved. 1075 $ Activity: A sequence of actions conducted by Computing Contexts 1076 that compose a Remote Attestation procedure. The actual 1077 composition of actions can vary, depending on the characteristics 1078 of the Computing Context they are conducted by/in and the 1079 protocols used to utilize an Interconnect. A single Activity 1080 provides only a minimal amount of semantic context, e.g.defined by 1081 the Activity's requirements imposed upon the Computing Context, or 1082 via the set of actions it is composed of. Example: The Conveyance 1083 of cryptographic Evidence or the appraisal of Evidence via 1084 imperative guidance. 1086 $ Task: A unit of work to be done or undertaken. 1088 In the scope of RATS, a task is a procedure to be conducted. 1089 Example: A Verifier can be tasked with the appraisal of Evidence 1090 originating from a specific type of Computing Contexts providing 1091 appropriate identities. 1093 $ Action: The accomplishment of a thing usually over a period of 1094 time, in stages, or with the possibility of repetition. 1096 In the scope of RATS, an action is the execution of an operation 1097 or function in the scope of an Activity conducted by a Computing 1098 Context. A single action provides no semantic context by itself, 1099 although it can limit potential semantic contexts of RATS to a 1100 specific scope. Example: Signing an existing public key via a 1101 specific openssl library, transmitting data, or receiving data are 1102 actions. 1104 $ Procedure: A series of actions that are done in a certain way or 1105 order. 1107 In the scope of RATS, a procedure is a composition of activities 1108 (sequences of actions) that is intended to create a well specified 1109 result with a well established semantic context. Example: The 1110 activities of Attestation, Conveyance and Verification compose a 1111 Remote Attestation procedure. 1113 8.6. RATS Reference Use Cases 1115 A "lying endpoint" is not trustworthy. 1117 This document provides NNN prominent examples of use cases 1118 Attestation procedures are intended to address: 1120 o Verification of the source integrity of a Computing Context via 1121 data integrity proofing of installed software instances that are 1122 executed, and 1124 o Verification of the identity proofing of a Computing Context. 1126 8.6.1. Use Case A 1128 8.6.2. Use Case B 1130 8.7. RATS Reference Terminology 1132 $ Attestable Computing Context: A Computing Context where a Claimant 1133 is able to create Claims, an Attester is able to Attest those 1134 Claims and a Verifier is able to verify the Claims. 1136 $ Attestation Identity: An identity that refers to an Attester. 1138 $ Attestation Identity Credential: A credential used to authenticate 1139 an Attestation Identity. 1141 $ Attestation Identity Key (AIK): An Attestation Identity Credential 1142 in the form of an asymmetric cryptographic key where the AIK 1143 private key is protected by a Computing Context with protection 1144 properties that are stronger than the Computing Context about 1145 which the AIK attests. A root-of-trust Computing Context normally 1146 protects AIK private keys. 1148 $ Claimant Identity: An identity that refers to an Claimant. 1150 $ Claimant Identity Credential: A credential used to authenticate a 1151 Claimant Identity. 1153 $ Measurements / Integrity Measurements: Metrics of Computing 1154 Context characteristics (i.e. composition, configuration and 1155 state) that affect the confidence in the trustworthiness of a 1156 Computing Context. Digests of integrity Measurements can be 1157 stored in shielded locations (e.g. a PCR of a TPM). 1159 $ Reference Integrity Measurements: Signed Measurements about a 1160 Computing Context's characteristics that are provided by a vendor 1161 or manufacturer and are intended to be used as declarative 1162 guidannce [I-D.ietf-sacm-terminology] (e.g. a signed CoSWID). 1164 $ Root-of-trust: The Computing Context that protects the following 1165 where no other Computing Context is expected to provide its 1166 Attestation Evidence: + Attestation Evidence. + AIKs. + Code 1167 used during the collection and reporting of Attestation Evidence. 1169 $ Root-of-trust-for-measurement (RTM): A trusted Computing Context 1170 where a Claimant creates integrity Measurements and other Evidence 1171 about a Computing Context where no other Computing Context is 1172 expected to provide its Attestation Evidence. 1174 $ Root-of-trust-for-reporting (RTR): A trusted Computing Context 1175 where an Attester stages reporting of Claims where no other 1176 Computing Context is expected to provide its Attestation Evidence. 1178 $ Root-of-trust-for-storage (RTS): A trusted Computing Context where 1179 a Claimaint or Attester stores Claims, Evidence, credentials or 1180 policies associated with Attestation where no other Computing 1181 Context is expected to provide its Attestation Evidence. 1183 $ Trustworthy Computing Context: A Computing Context that guarantees 1184 trustworthy behavior and/or composition (with respect to certain 1185 declarative guidance and a scope of confidence). A trustworthy 1186 Computing Context is a trustworthy system. 1188 Trustworthy Statement: Evidence conveyed 1189 by a Computing Context that is not necessarily trustworthy. 1190 [update with tamper related terms] 1192 8.8. Interpretations of RFC4949 Terminology for Attestation 1194 Assurance: An attribute of an information system that provides 1195 grounds for having confidence that the system operates such that 1196 the system's security policy is enforced [RFC4949] (see Trusted 1197 System below). 1199 In common criteria, assurance is the basis for the metric level of 1200 assurance, which represents the "confidence that a system's 1201 principal security features are reliably implemented". 1203 The NIST Handbook [get ref from 4949] notes that the levels of 1204 assurance defined in Common Criteria represent "a degree of 1205 confidence, not a true measure of how secure the system actually 1206 is. This distinction is necessary because it is extremely 1207 difficult-and in many cases, virtually impossible-to know exactly 1208 how secure a system is." 1210 Historically, assurance was well-defined in the Orange Book 1211 [http://csrc.nist.gov/publications/history/dod85.pdf] as 1212 "guaranteeing or providing confidence that the security policy has 1213 been implemented correctly and that the protection-relevant 1214 elements of the system do, indeed, accurately mediate and enforce 1215 the intent of that policy. By extension, assurance must include a 1216 guarantee that the trusted portion of the system works only as 1217 intended." 1219 Confidence: The definition of correctness integrity in [RFC4949] 1220 notes that "source integrity refers to confidence in data values". 1221 Hence, confidence in an Attestation procedure is referring to the 1222 degree of trustworthiness of an Attestation Activity that produces 1223 Evidence (Attester), of an Conveyance Activity that transfers 1224 Evidence (interconnect), and of a Verification Activity that 1225 appraises Evidence (Verifier), in respect to correctness 1226 integrity. 1228 Correctness: The property of a system that is guaranteed as the 1229 result of formal Verification activities. 1231 Correctness integrity: The property that the information represented 1232 by data is accurate and consistent. 1234 Data Integrity: (a) The property that data has not been changed, 1235 destroyed, or lost in an unauthorized or accidental manner. (See: 1236 data integrity service. Compare: correctness integrity, source 1237 integrity.) 1239 (b) The property that information has not been modified or 1240 destroyed in an unauthorized manner. 1242 Entity: A principal, Subject, relying party or stake holder in an 1243 Attestation ecosystem. 1245 Identity: The set of attributes that distinguishes a principal. 1247 Identifier: The set of attributes that distinguishes an object. 1249 Identity Proofing: A vetting process that verifies the information 1250 used to establish the identity of a system entity. 1252 (Information) System: An organized assembly of computing and 1253 communication resources and procedures - i.e., equipment and 1254 services, together with their supporting infrastructure, 1255 facilities, and personnel - that create, collect, record, process, 1256 store, transport, retrieve, display, disseminate, control, or 1257 dispose of information to accomplish a specified set of functions. 1259 Object: A system component that contains or receives information. 1261 Source Integrity: The property that data is trustworthy (i.e., 1262 worthy of reliance or trust), based on the trustworthiness of its 1263 sources and the trustworthiness of any procedures used for 1264 handling data in the system. 1266 Subject: A Computing Context acting in accordance with the interests 1267 of a principal. 1269 Subsystem: A collection of related system components that together 1270 perform a system function or deliver a system service. 1272 System Component: An instance of a system resource that (a) forms a 1273 physical or logical part of the system, (b) has specified 1274 functions and interfaces, and (c) is extant (e.g., by policies or 1275 specifications) outside of other parts of the system. (See: 1276 subsystem.) 1277 An identifiable and self-contained part of a $Target-of- 1278 Evaluation. 1280 Token: A data structure suitable for containing Claims. 1282 Trusted (Trustworthy) System: A system that operates as expected, 1283 according to design and policy, doing what is required - despite 1284 environmental disruption, human user and operator errors, and 1285 attacks by hostile parties - and not doing other things. 1287 Verification: (a) The process of examining information to establish 1288 the truth of a claimed fact or value. 1290 (b) The process of comparing two levels of system specification 1291 for proper correspondence, such as comparing a security model with 1292 a top-level specification, a top-level specification with source 1293 code, or source code with object code. 1295 8.9. Building Block Vocabulary (Not in RFC4949) 1297 [working title, pulled from various sources, vital] 1299 Attribute: TBD 1301 Characteristic: TBD 1303 Context: TBD 1305 Endpoint: TBD 1307 Environment: TBD 1309 Manifest: TBD 1311 Telemetry: An automated communications process by which data, 1312 readings, Measurements and Evidence are collected at remote points 1313 and transmitted to receiving equipment for monitoring and 1314 analysis. Derived from the Greek roots tele = remote, and metron 1315 = measure. 1317 9. IANA considerations 1319 This document will include requests to IANA: 1321 o first item 1323 o second item 1325 10. Security Considerations 1327 There are always some. 1329 11. Acknowledgements 1331 Maybe. 1333 12. Change Log 1335 No changes yet. 1337 13. References 1339 13.1. Normative References 1341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1342 Requirement Levels", BCP 14, RFC 2119, 1343 DOI 10.17487/RFC2119, March 1997, 1344 . 1346 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1347 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1348 May 2017, . 1350 13.2. Informative References 1352 [I-D.ietf-sacm-terminology] 1353 Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and 1354 A. Montville, "Security Automation and Continuous 1355 Monitoring (SACM) Terminology", draft-ietf-sacm- 1356 terminology-16 (work in progress), December 2018. 1358 [I-D.mandyam-eat] 1359 Mandyam, G., Lundblade, L., Lundblade, L., Ballesteros, 1360 M., and J. O'Donoghue, "The Entity Attestation Token 1361 (EAT)", draft-mandyam-eat-01 (work in progress), November 1362 2018. 1364 [I-D.richardson-rats-usecases] 1365 Richardson, M., "Use cases for Remote Attestation common 1366 encodings", draft-richardson-rats-usecases-00 (work in 1367 progress), March 2019. 1369 [I-D.tschofenig-rats-psa-token] 1370 Tschofenig, H., Frost, S., Brossard, M., and A. Shaw, 1371 "Arm's Platform Security Architecture (PSA) Attestation 1372 Token", draft-tschofenig-rats-psa-token-00 (work in 1373 progress), March 2019. 1375 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1376 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1377 . 1379 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1380 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1381 . 1383 13.3. URIs 1385 [1] https://tools.ietf.org/html/rfc4949 1387 Authors' Addresses 1389 Henk Birkholz 1390 Fraunhofer SIT 1391 Rheinstrasse 75 1392 Darmstadt 64295 1393 Germany 1395 Email: henk.birkholz@sit.fraunhofer.de 1397 Monty Wiseman 1398 GE Global Research 1399 USA 1401 Email: monty.wiseman@ge.com 1403 Hannes Tschofenig 1404 ARM Ltd. 1405 110 Fulbourn Rd 1406 Cambridge CB1 9NJ 1407 UK 1409 Email: hannes.tschofenig@gmx.net 1410 Ned Smith 1411 Intel Corporation 1412 USA 1414 Email: ned.smith@intel.com