idnits 2.17.1 draft-ietf-rats-reference-interaction-models-02.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 3 instances of too long lines in the document, the longest one being 16 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 April 2021) is 1095 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8610' is defined on line 784, 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-04 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-12 == Outdated reference: A later version (-14) exists of draft-ietf-rats-tpm-based-network-device-attest-06 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: 28 October 2021 W. Pan 6 Huawei Technologies 7 E. Voit 8 Cisco 9 26 April 2021 11 Reference Interaction Models for Remote Attestation Procedures 12 draft-ietf-rats-reference-interaction-models-02 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 28 October 2021. 40 Copyright Notice 42 Copyright (c) 2021 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 Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified 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.2. Uni-Directional Remote Attestation . . . . . . . . . . . 11 67 7.3. Streaming Remote Attestation . . . . . . . . . . . . . . 13 68 8. Additional Application-Specific Requirements . . . . . . . . 15 69 8.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 15 70 8.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 15 71 8.3. Hardware-Enforcement/Support . . . . . . . . . . . . . . 15 72 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 73 9.1. Implementer . . . . . . . . . . . . . . . . . . . . . . . 16 74 9.2. Implementation Name . . . . . . . . . . . . . . . . . . . 16 75 9.3. Implementation URL . . . . . . . . . . . . . . . . . . . 16 76 9.4. Maturity . . . . . . . . . . . . . . . . . . . . . . . . 16 77 9.5. Coverage and Version Compatibility . . . . . . . . . . . 16 78 9.6. License . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 9.7. Implementation Dependencies . . . . . . . . . . . . . . . 17 80 9.8. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 10. Security and Privacy Considerations . . . . . . . . . . . . . 17 82 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 85 12.2. Informative References . . . . . . . . . . . . . . . . . 18 86 Appendix A. CDDL Specification for a simple CoAP Challenge/ 87 Response Interaction . . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 90 1. Introduction 92 Remote ATtestation procedureS (RATS, [I-D.ietf-rats-architecture]) 93 are workflows composed of roles and interactions, in which Verifiers 94 create Attestation Results about the trustworthiness of an Attester's 95 system component characteristics. The Verifier's assessment in the 96 form of Attestation Results is created based on Attestation Policies 97 and Evidence -- trustable and tamper-evident Claims Sets about an 98 Attester's system component characteristics -- generated by an 99 Attester. The roles _Attester_ and _Verifier_, as well as the 100 Conceptual Messages _Evidence_ and _Attestation Results_ are concepts 101 defined by the RATS Architecture [I-D.ietf-rats-architecture]. This 102 document defines interaction models that can be used in specific 103 RATS-related solution documents. The primary focus of this document 104 is the conveyance of attestation Evidence. The reference models 105 defined can also be applied to the conveyance of other Conceptual 106 Messages in RATS. Specific goals of this document are to: 108 1.) prevent inconsistencies in descriptions of interaction models in 109 other documents (due to text cloning and evolution over time), and to 110 2.) enable to highlight an exact delta/divergence between the core 111 set of characteristics captured here in this document and variants of 112 these interaction models used in other specifications or solutions. 114 In summary, this document enables the specification and design of 115 trustworthy and privacy preserving conveyance methods for attestation 116 Evidence from an Attester to a Verifier. While the conveyance of 117 other Conceptual Messages is out-of-scope the methods described can 118 also be applied to the conveyance of, for example, Endorsements or 119 Attestation Results. 121 2. Terminology 123 This document uses the following set of terms, roles, and concepts as 124 defined in [I-D.ietf-rats-architecture]: Attester, Verifier, Relying 125 Party, Conceptual Message, Evidence, Endorsement, Attestation Result, 126 Appraisal Policy, Attesting Environment, Target Environment 128 A PKIX Certificate is an X.509v3 format certificate as specified by 129 [RFC5280]. 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in 134 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 2.1. Disambiguation 139 The term "Remote Attestation" is a common expression and often 140 associated or connoted with certain properties. The term "Remote" in 141 this context does not necessarily refer to a remote entity in the 142 scope of network topologies or the Internet. It rather refers to 143 decoupled systems or entities that exchange the payload of the 144 Conceptual Message type called Evidence [I-D.ietf-rats-architecture]. 145 This conveyance can also be "Local", if the Verifier role is part of 146 the same entity as the Attester role, e.g., separate system 147 components of the same Composite Device (a single RATS entity). Even 148 if an entity takes on two or more different roles, the functions they 149 provide typically reside in isolated environments that are components 150 of the same entity. Examples of such isolated environments include: 151 a Trusted Execution Environment (TEE), Baseboard Management 152 Controllers (BMCs), as well as other physical or logical 153 protected/isolated/shielded Computing Environments (e.g. embedded 154 Secure Elements (eSE) or Trusted Platform Modules (TPM)). Readers of 155 this document should be familiar with the concept of Layered 156 Attestation as described in Section 3.1 Two Types of Environments of 157 an Attester in [I-D.ietf-rats-architecture] and the definition of 158 Attestation as described in 159 [I-D.ietf-rats-tpm-based-network-device-attest]. 161 3. Scope and Intent 163 This document focuses on generic interaction models between Attesters 164 and Verifiers in order to convey Evidence. Complementary procedures, 165 functions, or services that are required for a complete semantic 166 binding of the concepts defined in [I-D.ietf-rats-architecture] are 167 out-of-scope of this document. Examples include: identity 168 establishment, key distribution and enrollment, time synchronization, 169 as well as certificate revocation. 171 Furthermore, any processes and duties that go beyond carrying out 172 remote attestation procedures are out-of-scope. 174 For instance, using the results of a remote attestation procedure 175 that are created by the Verifier, e.g., how to triggering remediation 176 actions or recovery processes, as well as such remediation actions 177 and recovery processes themselves, are also out-of-scope. 179 The interaction models illustrated in this document are intended to 180 provide a stable basis and reference for other solutions documents 181 inside or outside the IETF. Solution documents of any kind can 182 reference the interaction models in order to avoid text clones and to 183 avoid the danger of subtle discrepancies. Analogously, deviations 184 from the generic model descriptions in this document can be 185 illustrated in solutions documents to highlight distinct 186 contributions. 188 4. Essential Requirements 190 In order to ensure appropriate conveyance of Evidence, there exist 191 essential requirements which MUST be fulfilled: 193 Integrity: Information provided by an Attester MUST be integral. 194 This may be achieved by means of a digital signature over 195 Attestation Evidence. The signature may be symmetric, such as an 196 HMAC, or asymmetric, such as ECDSA. 198 Authentication: The information provided by the Attester MUST be 199 authentic. For that purpose, the Attester should authenticate 200 itself to the Verifier. This may be an implicit authentication by 201 means of a digital signature over the Attestation Evidence, which 202 does not require additional protocol steps, or may be achieved by 203 using a confidential channel by means of encryption. 205 4.1. Endorsement of Attesting Environments 207 Via its Attesting Environments, an Attester only generates Evidence 208 about its Target Environments. After being appraised to be 209 trustworthy, a Target Environment may become a new Attesting 210 Environment in charge of generating Evidence for further Target 211 Environments. [I-D.ietf-rats-architecture] explains this as Layered 212 Attestation. Layered Attestation has to start with an initial 213 Attesting Environment. In essence, there cannot be turtles all the 214 way down [turtles]. At this rock bottom of Layered Attestation, the 215 Attesting Environments are always called Roots of Trust (RoT). An 216 Attester cannot generate Evidence about its own RoTs by design. As a 217 consequence, a Verifier requires trustable statements about this 218 subset of Attesting Environments from a different source than the 219 Attester itself. The corresponding trustable statements are called 220 Endorsements and originate from external, trustable entities that 221 take on the role of an Endorser (e.g., supply chain entities). 223 5. Normative Prerequisites 225 In order to ensure an appropriate conveyance of Evidence via 226 interaction models in general, the following set of prerequisites 227 MUST be in place to support the implementation of interaction models: 229 Attester Identity: A statement about a distinguishable Attester made 230 by an Endorser without accompanying evidence about its validity, 231 used as proof of identity. 233 The provenance of Evidence with respect to a distinguishable 234 Attesting Environment MUST be correct and unambiguous. 236 An Attester Identity MAY be a unique identity, MAY be included in 237 a zero-knowledge proof (ZKP), MAY be part of a group signature, or 238 it MAY be a randomized DAA credential [DAA]. 240 Attestation Evidence Authenticity: Attestation Evidence MUST be 241 authentic. 243 In order to provide proofs of authenticity, Attestation Evidence 244 SHOULD be cryptographically associated with an identity document 245 (e.g. an PKIX certificate or trusted key material, or a randomized 246 DAA credential [DAA]), or SHOULD include a correct and unambiguous 247 and stable reference to an accessible identity document. 249 Authentication Secret: An Authentication Secret MUST be available 250 exclusively to an Attester's Attesting Environment. 252 The Attester MUST protect Claims with that Authentication Secret, 253 thereby proving the authenticity of the Claims included in 254 Evidence. The Authentication Secret MUST be established before 255 RATS can take place. 257 Evidence Freshness: Evidence MUST include an indicator about its 258 freshness that can be understood by a Verifier. Analogously, 259 interaction models MUST support the conveyance of proofs of 260 freshness in a way that is useful to Verifiers and their appraisal 261 procedures. 263 Evidence Protection: Evidence MUST be a set of well-formatted and 264 well-protected Claims that an Attester can create and convey to a 265 Verifier in a tamper-evident manner. 267 6. Generic Information Elements 269 This section defines the information elements that are vital to all 270 kinds interaction models. Varying from solution to solution, generic 271 information elements can be either included in the scope of protocol 272 messages (instantiating Conceptual Messages) or can be included in 273 additional protocol parameters or payload. Ultimately, the following 274 information elements are required by any kind of scalable remote 275 attestation procedure using one or more of the interaction models 276 provided. 278 Attester Identity ('attesterIdentity'): _mandatory_ 280 A statement about a distinguishable Attester made by an Endorser 281 without accompanying evidence about its validity - used as proof 282 of identity. 284 Authentication Secret IDs ('authSecIDs'): _mandatory_ 286 A statement representing an identifier list that MUST be 287 associated with corresponding Authentication Secrets used to 288 protect Claims included in Evidence. 290 Each Authentication Secret is uniquely associated with a 291 distinguishable Attesting Environment. Consequently, an 292 Authentication Secret ID also identifies an Attesting Environment. 294 Handle ('handle'): _mandatory_ 296 A statement that is intended to uniquely distinguish received 297 Evidence and/or determine the freshness of Evidence. 299 A Verifier can also use a Handle as an indicator for authenticity 300 or attestation provenance, as only Attesters and Verifiers that 301 are intended to exchange Evidence should have knowledge of the 302 corresponding Handles. Examples include Nonces or signed 303 timestamps. 305 Claims ('claims'): _mandatory_ 307 Claims are assertions that represent characteristics of an 308 Attester's Target Environment. 310 Claims are part of a Conceptual Message and are, for example, used 311 to appraise the integrity of Attesters via Verifiers. The other 312 information elements in this section can be expressed as Claims in 313 any type of Conceptional Messages. 315 Event Logs ('eventLogs'): _optional_ 317 Event Logs accompany Claims by providing event trails of security- 318 critical events in a system. The primary purpose of Event Logs is 319 to support Claim reproducibility by providing information on how 320 Claims originated. 322 Reference Values ('refValues') _mandatory_ 324 Reference Values as defined in [I-D.ietf-rats-architecture]. This 325 specific type of Claims is used to appraise Claims incorporated in 326 Evidence. For example, Reference Values MAY be Reference 327 Integrity Measurements (RIM) or assertions that are implicitly 328 trusted because they are signed by a trusted authority (see 329 Endorsements in [I-D.ietf-rats-architecture]). Reference Values 330 typically represent (trusted) Claim sets about an Attester's 331 intended platform operational state. 333 Claim Selection ('claimSelection'): _optional_ 335 A (sub-)set of Claims which can be created by an Attester. 337 Claim Selections act as filters to specify the exact set of Claims 338 to be included in Evidence. In a remote attestation process, a 339 Verifier sends a Claim Selection, among other elements, to an 340 Attester. An Attester MAY decide whether or not to provide all 341 requested Claims from a Claim Selection to the Verifier. 343 Collected Claims ('collectedClaims'): _mandatory_ 345 Collected Claims represent a (sub-)set of Claims created by an 346 Attester. 348 Collected Claims are gathered based on the Claims selected in the 349 Claim Selection. If a Verifier does not provide a Claim 350 Selection, then all available Claims on the Attester are part of 351 the Collected Claims. 353 Evidence ('evidence'): _mandatory_ 355 A set of Claims that consists of a list of Authentication Secret 356 IDs that each identifies an Authentication Secret in a single 357 Attesting Environment, the Attester Identity, Claims, and a 358 Handle. Attestation Evidence MUST cryptographically bind all of 359 these information elements. Evidence MUST be protected via an 360 Authentication Secret. The Authentication Secret MUST be trusted 361 by the Verifier as authoritative. 363 Attestation Result ('attestationResult'): _mandatory_ 365 An Attestation Result is produced by the Verifier as the output of 366 the appraisal of Evidence. Attestation Results include condensed 367 assertions about integrity or other characteristics of the 368 corresponding Attester that are processible by Relying Parties. 370 7. Interaction Models 372 The following subsections introduce and illustrate the interaction 373 models: 375 1. Challenge/Response Remote Attestation 377 2. Uni-Directional Remote Attestation 379 3. Streaming Remote Attestation 381 Each section starts with a sequence diagram illustrating the 382 interactions between Attester and Verifier. While the presented 383 interaction models focus on the conveyance of Evidence, the intention 384 of this document is in support of future work that applies the 385 presented models to the conveyance of other Conceptual Messages, 386 namely Attestation Results, Endorsements, Reference Values, or 387 Appraisal Policies. 389 All interaction models have a strong focus on the use of a handle to 390 incorporate a type of proof of freshness and to prevent replay 391 attacks. The way these handles are processed is the most prominent 392 difference between the three interaction models. 394 7.1. Challenge/Response Remote Attestation 395 .----------. .----------. 396 | Attester | | Verifier | 397 '----------' '----------' 398 | | 399 generateClaims(attestingEnvironment) | 400 | => claims, eventLogs | 401 | | 402 | <-- requestAttestation(handle, authSecIDs, claimSelection) | 403 | | 404 collectClaims(claims, claimSelection) | 405 | => collectedClaims | 406 | | 407 generateEvidence(handle, authSecIDs, collectedClaims) | 408 | => evidence | 409 | | 410 | evidence, eventLogs -------------------------------------> | 411 | | 412 | appraiseEvidence(evidence, eventLogs, refValues) 413 | attestationResult <= | 414 | | 416 The Attester boots up and thereby produces claims about its boot 417 state and its operational state. Event Logs accompany the produced 418 claims by providing an event trail of security-critical events in a 419 system. Claims are produced by all attesting Environments of an 420 Attester system. 422 The Challenge/Response remote attestation procedure is initiated by 423 the Verifier by sending a remote attestation request to the Attester. 424 A request includes a Handle, a list of Authentication Secret IDs, and 425 a Claim Selection. 427 In the Challenge/Response model, the handle is composed of qualifying 428 data in the form of a practically infeasible to guess nonce, such as 429 a cryptographically strong random number. The Verifier-generated 430 nonce is intended to guarantee Evidence freshness and to prevent 431 replay attacks. 433 The list of Authentication Secret IDs selects the attestation keys 434 with which the Attester is requested to sign the Attestation 435 Evidence. Each selected key is uniquely associated with an Attesting 436 Environment of the Attester. As a result, a single Authentication 437 Secret ID identifies a single Attesting Environment. 438 Correspondingly, a particular set of Evidence originating from a 439 particular Attesting Environment in a composite device can be 440 requested via multiple Authentication Secret IDs. Methods to acquire 441 Authentication Secret IDs or mappings between Attesting Environments 442 to Authentication Secret IDs are out-of-scope of this document. 444 The Attester collects Claims based on the Claim Selection. With the 445 Claim Selection the Verifier defines the set of Claims it requires. 446 Correspondingly, collected Claims can be a subset of the produced 447 Claims. This could be all available Claims, depending on the Claim 448 Selection. If the Claim Selection is omitted, then by default all 449 Claims that are known and available on the Attester MUST be used to 450 create corresponding Evidence. For example, when performing a boot 451 integrity evaluation, a Verifier may only be requesting a particular 452 subset of claims about the Attester, such as Evidence about BIOS/UEFI 453 and firmware that the Attester booted up, and not include information 454 about all currently running software. 456 With the Handle, the Authentication Secret IDs, and the collected 457 Claims, the Attester produces signed Evidence. That is, it digitally 458 signs the Handle and the collected Claims with a cryptographic secret 459 identified by the Authentication Secret ID. This is done once per 460 Attesting Environment which is identified by the particular 461 Authentication Secret ID. The Attester communicates the signed 462 Evidence as well as all accompanying Event Logs back to the Verifier. 464 While it is crucial that Claims, the Handle, and the Attester 465 Identity information MUST be cryptographically bound to the signature 466 of Evidence, they MAY be presented obfuscated, encrypted, or 467 cryptographically blinded. For further reference see section 468 Section 10. 470 As soon as the Verifier receives the signed Evidence and Event Logs, 471 it appraises the Evidence. For this purpose, it validates the 472 signature, the Attester Identity, and the Handle, and then appraises 473 the Claims. Appraisal procedures are application-specific and can be 474 conducted via comparison of the Claims with corresponding Reference 475 Values, such as Reference Integrity Measurements. The final output 476 of the Verifier are Attestation Results. Attestation Results 477 constitute new Claim Sets about the properties and characteristics of 478 an Attester, which enables Relying Parties, for example, to assess an 479 Attester's trustworthiness. 481 7.2. Uni-Directional Remote Attestation 482 .----------. .--------------------. .----------. 483 | Attester | | Handle Distributor | | Verifier | 484 '----------' '--------------------' '----------' 485 | | | 486 | generateHandle() | 487 | | => handle | 488 | | | 489 | <----------------------------- handle | handle ----------> | 490 | | | 491 generateClaims(attestingEnvironment) x | 492 | => claims, eventLogs | 493 | | 494 collectClaims(claims, claimSelection) | 495 | => collectedClaims | 496 | | 497 generateEvidence(handle, authSecIDs, collectedClaims) | 498 | => evidence | 499 | | 500 | evidence, eventLogs -------------------------------------> | 501 | | 502 | appraiseEvidence(evidence, eventLogs, refValues) 503 | attestationResult <= | 504 ~ ~ 505 | | 506 **********[loop]******************************************************** 507 * | | * 508 * generateClaims(attestingEnvironment) | * 509 * | => claimsDelta, eventLogsDelta | * 510 * | | * 511 * collectClaims(claimsDelta, claimSelection) | * 512 * | => collectedClaimsDelta | * 513 * | | * 514 * generateEvidence(handle, authSecIDs, collectedClaimsDelta) | * 515 * | => evidence | * 516 * | | * 517 * | evidence, eventLogsDelta --------------------------------> | * 518 * | | * 519 * | appraiseEvidence(evidence, eventLogsDelta, refValues) * 520 * | attestationResult <= | * 521 * | | * 522 ************************************************************************ 523 | | 525 Uni-Directional Remote Attestation procedures can be initiated both 526 by the Attester and by the Verifier. Initiation by the Attester can 527 result in unsolicited pushes of Evidence to the Verifier. Initiation 528 by the Verifier always results in solicited pushes to the Verifier. 530 The Uni-Directional model uses the same information elements as the 531 Challenge/Response model. In the sequence diagram above, the 532 Attester initiates the conveyance of Evidence (comparable with a 533 RESTful POST operation or the emission of a beacon). While a request 534 of Evidence from the Verifier would result in a sequence diagram more 535 similar to the Challenge/Response model (comparable with a RESTful 536 GET operation). The specific manner how Handles are created and used 537 always remains as the distinguishing quality of this model. 539 In the Uni-Directional model, handles are composed of 540 cryptographically signed trusted timestamps as shown in 541 [I-D.birkholz-rats-tuda], potentially including other qualifying 542 data. The Handles are created by an external 3rd entity -- the 543 Handle Distributor -- which includes a trustworthy source of time, 544 and takes on the role of a Time Stamping Authority (TSA, as initially 545 defined in [RFC3161]). Timestamps created from local clocks 546 (absolute clocks using a global timescale, as well as relative 547 clocks, such as tick-counters) of Attesters and Verifiers MUST be 548 cryptographically bound to fresh Handles received from the Handle 549 Distributor. This binding provides a proof of synchronization that 550 MUST be included in all produced Evidence. Correspondingly, conveyed 551 Evidence in this model provides a proof that it was fresh at a 552 certain point in time. 554 While periodically pushing Evidence to the Verifier, the Attester 555 only needs to generate and convey evidence generated from Claim 556 values that have changed and new Event Logs entries since the 557 previous conveyance. This updates reflecting the differences are 558 called "delta" in the sequence diagram above. 560 Effectively, the Uni-Directional model allows for a series of 561 Evidence to be pushed to multiple Verifiers simultaneously. Methods 562 to detect excessive time drift that would mandate a fresh Handle to 563 be received by the Handle Distributor as well as timing of Handle 564 distribution are out-of-scope of this document. 566 7.3. Streaming Remote Attestation 567 .----------. .----------. 568 | Attester | | Verifier | 569 '----------' '----------' 570 | | 571 generateClaims(attestingEnvironment) | 572 | => claims, eventLogs | 573 | | 574 | <----------- subscribe(handle, authSecIDs, claimSelection) | 575 | subscriptionResult --------------------------------------> | 576 | | 577 collectClaims(claims, claimSelection) | 578 | => collectedClaims | 579 | | 580 generateEvidence(handle, authSecIDs, collectedClaims) | 581 | => evidence | 582 | | 583 | evidence, eventLogs -------------------------------------> | 584 | | 585 | appraiseEvidence(evidence, eventLogs, refValues) 586 | attestationResult <= | 587 ~ ~ 588 | | 589 **********[loop]******************************************************** 590 * | | * 591 * generateClaims(attestingEnvironment) | * 592 * | => claimsDelta, eventLogsDelta | * 593 * | | * 594 * collectClaims(claimsDelta, claimSelection) | * 595 * | => collectedClaimsDelta | * 596 * | | * 597 * generateEvidence(handle, authSecIDs, collectedClaimsDelta) | * 598 * | => evidence | * 599 * | | * 600 * | evidence, eventLogsDelta --------------------------------> | * 601 * | | * 602 * | appraiseEvidence(evidence, eventLogsDelta, refValues) * 603 * | attestationResult <= | * 604 * | | * 605 ************************************************************************ 606 | | 608 Streaming Remote Attestation procedures require the setup of 609 subscription state. Setting up subscription state between a Verifier 610 and an Attester is conducted via a subscribe operation. The 611 subscribe operation is used to convey required Handles for producing 612 Evidence. Effectively, this allows for a series of Evidence to be 613 pushed to a Verifier, similar to the Uni-Directional model. While a 614 Handle Distributor is not required in this model, it is also limited 615 to bi-lateral subscription relationships in which each Verifier has 616 to create and provide its individual Handle. Handles provided by a 617 specific subscribing Verifier MUST be used in Evidence generation for 618 that specific Verifier. The Streaming model uses the same 619 information elements as the Challenge/Response and the Uni- 620 Directional model. Methods to detect excessive time drift that would 621 mandate a refreshed Handle to be conveyed via another subscribe 622 operation are out-of-scope of this document. 624 8. Additional Application-Specific Requirements 626 Depending on the use cases covered, there can be additional 627 requirements. An exemplary subset is illustrated in this section. 629 8.1. Confidentiality 631 Confidentiality of exchanged attestation information may be 632 desirable. This requirement usually is present when communication 633 takes place over insecure channels, such as the public Internet. In 634 such cases, TLS may be used as a suitable communication protocol 635 which provides confidentiality protection. In private networks, such 636 as carrier management networks, it must be evaluated whether or not 637 the transport medium is considered confidential. 639 8.2. Mutual Authentication 641 In particular use cases, mutual authentication may be desirable in 642 such a way that a Verifier also needs to prove its identity to the 643 Attester, instead of only the Attester proving its identity to the 644 Verifier. 646 8.3. Hardware-Enforcement/Support 648 Depending on given usage scenarios, hardware support for secure 649 storage of cryptographic keys, crypto accelerators, as well as 650 protected or isolated execution environments can be mandatory 651 requirements. Well-known technologies in support of these 652 requirements are roots of trusts, such as Hardware Security Modules 653 (HSM), Physically Unclonable Functions (PUFs), Shielded Secrets, or 654 Trusted Executions Environments (TEEs). 656 9. Implementation Status 658 Note to RFC Editor: Please remove this section as well as references 659 to [BCP205] before AUTH48. 661 This section records the status of known implementations of the 662 protocol defined by this specification at the time of posting of this 663 Internet-Draft, and is based on a proposal described in [BCP205]. 664 The description of implementations in this section is intended to 665 assist the IETF in its decision processes in progressing drafts to 666 RFCs. Please note that the listing of any individual implementation 667 here does not imply endorsement by the IETF. Furthermore, no effort 668 has been spent to verify the information presented here that was 669 supplied by IETF contributors. This is not intended as, and must not 670 be construed to be, a catalog of available implementations or their 671 features. Readers are advised to note that other implementations may 672 exist. 674 According to [BCP205], "this will allow reviewers and working groups 675 to assign due consideration to documents that have the benefit of 676 running code, which may serve as evidence of valuable experimentation 677 and feedback that have made the implemented protocols more mature. 678 It is up to the individual working groups to use this information as 679 they see fit". 681 9.1. Implementer 683 The open-source implementation was initiated and is maintained by the 684 Fraunhofer Institute for Secure Information Technology - SIT. 686 9.2. Implementation Name 688 The open-source implementation is named "CHAllenge-Response based 689 Remote Attestation" or in short: CHARRA. 691 9.3. Implementation URL 693 The open-source implementation project resource can be located via: 694 https://github.com/Fraunhofer-SIT/charra 696 9.4. Maturity 698 The code's level of maturity is considered to be "prototype". 700 9.5. Coverage and Version Compatibility 702 The current version ('1bcb469') implements a challenge/response 703 interaction model and is aligned with the exemplary specification of 704 the CoAP FETCH bodies defined in Section Appendix A of this document. 706 9.6. License 708 The CHARRA project and all corresponding code and data maintained on 709 GitHub are provided under the BSD 3-Clause "New" or "Revised" 710 license. 712 9.7. Implementation Dependencies 714 The implementation requires the use of the official Trusted Computing 715 Group (TCG) open-source Trusted Software Stack (TSS) for the Trusted 716 Platform Module (TPM) 2.0. The corresponding code and data is also 717 maintained on GitHub and the project resources can be located via: 718 https://github.com/tpm2-software/tpm2-tss/ 720 The implementation uses the Constrained Application Protocol 721 [RFC7252] (http://coap.technology/) and the Concise Binary Object 722 Representation [RFC7049] (https://cbor.io/). 724 9.8. Contact 726 Michael Eckel (michael.eckel@sit.fraunhofer.de) 728 10. Security and Privacy Considerations 730 In a remote attestation procedure the Verifier or the Attester MAY 731 want to cryptographically blind several attributes. For instance, 732 information can be part of the signature after applying a one-way 733 function (e. g. a hash function). 735 There is also a possibility to scramble the Nonce or Attester 736 Identity with other information that is known to both the Verifier 737 and Attester. A prominent example is the IP address of the Attester 738 that usually is known by the Attester itself as well as the Verifier. 739 This extra information can be used to scramble the Nonce in order to 740 counter certain types of relay attacks. 742 11. Acknowledgments 744 Olaf Bergmann, Michael Richardson, and Ned Smith 746 12. References 748 12.1. Normative References 750 [BCP205] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 751 Code: The Implementation Status Section", BCP 205, 752 RFC 7942, DOI 10.17487/RFC7942, July 2016, 753 . 755 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 756 Requirement Levels", BCP 14, RFC 2119, 757 DOI 10.17487/RFC2119, March 1997, 758 . 760 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 761 "Internet X.509 Public Key Infrastructure Time-Stamp 762 Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 763 2001, . 765 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 766 Housley, R., and W. Polk, "Internet X.509 Public Key 767 Infrastructure Certificate and Certificate Revocation List 768 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 769 . 771 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 772 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 773 October 2013, . 775 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 776 Application Protocol (CoAP)", RFC 7252, 777 DOI 10.17487/RFC7252, June 2014, 778 . 780 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 781 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 782 May 2017, . 784 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 785 Definition Language (CDDL): A Notational Convention to 786 Express Concise Binary Object Representation (CBOR) and 787 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 788 June 2019, . 790 12.2. Informative References 792 [DAA] Brickell, E., Camenisch, J., and L. Chen, "Direct 793 Anonymous Attestation", page 132-145, ACM Proceedings of 794 the 11rd ACM conference on Computer and Communications 795 Security, 2004. 797 [I-D.birkholz-rats-tuda] 798 Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann, 799 "Time-Based Uni-Directional Attestation", Work in 800 Progress, Internet-Draft, draft-birkholz-rats-tuda-04, 13 801 January 2021, . 804 [I-D.ietf-rats-architecture] 805 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 806 W. Pan, "Remote Attestation Procedures Architecture", Work 807 in Progress, Internet-Draft, draft-ietf-rats-architecture- 808 12, 23 April 2021, . 811 [I-D.ietf-rats-tpm-based-network-device-attest] 812 Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- 813 based Network Device Remote Integrity Verification", Work 814 in Progress, Internet-Draft, draft-ietf-rats-tpm-based- 815 network-device-attest-06, 7 December 2020, 816 . 819 [turtles] Rudnicki, R., "Turtles All the Way Down: Foundation, 820 Edifice, and Ruin in Faulkner and McCarthy", 821 DOI 10.1353/fau.2010.0002, The Faulkner Journal 25.2, 822 2010, . 824 Appendix A. CDDL Specification for a simple CoAP Challenge/Response 825 Interaction 827 The following CDDL specification is an exemplary proof-of-concept to 828 illustrate a potential implementation of the Challenge/Response 829 Interaction Model. The transfer protocol used is CoAP using the 830 FETCH operation. The actual resource operated on can be empty. Both 831 the Challenge Message and the Response Message are exchanged via the 832 FETCH operation and corresponding FETCH Request and FETCH Response 833 body. 835 In this example, evidence is created via the root-of-trust for 836 reporting primitive operation "quote" that is provided by a TPM 2.0. 838 RAIM-Bodies = CoAP-FETCH-Body / CoAP-FETCH-Response-Body 840 CoAP-FETCH-Body = [ hello: bool, ; if true, the AK-Cert is conveyed 841 nonce: bytes, 842 pcr-selection: [ + [ tcg-hash-alg-id: uint .size 2, ; TPM2_ALG_ID 843 [ + pcr: uint .size 1 ], 844 ] 845 ], 846 ] 848 CoAP-FETCH-Response-Body = [ attestation-evidence: TPMS_ATTEST-quote, 849 tpm-native-signature: bytes, 850 ? ak-cert: bytes, ; attestation key certificate 851 ] 853 TPMS_ATTEST-quote = [ qualifiediSigner: uint .size 2, ;TPM2B_NAME 854 TPMS_CLOCK_INFO, 855 firmwareVersion: uint .size 8 856 quote-responses: [ * [ pcr: uint .size 1, 857 + [ pcr-value: bytes, 858 ? hash-alg-id: uint .size 2, 859 ], 860 ], 861 ? pcr-digest: bytes, 862 ], 863 ] 865 TPMS_CLOCK_INFO = [ clock: uint .size 8, 866 resetCounter: uint .size 4, 867 restartCounter: uint .size 4, 868 save: bool, 869 ] 871 Authors' Addresses 873 Henk Birkholz 874 Fraunhofer SIT 875 Rheinstrasse 75 876 64295 Darmstadt 877 Germany 879 Email: henk.birkholz@sit.fraunhofer.de 880 Michael Eckel 881 Fraunhofer SIT 882 Rheinstrasse 75 883 64295 Darmstadt 884 Germany 886 Email: michael.eckel@sit.fraunhofer.de 888 Wei Pan 889 Huawei Technologies 891 Email: william.panwei@huawei.com 893 Eric Voit 894 Cisco Systems 896 Email: evoit@cisco.com