idnits 2.17.1 draft-ietf-rats-reference-interaction-models-05.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 a Security Considerations section. ** 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 52 instances of too long lines in the document, the longest one being 158 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 (26 January 2022) is 821 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8610' is defined on line 871, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-07) exists of draft-birkholz-rats-tuda-06 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-14 == Outdated reference: A later version (-14) exists of draft-ietf-rats-tpm-based-network-device-attest-10 Summary: 4 errors (**), 0 flaws (~~), 5 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 M. Eckel 4 Intended status: Informational Fraunhofer SIT 5 Expires: 30 July 2022 W. Pan 6 Huawei Technologies 7 E. Voit 8 Cisco 9 26 January 2022 11 Reference Interaction Models for Remote Attestation Procedures 12 draft-ietf-rats-reference-interaction-models-05 14 Abstract 16 This document describes interaction models for remote attestation 17 procedures (RATS). Three conveying mechanisms -- Challenge/Response, 18 Uni-Directional, and Streaming Remote Attestation -- are illustrated 19 and defined. Analogously, a general overview about the information 20 elements typically used by corresponding conveyance protocols are 21 highlighted. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 30 July 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Disambiguation . . . . . . . . . . . . . . . . . . . . . 4 59 3. Scope and Intent . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Essential Requirements . . . . . . . . . . . . . . . . . . . 5 61 4.1. Endorsement of Attesting Environments . . . . . . . . . . 5 62 5. Normative Prerequisites . . . . . . . . . . . . . . . . . . . 6 63 6. Generic Information Elements . . . . . . . . . . . . . . . . 7 64 7. Interaction Models . . . . . . . . . . . . . . . . . . . . . 9 65 7.1. Challenge/Response Remote Attestation . . . . . . . . . . 9 66 7.1.1. Models and example sequences of Challenge/Response 67 Remote Attestation . . . . . . . . . . . . . . . . . 11 68 7.2. Uni-Directional Remote Attestation . . . . . . . . . . . 13 69 7.3. Streaming Remote Attestation . . . . . . . . . . . . . . 15 70 8. Additional Application-Specific Requirements . . . . . . . . 17 71 8.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 17 72 8.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 17 73 8.3. Hardware-Enforcement/Support . . . . . . . . . . . . . . 17 74 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 75 9.1. Implementer . . . . . . . . . . . . . . . . . . . . . . . 18 76 9.2. Implementation Name . . . . . . . . . . . . . . . . . . . 18 77 9.3. Implementation URL . . . . . . . . . . . . . . . . . . . 18 78 9.4. Maturity . . . . . . . . . . . . . . . . . . . . . . . . 18 79 9.5. Coverage and Version Compatibility . . . . . . . . . . . 18 80 9.6. License . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 9.7. Implementation Dependencies . . . . . . . . . . . . . . . 19 82 9.8. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 10. Security and Privacy Considerations . . . . . . . . . . . . . 19 84 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 87 12.2. Informative References . . . . . . . . . . . . . . . . . 20 88 Appendix A. CDDL Specification for a simple CoAP Challenge/ 89 Response Interaction . . . . . . . . . . . . . . . . . . 21 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 92 1. Introduction 94 Remote ATtestation procedureS (RATS, [I-D.ietf-rats-architecture]) 95 are workflows composed of roles and interactions, in which Verifiers 96 create Attestation Results about the trustworthiness of an Attester's 97 system component characteristics. The Verifier's assessment in the 98 form of Attestation Results is created based on Attestation Policies 99 and Evidence -- trustable and tamper-evident Claims Sets about an 100 Attester's system component characteristics -- generated by an 101 Attester. The roles _Attester_ and _Verifier_, as well as the 102 Conceptual Messages _Evidence_ and _Attestation Results_ are concepts 103 defined by the RATS Architecture [I-D.ietf-rats-architecture]. This 104 document defines interaction models that can be used in specific 105 RATS-related solution documents. The primary focus of this document 106 is the conveyance of attestation Evidence. The reference models 107 defined can also be applied to the conveyance of other Conceptual 108 Messages in RATS. Specific goals of this document are to: 110 1.) prevent inconsistencies in descriptions of interaction models in 111 other documents (due to text cloning and evolution over time), and to 112 2.) enable to highlight an exact delta/divergence between the core 113 set of characteristics captured here in this document and variants of 114 these interaction models used in other specifications or solutions. 116 In summary, this document enables the specification and design of 117 trustworthy and privacy preserving conveyance methods for attestation 118 Evidence from an Attester to a Verifier. While the conveyance of 119 other Conceptual Messages is out-of-scope the methods described can 120 also be applied to the conveyance of, for example, Endorsements or 121 Attestation Results. 123 2. Terminology 125 This document uses the following set of terms, roles, and concepts as 126 defined in [I-D.ietf-rats-architecture]: Attester, Verifier, Relying 127 Party, Conceptual Message, Evidence, Endorsement, Attestation Result, 128 Appraisal Policy, Attesting Environment, Target Environment 130 A PKIX Certificate is an X.509v3 format certificate as specified by 131 [RFC5280]. 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in 136 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 2.1. Disambiguation 141 The term "Remote Attestation" is a common expression and often 142 associated or connoted with certain properties. The term "Remote" in 143 this context does not necessarily refer to a remote entity in the 144 scope of network topologies or the Internet. It rather refers to 145 decoupled systems or entities that exchange the payload of the 146 Conceptual Message type called Evidence [I-D.ietf-rats-architecture]. 147 This conveyance can also be "Local", if the Verifier role is part of 148 the same entity as the Attester role, e.g., separate system 149 components of the same Composite Device (a single RATS entity). Even 150 if an entity takes on two or more different roles, the functions they 151 provide typically reside in isolated environments that are components 152 of the same entity. Examples of such isolated environments include: 153 a Trusted Execution Environment (TEE), Baseboard Management 154 Controllers (BMCs), as well as other physical or logical 155 protected/isolated/shielded Computing Environments (e.g. embedded 156 Secure Elements (eSE) or Trusted Platform Modules (TPM)). Readers of 157 this document should be familiar with the concept of Layered 158 Attestation as described in Section 3.1 Two Types of Environments of 159 an Attester in [I-D.ietf-rats-architecture] and the definition of 160 Attestation as described in 161 [I-D.ietf-rats-tpm-based-network-device-attest]. 163 3. Scope and Intent 165 This document focuses on generic interaction models between Attesters 166 and Verifiers in order to convey Evidence. Complementary procedures, 167 functions, or services that are required for a complete semantic 168 binding of the concepts defined in [I-D.ietf-rats-architecture] are 169 out-of-scope of this document. Examples include: identity 170 establishment, key distribution and enrollment, time synchronization, 171 as well as certificate revocation. 173 Furthermore, any processes and duties that go beyond carrying out 174 remote attestation procedures are out-of-scope. 176 For instance, using the results of a remote attestation procedure 177 that are created by the Verifier, e.g., how to triggering remediation 178 actions or recovery processes, as well as such remediation actions 179 and recovery processes themselves, are also out-of-scope. 181 The interaction models illustrated in this document are intended to 182 provide a stable basis and reference for other solutions documents 183 inside or outside the IETF. Solution documents of any kind can 184 reference the interaction models in order to avoid text clones and to 185 avoid the danger of subtle discrepancies. Analogously, deviations 186 from the generic model descriptions in this document can be 187 illustrated in solutions documents to highlight distinct 188 contributions. 190 4. Essential Requirements 192 In order to ensure appropriate conveyance of Evidence, there exist 193 essential requirements which MUST be fulfilled: 195 Integrity: Information provided by an Attester MUST be integral. 196 This may be achieved by means of a digital signature over 197 Attestation Evidence. The signature may be symmetric, such as an 198 HMAC, or asymmetric, such as ECDSA. 200 Authentication: The information provided by the Attester MUST be 201 authentic. For that purpose, the Attester should authenticate 202 itself to the Verifier. This may be an implicit authentication by 203 means of a digital signature over the Attestation Evidence, which 204 does not require additional protocol steps, or may be achieved by 205 using a confidential channel by means of encryption. 207 4.1. Endorsement of Attesting Environments 209 Via its Attesting Environments, an Attester only generates Evidence 210 about its Target Environments. After being appraised to be 211 trustworthy, a Target Environment may become a new Attesting 212 Environment in charge of generating Evidence for further Target 213 Environments. [I-D.ietf-rats-architecture] explains this as Layered 214 Attestation. Layered Attestation has to start with an initial 215 Attesting Environment. In essence, there cannot be turtles all the 216 way down [turtles]. At this rock bottom of Layered Attestation, the 217 Attesting Environments are always called Roots of Trust (RoT). An 218 Attester cannot generate Evidence about its own RoTs by design. As a 219 consequence, a Verifier requires trustable statements about this 220 subset of Attesting Environments from a different source than the 221 Attester itself. The corresponding trustable statements are called 222 Endorsements and originate from external, trustable entities that 223 take on the role of an Endorser (e.g., supply chain entities). 225 5. Normative Prerequisites 227 In order to ensure an appropriate conveyance of Evidence via 228 interaction models in general, the following set of prerequisites 229 MUST be in place to support the implementation of interaction models: 231 Authentication Secret: An Authentication Secret MUST be available 232 exclusively to an Attesting Environment of an Attester. 234 The Attester MUST protect Claims with that Authentication Secret, 235 thereby proving the authenticity of the Claims included in 236 Evidence. The Authentication Secret MUST be established before 237 RATS can take place. 239 Attester Identity: A statement about a distinguishable Attester made 240 by an Endorser. 242 The provenance of Evidence with respect to a distinguishable 243 Attesting Environment MUST be correct and unambiguous. 245 An Attester Identity MAY be an Authentication Secret which is 246 available exclusively to one of the Attesting Environments of an 247 Attester. It MAY be a unique identity, MAY be included in a zero- 248 knowledge proof (ZKP), MAY be part of a group signature, or it MAY 249 be a randomized DAA credential [DAA]. 251 Attestation Evidence Authenticity: Attestation Evidence MUST be 252 authentic. 254 In order to provide proofs of authenticity, Attestation Evidence 255 SHOULD be cryptographically associated with an identity document 256 (e.g., a PKIX certificate or trusted key material, or a randomized 257 DAA credential [DAA]), or SHOULD include a correct, unambiguous 258 and stable reference to an accessible identity document. 260 Evidence Freshness: Evidence MUST include an indicator about its 261 freshness that can be understood by a Verifier. Analogously, 262 interaction models MUST support the conveyance of proofs of 263 freshness in a way that is useful to Verifiers and their appraisal 264 procedures. 266 Evidence Protection: Evidence MUST be a set of well-formatted and 267 well-protected Claims that an Attester can create and convey to a 268 Verifier in a tamper-evident manner. 270 6. Generic Information Elements 272 This section defines the information elements that are vital to all 273 kinds interaction models. Varying from solution to solution, generic 274 information elements can be either included in the scope of protocol 275 messages (instantiating Conceptual Messages) or can be included in 276 additional protocol parameters or payload. Ultimately, the following 277 information elements are required by any kind of scalable remote 278 attestation procedure using one or more of the interaction models 279 provided. 281 Authentication Secret IDs ('authSecIDs'): _mandatory_ 283 A statement representing an identifier list that MUST be 284 associated with corresponding Authentication Secrets used to 285 protect Claims included in Evidence. 287 Each distinguishable Attesting Environment has access to a 288 protected capability that provides an Authentication Secret 289 associated with that Attesting Environment. Consequently, an 290 Authentication Secret ID can also identify an Attesting 291 Environment. 293 Handle ('handle'): _mandatory_ 295 A statement that is intended to uniquely distinguish received 296 Evidence and/or determine the freshness of Evidence. 298 A Verifier can also use a Handle as an indicator for authenticity 299 or attestation provenance, as only Attesters and Verifiers that 300 are intended to exchange Evidence should have knowledge of the 301 corresponding Handles. Examples include Nonces or signed 302 timestamps. 304 Claims ('claims'): _mandatory_ 306 Claims are assertions that represent characteristics of an 307 Attester's Target Environment. 309 Claims are part of a Conceptual Message and are, for example, used 310 to appraise the integrity of Attesters via Verifiers. The other 311 information elements in this section can be expressed as Claims in 312 any type of Conceptional Messages. 314 Event Logs ('eventLogs'): _optional_ 316 Event Logs accompany Claims by providing event trails of security- 317 critical events in a system. The primary purpose of Event Logs is 318 to support Claim reproducibility by providing information on how 319 Claims originated. 321 Reference Values ('refValues') _mandatory_ 323 Reference Values as defined in [I-D.ietf-rats-architecture]. This 324 specific type of Claims is used to appraise Claims incorporated in 325 Evidence. For example, Reference Values MAY be Reference 326 Integrity Measurements (RIM) or assertions that are implicitly 327 trusted because they are signed by a trusted authority (see 328 Endorsements in [I-D.ietf-rats-architecture]). Reference Values 329 typically represent (trusted) Claim sets about an Attester's 330 intended platform operational state. 332 Claim Selection ('claimSelection'): _optional_ 334 A (sub-)set of Claims which can be created by an Attester. 336 Claim Selections act as filters to specify the exact set of Claims 337 to be included in Evidence. In a remote attestation process, a 338 Verifier sends a Claim Selection, among other elements, to an 339 Attester. An Attester MAY decide whether or not to provide all 340 requested Claims from a Claim Selection to the Verifier. 342 Collected Claims ('collectedClaims'): _mandatory_ 344 Collected Claims represent a (sub-)set of Claims created by an 345 Attester. 347 Collected Claims are gathered based on the Claims selected in the 348 Claim Selection. If a Verifier does not provide a Claim 349 Selection, then all available Claims on the Attester are part of 350 the Collected Claims. 352 Evidence ('evidence'): _mandatory_ 354 A set of Claims that consists of a list of Authentication Secret 355 IDs that each identifies an Authentication Secret in a single 356 Attesting Environment, the Attester Identity, Claims, and a 357 Handle. Attestation Evidence MUST cryptographically bind all of 358 these information elements. Evidence MUST be protected via an 359 Authentication Secret. The Authentication Secret MUST be trusted 360 by the Verifier as authoritative. 362 Attestation Result ('attestationResult'): _mandatory_ 364 An Attestation Result is produced by the Verifier as the output of 365 the appraisal of Evidence. Attestation Results include condensed 366 assertions about integrity or other characteristics of the 367 corresponding Attester that are processible by Relying Parties. 369 7. Interaction Models 371 The following subsections introduce and illustrate the interaction 372 models: 374 1. Challenge/Response Remote Attestation 376 2. Uni-Directional Remote Attestation 378 3. Streaming Remote Attestation 380 Each section starts with a sequence diagram illustrating the 381 interactions between Attester and Verifier. While the presented 382 interaction models focus on the conveyance of Evidence, the intention 383 of this document is in support of future work that applies the 384 presented models to the conveyance of other Conceptual Messages, 385 namely Attestation Results, Endorsements, Reference Values, or 386 Appraisal Policies. 388 All interaction models have a strong focus on the use of a handle to 389 incorporate a type of proof of freshness and to prevent replay 390 attacks. The way these handles are processed is the most prominent 391 difference between the three interaction models. 393 7.1. Challenge/Response Remote Attestation 394 .----------. .----------. 395 | Attester | | Verifier | 396 '----------' '----------' 397 | | 398 generateClaims(attestingEnvironment) | 399 | => claims, eventLogs | 400 | | 401 | <-- requestAttestation(handle, authSecIDs, claimSelection) | 402 | | 403 collectClaims(claims, claimSelection) | 404 | => collectedClaims | 405 | | 406 generateEvidence(handle, authSecIDs, collectedClaims) | 407 | => evidence | 408 | | 409 | evidence, eventLogs -------------------------------------> | 410 | | 411 | appraiseEvidence(evidence, eventLogs, refValues) 412 | attestationResult <= | 413 | | 415 The Attester boots up and thereby produces claims about its boot 416 state and its operational state. Event Logs accompany the produced 417 claims by providing an event trail of security-critical events in a 418 system. Claims are produced by all attesting Environments of an 419 Attester system. 421 The Challenge/Response remote attestation procedure is initiated by 422 the Verifier by sending a remote attestation request to the Attester. 423 A request includes a Handle, a list of Authentication Secret IDs, and 424 a Claim Selection. 426 In the Challenge/Response model, the handle is composed of qualifying 427 data in the form of a practically infeasible to guess nonce, such as 428 a cryptographically strong random number. The Verifier-generated 429 nonce is intended to guarantee Evidence freshness and to prevent 430 replay attacks. 432 The list of Authentication Secret IDs selects the attestation keys 433 with which the Attester is requested to sign the Attestation 434 Evidence. Each selected key is uniquely associated with an Attesting 435 Environment of the Attester. As a result, a single Authentication 436 Secret ID identifies a single Attesting Environment. 437 Correspondingly, a particular set of Evidence originating from a 438 particular Attesting Environment in a composite device can be 439 requested via multiple Authentication Secret IDs. Methods to acquire 440 Authentication Secret IDs or mappings between Attesting Environments 441 to Authentication Secret IDs are out-of-scope of this document. 443 The Attester collects Claims based on the Claim Selection. With the 444 Claim Selection the Verifier defines the set of Claims it requires. 445 Correspondingly, collected Claims can be a subset of the produced 446 Claims. This could be all available Claims, depending on the Claim 447 Selection. If the Claim Selection is omitted, then by default all 448 Claims that are known and available on the Attester MUST be used to 449 create corresponding Evidence. For example, when performing a boot 450 integrity evaluation, a Verifier may only be requesting a particular 451 subset of claims about the Attester, such as Evidence about BIOS/UEFI 452 and firmware that the Attester booted up, and not include information 453 about all currently running software. 455 With the Handle, the Authentication Secret IDs, and the collected 456 Claims, the Attester produces signed Evidence. That is, it digitally 457 signs the Handle and the collected Claims with a cryptographic secret 458 identified by the Authentication Secret ID. This is done once per 459 Attesting Environment which is identified by the particular 460 Authentication Secret ID. The Attester communicates the signed 461 Evidence as well as all accompanying Event Logs back to the Verifier. 463 While it is crucial that Claims, the Handle, and the Attester 464 Identity information (i.e., the Authentication Secret) MUST be 465 cryptographically bound to the signature of Evidence, they MAY be 466 presented obfuscated, encrypted, or cryptographically blinded. For 467 further reference see section Section 10. 469 As soon as the Verifier receives the Evidence and the Event Logs, it 470 appraises the Evidence. For this purpose, it validates the 471 signature, the Attester Identity, and the Handle, and then appraises 472 the Claims. Appraisal procedures are application-specific and can be 473 conducted via comparison of the Claims with corresponding Reference 474 Values, such as Reference Integrity Measurements. The final output 475 of the Verifier are Attestation Results. Attestation Results 476 constitute new Claim Sets about the properties and characteristics of 477 an Attester, which enables Relying Parties, for example, to assess an 478 Attester's trustworthiness. 480 7.1.1. Models and example sequences of Challenge/Response Remote 481 Attestation 483 According to the RATS Architecture, two reference models for 484 Challenge/Response Attestation have been proposed. This section 485 highlights the information flows bewteen the Attester, Verifier and 486 Relying Party undergoing Remote Attestation Procedure, using these 487 models. 489 1. Passport Model 490 The passport model is so named because of its resemblance to how 491 nations issue passports to their citizens. In this model, the 492 attestation sequence is a two step procedure. In the first step, an 493 Attester conveys Evidence to a Verifier which compares the Evidence 494 against its appraisal policy. The Verifier then gives back an 495 Attestation Result to the Attester, which simply caches it. In the 496 second step, the Attester presents the Attestation Result (and 497 possibly additional Claims/evidence) to a Relying Party, which then 498 compares this information against its own appraisal policy to 499 establish the trustworthiness of the Attester. 501 .----------. .----------. .----------. 502 | Attester | | Verifier | | R. P. | 503 '----------' '----------' '----------' 504 | | | 505 generateClaims(attestingEnvironment) | | 506 | => claims, eventLogs | | 507 | | | 508 | <-- requestAttestation(handle, authSecIDs, claimSelection) | | 509 | | | 510 collectClaims(claims, claimSelection) | | 511 | => collectedClaims | | 512 | | | 513 generateEvidence(handle, authSecIDs, collectedClaims) | | 514 | => evidence | | 515 | | | 516 | evidence, eventLogs -------------------------------------> | | 517 | | | 518 | appraiseEvidence(evidence, eventLogs, refValues) | 519 | | | 520 | attestationResults <----------------------------------- | | 521 | | | 522 | attestationResults(evidence, results) ----------------------------------------------------------> | | | | 523 | | | | | | appraiseResult() 524 | | | 526 1. BackGround Check Model 528 The background-check model is so named because of the resemblance of 529 how employers and volunteer organizations perform background checks. 530 In this model, the attestation sequence is initiated by a Relying 531 Party. The Attester conveys Evidence to the Relying Party, which 532 does not process its payload, but realys the message and optionally 533 check its signature against a policed trust anchor store. Upon 534 receiving the evidence the Relying Party initiates a session with the 535 Verifier. Once session is established, it forwards the received 536 Evidence to the Verfier. The Verifier, appraises the received 537 Evidence according to its appraisal policy for Evidence and returns a 538 corresponding Attestation Result to the Relying Party. The Relying 539 Party then checks the Attestation Result against its own appraisal 540 policy to conclude attestation. 542 .----------. .----------. .----------. 543 | Attester | | R. P. | | Verifier | 544 '----------' '----------' '----------' 545 | | | 546 generateClaims(attestingEnvironment) | | 547 | => claims, eventLogs | | 548 | | | 549 | <-- requestAttestation(handle, authSecIDs, claimSelection) | | 550 | | | 551 collectClaims(claims, claimSelection) | | 552 | => collectedClaims | | 553 | | | 554 generateEvidence(handle, authSecIDs, collectedClaims) | | 555 | => evidence | | 556 | | | 557 | evidence, eventLogs -------------------------------------> | | 558 | | | 559 | | handle, evidence, eventLogs -------> | 560 | | |appraiseEvidenc() 561 | | | 562 | | attestationResults <--------------- | 563 | | (evidence, results) | 564 | | | 565 | appraiseResults(evidence, results) | | 566 | | | 568 7.2. Uni-Directional Remote Attestation 569 .----------. .--------------------. .----------. 570 | Attester | | Handle Distributor | | Verifier | 571 '----------' '--------------------' '----------' 572 | | | 573 | generateHandle() | 574 | | => handle | 575 | | | 576 | <----------------------------- handle | handle ----------> | 577 | | | 578 generateClaims(attestingEnvironment) x | 579 | => claims, eventLogs | 580 | | 581 collectClaims(claims, claimSelection) | 582 | => collectedClaims | 583 | | 584 generateEvidence(handle, authSecIDs, collectedClaims) | 585 | => evidence | 586 | | 587 | evidence, eventLogs -------------------------------------> | 588 | | 589 | appraiseEvidence(evidence, eventLogs, refValues) 590 | attestationResult <= | 591 ~ ~ 592 | | 593 **********[loop]******************************************************** 594 * | | * 595 * generateClaims(attestingEnvironment) | * 596 * | => claimsDelta, eventLogsDelta | * 597 * | | * 598 * collectClaims(claimsDelta, claimSelection) | * 599 * | => collectedClaimsDelta | * 600 * | | * 601 * generateEvidence(handle, authSecIDs, collectedClaimsDelta) | * 602 * | => evidence | * 603 * | | * 604 * | evidence, eventLogsDelta --------------------------------> | * 605 * | | * 606 * | appraiseEvidence(evidence, eventLogsDelta, refValues) * 607 * | attestationResult <= | * 608 * | | * 609 ************************************************************************ 610 | | 612 Uni-Directional Remote Attestation procedures can be initiated both 613 by the Attester and by the Verifier. Initiation by the Attester can 614 result in unsolicited pushes of Evidence to the Verifier. Initiation 615 by the Verifier always results in solicited pushes to the Verifier. 617 The Uni-Directional model uses the same information elements as the 618 Challenge/Response model. In the sequence diagram above, the 619 Attester initiates the conveyance of Evidence (comparable with a 620 RESTful POST operation or the emission of a beacon). While a request 621 of Evidence from the Verifier would result in a sequence diagram more 622 similar to the Challenge/Response model (comparable with a RESTful 623 GET operation). The specific manner how Handles are created and used 624 always remains as the distinguishing quality of this model. 626 In the Uni-Directional model, handles are composed of 627 cryptographically signed trusted timestamps as shown in 628 [I-D.birkholz-rats-tuda], potentially including other qualifying 629 data. The Handles are created by an external 3rd entity -- the 630 Handle Distributor -- which includes a trustworthy source of time, 631 and takes on the role of a Time Stamping Authority (TSA, as initially 632 defined in [RFC3161]). Timestamps created from local clocks 633 (absolute clocks using a global timescale, as well as relative 634 clocks, such as tick-counters) of Attesters and Verifiers MUST be 635 cryptographically bound to fresh Handles received from the Handle 636 Distributor. This binding provides a proof of synchronization that 637 MUST be included in all produced Evidence. Correspondingly, conveyed 638 Evidence in this model provides a proof that it was fresh at a 639 certain point in time. 641 While periodically pushing Evidence to the Verifier, the Attester 642 only needs to generate and convey evidence generated from Claim 643 values that have changed and new Event Logs entries since the 644 previous conveyance. These updates reflecting the differences are 645 called "delta" in the sequence diagram above. 647 Effectively, the Uni-Directional model allows for a series of 648 Evidence to be pushed to multiple Verifiers simultaneously. Methods 649 to detect excessive time drift that would mandate a fresh Handle to 650 be received by the Handle Distributor as well as timing of Handle 651 distribution are out-of-scope of this document. 653 7.3. Streaming Remote Attestation 654 .----------. .----------. 655 | Attester | | Verifier | 656 '----------' '----------' 657 | | 658 generateClaims(attestingEnvironment) | 659 | => claims, eventLogs | 660 | | 661 | <----------- subscribe(handle, authSecIDs, claimSelection) | 662 | subscriptionResult --------------------------------------> | 663 | | 664 collectClaims(claims, claimSelection) | 665 | => collectedClaims | 666 | | 667 generateEvidence(handle, authSecIDs, collectedClaims) | 668 | => evidence | 669 | | 670 | evidence, eventLogs -------------------------------------> | 671 | | 672 | appraiseEvidence(evidence, eventLogs, refValues) 673 | attestationResult <= | 674 ~ ~ 675 | | 676 **********[loop]******************************************************** 677 * | | * 678 * generateClaims(attestingEnvironment) | * 679 * | => claimsDelta, eventLogsDelta | * 680 * | | * 681 * collectClaims(claimsDelta, claimSelection) | * 682 * | => collectedClaimsDelta | * 683 * | | * 684 * generateEvidence(handle, authSecIDs, collectedClaimsDelta) | * 685 * | => evidence | * 686 * | | * 687 * | evidence, eventLogsDelta --------------------------------> | * 688 * | | * 689 * | appraiseEvidence(evidence, eventLogsDelta, refValues) * 690 * | attestationResult <= | * 691 * | | * 692 ************************************************************************ 693 | | 695 Streaming Remote Attestation procedures require the setup of 696 subscription state. Setting up subscription state between a Verifier 697 and an Attester is conducted via a subscribe operation. The 698 subscribe operation is used to convey required Handles for producing 699 Evidence. Effectively, this allows for a series of Evidence to be 700 pushed to a Verifier, similar to the Uni-Directional model. While a 701 Handle Distributor is not required in this model, it is also limited 702 to bi-lateral subscription relationships in which each Verifier has 703 to create and provide its individual Handle. Handles provided by a 704 specific subscribing Verifier MUST be used in Evidence generation for 705 that specific Verifier. The Streaming model uses the same 706 information elements as the Challenge/Response and the Uni- 707 Directional model. Methods to detect excessive time drift that would 708 mandate a refreshed Handle to be conveyed via another subscribe 709 operation are out-of-scope of this document. 711 8. Additional Application-Specific Requirements 713 Depending on the use cases covered, there can be additional 714 requirements. An exemplary subset is illustrated in this section. 716 8.1. Confidentiality 718 Confidentiality of exchanged attestation information may be 719 desirable. This requirement usually is present when communication 720 takes place over insecure channels, such as the public Internet. In 721 such cases, TLS may be used as a suitable communication protocol 722 which provides confidentiality protection. In private networks, such 723 as carrier management networks, it must be evaluated whether or not 724 the transport medium is considered confidential. 726 8.2. Mutual Authentication 728 In particular use cases, mutual authentication may be desirable in 729 such a way that a Verifier also needs to prove its identity to the 730 Attester, instead of only the Attester proving its identity to the 731 Verifier. 733 8.3. Hardware-Enforcement/Support 735 Depending on given usage scenarios, hardware support for secure 736 storage of cryptographic keys, crypto accelerators, as well as 737 protected or isolated execution environments can be mandatory 738 requirements. Well-known technologies in support of these 739 requirements are roots of trusts, such as Hardware Security Modules 740 (HSM), Physically Unclonable Functions (PUFs), Shielded Secrets, or 741 Trusted Executions Environments (TEEs). 743 9. Implementation Status 745 Note to RFC Editor: Please remove this section as well as references 746 to [BCP205] before AUTH48. 748 This section records the status of known implementations of the 749 protocol defined by this specification at the time of posting of this 750 Internet-Draft, and is based on a proposal described in [BCP205]. 751 The description of implementations in this section is intended to 752 assist the IETF in its decision processes in progressing drafts to 753 RFCs. Please note that the listing of any individual implementation 754 here does not imply endorsement by the IETF. Furthermore, no effort 755 has been spent to verify the information presented here that was 756 supplied by IETF contributors. This is not intended as, and must not 757 be construed to be, a catalog of available implementations or their 758 features. Readers are advised to note that other implementations may 759 exist. 761 According to [BCP205], "this will allow reviewers and working groups 762 to assign due consideration to documents that have the benefit of 763 running code, which may serve as evidence of valuable experimentation 764 and feedback that have made the implemented protocols more mature. 765 It is up to the individual working groups to use this information as 766 they see fit". 768 9.1. Implementer 770 The open-source implementation was initiated and is maintained by the 771 Fraunhofer Institute for Secure Information Technology - SIT. 773 9.2. Implementation Name 775 The open-source implementation is named "CHAllenge-Response based 776 Remote Attestation" or in short: CHARRA. 778 9.3. Implementation URL 780 The open-source implementation project resource can be located via: 781 https://github.com/Fraunhofer-SIT/charra 783 9.4. Maturity 785 The code's level of maturity is considered to be "prototype". 787 9.5. Coverage and Version Compatibility 789 The current version ('1bcb469') implements a challenge/response 790 interaction model and is aligned with the exemplary specification of 791 the CoAP FETCH bodies defined in Section Appendix A of this document. 793 9.6. License 795 The CHARRA project and all corresponding code and data maintained on 796 GitHub are provided under the BSD 3-Clause "New" or "Revised" 797 license. 799 9.7. Implementation Dependencies 801 The implementation requires the use of the official Trusted Computing 802 Group (TCG) open-source Trusted Software Stack (TSS) for the Trusted 803 Platform Module (TPM) 2.0. The corresponding code and data is also 804 maintained on GitHub and the project resources can be located via: 805 https://github.com/tpm2-software/tpm2-tss/ 807 The implementation uses the Constrained Application Protocol 808 [RFC7252] (http://coap.technology/) and the Concise Binary Object 809 Representation [RFC7049] (https://cbor.io/). 811 9.8. Contact 813 Michael Eckel (michael.eckel@sit.fraunhofer.de) 815 10. Security and Privacy Considerations 817 In a remote attestation procedure the Verifier or the Attester MAY 818 want to cryptographically blind several attributes. For instance, 819 information can be part of the signature after applying a one-way 820 function (e. g. a hash function). 822 There is also a possibility to scramble the Nonce or Attester 823 Identity with other information that is known to both the Verifier 824 and Attester. A prominent example is the IP address of the Attester 825 that usually is known by the Attester itself as well as the Verifier. 826 This extra information can be used to scramble the Nonce in order to 827 counter certain types of relay attacks. 829 11. Acknowledgments 831 Olaf Bergmann, Michael Richardson, and Ned Smith 833 12. References 835 12.1. Normative References 837 [BCP205] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 838 Code: The Implementation Status Section", BCP 205, 839 RFC 7942, DOI 10.17487/RFC7942, July 2016, 840 . 842 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 843 Requirement Levels", BCP 14, RFC 2119, 844 DOI 10.17487/RFC2119, March 1997, 845 . 847 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 848 "Internet X.509 Public Key Infrastructure Time-Stamp 849 Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 850 2001, . 852 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 853 Housley, R., and W. Polk, "Internet X.509 Public Key 854 Infrastructure Certificate and Certificate Revocation List 855 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 856 . 858 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 859 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 860 October 2013, . 862 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 863 Application Protocol (CoAP)", RFC 7252, 864 DOI 10.17487/RFC7252, June 2014, 865 . 867 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 868 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 869 May 2017, . 871 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 872 Definition Language (CDDL): A Notational Convention to 873 Express Concise Binary Object Representation (CBOR) and 874 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 875 June 2019, . 877 12.2. Informative References 879 [DAA] Brickell, E., Camenisch, J., and L. Chen, "Direct 880 Anonymous Attestation", page 132-145, ACM Proceedings of 881 the 11th ACM conference on Computer and Communications 882 Security, 2004. 884 [I-D.birkholz-rats-tuda] 885 Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann, 886 "Time-Based Uni-Directional Attestation", Work in 887 Progress, Internet-Draft, draft-birkholz-rats-tuda-06, 12 888 January 2022, . 891 [I-D.ietf-rats-architecture] 892 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 893 W. Pan, "Remote Attestation Procedures Architecture", Work 894 in Progress, Internet-Draft, draft-ietf-rats-architecture- 895 14, 9 December 2021, . 898 [I-D.ietf-rats-tpm-based-network-device-attest] 899 Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- 900 based Network Device Remote Integrity Verification", Work 901 in Progress, Internet-Draft, draft-ietf-rats-tpm-based- 902 network-device-attest-10, 30 December 2021, 903 . 906 [turtles] Rudnicki, R., "Turtles All the Way Down: Foundation, 907 Edifice, and Ruin in Faulkner and McCarthy", 908 DOI 10.1353/fau.2010.0002, The Faulkner Journal 25.2, 909 2010, . 911 Appendix A. CDDL Specification for a simple CoAP Challenge/Response 912 Interaction 914 The following CDDL specification is an exemplary proof-of-concept to 915 illustrate a potential implementation of the Challenge/Response 916 Interaction Model. The transfer protocol used is CoAP using the 917 FETCH operation. The actual resource operated on can be empty. Both 918 the Challenge Message and the Response Message are exchanged via the 919 FETCH operation and corresponding FETCH Request and FETCH Response 920 body. 922 In this example, evidence is created via the root-of-trust for 923 reporting primitive operation "quote" that is provided by a TPM 2.0. 925 RAIM-Bodies = CoAP-FETCH-Body / CoAP-FETCH-Response-Body 927 CoAP-FETCH-Body = [ hello: bool, ; if true, the AK-Cert is conveyed 928 nonce: bytes, 929 pcr-selection: [ + [ tcg-hash-alg-id: uint .size 2, ; TPM2_ALG_ID 930 [ + pcr: uint .size 1 ], 931 ] 932 ], 933 ] 935 CoAP-FETCH-Response-Body = [ attestation-evidence: TPMS_ATTEST-quote, 936 tpm-native-signature: bytes, 937 ? ak-cert: bytes, ; attestation key certificate 938 ] 940 TPMS_ATTEST-quote = [ qualifiediSigner: uint .size 2, ;TPM2B_NAME 941 TPMS_CLOCK_INFO, 942 firmwareVersion: uint .size 8 943 quote-responses: [ * [ pcr: uint .size 1, 944 + [ pcr-value: bytes, 945 ? hash-alg-id: uint .size 2, 946 ], 947 ], 948 ? pcr-digest: bytes, 949 ], 950 ] 952 TPMS_CLOCK_INFO = [ clock: uint .size 8, 953 resetCounter: uint .size 4, 954 restartCounter: uint .size 4, 955 save: bool, 956 ] 958 Authors' Addresses 960 Henk Birkholz 961 Fraunhofer SIT 962 Rheinstrasse 75 963 64295 Darmstadt 964 Germany 966 Email: henk.birkholz@sit.fraunhofer.de 967 Michael Eckel 968 Fraunhofer SIT 969 Rheinstrasse 75 970 64295 Darmstadt 971 Germany 973 Email: michael.eckel@sit.fraunhofer.de 975 Wei Pan 976 Huawei Technologies 978 Email: william.panwei@huawei.com 980 Eric Voit 981 Cisco Systems 983 Email: evoit@cisco.com