idnits 2.17.1 draft-ietf-rats-reference-interaction-models-04.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 July 2021) is 1004 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8610' is defined on line 781, 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-05 == 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-07 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: 27 January 2022 W. Pan 6 Huawei Technologies 7 E. Voit 8 Cisco 9 26 July 2021 11 Reference Interaction Models for Remote Attestation Procedures 12 draft-ietf-rats-reference-interaction-models-04 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 27 January 2022. 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 Authentication Secret: An Authentication Secret MUST be available 230 exclusively to an Attesting Environment of an Attester. 232 The Attester MUST protect Claims with that Authentication Secret, 233 thereby proving the authenticity of the Claims included in 234 Evidence. The Authentication Secret MUST be established before 235 RATS can take place. 237 Attester Identity: A statement about a distinguishable Attester made 238 by an Endorser. 240 The provenance of Evidence with respect to a distinguishable 241 Attesting Environment MUST be correct and unambiguous. 243 An Attester Identity MAY be an Authentication Secret which is 244 available exclusively to one of the Attesting Environments of an 245 Attester. It MAY be a unique identity, MAY be included in a zero- 246 knowledge proof (ZKP), MAY be part of a group signature, or it MAY 247 be a randomized DAA credential [DAA]. 249 Attestation Evidence Authenticity: Attestation Evidence MUST be 250 authentic. 252 In order to provide proofs of authenticity, Attestation Evidence 253 SHOULD be cryptographically associated with an identity document 254 (e.g., a PKIX certificate or trusted key material, or a randomized 255 DAA credential [DAA]), or SHOULD include a correct, unambiguous 256 and stable reference to an accessible identity document. 258 Evidence Freshness: Evidence MUST include an indicator about its 259 freshness that can be understood by a Verifier. Analogously, 260 interaction models MUST support the conveyance of proofs of 261 freshness in a way that is useful to Verifiers and their appraisal 262 procedures. 264 Evidence Protection: Evidence MUST be a set of well-formatted and 265 well-protected Claims that an Attester can create and convey to a 266 Verifier in a tamper-evident manner. 268 6. Generic Information Elements 270 This section defines the information elements that are vital to all 271 kinds interaction models. Varying from solution to solution, generic 272 information elements can be either included in the scope of protocol 273 messages (instantiating Conceptual Messages) or can be included in 274 additional protocol parameters or payload. Ultimately, the following 275 information elements are required by any kind of scalable remote 276 attestation procedure using one or more of the interaction models 277 provided. 279 Authentication Secret IDs ('authSecIDs'): _mandatory_ 281 A statement representing an identifier list that MUST be 282 associated with corresponding Authentication Secrets used to 283 protect Claims included in Evidence. 285 Each distinguishable Attesting Environment has access to a 286 protected capability that provides an Authentication Secret 287 associated with that Attesting Environment. Consequently, an 288 Authentication Secret ID can also identify an Attesting 289 Environment. 291 Handle ('handle'): _mandatory_ 293 A statement that is intended to uniquely distinguish received 294 Evidence and/or determine the freshness of Evidence. 296 A Verifier can also use a Handle as an indicator for authenticity 297 or attestation provenance, as only Attesters and Verifiers that 298 are intended to exchange Evidence should have knowledge of the 299 corresponding Handles. Examples include Nonces or signed 300 timestamps. 302 Claims ('claims'): _mandatory_ 304 Claims are assertions that represent characteristics of an 305 Attester's Target Environment. 307 Claims are part of a Conceptual Message and are, for example, used 308 to appraise the integrity of Attesters via Verifiers. The other 309 information elements in this section can be expressed as Claims in 310 any type of Conceptional Messages. 312 Event Logs ('eventLogs'): _optional_ 314 Event Logs accompany Claims by providing event trails of security- 315 critical events in a system. The primary purpose of Event Logs is 316 to support Claim reproducibility by providing information on how 317 Claims originated. 319 Reference Values ('refValues') _mandatory_ 321 Reference Values as defined in [I-D.ietf-rats-architecture]. This 322 specific type of Claims is used to appraise Claims incorporated in 323 Evidence. For example, Reference Values MAY be Reference 324 Integrity Measurements (RIM) or assertions that are implicitly 325 trusted because they are signed by a trusted authority (see 326 Endorsements in [I-D.ietf-rats-architecture]). Reference Values 327 typically represent (trusted) Claim sets about an Attester's 328 intended platform operational state. 330 Claim Selection ('claimSelection'): _optional_ 332 A (sub-)set of Claims which can be created by an Attester. 334 Claim Selections act as filters to specify the exact set of Claims 335 to be included in Evidence. In a remote attestation process, a 336 Verifier sends a Claim Selection, among other elements, to an 337 Attester. An Attester MAY decide whether or not to provide all 338 requested Claims from a Claim Selection to the Verifier. 340 Collected Claims ('collectedClaims'): _mandatory_ 342 Collected Claims represent a (sub-)set of Claims created by an 343 Attester. 345 Collected Claims are gathered based on the Claims selected in the 346 Claim Selection. If a Verifier does not provide a Claim 347 Selection, then all available Claims on the Attester are part of 348 the Collected Claims. 350 Evidence ('evidence'): _mandatory_ 352 A set of Claims that consists of a list of Authentication Secret 353 IDs that each identifies an Authentication Secret in a single 354 Attesting Environment, the Attester Identity, Claims, and a 355 Handle. Attestation Evidence MUST cryptographically bind all of 356 these information elements. Evidence MUST be protected via an 357 Authentication Secret. The Authentication Secret MUST be trusted 358 by the Verifier as authoritative. 360 Attestation Result ('attestationResult'): _mandatory_ 362 An Attestation Result is produced by the Verifier as the output of 363 the appraisal of Evidence. Attestation Results include condensed 364 assertions about integrity or other characteristics of the 365 corresponding Attester that are processible by Relying Parties. 367 7. Interaction Models 369 The following subsections introduce and illustrate the interaction 370 models: 372 1. Challenge/Response Remote Attestation 374 2. Uni-Directional Remote Attestation 376 3. Streaming Remote Attestation 378 Each section starts with a sequence diagram illustrating the 379 interactions between Attester and Verifier. While the presented 380 interaction models focus on the conveyance of Evidence, the intention 381 of this document is in support of future work that applies the 382 presented models to the conveyance of other Conceptual Messages, 383 namely Attestation Results, Endorsements, Reference Values, or 384 Appraisal Policies. 386 All interaction models have a strong focus on the use of a handle to 387 incorporate a type of proof of freshness and to prevent replay 388 attacks. The way these handles are processed is the most prominent 389 difference between the three interaction models. 391 7.1. Challenge/Response Remote Attestation 392 .----------. .----------. 393 | Attester | | Verifier | 394 '----------' '----------' 395 | | 396 generateClaims(attestingEnvironment) | 397 | => claims, eventLogs | 398 | | 399 | <-- requestAttestation(handle, authSecIDs, claimSelection) | 400 | | 401 collectClaims(claims, claimSelection) | 402 | => collectedClaims | 403 | | 404 generateEvidence(handle, authSecIDs, collectedClaims) | 405 | => evidence | 406 | | 407 | evidence, eventLogs -------------------------------------> | 408 | | 409 | appraiseEvidence(evidence, eventLogs, refValues) 410 | attestationResult <= | 411 | | 413 The Attester boots up and thereby produces claims about its boot 414 state and its operational state. Event Logs accompany the produced 415 claims by providing an event trail of security-critical events in a 416 system. Claims are produced by all attesting Environments of an 417 Attester system. 419 The Challenge/Response remote attestation procedure is initiated by 420 the Verifier by sending a remote attestation request to the Attester. 421 A request includes a Handle, a list of Authentication Secret IDs, and 422 a Claim Selection. 424 In the Challenge/Response model, the handle is composed of qualifying 425 data in the form of a practically infeasible to guess nonce, such as 426 a cryptographically strong random number. The Verifier-generated 427 nonce is intended to guarantee Evidence freshness and to prevent 428 replay attacks. 430 The list of Authentication Secret IDs selects the attestation keys 431 with which the Attester is requested to sign the Attestation 432 Evidence. Each selected key is uniquely associated with an Attesting 433 Environment of the Attester. As a result, a single Authentication 434 Secret ID identifies a single Attesting Environment. 435 Correspondingly, a particular set of Evidence originating from a 436 particular Attesting Environment in a composite device can be 437 requested via multiple Authentication Secret IDs. Methods to acquire 438 Authentication Secret IDs or mappings between Attesting Environments 439 to Authentication Secret IDs are out-of-scope of this document. 441 The Attester collects Claims based on the Claim Selection. With the 442 Claim Selection the Verifier defines the set of Claims it requires. 443 Correspondingly, collected Claims can be a subset of the produced 444 Claims. This could be all available Claims, depending on the Claim 445 Selection. If the Claim Selection is omitted, then by default all 446 Claims that are known and available on the Attester MUST be used to 447 create corresponding Evidence. For example, when performing a boot 448 integrity evaluation, a Verifier may only be requesting a particular 449 subset of claims about the Attester, such as Evidence about BIOS/UEFI 450 and firmware that the Attester booted up, and not include information 451 about all currently running software. 453 With the Handle, the Authentication Secret IDs, and the collected 454 Claims, the Attester produces signed Evidence. That is, it digitally 455 signs the Handle and the collected Claims with a cryptographic secret 456 identified by the Authentication Secret ID. This is done once per 457 Attesting Environment which is identified by the particular 458 Authentication Secret ID. The Attester communicates the signed 459 Evidence as well as all accompanying Event Logs back to the Verifier. 461 While it is crucial that Claims, the Handle, and the Attester 462 Identity information (i.e., the Authentication Secret) MUST be 463 cryptographically bound to the signature of Evidence, they MAY be 464 presented obfuscated, encrypted, or cryptographically blinded. For 465 further reference see section Section 10. 467 As soon as the Verifier receives the Evidence and the Event Logs, it 468 appraises the Evidence. For this purpose, it validates the 469 signature, the Attester Identity, and the Handle, and then appraises 470 the Claims. Appraisal procedures are application-specific and can be 471 conducted via comparison of the Claims with corresponding Reference 472 Values, such as Reference Integrity Measurements. The final output 473 of the Verifier are Attestation Results. Attestation Results 474 constitute new Claim Sets about the properties and characteristics of 475 an Attester, which enables Relying Parties, for example, to assess an 476 Attester's trustworthiness. 478 7.2. Uni-Directional Remote Attestation 479 .----------. .--------------------. .----------. 480 | Attester | | Handle Distributor | | Verifier | 481 '----------' '--------------------' '----------' 482 | | | 483 | generateHandle() | 484 | | => handle | 485 | | | 486 | <----------------------------- handle | handle ----------> | 487 | | | 488 generateClaims(attestingEnvironment) x | 489 | => claims, eventLogs | 490 | | 491 collectClaims(claims, claimSelection) | 492 | => collectedClaims | 493 | | 494 generateEvidence(handle, authSecIDs, collectedClaims) | 495 | => evidence | 496 | | 497 | evidence, eventLogs -------------------------------------> | 498 | | 499 | appraiseEvidence(evidence, eventLogs, refValues) 500 | attestationResult <= | 501 ~ ~ 502 | | 503 **********[loop]******************************************************** 504 * | | * 505 * generateClaims(attestingEnvironment) | * 506 * | => claimsDelta, eventLogsDelta | * 507 * | | * 508 * collectClaims(claimsDelta, claimSelection) | * 509 * | => collectedClaimsDelta | * 510 * | | * 511 * generateEvidence(handle, authSecIDs, collectedClaimsDelta) | * 512 * | => evidence | * 513 * | | * 514 * | evidence, eventLogsDelta --------------------------------> | * 515 * | | * 516 * | appraiseEvidence(evidence, eventLogsDelta, refValues) * 517 * | attestationResult <= | * 518 * | | * 519 ************************************************************************ 520 | | 522 Uni-Directional Remote Attestation procedures can be initiated both 523 by the Attester and by the Verifier. Initiation by the Attester can 524 result in unsolicited pushes of Evidence to the Verifier. Initiation 525 by the Verifier always results in solicited pushes to the Verifier. 527 The Uni-Directional model uses the same information elements as the 528 Challenge/Response model. In the sequence diagram above, the 529 Attester initiates the conveyance of Evidence (comparable with a 530 RESTful POST operation or the emission of a beacon). While a request 531 of Evidence from the Verifier would result in a sequence diagram more 532 similar to the Challenge/Response model (comparable with a RESTful 533 GET operation). The specific manner how Handles are created and used 534 always remains as the distinguishing quality of this model. 536 In the Uni-Directional model, handles are composed of 537 cryptographically signed trusted timestamps as shown in 538 [I-D.birkholz-rats-tuda], potentially including other qualifying 539 data. The Handles are created by an external 3rd entity -- the 540 Handle Distributor -- which includes a trustworthy source of time, 541 and takes on the role of a Time Stamping Authority (TSA, as initially 542 defined in [RFC3161]). Timestamps created from local clocks 543 (absolute clocks using a global timescale, as well as relative 544 clocks, such as tick-counters) of Attesters and Verifiers MUST be 545 cryptographically bound to fresh Handles received from the Handle 546 Distributor. This binding provides a proof of synchronization that 547 MUST be included in all produced Evidence. Correspondingly, conveyed 548 Evidence in this model provides a proof that it was fresh at a 549 certain point in time. 551 While periodically pushing Evidence to the Verifier, the Attester 552 only needs to generate and convey evidence generated from Claim 553 values that have changed and new Event Logs entries since the 554 previous conveyance. These updates reflecting the differences are 555 called "delta" in the sequence diagram above. 557 Effectively, the Uni-Directional model allows for a series of 558 Evidence to be pushed to multiple Verifiers simultaneously. Methods 559 to detect excessive time drift that would mandate a fresh Handle to 560 be received by the Handle Distributor as well as timing of Handle 561 distribution are out-of-scope of this document. 563 7.3. Streaming Remote Attestation 564 .----------. .----------. 565 | Attester | | Verifier | 566 '----------' '----------' 567 | | 568 generateClaims(attestingEnvironment) | 569 | => claims, eventLogs | 570 | | 571 | <----------- subscribe(handle, authSecIDs, claimSelection) | 572 | subscriptionResult --------------------------------------> | 573 | | 574 collectClaims(claims, claimSelection) | 575 | => collectedClaims | 576 | | 577 generateEvidence(handle, authSecIDs, collectedClaims) | 578 | => evidence | 579 | | 580 | evidence, eventLogs -------------------------------------> | 581 | | 582 | appraiseEvidence(evidence, eventLogs, refValues) 583 | attestationResult <= | 584 ~ ~ 585 | | 586 **********[loop]******************************************************** 587 * | | * 588 * generateClaims(attestingEnvironment) | * 589 * | => claimsDelta, eventLogsDelta | * 590 * | | * 591 * collectClaims(claimsDelta, claimSelection) | * 592 * | => collectedClaimsDelta | * 593 * | | * 594 * generateEvidence(handle, authSecIDs, collectedClaimsDelta) | * 595 * | => evidence | * 596 * | | * 597 * | evidence, eventLogsDelta --------------------------------> | * 598 * | | * 599 * | appraiseEvidence(evidence, eventLogsDelta, refValues) * 600 * | attestationResult <= | * 601 * | | * 602 ************************************************************************ 603 | | 605 Streaming Remote Attestation procedures require the setup of 606 subscription state. Setting up subscription state between a Verifier 607 and an Attester is conducted via a subscribe operation. The 608 subscribe operation is used to convey required Handles for producing 609 Evidence. Effectively, this allows for a series of Evidence to be 610 pushed to a Verifier, similar to the Uni-Directional model. While a 611 Handle Distributor is not required in this model, it is also limited 612 to bi-lateral subscription relationships in which each Verifier has 613 to create and provide its individual Handle. Handles provided by a 614 specific subscribing Verifier MUST be used in Evidence generation for 615 that specific Verifier. The Streaming model uses the same 616 information elements as the Challenge/Response and the Uni- 617 Directional model. Methods to detect excessive time drift that would 618 mandate a refreshed Handle to be conveyed via another subscribe 619 operation are out-of-scope of this document. 621 8. Additional Application-Specific Requirements 623 Depending on the use cases covered, there can be additional 624 requirements. An exemplary subset is illustrated in this section. 626 8.1. Confidentiality 628 Confidentiality of exchanged attestation information may be 629 desirable. This requirement usually is present when communication 630 takes place over insecure channels, such as the public Internet. In 631 such cases, TLS may be used as a suitable communication protocol 632 which provides confidentiality protection. In private networks, such 633 as carrier management networks, it must be evaluated whether or not 634 the transport medium is considered confidential. 636 8.2. Mutual Authentication 638 In particular use cases, mutual authentication may be desirable in 639 such a way that a Verifier also needs to prove its identity to the 640 Attester, instead of only the Attester proving its identity to the 641 Verifier. 643 8.3. Hardware-Enforcement/Support 645 Depending on given usage scenarios, hardware support for secure 646 storage of cryptographic keys, crypto accelerators, as well as 647 protected or isolated execution environments can be mandatory 648 requirements. Well-known technologies in support of these 649 requirements are roots of trusts, such as Hardware Security Modules 650 (HSM), Physically Unclonable Functions (PUFs), Shielded Secrets, or 651 Trusted Executions Environments (TEEs). 653 9. Implementation Status 655 Note to RFC Editor: Please remove this section as well as references 656 to [BCP205] before AUTH48. 658 This section records the status of known implementations of the 659 protocol defined by this specification at the time of posting of this 660 Internet-Draft, and is based on a proposal described in [BCP205]. 661 The description of implementations in this section is intended to 662 assist the IETF in its decision processes in progressing drafts to 663 RFCs. Please note that the listing of any individual implementation 664 here does not imply endorsement by the IETF. Furthermore, no effort 665 has been spent to verify the information presented here that was 666 supplied by IETF contributors. This is not intended as, and must not 667 be construed to be, a catalog of available implementations or their 668 features. Readers are advised to note that other implementations may 669 exist. 671 According to [BCP205], "this will allow reviewers and working groups 672 to assign due consideration to documents that have the benefit of 673 running code, which may serve as evidence of valuable experimentation 674 and feedback that have made the implemented protocols more mature. 675 It is up to the individual working groups to use this information as 676 they see fit". 678 9.1. Implementer 680 The open-source implementation was initiated and is maintained by the 681 Fraunhofer Institute for Secure Information Technology - SIT. 683 9.2. Implementation Name 685 The open-source implementation is named "CHAllenge-Response based 686 Remote Attestation" or in short: CHARRA. 688 9.3. Implementation URL 690 The open-source implementation project resource can be located via: 691 https://github.com/Fraunhofer-SIT/charra 693 9.4. Maturity 695 The code's level of maturity is considered to be "prototype". 697 9.5. Coverage and Version Compatibility 699 The current version ('1bcb469') implements a challenge/response 700 interaction model and is aligned with the exemplary specification of 701 the CoAP FETCH bodies defined in Section Appendix A of this document. 703 9.6. License 705 The CHARRA project and all corresponding code and data maintained on 706 GitHub are provided under the BSD 3-Clause "New" or "Revised" 707 license. 709 9.7. Implementation Dependencies 711 The implementation requires the use of the official Trusted Computing 712 Group (TCG) open-source Trusted Software Stack (TSS) for the Trusted 713 Platform Module (TPM) 2.0. The corresponding code and data is also 714 maintained on GitHub and the project resources can be located via: 715 https://github.com/tpm2-software/tpm2-tss/ 717 The implementation uses the Constrained Application Protocol 718 [RFC7252] (http://coap.technology/) and the Concise Binary Object 719 Representation [RFC7049] (https://cbor.io/). 721 9.8. Contact 723 Michael Eckel (michael.eckel@sit.fraunhofer.de) 725 10. Security and Privacy Considerations 727 In a remote attestation procedure the Verifier or the Attester MAY 728 want to cryptographically blind several attributes. For instance, 729 information can be part of the signature after applying a one-way 730 function (e. g. a hash function). 732 There is also a possibility to scramble the Nonce or Attester 733 Identity with other information that is known to both the Verifier 734 and Attester. A prominent example is the IP address of the Attester 735 that usually is known by the Attester itself as well as the Verifier. 736 This extra information can be used to scramble the Nonce in order to 737 counter certain types of relay attacks. 739 11. Acknowledgments 741 Olaf Bergmann, Michael Richardson, and Ned Smith 743 12. References 745 12.1. Normative References 747 [BCP205] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 748 Code: The Implementation Status Section", BCP 205, 749 RFC 7942, DOI 10.17487/RFC7942, July 2016, 750 . 752 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 753 Requirement Levels", BCP 14, RFC 2119, 754 DOI 10.17487/RFC2119, March 1997, 755 . 757 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 758 "Internet X.509 Public Key Infrastructure Time-Stamp 759 Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 760 2001, . 762 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 763 Housley, R., and W. Polk, "Internet X.509 Public Key 764 Infrastructure Certificate and Certificate Revocation List 765 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 766 . 768 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 769 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 770 October 2013, . 772 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 773 Application Protocol (CoAP)", RFC 7252, 774 DOI 10.17487/RFC7252, June 2014, 775 . 777 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 778 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 779 May 2017, . 781 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 782 Definition Language (CDDL): A Notational Convention to 783 Express Concise Binary Object Representation (CBOR) and 784 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 785 June 2019, . 787 12.2. Informative References 789 [DAA] Brickell, E., Camenisch, J., and L. Chen, "Direct 790 Anonymous Attestation", page 132-145, ACM Proceedings of 791 the 11th ACM conference on Computer and Communications 792 Security, 2004. 794 [I-D.birkholz-rats-tuda] 795 Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann, 796 "Time-Based Uni-Directional Attestation", Work in 797 Progress, Internet-Draft, draft-birkholz-rats-tuda-05, 12 798 July 2021, . 801 [I-D.ietf-rats-architecture] 802 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 803 W. Pan, "Remote Attestation Procedures Architecture", Work 804 in Progress, Internet-Draft, draft-ietf-rats-architecture- 805 12, 23 April 2021, . 808 [I-D.ietf-rats-tpm-based-network-device-attest] 809 Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- 810 based Network Device Remote Integrity Verification", Work 811 in Progress, Internet-Draft, draft-ietf-rats-tpm-based- 812 network-device-attest-07, 10 June 2021, 813 . 816 [turtles] Rudnicki, R., "Turtles All the Way Down: Foundation, 817 Edifice, and Ruin in Faulkner and McCarthy", 818 DOI 10.1353/fau.2010.0002, The Faulkner Journal 25.2, 819 2010, . 821 Appendix A. CDDL Specification for a simple CoAP Challenge/Response 822 Interaction 824 The following CDDL specification is an exemplary proof-of-concept to 825 illustrate a potential implementation of the Challenge/Response 826 Interaction Model. The transfer protocol used is CoAP using the 827 FETCH operation. The actual resource operated on can be empty. Both 828 the Challenge Message and the Response Message are exchanged via the 829 FETCH operation and corresponding FETCH Request and FETCH Response 830 body. 832 In this example, evidence is created via the root-of-trust for 833 reporting primitive operation "quote" that is provided by a TPM 2.0. 835 RAIM-Bodies = CoAP-FETCH-Body / CoAP-FETCH-Response-Body 837 CoAP-FETCH-Body = [ hello: bool, ; if true, the AK-Cert is conveyed 838 nonce: bytes, 839 pcr-selection: [ + [ tcg-hash-alg-id: uint .size 2, ; TPM2_ALG_ID 840 [ + pcr: uint .size 1 ], 841 ] 842 ], 843 ] 845 CoAP-FETCH-Response-Body = [ attestation-evidence: TPMS_ATTEST-quote, 846 tpm-native-signature: bytes, 847 ? ak-cert: bytes, ; attestation key certificate 848 ] 850 TPMS_ATTEST-quote = [ qualifiediSigner: uint .size 2, ;TPM2B_NAME 851 TPMS_CLOCK_INFO, 852 firmwareVersion: uint .size 8 853 quote-responses: [ * [ pcr: uint .size 1, 854 + [ pcr-value: bytes, 855 ? hash-alg-id: uint .size 2, 856 ], 857 ], 858 ? pcr-digest: bytes, 859 ], 860 ] 862 TPMS_CLOCK_INFO = [ clock: uint .size 8, 863 resetCounter: uint .size 4, 864 restartCounter: uint .size 4, 865 save: bool, 866 ] 868 Authors' Addresses 870 Henk Birkholz 871 Fraunhofer SIT 872 Rheinstrasse 75 873 64295 Darmstadt 874 Germany 876 Email: henk.birkholz@sit.fraunhofer.de 877 Michael Eckel 878 Fraunhofer SIT 879 Rheinstrasse 75 880 64295 Darmstadt 881 Germany 883 Email: michael.eckel@sit.fraunhofer.de 885 Wei Pan 886 Huawei Technologies 888 Email: william.panwei@huawei.com 890 Eric Voit 891 Cisco Systems 893 Email: evoit@cisco.com