idnits 2.17.1 draft-ietf-rats-architecture-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 18 instances of too long lines in the document, the longest one being 4 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 (4 February 2020) is 1541 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4949' is mentioned on line 135, but not defined == Outdated reference: A later version (-07) exists of draft-birkholz-rats-tuda-01 == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-05 Summary: 1 error (**), 0 flaws (~~), 4 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: Informational D. Thaler 5 Expires: 7 August 2020 Microsoft 6 M. Richardson 7 Sandelman Software Works 8 N. Smith 9 Intel 10 4 February 2020 12 Remote Attestation Procedures Architecture 13 draft-ietf-rats-architecture-01 15 Abstract 17 In network protocol exchanges, it is often the case that one entity 18 (a Relying Party) requires evidence about a remote peer to assess the 19 peer's trustworthiness, and a way to appraise such evidence. The 20 evidence is typically a set of claims about its software and hardware 21 platform. This document describes an architecture for such remote 22 attestation procedures (RATS). 24 Note to Readers 26 Discussion of this document takes place on the RATS Working Group 27 mailing list (rats@ietf.org), which is archived at 28 https://mailarchive.ietf.org/arch/browse/rats/ 29 (https://mailarchive.ietf.org/arch/browse/rats/). 31 Source for this draft and an issue tracker can be found at 32 https://github.com/ietf-rats-wg/architecture (https://github.com/ 33 ietf-rats-wg/architecture). 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 7 August 2020. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Simplified BSD License text 62 as described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Reference Use Cases . . . . . . . . . . . . . . . . . . . . . 4 70 4. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 71 4.1. Composite Attester . . . . . . . . . . . . . . . . . . . 5 72 5. Topological Models . . . . . . . . . . . . . . . . . . . . . 7 73 5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 7 74 5.2. Background-Check Model . . . . . . . . . . . . . . . . . 8 75 5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 9 76 6. Two Types of Environments of an Attester . . . . . . . . . . 10 77 7. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 8. Conceptual Messages . . . . . . . . . . . . . . . . . . . . . 11 79 8.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 12 80 8.2. Endorsements . . . . . . . . . . . . . . . . . . . . . . 12 81 8.3. Attestation Results . . . . . . . . . . . . . . . . . . . 13 82 9. Claims Encoding Formats . . . . . . . . . . . . . . . . . . . 13 83 10. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 85 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 86 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 88 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 89 16. Informative References . . . . . . . . . . . . . . . . . . . 17 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 92 1. Introduction 94 95 Remote Attestation, as used in this document, is a process by which 96 one entity (the "Attester") provides evidence about its identity and 97 state to another remote entity (the "Relying Party"), which then 98 assesses the Attester's trustworthiness for the Relying Party's own 99 purposes. 101 2. Terminology 103 This document uses the following terms: 105 * Appraisal Policy for Evidence: A set of rules that direct how a 106 Verifier evaluates the validity of information about an Attester. 107 Compare /security policy/ in [RFC4949]. 109 * Appraisal Policy for Attestation Result: A set of rules that 110 direct how a Relying Party uses the evaluation results about an 111 Attester generated by the Verifiers. Compare /security policy/ in 112 [RFC4949]. 114 * Attestation Result: The evaluation results generated by a 115 Verifier, typically including information about an Attester, where 116 the Verifier vouches for the validity of the results. 118 * Attester: An entity whose attributes must be evaluated in order to 119 determine whether the entity is considered trustworthy, such as 120 when deciding whether the entity is authorized to perform some 121 operation. 123 * Endorsement: A secure statement that some entity (typically a 124 manufacturer) vouches for the integrity of an Attester's signing 125 capability. 127 * Endorser: An entity that creates Endorsements that can be used to 128 help evaluate trustworthiness of Attesters. 130 * Evidence: A set of information about an Attester that is to be 131 evaluated by a Verifier. 133 * Relying Party: An entity that depends on the validity of 134 information about another entity, typically for purposes of 135 authorization. Compare /relying party/ in [RFC4949]. 137 * Relying Party Owner: An entity, such as an administrator, that is 138 authorized to configure Appraisal Policy for Attestation Results 139 in a Relying Party. 141 * Verifier: An entity that evaluates the validity of Evidence about 142 an Attester. 144 * Verifier Owner: An entity, such as an administrator, that is 145 authorized to configure Appraisal Policy for Evidence in a 146 Verifier. 148 3. Reference Use Cases 150 152 4. Architectural Overview 154 Figure 1 depicts the data that flows between different roles, 155 independent of protocol or use case. 157 ************ ************ ***************** 158 * Endorser * * Verifier * * Relying Party * 159 ************ * Owner * * Owner * 160 | ************ ***************** 161 | | | 162 Endorsements| | | 163 | |Appraisal | 164 | |Policy for | 165 | |Evidence | Appraisal 166 | | | Policy for 167 | | | Attestation 168 | | | Result 169 v v | 170 .-----------------. | 171 .----->| Verifier |------. | 172 | '-----------------' | | 173 | | | 174 | Attestation| | 175 | Results | | 176 | Evidence | | 177 | | | 178 | v v 179 .----------. .-----------------. 180 | Attester | | Relying Party | 181 '----------' '-----------------' 183 Figure 1: Conceptual Data Flow 185 An Attester creates Evidence that is conveyed to a Verifier. 187 The Verifier uses the Evidence, and any Endorsements from Endorsers, 188 by applying an Evidence Appraisal Policy to assess the 189 trustworthiness of the Attester, and generates Attestation Results 190 for use by Relying Parties. The Evidence Appraisal Policy might be 191 obtained from an Endorser along with the Endorsements, or might be 192 obtained via some other mechanism such as being configured in the 193 Verifier by an administrator. 195 The Relying Party uses Attestation Results by applying its own 196 Appraisal Policy to make application-specific decisions such as 197 authorization decisions. The Attestation Result Appraisal Policy 198 might, for example, be configured in the Relying Party by an 199 administrator. 201 4.1. Composite Attester 203 A Composite Attester is an entity composed of multiple sub-entities 204 such that its trustworthiness has to be determined by evaluating all 205 these sub-entities. Each sub-entity has at least one Attesting 206 Environment collecting the claims from at least one Target 207 Environment, then this sub-entity generates Evidence about its 208 trustworthiness. Therefore each sub-entity can be called an 209 Attester. Among these Attesters, there may be only some, which can 210 be called Lead Attesters, that have the ability to communicate with 211 the Verifier. Other Attesters don't have this ability, but they are 212 connected to the Lead Attesters via internal links or network 213 connections, and they are evaluated via the Lead Attester's help. 215 For example, a carrier-grade router is a composite device consisting 216 of a chassis and multiple slots. The trustworthiness of the router 217 depends on all its slots' trustworthiness. Each slot has an 218 Attesting Environment such as a TPM or TEE collecting the claims of 219 its boot process, after which it generates Evidence from the claims. 220 Among these slots, only a main slot can communicate with the Verifier 221 while other slots cannot. But other slots can communicate with the 222 main slot by the links between them inside the router. So the main 223 slot collects the Evidence of other slots, produces the final 224 Evidence of the whole router and conveys the final Evidence to the 225 Verifier. Therefore the router is a Composite Attester, each slot is 226 an Attester, and the main slot is the Lead Attester. 228 Another example is a multi-chassis router composed of multiple single 229 carrier-grade routers. The multi-chassis router provides higher 230 throughput by interconnecting multiple routers and simpler management 231 by being logically treated as one router. Among these routers, there 232 is only one main router that connects to the Verifier. Other routers 233 are only connected to the main router by the network cables, and 234 therefore they are managed and verified via this main router. So, in 235 this case, the multi-chassis router is the Composite Attester, each 236 router is an Attester and the main router is the Lead Attester. 238 Figure 2 depicts the conceptual data flow for a Composite Attester. 240 .-----------------------------. 241 | Verifier | 242 '-----------------------------' 243 ^ 244 | 245 | Composite 246 | Evidence 247 | 248 .----------------------------------|-------------------------------. 249 | .--------------------------------|-----. .------------. | 250 | | .------------. | | | | 251 | | | Attesting |<--------| Attester B |-. | 252 | | |Environment | | '------------. | | 253 | | .----------------. | |<----------| Attester C |-. | 254 | | | Target | | | | '------------' | | 255 | | | Environment(s) | | |<------------| ... | | 256 | | | | '------------' | Evidence '------------' | 257 | | | | ^ | of | 258 | | | |------------/ | Attesters | 259 | | '----------------' Collecting | (via Internal Links or | 260 | | Claims | Network Connections) | 261 | | | | 262 | | Lead Attester A | | 263 | '--------------------------------------' | 264 | | 265 | Device/Composite Device/Attester/TBD #33 | 266 '------------------------------------------------------------------' 268 Figure 2: Conceptual Data Flow for a Composite Attester 270 In the Composite Attester, each Attester generates its own Evidence 271 by its Attesting Environment(s) collecting the claims from its Target 272 Environment(s). The Lead Attester collects the Evidence of all other 273 Attesters and then generates the Evidence of the whole Composite 274 Attester. 276 The Lead Attester's Attesting Environment may or may not include its 277 own Verifier. One situation is that the Attesting Environment has no 278 internal Verifier. In this situation, the Lead Attesting Environment 279 simply combines the various Evidences into the final Evidence that is 280 sent off to the remote Verifier, which evaluates the Composite 281 Attester's, including the Lead Attester's and other Attesters', 282 trustworthiness. 284 The other situation is that the Lead Attesting Environment has an 285 internal Verifier. After collecting the Evidence of other Attesters, 286 this Attesting Environment verifies them using Endorsements and 287 Appraisal Policies (obtained the same way as any other Verifier), for 288 evaluating these Attesters' trustworthiness. Then the Lead Attesting 289 Environment combines the Attestation Results into the final Evidence 290 of the whole Composite Attester which is sent off to the remote 291 Verifier, which might treat the claims obtained from the local 292 Attestation Results as if they were Evidence. 294 5. Topological Models 296 There are multiple possible models for communication between an 297 Attester, a Verifier, and a Relying Party. This section includes 298 some reference models, but this is not intended to be a restrictive 299 list, and other variations may exist. 301 5.1. Passport Model 303 In this model, an Attester sends Evidence to a Verifier, which 304 compares the Evidence against its Appraisal Policy. The Verifier 305 then gives back an Attestation Result. If the Attestation Result was 306 a successful one, the Attester can then present the Attestation 307 Result to a Relying Party, which then compares the Attestation Result 308 against its own Appraisal Policy. 310 Since the resource access protocol between the Attester and Relying 311 Party includes an Attestation Result, in this model the details of 312 that protocol constrain the serialization format of the Attestation 313 Result. The format of the Evidence on the other hand is only 314 constrained by the Attester-Verifier attestation protocol. 316 +-------------+ 317 | | Compare Evidence 318 | Verifier | against Appraisal Policy 319 | | 320 +-------------+ 321 ^ | 322 Evidence| |Attestation 323 | | Result 324 | v 325 +-------------+ +-------------+ 326 | |-------------->| | Compare Attestation 327 | Attester | Attestation | Relying | Result against 328 | | Result | Party | Appraisal Policy 329 +-------------+ +-------------+ 331 Figure 3: Passport Model 333 The passport model is so named because of its resemblance to how 334 nations issue passports to their citizens. The nature of the 335 Evidence that an individual needs to provide to its local authority 336 is specific to the country involved. The citizen retains control of 337 the resulting passport document and presents it to other entities 338 when it needs to assert a citizenship or identity claim, such as an 339 airport immigration desk. The passport is considered sufficient 340 because it vouches for the citizenship and identity claims, and it is 341 issued by a trusted authority. Thus, in this immigration desk 342 analogy, the passport issuing agency is a Verifier, the passport is 343 an Attestation Result, and the immigration desk is a Relying Party. 345 5.2. Background-Check Model 347 In this model, an Attester sends Evidence to a Relying Party, which 348 simply passes it on to a Verifier. The Verifier then compares the 349 Evidence against its Appraisal Policy, and returns an Attestation 350 Result to the Relying Party. The Relying Party then compares the 351 Attestation Result against its own security policy. 353 The resource access protocol between the Attester and Relying Party 354 includes Evidence rather than an Attestation Result, but that 355 Evidence is not processed by the Relying Party. Since the Evidence 356 is merely forwarded on to a trusted Verifier, any serialization 357 format can be used for Evidence because the Relying Party does not 358 need a parser for it. The only requirement is that the Evidence can 359 be _encapsulated in_ the format required by the resource access 360 protocol between the Attester and Relying Party. 362 However, like in the Passport model, an Attestation Result is still 363 consumed by the Relying Party and so the serialization format of the 364 Attestation Result is still important. If the Relying Party is a 365 constrained node whose purpose is to serve a given type resource 366 using a standard resource access protocol, it already needs the 367 parser(s) required by that existing protocol. Hence, the ability to 368 let the Relying Party obtain an Attestation Result in the same 369 serialization format allows minimizing the code footprint and attack 370 surface area of the Relying Party, especially if the Relying Party is 371 a constrained node. 373 +-------------+ 374 | | Compare Evidence 375 | Verifier | against Appraisal Policy 376 | | 377 +-------------+ 378 ^ | 379 Evidence| |Attestation 380 | | Result 381 | v 382 +-------------+ +-------------+ 383 | |-------------->| | Compare Attestation 384 | Attester | Evidence | Relying | Result against 385 | | | Party | Appraisal Policy 386 +-------------+ +-------------+ 388 Figure 4: Background-Check Model 390 The background-check model is so named because of the resemblance of 391 how employers and volunteer organizations perform background checks. 392 When a prospective employee provides claims about education or 393 previous experience, the employer will contact the respective 394 institutions or former employers to validate the claim. Volunteer 395 organizations often perform police background checks on volunteers in 396 order to determine the volunteer's trustworthiness. Thus, in this 397 analogy, a prospective volunteer is an Attester, the organization is 398 the Relying Party, and a former employer or government agency that 399 issues a report is a Verifier. 401 5.3. Combinations 403 One variation of the background-check model is where the Relying 404 Party and the Verifier on the same machine, and so there is no need 405 for a protocol between the two. 407 It is also worth pointing out that the choice of model is generally 408 up to the Relying Party, and the same device may need to attest to 409 different Relying Parties for different use cases (e.g., a network 410 infrastructure device to gain access to the network, and then a 411 server holding confidential data to get access to that data). As 412 such, both models may simultaneously be in use by the same device. 414 Figure 5 shows another example of a combination where Relying Party 1 415 uses the passport model, whereas Relying Party 2 uses an extension of 416 the background-check model. Specifically, in addition to the basic 417 functionality shown in Figure 4, Relying Party 2 actually provides 418 the Attestation Result back to the Attester, allowing the Attester to 419 use it with other Relying Parties. This is the model that the 420 Trusted Application Manager plans to support in the TEEP architecture 421 [I-D.ietf-teep-architecture]. 423 +-------------+ 424 | | Compare Evidence 425 | Verifier | against Appraisal Policy 426 | | 427 +-------------+ 428 ^ | 429 Evidence| |Attestation 430 | | Result 431 | v 432 +-------------+ 433 | | Compare 434 | Relying | Attestation Result 435 | Party 2 | against Appraisal Policy 436 +-------------+ 437 ^ | 438 Evidence| |Attestation 439 | | Result 440 | v 441 +----------+ +----------+ 442 | |-------------->| | Compare Attestation 443 | Attester | Attestation | Relying | Result against 444 | | Result | Party 1 | Appraisal Policy 445 +----------+ +----------+ 447 Figure 5: Example Combination 449 6. Two Types of Environments of an Attester 451 An Attester consists of at least one Attesting Environment and at 452 least one Target Environment. In some implementations, the Attesting 453 and Target Environments might be combined. Other implementations 454 might have multiple Attesting and Target Environments. One example 455 is a set of components in a boot sequence (e.g., ROM, firmware, OS, 456 and application) where a Target Environment is the Attesting 457 Environment for the next environment in the boot sequence. 459 Claims are collected from Target Environments. That is, Attesting 460 Environments collect the raw values and the information to be 461 represented in claims. Attesting Environments then format them 462 appropriately, and typically use key material and cryptographic 463 functions, such as signing or cipher algorithms, to create Evidence. 464 Examples of environments that can be used as Attesting Environments 465 include Trusted Execution Environments (TEE), embedded Secure 466 Elements (eSE), or Hardware Security Modules (HSM). 468 7. Trust Model 470 The scope of this document is scenarios for which a Relying Party 471 trusts a Verifier that can evaluate the trustworthiness of 472 information about an Attester. Such trust might come by the Relying 473 Party trusting the Verifier (or its public key) directly, or might 474 come by trusting an entity (e.g., a Certificate Authority) that is in 475 the Verifier's certificate chain. The Relying Party might implicitly 476 trust a Verifier (such as in the Verifying Relying Party 477 combination). Or, for a stronger level of security, the Relying 478 Party might require that the Verifier itself provide information 479 about itself that the Relying Party can use to evaluate the 480 trustworthiness of the Verifier before accepting its Attestation 481 Results. 483 In solutions following the background-check model, the Attester is 484 assumed to trust the Verifier (again, whether directly or indirectly 485 via a Certificate Authority that it trusts), since the Attester 486 relies on an Attestation Result it obtains from the Verifier, in 487 order to access resources. 489 The Verifier trusts (or more specifically, the Verifier's security 490 policy is written in a way that configures the Verifier to trust) a 491 manufacturer, or the manufacturer's hardware, so as to be able to 492 evaluate the trustworthiness of that manufacturer's devices. In 493 solutions with weaker security, a Verifier might be configured to 494 implicitly trust firmware or even software (e.g., a hypervisor). 495 That is, it might evaluate the trustworthiness of an application 496 component, or operating system component or service, under the 497 assumption that information provided about it by the lower-layer 498 hypervisor or firmware is true. A stronger level of security comes 499 when information can be vouched for by hardware or by ROM code, 500 especially if such hardware is physically resistant to hardware 501 tampering. The component that is implicitly trusted is often 502 referred to as a Root of Trust. 504 8. Conceptual Messages 505 8.1. Evidence 507 Today, Evidence tends to be highly device-specific, since the 508 information in the Evidence often includes vendor-specific 509 information that is necessary to fully describe the manufacturer and 510 model of the device including its security properties, the health of 511 the device, and the level of confidence in the correctness of the 512 information. Evidence is typically signed by the device (whether by 513 hardware, firmware, or software on the device), and evaluating it in 514 isolation would require Appraisal Policy to be based on device- 515 specific details (e.g., a device public key). 517 8.2. Endorsements 519 An Endorsement is a secure statement that some entity (e.g., a 520 manufacturer) vouches for the integrity of the device's signing 521 capability. For example, if the signing capability is in hardware, 522 then an Endorsement might be a manufacturer certificate that signs a 523 public key whose corresponding private key is only known inside the 524 device's hardware. Thus, when Evidence and such an Endorsement are 525 used together, evaluating them can be done against Appraisal Policy 526 that may not be specific to the device instance, but merely specific 527 to the manufacturer providing the Endorsement. For example, an 528 Appraisal Policy might simply check that devices from a given 529 manufacturer have information matching a set of known-good reference 530 values, or an Appraisal Policy might have a set of more complex logic 531 on how to evaluate the validity of information. 533 However, while an Appraisal Policy that treats all devices from a 534 given manufacturer the same may be appropriate for some use cases, it 535 would be inappropriate to use such an Appraisal Policy as the sole 536 means of authorization for use cases that wish to constrain _which_ 537 compliant devices are considered authorized for some purpose. For 538 example, an enterprise using attestation for Network Endpoint 539 Assessment may not wish to let every healthy laptop from the same 540 manufacturer onto the network, but instead only want to let devices 541 that it legally owns onto the network. Thus, an Endorsement may be 542 helpful information in authenticating information about a device, but 543 is not necessarily sufficient to authorize access to resources which 544 may need device-specific information such as a public key for the 545 device or component or user on the device. 547 8.3. Attestation Results 549 Attestation Results may indicate compliance or non-compliance with a 550 Verifier's Appraisal Policy. A result that indicates non-compliance 551 can be used by an Attester (in the passport model) or a Relying Party 552 (in the background-check model) to indicate that the Attester should 553 not be treated as authorized and may be in need of remediation. In 554 some cases, it may even indicate that the Evidence itself cannot be 555 authenticated as being correct. 557 An Attestation Result that indicates compliance can be used by a 558 Relying Party to make authorization decisions based on the Relying 559 Party's Appraisal Policy. The simplest such policy might be to 560 simply authorize any party supplying a compliant Attestation Result 561 signed by a trusted Verifier. A more complex policy might also 562 entail comparing information provided in the result against known- 563 good reference values, or applying more complex logic such 564 information. 566 Thus, Attestation Results often need to include detailed information 567 about the Attester, for use by Relying Parties, much like physical 568 passports and drivers licenses include personal information such as 569 name and date of birth. Unlike Evidence, which is often very device- 570 and vendor-specific, Attestation Results can be vendor-neutral if the 571 Verifier has a way to generate vendor-agnostic information based on 572 evaluating vendor-specific information in Evidence. This allows a 573 Relying Party's Appraisal Policy to be simpler, potentially based on 574 standard ways of expressing the information, while still allowing 575 interoperability with heterogeneous devices. 577 Finally, whereas Evidence is signed by the device (or indirectly by a 578 manufacturer, if Endorsements are used), Attestation Results are 579 signed by a Verifier, allowing a Relying Party to only need a trust 580 relationship with one entity, rather than a larger set of entities, 581 for purposes of its Appraisal Policy. 583 9. Claims Encoding Formats 585 The following diagram illustrates a relationship to which attestation 586 is desired to be added: 588 +-------------+ +-------------+ 589 | |-------------->| | 590 | Attester | Access some | Relying | Evaluate request 591 | | resource | Party | against security policy 592 +-------------+ +-------------+ 594 Figure 6: Typical Resource Access 596 In this diagram, the protocol between Attester and a Relying Party 597 can be any new or existing protocol (e.g., HTTP(S), COAP(S), 802.1x, 598 OPC UA, etc.), depending on the use case. Such protocols typically 599 already have mechanisms for passing security information for purposes 600 of authentication and authorization. Common formats include JWTs 601 [RFC7519], CWTs [RFC8392], and X.509 certificates. 603 To enable attestation to be added to existing protocols, enabling a 604 higher level of assurance against malware for example, it is 605 important that information needed for evaluating the Attester be 606 usable with existing protocols that have constraints around what 607 formats they can transport. For example, OPC UA [OPCUA] (probably 608 the most common protocol in industrial IoT environments) is defined 609 to carry X.509 certificates and so security information must be 610 embedded into an X.509 certificate to be passed in the protocol. 611 Thus, attestation-related information could be natively encoded in 612 X.509 certificate extensions, or could be natively encoded in some 613 other format (e.g., a CWT) which in turn is then encoded in an X.509 614 certificate extension. 616 Especially for constrained nodes, however, there is a desire to 617 minimize the amount of parsing code needed in a Relying Party, in 618 order to both minimize footprint and to minimize the attack surface 619 area. So while it would be possible to embed a CWT inside a JWT, or 620 a JWT inside an X.509 extension, etc., there is a desire to encode 621 the information natively in the format that is natural for the 622 Relying Party. 624 This motivates having a common "information model" that describes the 625 set of attestation related information in an encoding-agnostic way, 626 and allowing multiple encoding formats (CWT, JWT, X.509, etc.) that 627 encode the same information into the claims format needed by the 628 Relying Party. 630 The following diagram illustrates that Evidence and Attestation 631 Results might each have multiple possible encoding formats, so that 632 they can be conveyed by various existing protocols. It also 633 motivates why the Verifier might also be responsible for accepting 634 Evidence that encodes claims in one format, while issuing Attestation 635 Results that encode claims in a different format. 637 Evidence Attestation Results 639 .--------------. CWT CWT .-------------------. 640 | Attester-A |------------. .----------->| Relying Party V | 641 '--------------' v | `-------------------' 642 .--------------. JWT .------------. JWT .-------------------. 643 | Attester-B |-------->| Verifier |-------->| Relying Party W | 644 '--------------' | | `-------------------' 645 .--------------. X.509 | | X.509 .-------------------. 646 | Attester-C |-------->| |-------->| Relying Party X | 647 '--------------' | | `-------------------' 648 .--------------. TPM | | TPM .-------------------. 649 | Attester-D |-------->| |-------->| Relying Party Y | 650 '--------------' '------------' `-------------------' 651 .--------------. other ^ | other .-------------------. 652 | Attester-E |------------' '----------->| Relying Party Z | 653 '--------------' `-------------------' 655 Figure 7: Multiple Attesters and Relying Parties with Different 656 Formats 658 10. Freshness 660 It is important to prevent replay attacks where an attacker replays 661 old Evidence or an old Attestation Result that is no longer correct. 662 To do so, some mechanism of ensuring that the Evidence and 663 Attestation Result are fresh, meaning that there is some degree of 664 assurance that they still reflect the latest state of the Attester, 665 and that any Attestation Result was generated using the latest 666 Appraisal Policy for Evidence. There is, however, always a race 667 condition possible in that the state of the Attester, and the 668 Appraisal Policy for Evidence, may change immediately after the 669 Evidence or Attestation Result was generated. The goal is merely to 670 narrow the time window to something the Verifier (for Evidence) or 671 Relying Party (for an Attestation Result) is willing to accept. 673 There are two common approaches to providing some assurance of 674 freshness. The first approach is that a nonce is generated by a 675 remote entity (e.g., the Verifier for Evidence, or the Relying Party 676 for an Attestation Result), and the nonce is then signed and included 677 along with the claims in the Evidence or Attestation Result, so that 678 the remote entity knows that the claims were signed after the nonce 679 was generated. 681 A second approach is to rely on synchronized clocks, and include a 682 signed timestamp (e.g., using [I-D.birkholz-rats-tuda]) along with 683 the claims in the Evidence or Attestation Result, so that the remote 684 entity knows that the claims were signed at that time, as long as it 685 has some assurance that the timestamp is correct. This typically 686 requires additional claims about the signer's time synchronization 687 mechanism in order to provide such assurance. 689 In either approach, it is important to note that the actual values in 690 claims might have been generated long before the claims are signed. 691 If so, it is the signer's responsibility to ensure that the values 692 are still correct when they are signed. For example, values might 693 have been generated at boot, and then used in claims as long as the 694 signer can guarantee that they cannot have changed since boot. 696 11. Privacy Considerations 698 The conveyance of Evidence and the resulting Attestation Results 699 reveal a great deal of information about the internal state of a 700 device. In many cases, the whole point of the Attestation process is 701 to provide reliable information about the type of the device and the 702 firmware/software that the device is running. This information is 703 particularly interesting to many attackers. For example, knowing 704 that a device is running a weak version of firmware provides a way to 705 aim attacks better. 707 Protocols that convey Evidence or Attestation Results are responsible 708 for detailing what kinds of information are disclosed, and to whom 709 they are exposed. 711 12. Security Considerations 713 Any solution that conveys information used for security purposes, 714 whether such information is in the form of Evidence, Attestation 715 Results, or Endorsements, or Appraisal Policy, needs to support end- 716 to-end integrity protection and replay attack prevention, and often 717 also needs to support additional security protections. For example, 718 additional means of authentication, confidentiality, integrity, 719 replay, denial of service and privacy protection are needed in many 720 use cases. Section 10 discusses ways in which freshness can be used 721 in this architecture to protect against replay attacks. 723 To evaluate the security provided by a particular Appraisal Policy, 724 it is important to understand the strength of the Root of Trust, 725 e.g., whether it is mutable software, or firmware that is read-only 726 after boot, or immutable hardware/ROM. 728 It is also important that the Appraisal Policy was itself obtained 729 securely. As such, if Appraisal Policy in a Relying Party or 730 Verifier can be configured via a network protocol, the ability to 731 attest to the health of the client providing the Appraisal Policy 732 needs to be considered. 734 13. IANA Considerations 736 This document does not require any actions by IANA. 738 14. Acknowledgments 740 Special thanks go to David Wooten, Joerg Borchert, Hannes Tschofenig, 741 Laurence Lundblade, Diego Lopez, Jessica Fitzgerald-McKay, Frank Xia, 742 and Nancy Cam-Winget. 744 15. Contributors 746 Thomas Hardjono created older versions of the terminology section in 747 collaboration with Ned Smith. Eric Voit provided the conceptual 748 separation between Attestation Provision Flows and Attestation 749 Evidence Flows. Monty Wisemen created the content structure of the 750 first three architecture drafts. Carsten Bormann provided many of 751 the motivational building blocks with respect to the Internet Threat 752 Model. 754 16. Informative References 756 [I-D.birkholz-rats-tuda] 757 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 758 "Time-Based Uni-Directional Attestation", Work in 759 Progress, Internet-Draft, draft-birkholz-rats-tuda-01, 11 760 September 2019, . 763 [I-D.ietf-teep-architecture] 764 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 765 "Trusted Execution Environment Provisioning (TEEP) 766 Architecture", Work in Progress, Internet-Draft, draft- 767 ietf-teep-architecture-05, 12 December 2019, 768 . 771 [OPCUA] OPC Foundation, "OPC Unified Architecture Specification, 772 Part 2: Security Model, Release 1.03", OPC 10000-2 , 25 773 November 2015, . 777 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 778 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 779 . 781 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 782 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 783 May 2018, . 785 Authors' Addresses 787 Henk Birkholz 788 Fraunhofer SIT 789 Rheinstrasse 75 790 64295 Darmstadt 791 Germany 793 Email: henk.birkholz@sit.fraunhofer.de 795 Dave Thaler 796 Microsoft 797 United States of America 799 Email: dthaler@microsoft.com 801 Michael Richardson 802 Sandelman Software Works 803 Canada 805 Email: mcr+ietf@sandelman.ca 807 Ned Smith 808 Intel Corporation 809 United States of America 811 Email: ned.smith@intel.com