idnits 2.17.1 draft-birkholz-rats-architecture-00.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 : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 5 characters in excess of 72. 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 (October 24, 2018) is 2012 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 715, but not defined -- Looks like a reference, but probably isn't: '1' on line 1103 == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-15 Summary: 1 error (**), 0 flaws (~~), 4 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: April 27, 2019 GE Global Research 6 H. Tschofenig 7 ARM Ltd. 8 N. Smith 9 Intel 10 October 24, 2018 12 Architecture and Reference Terminology for Remote Attestation Procedures 13 draft-birkholz-rats-architecture-00 15 Abstract 17 Remote ATtestation ProcedureS (RATS), such as Remote Integrity 18 VERification (RIVER), the creation of Entity Attestation Tokens 19 (EAT), software integrity Measurement And ATtestation (MAAT), or the 20 attestation of device characteristics, in general, are based on 21 specific operations and qualities provided by hardware and software. 22 The RATS architecture maps corresponding functions and operation 23 capabilities to specific RATS roles. The goal is to enable an 24 appropriate conveyance of believable evidence about device health or 25 trusted claims about device capabilities via network protocols. The 26 flows of data between these roles depend on the composition of RATS 27 roles and their location with respect to devices or services. The 28 RATS architecture provides these roles as building blocks to enable 29 suitable composition, while remaining hardware-agnostic. This 30 flexibility is intended to address a significant majority of use 31 cases or usage scenarios in the domain of RATS. Examples include, 32 but are not limited to: financial transactions, voting machines, 33 critical safety systems, network equipment health, or trustworthy 34 end-user device management. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 27, 2019. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 72 2. RATS Architecture . . . . . . . . . . . . . . . . . . . . . . 3 73 2.1. Roles, Devices, and Services . . . . . . . . . . . . . . 4 74 2.2. Trust and Trustworthiness . . . . . . . . . . . . . . . . 5 75 2.3. Claims and Evidence . . . . . . . . . . . . . . . . . . . 6 76 2.4. RATS Roles . . . . . . . . . . . . . . . . . . . . . . . 6 77 2.5. Exemplary Composition of Roles . . . . . . . . . . . . . 8 78 2.5.1. Conveyance of Trusted Claim Sets Validated by 79 Signature . . . . . . . . . . . . . . . . . . . . . . 8 80 2.5.2. Conveyance of Attestation Evidence Appraised by a 81 Verifier . . . . . . . . . . . . . . . . . . . . . . 9 82 2.6. The Scope of RATS . . . . . . . . . . . . . . . . . . . . 9 83 2.6.1. The Lying Endpoint Problem . . . . . . . . . . . . . 10 84 2.6.2. How the RATS Architecture Addresses the Lying 85 Endpoint Problem . . . . . . . . . . . . . . . . . . 11 86 3. RATS Terminology . . . . . . . . . . . . . . . . . . . . . . 11 87 3.1. Computing Context . . . . . . . . . . . . . . . . . . . . 12 88 3.1.1. Characteristics of a Computing Context . . . . . . . 13 89 3.1.2. Computing Context Semantic Relationships . . . . . . 14 90 3.1.3. Computing Context Identity . . . . . . . . . . . . . 16 91 3.2. Remote Attestation Concepts . . . . . . . . . . . . . . . 16 92 3.3. Core RATS Terminology . . . . . . . . . . . . . . . . . . 16 93 3.4. RATS Information Model Terminology . . . . . . . . . . . 17 94 3.5. RATS Work-Flow Terminology . . . . . . . . . . . . . . . 18 95 3.6. RATS Reference Use Cases . . . . . . . . . . . . . . . . 19 96 3.6.1. Use Case A . . . . . . . . . . . . . . . . . . . . . 19 97 3.6.2. Use Case B . . . . . . . . . . . . . . . . . . . . . 19 98 3.7. RATS Reference Terminology . . . . . . . . . . . . . . . 19 99 3.8. Interpretations of RFC4949 Terminology for Attestation . 21 100 3.9. Building Block Vocabulary (Not in RFC4949) . . . . . . . 23 101 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23 102 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 103 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 104 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 24 105 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 106 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 107 8.2. Informative References . . . . . . . . . . . . . . . . . 24 108 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 111 1. Introduction 113 This document provides normative guidance how to use, create or adopt 114 network protocols that facilitate remote attestation procedures. The 115 foundation of the RATS architecture are specific roles that can be 116 chained and as a result compose remote attestation procedures. The 117 term attestation, unfortunately, is an overloaded term. There are 118 different interpretations, connotations and meanings to the term 119 attestation and therefore also to terms related to attestation. In 120 consequence, this document also provides a detailed definition of 121 Attestation Terminology. The intent is to illustrate and remediate 122 the impedance mismatch of terms related to Remote Attestation 123 Procedures used in different domains today. New terms defined by 124 this document provide a consolidated basis to support future work on 125 RATS in the IETF and beyond. 127 1.1. Requirements notation 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in RFC 132 2119, BCP 14 [RFC2119]. 134 2. RATS Architecture 136 The goal of the RATS architecture is to provide the building blocks - 137 the roles defined by the RATS architecture - to enable the 138 composition of service-chains and work-flows to create and appraise 139 evidence about the trustworthiness of devices and services. 141 The RATS architecture does not prescribe specific payload 142 definitions, role composition, or protocol use. However, it imposes 143 requirements on payload definitions, interfaces, and network 144 protocols with respect to proofs of freshness, attestation 145 provenance, and required operational primitives that are available to 146 devices and services taking on RATS roles. For brevity, the term 147 "system" is a synonym for "device or service" in this document. 149 2.1. Roles, Devices, and Services 151 In the RATS architecture, devices or services can take on RATS roles. 152 In this context, devices are typically composite devices (in the case 153 of atomically integrated devices that would result in a composite 154 device with one component). Services are software components - e.g. 155 a daemon, a virtual network function (vnf) or a network security 156 function (nsf) - that can reside on one or more devices and are not 157 necessarily bound to a specific set of devices. 159 Devices or Services (Systems) can take on one or more RATS roles 160 either by separate functions or via a collapsed functions that take 161 on multiple RATS roles. Systems that take on RATS roles: 163 o are consumer and/or producer of role-specific information, and 165 o can be chained to compose specific work-flows. 167 Systems can be distinguished on the management plane via identity 168 documents (which includes specific claim sets about device 169 characteristics, see RFC4949) or via trusted claim sets (e.g. the 170 Entity Attestation Token) and can be addressed by network protocols 171 via IP addresses. RATS can be used in environments without network 172 protocols and RATS roles can be used to design work-flows in these 173 domains, correspondingly. However, the primary focus of the RATS 174 architecture is to facilitate network protocols between RATS roles 175 that convey information via the Internet Protocol. 177 Relevant decision-factors that influence the composition of RATS 178 roles on systems and resulting work-flows are (amongst others): 180 o which role (or correspondingly, which system that is taking on 181 specific RATS roles) is triggering a Remote Attestation Procedure 183 o which entities are involved in a Remote Attestation Procedure 184 (e.g. the attester itself, trusted third parties, specific trust 185 anchors, or other sources of assertions) 187 o the capabilities of the protocols used (e.g. challenge-response 188 based, RESTful, uni-directional) 190 o the security requirements and security capabilities of systems in 191 a domain of application 193 o the risks and corresponding threats that are intended to be 194 mitigated 196 2.2. Trust and Trustworthiness 198 [RFC4949] provides definitions that highlight the difference between 199 a "trusted system" and a "trustworthy system". The following 200 definitions exclude the explicit specialization of concepts that are 201 "environmental disruption" as well as "human user and operator 202 errors". 204 A trusted system in the context of RATS "operates as expected, 205 according to design and policy, doing what is required and not doing 206 other things" [RFC4949]. A trustworthy system is a system "that not 207 only is trusted, but also warrants that trust because the system's 208 behavior can be validated in some convincing way, such as through 209 formal analysis or code review" [RFC4949]. 211 The goal of RATS is to convey information about system component 212 characteristics, such as integrity or authenticity, that can be 213 appraised in a convincing way. 215 RATS require trust relationships with third parties that qualify 216 assertions about, for example, origin of data, the manufacturer or 217 the capabilities of a system, or the origination of attestation 218 evidence (attestation provenance). Without trusted authorities (e.g. 219 a certificate authority) it is virtually impossible to assess the 220 level of assurance (or resulting level of confidence, 221 correspondingly) of information produced by RATS. Trusting a system 222 does not make it trustworthy. Assessing trustworthiness requires the 223 conveyance of evidence that a system is a trustworthy system, which 224 has to originate from the system itself and has to be convincing. If 225 the convincing information is not originating from the system itself, 226 it comprises trusted claim sets and not evidence. In essence, the 227 attestation provenance of attestation evidence is the system that 228 intends to present its trustworthiness in a believable manner. 230 The essential basis for trust in the information created via RATS are 231 roots of trust. 233 Roots of trust are defined by the NIST special publication 800-164 234 draft as "security primitives composed of hardware, firmware and/or 235 software that provide a set of trusted, security-critical functions. 236 They must always behave in an expected manner because their 237 misbehavior cannot be detected. As such, RoTs need to be secured by 238 their design. Hardware RoTs are preferred over software RoTs due to 239 their immutability, smaller attack surface, and more reliable 240 behavior." 241 If the root of trust involved is a root of trust for measurement 242 (RTM), the producer of information takes on the role of a asserter. 243 An asserter can also make use of a root of trust for integrity (RTI) 244 in order to increase the level of assurance in the assertions 245 produced. If the root of trust involved is a root of trust for 246 reporting (RTR), the producer of information takes on the role of an 247 attester. 249 2.3. Claims and Evidence 251 The RATS asserter role produces measurements about the system's 252 characteristics in the form of signed (sometimes un-signed) claim 253 sets in order to convey information. A secret signing key is 254 required for this procedure, which is typically stored in a shielded 255 location that can be trusted, for example, via a root of trust for 256 storage (RTS). 258 The RATS attester role produces signed attestation evidence in order 259 to convey information. The secret key required for this procedure is 260 stored in a shielded location that only allows access to that key, if 261 a specific operational state of the system is met. The trust with 262 respect to this origination is based on a root of trust for 263 reporting. 265 2.4. RATS Roles 267 There are six roles defined in the RATS architecture. iFigure 1 268 provides a simplified overview of the roles defined in this section. 270 +------------+ +------------------+ 271 | | | | 272 | Attester | +->| Verifier | 273 | | | | | 274 +------------+ | +------------------+ 275 ^ | 276 | | +------------------+ 277 | +----------------+ | | | 278 +---->| |<-+ | Authentication | 279 | Interconnect |<--->| Checker | 280 +---->| |<-+ | | 281 | +----------------+ | +------------------+ 282 v | 283 +------------+ | +------------------+ 284 | | | | | 285 | Claimant | +->| Relying Party | 286 | | | | 287 +------------+ +------------------+ 289 Figure 1: Overall Relationships of Roles in the RATS Architecture 291 Attester: The producer of attestation evidence that has a root of 292 trust for reporting (RTR) and implements a conveyance protocol, 293 authenticates using an attestation credential, consumes assertions 294 about itself and presents it to a consumer of evidence (e.g. a 295 relying party or a verifier). Every output of an attester can be 296 appraised via reference values. 298 Claimant: The producer of measurements or assertions to certain 299 properties regarding the trustworthiness of a system's 300 characteristics that has a root of trust for measurement. It is 301 not guaranteed that a verifier can appraise the output of a 302 claimant via reference values. Examples of claim output include: 303 the binding of an attester to an RTR, GPS coordinates set of 304 integrity measurements, or an Universal Entity ID (UEID). 306 Interconnect: A communication channel or secure path between systems 307 that take on RATS roles. Attestation evidence, for example, can 308 be conveyed from an attester to a verifier via an interconnect. 309 Examples include: GPIO pins, an USB link, or the Internet. 311 Relying Party: The consumer and assessor of verifier or 312 Authentication Checker results for the purpose of improved risk 313 management, operational efficiency, security, privacy (natural or 314 legal person) or safety. The verifier and/or authentication 315 checker roles and the relying party role may be tightly 316 integrated. 318 Authentication Checker: The consumer of signed assertions such as 319 trusted claim sets or attestation evidence that assesses the 320 trustworthiness or other trust relationships of the information 321 consumed via trusted third parties or external trust authorities, 322 such as a privacy certificate authority. In certain environments, 323 an Authentication Checker can assess a system's trustworthiness 324 via external trust anchors, implicitly. 326 Verifier: The consumer of attestation evidence that has a root of 327 trust for verification and implements a conveyance protocol, 328 appraises attestation evidence against reference values or 329 policies and makes verification results available to relying 330 parties. 332 2.5. Exemplary Composition of Roles 334 In order to provide an intuitive understanding how the roles used in 335 RATS can be composed into work-flows, this document provides a few 336 example work-flows. Boxes in the following examples that include 337 more than one role are systems that take on more than one role. 339 2.5.1. Conveyance of Trusted Claim Sets Validated by Signature 341 If there is a trust relationship between a trusted third party that 342 can assert that signed claims created by a claimant guarantee a 343 trustworthy origination of claim, the work-flow depicted in Figure 2 344 can facilitate a trust-based implicit remote attestation procedure. 345 The information conveyed are signed claim sets that are trusted via 346 an authoritative third party. In this work-flow claim emission is 347 triggered by the claimant. Variations based on requests emitted by 348 the relying party can be easily facilitated by the same set of roles. 350 +---------------------------------------+ 351 | | 352 | +------------------+ +-----------+ | 353 +------------+ +----------------+ | | | | | | 354 | | | | | | Authentication | | Relying | | 355 | Claimant |->| Interconnect |--+->| Checker |->| Party | | 356 | | | | | | | | | | 357 +------------+ +----------------+ | +------------------+ +-----------+ | 358 | | 359 +---------------------------------------+ 361 Figure 2: Conveyance of Trusted Claim Sets Validated by Signature 363 2.5.2. Conveyance of Attestation Evidence Appraised by a Verifier 365 If there is trust in the root of trust for reporting based on the 366 assertions of a trusted third party, the work-flow depicted in 367 Figure 3 can facilitate an evidence-based explicit remote attestation 368 procedure. The information conveyed is signed attestation evidence 369 that is created by the trusted verifier. In this work-flow claims do 370 not necessarily have to be signed and the work-flow is triggered by 371 the attestor that aggregates claims from a root of trust of 372 measurement. Variations based on requests emitted by the verifier 373 can be easily facilitated by the same set of roles. 375 +------------------+ +------------------------+ 376 | | | +------------------+ | 377 | +------------+ | +----------------+ | | | | 378 | | | | | | | | Authentication | | 379 | | Attester |--+->| Interconnect |--+->| Checker | | 380 | | | | | | | | | | 381 | +------------+ | +----------------+ | +------------------+ | 382 | ^ | +-------------------+ | | 383 | | | | | | 384 | | | | +-----------+ v | 385 | +-----+------+ | | | | +------------+ | 386 | | | | | | Relying | | | | 387 | | Claimant | | | | Party |<---------| Verifier | | 388 | | | | | | | | | | 389 | +------------+ | | +-----------+ +------------+ | 390 | | | | 391 +------------------+ +--------------------------------------------+ 393 Figure 3: Conveyance of Attestation Evidence Appraised by a Verifier 395 2.6. The Scope of RATS 397 During its evolution, the term Remote Attestation has been used in 398 multiple contexts and multiple scopes and in consequence accumulated 399 various connotations with slightly different semantic meaning. 400 Correspondingly, Remote Attestation Procedures (RATS) are employed in 401 various usage scenarios and different environments. 403 In order to better understand and grasp the intent and meaning of 404 specific RATS in the scope of the security area - including the 405 requirements that are addressed by them - this document provides an 406 overview of existing work, its background, and common terminology. 407 As the contribution, from that state-of-the-art a set of terms that 408 provides a stable basis for future work on RATS in the IETF is 409 derived. 411 In essence, a prerequisite for providing an adequate set of terms and 412 definitions for the RATS architecute is a general understanding and a 413 common definitions of "what" RATS can accomplish "how" RATS can to be 414 used. 416 Please note that this section is still missing various references and 417 is considered "under construction". The majority of definitions is 418 still only originating from IETF work. Future iterations will pull 419 in more complementary definitions from other SDO (e.g. Global 420 Platform, TCG, etc.) and a general structure template to highlight 421 semantic relationships and capable of resolving potential 422 discrepancies will be introduced. A section of context awareness 423 will provide further insight on how Attestation procedures are vital 424 to ongoing work in the IETF (e.g. I2NSF & tokbind). The definitions 425 in the section about RATS are still self-describing in this version. 426 Additional explanatory text will be added to provide more context and 427 coherence. 429 2.6.1. The Lying Endpoint Problem 431 A very prominent goal of RATS is to address the "lying endpoint 432 problem". The lying endpoint problem is characterized as a condition 433 of a Computing Context where the information or behavior embedded, 434 created, relayed, stored, or emitted by the Computing Context is not 435 "correct" according to expectations of the authorized system 436 designers, operators and users. There can be multiple reasons why 437 these expectations are incorrect, either from malicious Activity, 438 unanticipated conditions or accidental means. The observed behavior, 439 nevertheless, appears to be a compromised Computing Context. 441 Attempts to "scrub" the data or "proxy" control elements implies the 442 existence of a more fundamental trusted endpoint that is operating 443 correctly. Therefore, Remote Attestation - the technology designed 444 to detect and mitigate the "lying endpoint problem" - must be trusted 445 to behave correctly independent of other controls. 447 Consequently, a "lying endpoint" cannot also be a "trusted system". 449 Remote Attestation procedures are intended to enable the consumer of 450 information emitted by a Computing Context to assess the validity and 451 integrity of the information transferred. The approach is based, for 452 example, on the assumption that if attestation evidence can be 453 provided in order to prove the integrity of every software instance 454 installed involved in the activity of creating the emitted 455 information in question, the emitted information can be considered 456 valid and integer. 458 In contrast, such Evidence has to be impossible to create if the 459 software instances used in a Computing Context are compromised. 460 Attestation activities that are intended to create this Evidence 461 therefore also provide guarantees about the validity of the Evidence 462 they can create. 464 2.6.2. How the RATS Architecture Addresses the Lying Endpoint Problem 466 RATS imply the involvement of at least two players (roles) who seek 467 to overcome the lying endpoint problem. The Verifier wishes to 468 consume application data supplied by a Computing Context. But before 469 application data is consumed, the Verifier obtains Attestation 470 Evidence about the Computing Context to assess likelihood of poisoned 471 data due to endpoint compromise or failure. Remote Attestation 472 argues that a systems's integrity characteristics should not be 473 believed until rationale for believability is presented to the 474 relying party seeking to interact with the system. 476 An Interconnect defines an untrusted channel between subject and 477 object wherein the rationale for believability is securely exchanged. 478 The type of interconnect technology could vary widely, ranging from 479 GPIO pins, to a PC peripheral IO bus, to the Internet, to a direct 480 physical connection, to a wireless radio-receiver association, or to 481 a world wide mesh of peers. In other words, virtually every kind 482 communication path could be used as the "Interconnect" in RATS. In 483 fact, a single party could take on all roles at the same time (e.g. 484 Self Encrypting Devices). 486 Attestation evidence can be thought of as the topics of the exchange 487 that is created the operational primitives of a root of trust for 488 reporting. Evidence may be structured in an interoperable format 489 called claims that may include references to the claimants which are 490 asserting the claims. RATS aims to define "interoperable Remote 491 Attestation" such that evidence can be created and consumed by 492 different ecosystem systems and can be securely exchanged by a broad 493 set of network protocols. 495 3. RATS Terminology 497 This document relies on terminology found in [RFC4949]. This 498 document presumes the reader is familiar with the following terms. 500 o Cryptography 502 o Entity (System entity) 504 o Identity 505 o Object 507 o Principal 509 o Proof-of-possession protocol 511 o Security environment (Environment) 513 o Security perimeter 515 o Subject 517 o Subsystem 519 o System 521 o Target-of-Evaluation (TOE) 523 o Trusted Computing Base (TCB) 525 o Trusted Platform Module (TPM) 527 o Trusted (Trustworthy) system 529 o Verification 531 Terminology defined by this document is preceded by a dollar sign ($) 532 to distinguish it from terms defined elsewhere and as a way to 533 disambiguate term definition from explanatory text. 535 Terms defined by this document that are subsequently used by this 536 document are distinguished by capitalizing the first letter of the 537 term (e.g. Term or First_word Second_word). 539 3.1. Computing Context 541 This section introduces the term Computing Context in order to 542 specialize the notions of environment and endpoint to terminology 543 that has relevance to trusted computing. Attestation is a discipline 544 of trusted computing. 546 A Computing Context could refer to a large variety of endpoints. 547 Examples include but are not limited to: the compartmentalization of 548 physical resources, the separation of software instances with 549 different dependencies in dedicated containers, and the nesting of 550 virtual components via hardware-based and software-based solutions. 551 The number of approaches and techniques to construct an endpoint 552 continuously changes with new innovation. Hence, it isn't a goal of 553 this document to define remote attestation for a fixed set of 554 endpoints. Rather, it attempts to define endpoints conceptually and 555 rely on Claims management as a way to clarify the details and 556 specific attributes of conceptual endpoints. 558 Computing Contexts may be recursive in nature in that it could be 559 composed of a system that is itself a composite of subsystems. In 560 consequence, a system may be composed of other systems that may be 561 further composed of one or more Computing Contexts capable of taking 562 on the RATS roles. The scope and application of these roles can 563 range from: 565 o Continuous mutual Attestation procedures of every subsystem inside 566 a composite device, to 568 o Sporadic Remote Attestation of unknown parties via heterogeneous 569 Interconnects. 571 Analogously, the increasing number of features and functions that 572 constitute components of a device start to blur the lines that are 573 required to categorize each solution and approach precisely. To 574 address this increasingly challenging categorization, the term 575 Computing Context defines the characteristics of the (sub)systems 576 that can take on the role of an Attester and/or the role of a 577 Verifier. This approach is intended to provide a stable basis of 578 definitions for future solutions that continuous to remain viable 579 long-term. 581 $ Computing Context : An umbrella term that combines the scope of 582 the definitions of endpoint [ref NEA], device [ref 1ar], and thing 583 [ref t2trg], including hardware-based and software-based sub- 584 contexts that constitute independent, isolated and distinguishable 585 slices of a Computing Context created by compartmentalization 586 mechanisms, such as Trusted Execution Environments (TEE), Hardware 587 Security Modules (HSM) or Virtual Network Function (VNF) contexts. 589 3.1.1. Characteristics of a Computing Context 591 While the semantic relationships highlighted above constitute the 592 fundamental basis to provide a define Computing Context, the 593 following list of object characteristics is intended to improve the 594 application of the term and provide a better understanding of its 595 meaning: 597 $ Computing Context Characteristics: A representation of the 598 identity, composition, configuration and state of a Computing 599 Context. 601 Computing context characteristics provide the following: * An 602 independent environment in regard to executing and running 603 software, * An isolated control plane state (by potentially 604 interacting with other Computing Contexts), * A dedicated 605 management interface by which control plane behavior can be 606 effected, * Unique identification towards reliable disambiguation 607 within a given scope. 609 Computing context characteristics do not necessarily include a 610 network interface with associated network addresses (as required by 611 the definition of an endpoint) - although it is very likely to have 612 (access to) one. 614 [Issue: This conclusion could be incorrect] In contrast, a container 615 [ref docker, find a more general term here] context is not a 616 distinguishable isolated slice of an information system and therefore 617 is not an independent Computing Context. [more feedback on this 618 statement is required as the capabilities of docker-like functions 619 evolve continuously] 621 Examples include: a smart phone, a nested virtual machine, a 622 virtualized firewall function running distributed on a cluster of 623 physical and virtual nodes, or a trust-zone. 625 3.1.2. Computing Context Semantic Relationships 627 Computing Contexts may relate to other Computing Contexts that are 628 decomposable in a variety of ways. 630 o Singleton, 632 o Tuples (e.g. 2-tuple, n-tuple), 634 o Nested, 636 o Clustered (homogeneous), 638 o Grouped (heterogenous). 640 The scope of Computing Context encompasses a broad spectrum of 641 systems including, but not limited to: 643 o An information system, 645 o An object, 647 o A composition of objects, 648 o A system component, 650 o A system sub-component, 652 o A composition of system sub-components, 654 o A system entity, 656 o A composition of system entities. 658 A Computing Context may be realized in a variety of ways including, 659 but not limited to: 661 o A process, thread or task as defined by an operating system, 663 o A privileged operating system task, interrupt handler or event 664 handler, 666 o A virtual machine, 668 o A virtual machine monitor, 670 o A processor mode (e.g. system management mode), 672 o A co-processor, 674 o A peripheral device, 676 o A secure element, 678 o A trusted execution environment, 680 o A controller, sensor, actutor, switch, router or gateway, 682 o An FPGA, 684 o An ASIC, 686 o A memory resource, 688 o A storage resource. 690 Analogously, a computing sub-context is a decomposition of a 691 Computing Context; a subsystem is a decomposition of a system; a sub- 692 component is a decomposition of a component; and a peer node is a 693 decomposition of a node cluster. 695 A formal semantic relationship is therefore expressed using an 696 information model that captures interactions, relationships, bindings 697 and interfaces among systems, subsystems, system components, system 698 entities or objects. 700 [Issue: A tangible relationship to an information model is required 701 here] An information model that richly captures Computing Context 702 semantics is therefore believed to be relevant if not fundamental to 703 Remote Attestation. 705 3.1.3. Computing Context Identity 707 The identity of a Computing Context implies there is a binding 708 operation between an identifier and the Computing Context. 710 $ Computing Context Identity: Computing Context Identity provides 711 the basis for associating attestation Evidence about a particular 712 Computing Context to create believable knowledge about attestation 713 provenance. 715 Confidence in the identity assurance level [NIST SP-800-63-3] or the 716 assurance levels for identity authentication [RFC4949] is a property 717 of the identifier uniqueness properties and binding operation 718 veracity. Such properties impact the trustworthiness of associated 719 attestation Evidence. 721 3.2. Remote Attestation Concepts 723 Attestation Evidence created by RATS is a form of telemetry about a 724 computing environment that enables better security risk management 725 through disclosure of security properties of the environment. 726 Attestation may be performed locally (within the same computing 727 environment) or remotely (between different computing environments). 728 The exchange of attestation evidence can be formalized to include 729 well-defined protocol, message syntax and semantics. 731 3.3. Core RATS Terminology 733 $ Attestation: The creation of evidence by the Attester based on 734 measurements or other claimant output. 736 A form of telemetry involving the delivery of Claims describing 737 various security properties of a Computing Context by an Attester, 738 such that the Claims can be used as Evidence toward convincing a 739 Verifier regarding trustworthiness of the Computing Context. 741 $ Conveyance: The transfer of Evidence from the Attester to the 742 Verifier. 744 $ Verification: The appraisal of Evidence by the Verifier who 745 evaluates it against a reference policy. See also RFC4949 [1]. 747 $ Remote Attestation: A procedure involving Attestation, Conveyance 748 and Verification. 750 3.4. RATS Information Model Terminology 752 Evidence conveyed to a Verifier by an Attester is structured to 753 facilitate syntactic and semantic interoperability. An information 754 model defines the tag namespaces used to create tag-value pairs 755 containing discrete bits of Evidence. 757 $ Evidence: A set of Measurements, quality metrics, quality 758 procedures or assurance criteria about an Computing Context's 759 behavioral, operational and intrinsic characteristics. 761 $ Claim: Structured Evidence asserted about a Computing Context. It 762 contains metadata that informs regarding the type, class, 763 representation and semantics of Evidence information. A Claim is 764 represented as a name-value pair consisting of a Claim Name and a 765 Claim Value [RFC7519]. In the context of SACM, a Claim is also 766 specialized as an attribute-value pair that is intended to be 767 related to a statement [I-D.ietf-sacm-terminology]. 769 $ Attestable Claim: Structured Evidence including one or more Claims 770 that are asserted by a Claimant (Note: an Attester role doubles as 771 a Claimant role). An Attestable Claim has the following 772 structure: 774 1. A Claim or Claims. 776 2. A Claimant identity. 778 3. Proof of Claimant identity. 780 4. Proof the Claimant intended to make these Claims. 782 Note: Proofs of Claims assertions may be separated from the Claim 783 itself. For example, a secure transport over which Claims are 784 conveyed where Claimant's signing key integrity protects the 785 transport payload could be used as proof of Claim assertion. 786 Alternatively, each Claim could be separately signed by a Claimant. 788 $ Attested (Asserted) Claim: An Attestable Claim where the proof 789 elements are populated. 791 $ Evidence (Claims) Creation: Instantiation of Attested Claims by a 792 Claimant. 794 $ Evidence (Claims) Collection: Assembling of Attested Claims by an 795 Attester for the purpose of Conveyance. 797 $ Verified (Valid) Claim: An Attested Claim where the proof elements 798 have been verified by a Verifier according to a policy that 799 identifies trusted Claimants and/or trusted Evidence values. 801 3.5. RATS Work-Flow Terminology 803 This section introduces terms and definitions that are required to 804 illustrate the scope and the granularity of RATS workflows in the 805 domain of security automation. Terms defined in the following 806 sections will be based on this workflow-related definitions. 808 In general, RATS are composed of iterative activities that can be 809 conducted in intervals. It is neither a generic set of actions nor 810 simply a task, because the actual actions to be conducted by RATS can 811 vary significantly depending on the protocols employed and types of 812 Computing Contexts involved. 814 $ Activity: A sequence of actions conducted by Computing Contexts 815 that compose a Remote Attestation procedure. The actual 816 composition of actions can vary, depending on the characteristics 817 of the Computing Context they are conducted by/in and the 818 protocols used to utilize an Interconnect. A single Activity 819 provides only a minimal amount of semantic context, e.g.defined by 820 the Activity's requirements imposed upon the Computing Context, or 821 via the set of actions it is composed of. Example: The Conveyance 822 of cryptographic Evidence or the appraisal of Evidence via 823 imperative guidance. 825 $ Task: A unit of work to be done or undertaken. 827 In the scope of RATS, a task is a procedure to be conducted. 828 Example: A Verifier can be tasked with the appraisal of Evidence 829 originating from a specific type of Computing Contexts providing 830 appropriate identities. 832 $ Action: The accomplishment of a thing usually over a period of 833 time, in stages, or with the possibility of repetition. 835 In the scope of RATS, an action is the execution of an operation 836 or function in the scope of an Activity conducted by a Computing 837 Context. A single action provides no semantic context by itself, 838 although it can limit potential semantic contexts of RATS to a 839 specific scope. Example: Signing an existing public key via a 840 specific openssl library, transmitting data, or receiving data are 841 actions. 843 $ Procedure: A series of actions that are done in a certain way or 844 order. 846 In the scope of RATS, a procedure is a composition of activities 847 (sequences of actions) that is intended to create a well specified 848 result with a well established semantic context. Example: The 849 activities of Attestation, Conveyance and Verification compose a 850 Remote Attestation procedure. 852 3.6. RATS Reference Use Cases 854 A "lying endpoint" is not trustworthy. 856 This document provides NNN prominent examples of use cases 857 Attestation procedures are intended to address: 859 o Verification of the source integrity of a Computing Context via 860 data integrity proofing of installed software instances that are 861 executed, and 863 o Verification of the identity proofing of a Computing Context. 865 3.6.1. Use Case A 867 3.6.2. Use Case B 869 3.7. RATS Reference Terminology 871 $ Attestable Computing Context: A Computing Context where a Claimant 872 is able to create Claims, an Attester is able to Attest those 873 Claims and a Verifier is able to verify the Claims. 875 $ Attestation Identity: An identity that refers to an Attester. 877 $ Attestation Identity Credential: A credential used to authenticate 878 an Attestation Identity. 880 $ Attestation Identity Key (AIK): An Attestation Identity Credential 881 in the form of an asymmetric cryptographic key where the AIK 882 private key is protected by a Computing Context with protection 883 properties that are stronger than the Computing Context about 884 which the AIK attests. A root-of-trust Computing Context normally 885 protects AIK private keys. 887 $ Claimant Identity: An identity that refers to an Claimant. 889 $ Claimant Identity Credential: A credential used to authenticate a 890 Claimant Identity. 892 $ Measurements / Integrity Measurements: Metrics of Computing 893 Context characteristics (i.e. composition, configuration and 894 state) that affect the confidence in the trustworthiness of a 895 Computing Context. Digests of integrity Measurements can be 896 stored in shielded locations (e.g. a PCR of a TPM). 898 $ Reference Integrity Measurements: Signed Measurements about a 899 Computing Context's characteristics that are provided by a vendor 900 or manufacturer and are intended to be used as declarative 901 guidannce [I-D.ietf-sacm-terminology] (e.g. a signed CoSWID). 903 $ Root-of-trust: The Computing Context that protects the following 904 where no other Computing Context is expected to provide its 905 Attestation Evidence: + Attestation Evidence. + AIKs. + Code 906 used during the collection and reporting of Attestation Evidence. 908 $ Root-of-trust-for-measurement (RTM): A trusted Computing Context 909 where a Claimant creates integrity Measurements and other Evidence 910 about a Computing Context where no other Computing Context is 911 expected to provide its Attestation Evidence. 913 $ Root-of-trust-for-reporting (RTR): A trusted Computing Context 914 where an Attester stages reporting of Claims where no other 915 Computing Context is expected to provide its Attestation Evidence. 917 $ Root-of-trust-for-storage (RTS): A trusted Computing Context where 918 a Claimaint or Attester stores Claims, Evidence, credentials or 919 policies associated with Attestation where no other Computing 920 Context is expected to provide its Attestation Evidence. 922 $ Trustworthy Computing Context: A Computing Context that guarantees 923 trustworthy behavior and/or composition (with respect to certain 924 declarative guidance and a scope of confidence). A trustworthy 925 Computing Context is a trustworthy system. 927 Trustworthy Statement: Evidence conveyed 928 by a Computing Context that is not necessarily trustworthy. 929 [update with tamper related terms] 931 3.8. Interpretations of RFC4949 Terminology for Attestation 933 Assurance: An attribute of an information system that provides 934 grounds for having confidence that the system operates such that 935 the system's security policy is enforced [RFC4949] (see Trusted 936 System below). 938 In common criteria, assurance is the basis for the metric level of 939 assurance, which represents the "confidence that a system's 940 principal security features are reliably implemented". 942 The NIST Handbook [get ref from 4949] notes that the levels of 943 assurance defined in Common Criteria represent "a degree of 944 confidence, not a true measure of how secure the system actually 945 is. This distinction is necessary because it is extremely 946 difficult-and in many cases, virtually impossible-to know exactly 947 how secure a system is." 949 Historically, assurance was well-defined in the Orange Book 950 [http://csrc.nist.gov/publications/history/dod85.pdf] as 951 "guaranteeing or providing confidence that the security policy has 952 been implemented correctly and that the protection-relevant 953 elements of the system do, indeed, accurately mediate and enforce 954 the intent of that policy. By extension, assurance must include a 955 guarantee that the trusted portion of the system works only as 956 intended." 958 Confidence: The definition of correctness integrity in [RFC4949] 959 notes that "source integrity refers to confidence in data values". 960 Hence, confidence in an Attestation procedure is referring to the 961 degree of trustworthiness of an Attestation Activity that produces 962 Evidence (Attester), of an Conveyance Activity that transfers 963 Evidence (interconnect), and of a Verification Activity that 964 appraises Evidence (Verifier), in respect to correctness 965 integrity. 967 Correctness: The property of a system that is guaranteed as the 968 result of formal Verification activities. 970 Correctness integrity: The property that the information represented 971 by data is accurate and consistent. 973 Data Integrity: (a) The property that data has not been changed, 974 destroyed, or lost in an unauthorized or accidental manner. (See: 975 data integrity service. Compare: correctness integrity, source 976 integrity.) 977 (b) The property that information has not been modified or 978 destroyed in an unauthorized manner. 980 Entity: A principal, Subject, relying party or stake holder in an 981 Attestation ecosystem. 983 Identity: The set of attributes that distinguishes a principal. 985 Identifier: The set of attributes that distinguishes an object. 987 Identity Proofing: A vetting process that verifies the information 988 used to establish the identity of a system entity. 990 (Information) System: An organized assembly of computing and 991 communication resources and procedures - i.e., equipment and 992 services, together with their supporting infrastructure, 993 facilities, and personnel - that create, collect, record, process, 994 store, transport, retrieve, display, disseminate, control, or 995 dispose of information to accomplish a specified set of functions. 997 Object: A system component that contains or receives information. 999 Source Integrity: The property that data is trustworthy (i.e., 1000 worthy of reliance or trust), based on the trustworthiness of its 1001 sources and the trustworthiness of any procedures used for 1002 handling data in the system. 1004 Subject: A Computing Context acting in accordance with the interests 1005 of a principal. 1007 Subsystem: A collection of related system components that together 1008 perform a system function or deliver a system service. 1010 System Component: An instance of a system resource that (a) forms a 1011 physical or logical part of the system, (b) has specified 1012 functions and interfaces, and (c) is extant (e.g., by policies or 1013 specifications) outside of other parts of the system. (See: 1014 subsystem.) 1016 An identifiable and self-contained part of a $Target-of- 1017 Evaluation. 1019 Token: A data structure suitable for containing Claims. 1021 Trusted (Trustworthy) System: A system that operates as expected, 1022 according to design and policy, doing what is required - despite 1023 environmental disruption, human user and operator errors, and 1024 attacks by hostile parties - and not doing other things. 1026 Verification: (a) The process of examining information to establish 1027 the truth of a claimed fact or value. 1029 (b) The process of comparing two levels of system specification 1030 for proper correspondence, such as comparing a security model with 1031 a top-level specification, a top-level specification with source 1032 code, or source code with object code. 1034 3.9. Building Block Vocabulary (Not in RFC4949) 1036 [working title, pulled from various sources, vital] 1038 Attribute: TBD 1040 Characteristic: TBD 1042 Context: TBD 1044 Endpoint: TBD 1046 Environment: TBD 1048 Manifest: TBD 1050 Telemetry: An automated communications process by which data, 1051 readings, Measurements and Evidence are collected at remote points 1052 and transmitted to receiving equipment for monitoring and 1053 analysis. Derived from the Greek roots tele = remote, and metron 1054 = measure. 1056 4. IANA considerations 1058 This document will include requests to IANA: 1060 o first item 1062 o second item 1064 5. Security Considerations 1066 There are always some. 1068 6. Acknowledgements 1070 Maybe. 1072 7. Change Log 1074 No changes yet. 1076 8. References 1078 8.1. Normative References 1080 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1081 Requirement Levels", BCP 14, RFC 2119, 1082 DOI 10.17487/RFC2119, March 1997, 1083 . 1085 8.2. Informative References 1087 [I-D.ietf-sacm-terminology] 1088 Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and 1089 A. Montville, "Security Automation and Continuous 1090 Monitoring (SACM) Terminology", draft-ietf-sacm- 1091 terminology-15 (work in progress), June 2018. 1093 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1094 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1095 . 1097 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1098 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1099 . 1101 8.3. URIs 1103 [1] https://tools.ietf.org/html/rfc4949 1105 Authors' Addresses 1107 Henk Birkholz 1108 Fraunhofer SIT 1109 Rheinstrasse 75 1110 Darmstadt 64295 1111 Germany 1113 Email: henk.birkholz@sit.fraunhofer.de 1114 Monty Wiseman 1115 GE Global Research 1116 USA 1118 Email: monty.wiseman@ge.com 1120 Hannes Tschofenig 1121 ARM Ltd. 1122 110 Fulbourn Rd 1123 Cambridge CB1 9NJ 1124 UK 1126 Email: hannes.tschofenig@gmx.net 1128 Ned Smith 1129 Intel Corporation 1130 USA 1132 Email: ned.smith@intel.com