idnits 2.17.1 draft-birkholz-rats-architecture-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 6 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 date (November 04, 2019) is 1628 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) == Unused Reference: 'ABLP' is defined on line 1061, but no explicit reference was found in the text == Unused Reference: 'Lampson2007' is defined on line 1110, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-birkholz-rats-tuda-01 == Outdated reference: A later version (-05) exists of draft-fedorkow-rats-network-device-attestation-00 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-01 == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-03 == Outdated reference: A later version (-08) exists of draft-richardson-rats-usecases-05 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Standards Track M. Wiseman 5 Expires: May 7, 2020 GE Global Research 6 H. Tschofenig 7 ARM Ltd. 8 N. Smith 9 Intel 10 M. Richardson 11 Sandelman Software Works 12 November 04, 2019 14 Remote Attestation Procedures Architecture 15 draft-birkholz-rats-architecture-03 17 Abstract 19 An entity (a relying party) requires a source of truth and evidence 20 about a remote peer to assess the peer's trustworthiness. The 21 evidence is typically a believable set of claims about its host, 22 software or hardware platform. This document describes an 23 architecture for such remote attestation procedures (RATS). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 7, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Opportunities . . . . . . . . . . . . . . . . . . . . . . 3 62 1.3. Overview of Document . . . . . . . . . . . . . . . . . . 4 63 1.4. RATS in a Nutshell . . . . . . . . . . . . . . . . . . . 5 64 1.5. Remote Attestation Workflow . . . . . . . . . . . . . . . 5 65 1.6. Message Flows . . . . . . . . . . . . . . . . . . . . . . 7 66 1.6.1. Passport Model . . . . . . . . . . . . . . . . . . . 7 67 1.6.2. Background Check . . . . . . . . . . . . . . . . . . 8 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 3. Reference use cases . . . . . . . . . . . . . . . . . . . . . 10 70 3.1. Device Capabilities/Firmware Attestation . . . . . . . . 11 71 3.2. IETF TEEP WG Use-Case . . . . . . . . . . . . . . . . . . 11 72 3.3. Safety Critical Systems . . . . . . . . . . . . . . . . . 12 73 3.4. Virtualized Multi-Tenant Hosts . . . . . . . . . . . . . 12 74 3.5. Cryptographic Key Attestation . . . . . . . . . . . . . . 13 75 3.6. Geographic Evidence . . . . . . . . . . . . . . . . . . . 13 76 3.7. Device Provenance Attestation . . . . . . . . . . . . . . 14 77 4. Conceptual Overview . . . . . . . . . . . . . . . . . . . . . 14 78 4.1. Two Types of Environments . . . . . . . . . . . . . . . . 15 79 4.2. Evidence Creation Prerequisites . . . . . . . . . . . . . 16 80 4.3. Trustworthiness . . . . . . . . . . . . . . . . . . . . . 17 81 4.4. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 17 82 4.5. Interoperability between RATS . . . . . . . . . . . . . . 18 83 5. RATS Architecture . . . . . . . . . . . . . . . . . . . . . . 18 84 5.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 5.2. Attestation Principles . . . . . . . . . . . . . . . . . 18 86 5.3. Attestation Workflow . . . . . . . . . . . . . . . . . . 19 87 5.3.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . 19 88 5.3.2. Role Messages . . . . . . . . . . . . . . . . . . . . 20 89 5.4. Principals (Entities?) - Containers for the Roles . . . . 22 90 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 92 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 95 9.2. Informative References . . . . . . . . . . . . . . . . . 24 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 98 1. Introduction 100 Remote Attestation provides a way for an entity (the Relying Party) 101 to determine the health and provenance of an endpoint/host (the 102 Attester). Knowledge of the health of the endpoint allows for a 103 determination of trustworthiness of the endpoint. 105 1.1. Motivation 107 The IETF has long spent it's time focusing on threats to the 108 communication channel (see [RFC3552] and [DOLEV-YAO]), assuming that 109 endpoints could be trusted and were under the observation of trusted, 110 well-trained professionals. This assumption has not been true since 111 the days of the campus mini-computer. For some time after the 112 desktop PC became ubiquitous, the threat to the endpoints has been 113 dealt with as an internal matter, with generally poor results. 114 Enterprises have done some deployment of Network Endpoint Assessment 115 ([RFC5209]) to assess the security posture about an endpoint, but it 116 has not been ubiquitous. 118 The movement towards personal mobile devices ("smartphones") and the 119 continuing threat from unmanaged residential desktops has resulted in 120 a renewed interest in standardizing internet-scale endpoint remote 121 attestation. Additionally, the rise of the Internet of Things (IoT) 122 has made this issue even more critical: some skeptics have even 123 renamed it to the Internet of Threats [iothreats] :-) IoT devices 124 have poor or non-existent user interfaces, as such as there are not 125 even good ways to assess the health of the devices manually: a need 126 to determine the health via remote attestation is now critical. 128 In addition to the health of the device, knowledge of its provenance 129 helps to determine the level of trust, and prevents attacks to the 130 supply chain. 132 1.2. Opportunities 134 The Trusted Platform Module (TPM) is now a commonly available 135 peripheral on many commodity compute platforms, both servers and 136 desktops. Smartphones commonly have either an actual TPM, or have 137 the ability to emulate one in software running in a Trusted Execution 138 Environment [I-D.ietf-teep-architecture]. There are now few barriers 139 to creating a standards-based system for remote attestation 140 procedures. 142 A number of niche solutions have emerged that provide for use-case 143 specific remote attestation, but none have the generality needed to 144 be used across the Internet. 146 1.3. Overview of Document 148 The architecture described in this document (along with the 149 accompanying solution and reference documents) enables the use of 150 common formats for communicating Claims about an Attester to a 151 Relying Party. [FIXME Attester? Flows? To what end?] 153 Existing transports were not designed to carry attestation Claims. 154 It is therefore necessary to design serializations of Claims that fit 155 into a variety of transports, for instance: X.509 certificates, TLS 156 negotiations, YANG modules or EtherNet/IP. There are also new, 157 greenfield uses for remote attestation. Transport and serialization 158 of these can be done without retrofitting. This is (will be) 159 described in [INSERT reference to adopted document on transport]. 161 While it is not anticipated that the existing niche solutions 162 described in the use cases section Section 3 will exchange claims 163 directly, the use of a common format enables common code. As some of 164 the code needs to be in intentionally hard to modify trusted modules, 165 the use of a common formats and transfer protocols significantly 166 reduces the cost of adoption to all parties. This commonality also 167 significantly reduces the incidence of critical bugs. 169 In some environments the collection of Evidence by the Attester to be 170 provided to the Verifier is part of an existing protocol: this 171 document does not change that, rather embraces those legacy 172 mechanisms as part of the specification. This is an evolutionary 173 path forward, not revolutionary. Yet in other greenfield 174 environments, there is a desire to have a standard for Evidence as 175 well as for Attestation Results, and this architecture outlines how 176 that is done. 178 This introduction gives an overview of the message flows and roles 179 involved. Following this, is a terminology section that is 180 referenced normatively by other documents and is a key part of this 181 document. There is then a section on use cases and how they leverage 182 the roles and workflows described. 184 In this document, terms defined within this document are consistently 185 Capitalized [work in progress. please raise issues, if there are 186 Blatant inconsistencies]. 188 Current verticals that use remote attestation include: 190 o The Trusted Computing Group "Network Device Attestation Workflow" 191 [I-D.fedorkow-rats-network-device-attestation] 193 o Android Keystore [keystore] 194 o Fast Identity Online (FIDO) Alliance attestation [fido] 196 o A number of Intel SGX niche systems based upon OTRP. 198 1.4. RATS in a Nutshell 200 1. Remote Attestation message flows typically convey Claims that 201 contain the trustworthiness properties associated with an 202 Attested Environment (Evidence). 204 2. A corresponding provisioning message flows conveys Reference 205 trustworthiness claims that can be compared with attestation 206 Evidence. Reference Values typically consist of firmware or 207 software digests and details about what makes the attesting 208 module a trusted source of Evidence. 210 3. Relying Parties are performing tasks such as managing a resource, 211 controlling access, and/or managing risk. Attestation Results 212 helps Relying Parties determine levels of trust. 214 1.5. Remote Attestation Workflow 216 The logical information flow is from Attester to Verifier to Relying 217 Party. There are variations presented below on how this integrates 218 into actual protocols. 220 ************ 221 * Asserter * 222 ************ 223 | 224 | 225 |Known-Good-Values 226 |Endorsements 227 | 228 v 229 .---------------. 230 | Verifier | 231 .--------->| |----------. 232 | | | | 233 | '---------------' | 234 | | 235 |Evidence |Attestation Results 236 | |(Claims) 237 | | 238 | v 239 .---------------. .---------------. 240 | Attester | | Relying Party | 241 | | | | 242 | | | | 243 '---------------' '---------------' 245 Figure 1: RATS Workflow 247 In the architecture shown above, specific content items (payload 248 conveyed in message flows) are identified: 250 o Evidence is as set of believable Claims about distinguishable 251 Environments made by an Attester. 253 o Known-Good-Values are reference Claims used to appraise Evidence 254 by an Verifier. 256 o Endorsements are reference Claims about the type of protection 257 that enables an Attester to create believable Evidence. 258 Endorsements enable trust relationships towards system components 259 or environments Evidence cannot be created for by an Attester. 261 o Attestation Results are the output from the appraisal of Evidence, 262 Known-Good-Values and Endorsements and are consumed by Relying 263 Parties. 265 Attestation Results are the output of RATS. 267 Assessment of Attestation Results is be multi-faceted and out-of- 268 scope for the architecture. 270 If appropriate Endorsements about the Attester are available, Known- 271 Good-Values about the Attester are available, and if the Attester is 272 capable of creating believable Evidence - then the Verifier is able 273 to create Attestation Results that enable Relying Parties to 274 establish a level of confidence in the trustworthiness of the 275 Attester. 277 The Asserter role and the format for Known-Good-Values and 278 Endorsements are not subject to standardization at this time. The 279 current verticals already include provisions for encoding and/or 280 distributing these objects. 282 1.6. Message Flows 284 Two distinct flows have been identified for passage of Evidence and 285 production of Attestation Results. It is possible that there are 286 additional situations which are not captured by these two flows. 288 1.6.1. Passport Model 290 In the Passport Model message flow the Attester provides it's 291 Evidence directly to the Verifier. The Verifier will evaluate the 292 Evidence and then sign an Attestation Result. This Attestation 293 Result is returned to the Attester, and it is up to the Attester to 294 communicate the Attestation Result (potentially including the 295 Evidence, if disclosable) to the Relying Party. 297 ************ 298 * Asserter * 299 ************ 300 |Known-Good-Values 301 |Endorsements 302 | 303 v 304 .---------------. 305 | Verifier | 306 | | 307 | | 308 '------------|--' 309 ^ | 310 | |Attestation Results 311 Evidence | |(Claims) 312 | | 313 | | 314 | v 315 .---|-----------. .---------------. 316 | Attester | | Relying Party | 317 | ----------------------> | 318 | | Attestation Results | | 319 '---------------' (Claims) '---------------' 321 Figure 2: RATS Passport Flow 323 This flow is named in this way because of the resemblance of how 324 Nations issue Passports to their citizens. The nature of the 325 Evidence that an individual needs to provide to it's local authority 326 is specific to the country involved. The citizen retains control of 327 the resulting document and presents it to other entities when it 328 needs to assert a citizenship or identity claim. 330 1.6.2. Background Check 332 In the Background-Check message flow the Attester provides it's 333 Evidence to the Relying Party. The Relying Party sends this evidence 334 to a Verifier of its choice. The Verifier will evaluate the Evidence 335 and then sign an Attestation Result. This Attestation Result is 336 returned to the Relying Party, which processes it directly. 338 ************ 339 * Asserter * 340 ************ 341 |Known-Good-Values 342 |Endorsements 343 | 344 v 345 .---------------. 346 | Verifier | 347 | | 348 | | 349 '--^---------|--' 350 | | 351 | |Attestation Results 352 Evidence | |(Claims) 353 | | 354 | v 355 .---------------. .--|------------. 356 | Attester | Evidence | Relying Party | 357 | ----------------------> | 358 | | | | 359 '---------------' '---------------' 361 Figure 3: RATS Background Check Flow 363 This flow is named in this way because of the resemblance of how 364 employers and volunteer organizations perform background checks. 365 When a prospective employee provides claims about education or 366 previous experience, the employer will contact the respective 367 institutions or former employers to validate the claim. Volunteer 368 organizations often perform police background checks on volunteers in 369 order to determine the volunteer's trustworthiness. 371 2. Terminology 373 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 374 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 375 "OPTIONAL" in this document are to be interpreted as described in 376 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 377 capitals, as shown here. 379 Appraisal: A Verifier process that compares Evidence to Reference 380 values while taking into account Endorsements and produces 381 Attestation Results. 383 Asserter: See Section 5.3.1.2. 385 Attester: See Section 5.3.1.1. 387 Attested Environment: A target environment that is observed or 388 controlled by an Attesting Environment. 390 Attesting Environment: An environment capable of making 391 trustworthiness Claims about an Attested Environment. 393 Background-Check Message Flow: An attestation workflow where the 394 Attester provides Evidence to a Relying Party, who consults one or 395 more Verifiers who supply Attestation Results to the Relying 396 Party. See Section 1.6.2. 398 Claim: A statement about the construction, composition, validation 399 or behavior of an Entity that affects trustworthiness. Evidence, 400 Reference Values and Attestation Results are expressions that 401 consists of one or more Claims. 403 Conveyance: The process of transferring Evidence, Reference Values 404 and Attestation Results between Entities participating in 405 attestation workflow. 407 Entity: A device, component (see System Component [RFC4949]), or 408 environment that implements one or more Roles. 410 Evidence: See Section 5.3.2.1. 412 Passport Message Flow: An attestation workflow where the Attester 413 provides Evidence to a Verifier who returns Attestation Results 414 that are then forwarded to one or more Relying Parties. See 415 Section 1.6.1. 417 Reference Values: See Section 5.3.2.2. Also referred to as Known- 418 Good-Values. 420 Relying Party: See Section 5.3.1.4. 422 Attestation Results: See Section 5.3.2.3. 424 Role: A function or process in an attestation workflow, typically 425 described by: Attester, Verifier, Relying Party and Asserter. 427 Verifier: See Section 5.3.1.3. 429 3. Reference use cases 431 This section provides an overview of a number of distinct use cases 432 that benefit from a standardized claim format. In addition to 433 outlining the user, the specific message flow is identified from 434 among the flows detailed in Section 1.6. 436 3.1. Device Capabilities/Firmware Attestation 438 This is a large category of claims that includes a number of 439 subcategories, not detailed here. 441 Use case name: Device Identity 443 Who will use it: Network Operators, larger enterprises 445 Attester: varies 447 Message Flow: sometimes passport and sometimes background check 449 Relying Party: varies 451 Description: Network operators want a trustworth report of identity 452 and version of information of the hardware and software on the 453 machines attached to their network. The process starts with some 454 kind of Root of Trust that provides device identity and protected 455 storage for measurements. The mechanism performs a series of 456 measurements, and expresses this with an attestation as to the 457 hardware and firmware/software which is running. 459 This is a general description for which there are many specific use 460 cases, including [I-D.fedorkow-rats-network-device-attestation] 461 section 1.2, "Software Inventory" 463 3.2. IETF TEEP WG Use-Case 465 Use case name: TAM validation 467 Who will use it: The TAM server 469 Message Flow: background check 471 Attester: Trusted Execution Environment (TEE) 473 Relying Party: end-application 475 Description: The "Trusted Application Manager (TAM)" server wants to 476 verify the state of a TEE, or applications in the TEE, of a 477 device. The TEE attests to the TAM, which can then decide whether 478 to install sensitive data in the TEE, or whether the TEE is out of 479 compliance and the TAM needs to install updated code in the TEE to 480 bring it back into compliance with the TAM's policy. 482 3.3. Safety Critical Systems 484 Use case name: Safety Critical Systems 486 Who will use it: Power plants and other systems that need to assert 487 their current state, but which can not accept any inputs from the 488 outside. The corollary system is a black-box (such as in an 489 aircraft), which needs to log the state of a system, but which can 490 never initiate a handshake. 492 Message Flow: background check 494 Attester: web services and other sources of status/sensor 495 information 497 Relying Party: open 499 Claims used as Evidence: the beginning and ending time as endorsed 500 by a Time Stamp Authority, represented by a time stamp token. The 501 real time clock of the system itself. A Root of Trust for time; 502 the TPM has a relative time from startup. 504 Description: These requirements motivate the creation of the Time- 505 Base Unidirectional Attestation (TUDA) [I-D.birkholz-rats-tuda], 506 the output of TUDA is typically a secure audit log, where 507 freshness is determined by synchronization to a trusted source of 508 external time. 510 The freshness is preserved in the Evidence by the use of a Time 511 Stamp Authority (TSA) which provides Time Stamp Tokens (TST). 513 3.4. Virtualized Multi-Tenant Hosts 515 Use case name: Multi-Tenant Hosts 517 Who will use it: Virtual machine systems 519 Message Flow: passport 521 Attester: virtual machine hypervisor 523 Relying Party: network operators 525 Description: The host system will do verification as per Section 3.1 527 The tenant virtual machines will do verification as per 528 Section 3.1. 530 The network operator wants to know if the system _as a whole_ is 531 free of malware, but the network operator is not allowed to know 532 who the tenants are. 534 This is contrasted to the Chassis + Line Cards case (To Be 535 Defined: TBD). 537 Multiple Line Cards, but a small attestation system on the main 538 card can combine things together. This is a kind of proxy. 540 3.5. Cryptographic Key Attestation 542 Cryptographic Attestion includes subcategories such as Device Type 543 Attestation (the FIDO use case), and Key storage Attestation (the 544 Android Keystore use case), and End-User Authorization. 546 Use case name: Key Attestation 548 Who will use it: network authentication systems 550 Message Flow: passport 552 Attester: device platform 554 Relying Party: internet peers 556 Description: The relying party wants to know how secure a private 557 key that identifies an entity is. Unlike the network attestation, 558 the relying party is not part of the network infrastructure, nor 559 do they necessarily have a business relationship (such as 560 ownership) over the end device. 562 The Device Type Attestation is provided by a Firmware TPM 563 performing the Verifier function, creating Attestation Results 564 that indicate a particular model/type of device. In TCG terms, 565 this is called Implicit Attestation, in this case the Attested 566 Environment is the (smartphone) Rich Execution Environment (REE) 567 ([I-D.ietf-teep-architecture] section 2), and the Attesting 568 Environment is within the TEE. 570 3.6. Geographic Evidence 572 Use case name: Location Evidence 574 Who will use it: geo-fenced systems 576 Message Flow: passport (probably) 577 Attester: secure GPS system(s) 579 Relying Party: internet peers 581 Description: The relying party wants to know the physical location 582 (on the planet earth, using a geodetic system) of the device. 583 This may be provided directly by a GPS/GLONASS/BeiDou/Galileo 584 module that is incorporated into a TPM. This may also be provided 585 by collecting other proximity messages from other device that the 586 relying party can form a trust relationship with. 588 3.7. Device Provenance Attestation 590 Use case name: RIV - Device Provenance 592 Who will use it: Industrial IoT devices 594 Message Flow: passport 596 Attester: network management station 598 Relying Party: a network entity 600 Description: A newly manufactured device needs to be onboarded into 601 a network where many if not all device management duties are 602 performed by the network owner. The device owner wants to verify 603 the device originated from a legitimate vendor. A cryptographic 604 device identity such as an IEEE802.1AR is embedded during 605 manufacturing and a certificate identifying the device is 606 delivered to the owner onboarding agent. The device authenticates 607 using its 802.1AR IDevID to prove it originated from the expected 608 vendor. 610 The device chain of custody from the original device manufacturer to 611 the new owner may also be verified as part of device provenance 612 attestation. The chain of custody history may be collected by a 613 cloud service or similar capability that the supply chain and owner 614 agree to use. 616 [I-D.fedorkow-rats-network-device-attestation] section 1.2 refers to 617 this as "Provable Device Identity", and section 2.3 details the 618 parties. 620 4. Conceptual Overview 622 In network protocol exchanges, it is often the case that one entity 623 (a Relying Party) requires an assessment of the trustworthiness of a 624 remote entity (an Attester or specific system components [RFC4949] 625 thereof). Remote ATtestation procedureS (RATS) enable Relying 626 Parties to establish a level of confidence in the trustworthiness of 627 Attesters through the 629 o Creation, 631 o Conveyance, and 633 o Appraisal 635 of attestation Evidence. 637 Qualities of Evidence: Evidence is composed of Claims about 638 trustworthiness (the set of Claims is unbounded). The system 639 characteristics of Attesters - the Environments they are composed- 640 of, and their continuous development - have an impact on the 641 veracity of trustworthiness Claims included in valid Evidence. 643 Valid Evidence about the intactness of an Attester must be 644 impossible to create by an untrustworthy or compromised 645 Environment of an Attester. 647 Qualities of Environments: The resilience of Environments that are 648 part of an Attester can vary widely - ranging from those highly 649 resistant to attacks to those having little or no resistance to 650 attacks. Configuration options, if set poorly, can result in a 651 highly resistant environment being operationally less resistant. 652 When a trustworthy Environment changes, it is possible that it 653 transitions from being trustworthy to being untrustworthy. 655 An untrustworthy or compromised Environment must never be able to 656 create valid Evidence expressing the intactness of an Attester. 658 The architecture provides a framework for anticipating when a 659 relevant change with respect to a trustworthiness attribute occurs, 660 what exactly changed and how relevant it is. The architecture also 661 creates a context for enabling an appropriate response by 662 applications, system software and protocol endpoints when changes to 663 trustworthiness attributes do occur. 665 Detailed protocol specifications for message flows are defined in 666 separate documents. 668 4.1. Two Types of Environments 670 An Attester produces Evidence about its own integrity, which means 671 "it measures itself". To disambiguate this recursive or circular 672 looking relationships, two types of Environments inside an Attester 673 are distinguished: 675 The attest-ED Environments and the attest-ING Environments. 677 Attested Environments are measured. They provide the raw values and 678 the information to be represented in Claims and ultimately expressed 679 as Evidence. 681 Attesting Environments conduct the measuring. They collect the 682 Claims, format them appropriately, and typically use key material and 683 cryptographic functions, such as signing or cipher algorithms, to 684 create Evidence. 686 Attesting Environments use system components that have to be trusted. 687 As a result, Evidence includes Claims about the Attested and the 688 Attesting Environments. Claims about the Attested Environments are 689 appraised using Reference Values and Claims about the Attesting 690 Environments are appraised using Endorsements. It is not mandated 691 that both Environments have to be separate, but it is highly 692 encouraged. Examples of separated Environments that can be used as 693 Attesting Environments include: Trusted Execution Environments (TEE), 694 embedded Secure Elements (eSE), or Hardware Security Modules (HSM). 696 In summary, the majority of the creation of evidence can take place 697 in an Attested Environments. Exemplary duties include the collection 698 and formatting of Claim values, or the trigger for creating Evidence. 699 A trusted sub-set of the creation of evidence can take place in an 700 Attesting Environment, that provide special protection with respect 701 to key material, identity documents, or primitive functions to create 702 the Evidence itself. 704 4.2. Evidence Creation Prerequisites 706 One or more Environments that are part of an Attester must be able to 707 conduct the following duties in order to create Evidence: 709 o monitoring trustworthiness attributes of other Environments, 711 o collecting trustworthiness attributes and create Claims about 712 them, 714 o serialize Claims using interoperable representations, 716 o provide integrity protection for the sets of Claims, and 718 o add appropriate attestation provenance attributes about the sets 719 of Claims. 721 4.3. Trustworthiness 723 The trustworthiness of an Attester and therefore the believability of 724 the Evidence it creates relies on the protection methods in place to 725 shield and restrict the use of key material and the duties conducted 726 by the Attesting Environment. In order to assess trustworthiness 727 effectively, it is mandatory to understand the trustworthiness 728 properties of the environments of an Attester. The corresponding 729 appraisal of Evidence that leads to such an assessment of 730 trustworthiness is the duty of a Verifier. 732 Trusting the assessment of a Verifier might com frome trusting the 733 Verifier's key material (direct trust), or trusting an Entity that 734 the Verifier is associated with via a certification path (indirect 735 trust). 737 The trustworthiness of corresponding Attestation Results also relies 738 on trust towards manufacturers and those manufacturer's hardware in 739 order to assess the integrity and resilience of that manufacturer's 740 devices. 742 A stronger level of security comes when information can be vouched 743 for by hardware or by (unchangeable) firmware, especially if such 744 hardware is physically resistant to hardware tampering. The 745 component that is implicitly trusted is often referred to as a Root 746 of Trust. 748 4.4. Workflow 750 The basic function of RATS is creation, conveyance and appraisal of 751 attestation Evidence. An Attester creates attestation Evidence that 752 are conveyed to a Verifier for appraisal. The appraisals compare 753 Evidence with expected Known-Good-Values obtained from Asserters 754 (e.g. Principals that are Supply Chain Entities). There can be 755 multiple forms of appraisal (e.g., software integrity verification, 756 device composition and configuration verification, device identity 757 and provenance verification). Attestation Results are the output of 758 appraisals. Attestation Results are signed and conveyed to Relying 759 Parties. Attestation Results provide the basis by which the Relying 760 Party may determine a level of confidence to place in the application 761 data or operations that follow. 763 The architecture defines attestation Roles: Attester, Verifier, 764 Asserter and Relying Party. Roles exchange messages, but their 765 structure is not defined in this document. The detailed definition 766 of the messages is in an appropriate document, such as 767 [I-D.ietf-rats-eat] or other protocols to be defined. Roles can be 768 combined in various ways into Principals, depending upon the needs of 769 the use case. Information Model representations are realized as data 770 structure and conveyance protocol specifications. 772 4.5. Interoperability between RATS 774 The RATS architecture anticipates use of information modeling 775 techniques that describe computing structures - their components/ 776 computational elements and corresponding capabilities - so that 777 verification operations may rely on the information model as an 778 interoperable way to navigate the structural complexity. 780 5. RATS Architecture 782 5.1. Goals 784 RATS architecture has the following goals: 786 o Enable semantic interoperability of attestation semantics through 787 information models about computing environments and 788 trustworthiness. 790 o Enable data structure interoperability related to claims, endpoint 791 composition / structure, and end-to-end integrity and 792 confidentiality protection mechanisms. 794 o Enable programmatic assessment of trustworthiness. (Note: 795 Mechanisms that manage risk, justify a level of confidence, or 796 determine a consequence of an attestation result are out of 797 scope). 799 o Provide the building blocks, including Roles and Principals that 800 enable the composition of service-chains/hierarchies and workflows 801 that can create and appraise evidence about the trustworthiness of 802 devices and services. 804 o Use-case driven architecture and design (see 805 [I-D.richardson-rats-usecases] and Section 3) 807 o Terminology conventions that are consistently applied across RATS 808 specifications. 810 o Reinforce trusted computing principles that include attestation. 812 5.2. Attestation Principles 814 Specifications developed by the RATS working group apply the 815 following principles: 817 o Freshness - replay of previously asserted Claims about an Attested 818 Environment can be detected. 820 o Identity - the Attesting Environment is identifiable (non- 821 anonymous). 823 o Context - the Attested Environment is well-defined (unambiguous). 825 o Provenance - the origin of Claims with respect to the Attested and 826 Attesting Environments are known. 828 o Validity - the expected lifetime of Claims about an Attested 829 Environment is known. 831 o Veracity - the believability (level of confidence) of Claims is 832 based on verifiable proofs. 834 5.3. Attestation Workflow 836 Attestation workflow helps a Relying Party make better decisions by 837 providing insight about the trustworthiness of endpoints 838 participating in a distributed system. The workflow consists 839 primarily of four roles; Relying Party, Verifier, Attester and 840 Asserter. Attestation messages contain information useful for 841 appraising the trustworthiness of an Attester endpoint and informing 842 the Relying Party of the appraisal result. 844 This section details the primary roles of an attestation workflow and 845 the messages they exchange. 847 5.3.1. Roles 849 An endpoint system (a.k.a., Entity) may implement one or more 850 attestation Roles to accommodate a variety of possible message flows. 851 Exemplary message flows are described in Section 1.6.1 and 852 Section 1.6.2. Role messages are secured by the Entity that 853 generated it. Entities possess credentials (e.g., cryptographic 854 keys) that authenticate, integrity protect and optionally 855 confidentiality protect attestation messages. 857 5.3.1.1. Attester 859 The Attester consists of both an Attesting Environment and an 860 Attested Environment. In some implementations these environments may 861 be combined. Other implementations may have multiples of Attesting 862 and Attested environments. Although endpoint environments can be 863 complex, and that complexity is security relevant, the basic function 864 of an Attester is to create Evidence that captures operational 865 conditions affecting trustworthiness. 867 5.3.1.2. Asserter 869 The Asserter role is out of scope. The mechanism by which an 870 Asserter communicates Known-Good-Values to a Verifier is also not 871 subject to standardization. Users of the RATS architecture are 872 assumed to have pre-existing mechanisms. 874 5.3.1.3. Verifier 876 The Verifier workflow function accepts Evidence from an Attester and 877 accepts Reference Values from one or more Asserters. Reference 878 values may be supplied a priori, cached or used to created policies. 879 The Verifier performs an appraisal by matching Claims found in 880 Evidence with Claims found in Reference Values and policies. If an 881 attested Claim value differs from an expected Claim value, the 882 Verifier flags this as a change possibly impacting trust level. 884 Endorsements may not have corresponding Claims in Evidence (because 885 of their intrinsic nature). Consequently, the Verifier need only 886 authenticate the endpoint and verify the Endorsements match the 887 endpoint identity. 889 The result of appraisals and Endorsements, informed by owner 890 policies, produces a new set of Claims that a Relying Party is suited 891 to consume. 893 5.3.1.4. Relying Party 895 A Role in an attestation workflow that accepts Attestation Results 896 from a Verifier that may be used by the Relying Party to inform 897 application specific decision making. How Attestation Results are 898 used to inform decision making is out-of-scope for this architecture. 900 5.3.2. Role Messages 902 5.3.2.1. Evidence 904 Claims that are formatted and protected by an Attester. 906 Evidence SHOULD satisfy Verifier expectations for freshness, 907 identity, context, provenance, validity, and veracity. 909 5.3.2.2. Reference Values 911 Reference-values are Claims that a manufacturer, vendor or other 912 supply chain entity makes that affects the trustworthiness of an 913 Attester endpoint. 915 Claims may be persistent properties of the endpoint due to the 916 physical nature of how it was manufactured or may reflect the 917 processes that were followed as part of moving the endpoint through a 918 supply-chain; e.g., validation or compliance testing. This class of 919 Reference-values is known as Endorsements. 921 Another class of Reference-values identifies the firmware and 922 software that could be installed in the endpoint after its 923 manufacture. A digest of the the firmware or software can be an 924 effective identifier for keeping track of the images produced by 925 vendors and installed on an endpoint. This class of Reference-value 926 is referred to as Known-Good-Value (KGV). 928 Known-Good-Values: Claims about the Attested Environment. 929 Typically, Known-Good-Value (KGV) Claims are message digests of 930 firmware, software or configuration data supplied by various 931 vendors. If an Attesting Environment implements cryptography, 932 they include Claims about key material. 934 Like Claims, Known-Good-Values SHOULD satisfy a Verifier's 935 expectations for freshness, identity, context, provenance, 936 validity, relevance and veracity. Known-Good-Values are reference 937 Claims that are - like Evidence - well formatted and protected 938 (e.g. signed). 940 Endorsements: Claims about immutable and implicit characteristics of 941 the Attesting Environment. Typically, endorsement Claims are 942 created by manufacturing or supply chain entities. 944 Endorsements are intended to increase the level of confidence with 945 respect to Evidence created by an Attester. 947 5.3.2.3. Attestation Results 949 Statements about the output of an appraisal of Evidence that are 950 created, formatted and protected by a Verifier. 952 Attestation Results provide the basis for a Relying Party to 953 establish a level of confidence in the trustworthiness of an 954 Attester. Attestation Results SHOULD satisfy Relying Party 955 expectations for freshness, identity, context, provenance, validity, 956 relevance and veracity. 958 5.4. Principals (Entities?) - Containers for the Roles 960 [The authors are unhappy with the term Principal, and have been 961 looking for something else. JOSE/JWT uses the term Principal] 963 Principals are Containers for the Roles. 965 Principals are users, organizations, devices and computing 966 environments (e.g., devices, platforms, services, peripherals). 968 Principals may implement one or more Roles. Massage flows occurring 969 within the same Principal are out-of-scope. 971 The methods whereby Principals may be identified, discovered, 972 authenticated, connected and trusted, though important, are out-of- 973 scope. 975 Principal operations that apply resiliency, scaling, load balancing 976 or replication are generally believed to be out-of-scope. 978 +------------------+ +------------------+ 979 | Principal 1 | | Principal 2 | 980 | +------------+ | | +------------+ | 981 | | | | | | | | 982 | | Role A |<-|---|->| Role D | | 983 | | | | | | | | 984 | +------------+ | | +------------+ | 985 | | | | 986 | +-----+------+ | | +-----+------+ | 987 | | | | | | | | 988 | | Role B |<-|---|->| Role E | | 989 | | | | | | | | 990 | +------------+ | | +------------+ | 991 | | | | 992 +------------------+ +------------------+ 994 Figure 4: Principals-Role Composition 996 Principals have the following properties: 998 o Multiplicity - Multiple instances of Principals that possess the 999 same Roles can exist. 1001 o Composition - Principals possessing different Roles can be 1002 combined into a singleton Principal possessing the union of Roles. 1003 Message flows between combined Principals is uninteresting. 1005 o Decomposition - A singleton Principal possessing multiple Roles 1006 can be divided into multiple Principals. 1008 6. Privacy Considerations 1010 The conveyance of Evidence and the resulting Attestation Results 1011 reveal a great deal of information about the internal state of a 1012 device. In many cases the whole point of the Attestation process is 1013 to provided reliable evidence about the type of the device and the 1014 firmware that the device is running. This information is 1015 particularly interesting to many attackers: knowing that a device is 1016 running a weak version of a the firmware provides a way to aim 1017 attacks better. 1019 Just knowing the existence of a device is itself a disclosure. 1021 Conveyance protocols must detail what kinds of information is 1022 disclosed, and to whom it is exposed. 1024 7. Security Considerations 1026 Evidence, Verifiable Assertions and Attestation Results SHOULD use 1027 formats that support end-to-end integrity protection and MAY support 1028 end-to-end confidentiality protection. 1030 Replay attacks are a concern that protocol implementations MUST deal 1031 with. This is typically done via a Nonce Claim, but the details 1032 belong to the protocol. 1034 All other attacks involving RATS structures are not explicitly 1035 addressed by the architecture. 1037 Additional security protections MAY be required of conveyance 1038 mechanisms. For example, additional means of authentication, 1039 confidentiality, integrity, replay, denial of service and privacy 1040 protection of RATS payloads and Principals may be needed. 1042 8. Acknowledgements 1044 Dave Thaler created the concepts of "Passport" and "Background 1045 Check". 1047 9. References 1048 9.1. Normative References 1050 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1051 Requirement Levels", BCP 14, RFC 2119, 1052 DOI 10.17487/RFC2119, March 1997, 1053 . 1055 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1056 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1057 May 2017, . 1059 9.2. Informative References 1061 [ABLP] Abadi, M., Burrows, M., Lampson, B., and G. Plotkin, "A 1062 Calculus for Access Control in Distributed Systems", 1063 Springer Annual International Cryptology Conference, 1064 page 1-23, DOI 10.1.1.36.691, 1991. 1066 [DOLEV-YAO] 1067 Dolev, D. and A. Yao, "On the security of public key 1068 protocols", IEEE Transactions on Information Theory Vol. 1069 29, pp. 198-208, DOI 10.1109/tit.1983.1056650, March 1983. 1071 [fido] FIDO Alliance, ., "FIDO Specification Overview", 2019, 1072 . 1074 [I-D.birkholz-rats-tuda] 1075 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 1076 "Time-Based Uni-Directional Attestation", draft-birkholz- 1077 rats-tuda-01 (work in progress), September 2019. 1079 [I-D.fedorkow-rats-network-device-attestation] 1080 Fedorkow, G. and J. Fitzgerald-McKay, "Network Device 1081 Attestation Workflow", draft-fedorkow-rats-network-device- 1082 attestation-00 (work in progress), July 2019. 1084 [I-D.ietf-rats-eat] 1085 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 1086 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 1087 ietf-rats-eat-01 (work in progress), July 2019. 1089 [I-D.ietf-teep-architecture] 1090 Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D. 1091 Liu, "Trusted Execution Environment Provisioning (TEEP) 1092 Architecture", draft-ietf-teep-architecture-03 (work in 1093 progress), July 2019. 1095 [I-D.richardson-rats-usecases] 1096 Richardson, M., Wallace, C., and W. Pan, "Use cases for 1097 Remote Attestation common encodings", draft-richardson- 1098 rats-usecases-05 (work in progress), October 2019. 1100 [iothreats] 1101 GDN, ., "The Internet of Things or the Internet of 1102 threats?", 2016, . 1105 [keystore] 1106 Google, ., "Android Keystore System", 2019, 1107 . 1110 [Lampson2007] 1111 Lampson, B., "Practical Principles for Computer Security", 1112 IOSPress Proceedings of Software System Reliability and 1113 Security, page 151-195, DOI 10.1.1.63.5360, 2007. 1115 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1116 Text on Security Considerations", BCP 72, RFC 3552, 1117 DOI 10.17487/RFC3552, July 2003, 1118 . 1120 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1121 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1122 . 1124 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1125 Tardo, "Network Endpoint Assessment (NEA): Overview and 1126 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 1127 . 1129 Authors' Addresses 1131 Henk Birkholz 1132 Fraunhofer SIT 1133 Rheinstrasse 75 1134 Darmstadt 64295 1135 Germany 1137 Email: henk.birkholz@sit.fraunhofer.de 1138 Monty Wiseman 1139 GE Global Research 1140 USA 1142 Email: monty.wiseman@ge.com 1144 Hannes Tschofenig 1145 ARM Ltd. 1146 110 Fulbourn Rd 1147 Cambridge CB1 9NJ 1148 UK 1150 Email: hannes.tschofenig@gmx.net 1152 Ned Smith 1153 Intel Corporation 1154 USA 1156 Email: ned.smith@intel.com 1158 Michael Richardson 1159 Sandelman Software Works 1160 Canada 1162 Email: mcr+ietf@sandelman.ca