idnits 2.17.1 draft-birkholz-rats-reference-interaction-model-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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 13 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 (July 08, 2020) is 1386 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8610' is defined on line 870, 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-02 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-04 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group H. Birkholz 3 Internet-Draft M. Eckel 4 Intended status: Informational Fraunhofer SIT 5 Expires: January 9, 2021 C. Newton 6 L. Chen 7 University of Surrey 8 July 08, 2020 10 Reference Interaction Models for Remote Attestation Procedures 11 draft-birkholz-rats-reference-interaction-model-03 13 Abstract 15 This document describes interaction models for remote attestation 16 procedures (RATS). Three conveying mechanisms - Challenge/Response, 17 Uni-Directional, and Streaming Remote Attestation - are illustrated 18 and defined. Analogously, a general overview about the information 19 elements typically used by corresponding conveyance protocols are 20 highlighted. Privacy preserving conveyance of Evidence via Direct 21 Anonymous Attestation is elaborated on for each interaction model, 22 individually. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 9, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Disambiguation . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Scope and Intent . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Direct Anonymous Attestation . . . . . . . . . . . . . . . . 5 63 5.1. Endorsers . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5.2. Endorsers for Direct Anonymous Attestation . . . . . . . 6 65 6. Normative Prerequisites . . . . . . . . . . . . . . . . . . . 6 66 7. Generic Information Elements . . . . . . . . . . . . . . . . 7 67 8. Interaction Models . . . . . . . . . . . . . . . . . . . . . 9 68 8.1. Challenge/Response Remote Attestation . . . . . . . . . . 10 69 8.2. Uni-Directional Remote Attestation . . . . . . . . . . . 11 70 8.3. Streaming Remote Attestation . . . . . . . . . . . . . . 13 71 9. Additional Application-Specific Requirements . . . . . . . . 15 72 9.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 15 73 9.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 15 74 9.3. Hardware-Enforcement/Support . . . . . . . . . . . . . . 15 75 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 76 10.1. Implementer . . . . . . . . . . . . . . . . . . . . . . 16 77 10.2. Implementation Name . . . . . . . . . . . . . . . . . . 16 78 10.3. Implementation URL . . . . . . . . . . . . . . . . . . . 16 79 10.4. Maturity . . . . . . . . . . . . . . . . . . . . . . . . 16 80 10.5. Coverage and Version Compatibility . . . . . . . . . . . 16 81 10.6. License . . . . . . . . . . . . . . . . . . . . . . . . 16 82 10.7. Implementation Dependencies . . . . . . . . . . . . . . 16 83 10.8. Contact . . . . . . . . . . . . . . . . . . . . . . . . 17 84 11. Security and Privacy Considerations . . . . . . . . . . . . . 17 85 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 86 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 14.1. Normative References . . . . . . . . . . . . . . . . . . 19 89 14.2. Informative References . . . . . . . . . . . . . . . . . 20 90 Appendix A. CDDL Specification for a simple CoAP 91 Challenge/Response Interaction . . . . . . . . . . . 20 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 94 1. Introduction 96 Remote ATtestation procedureS (RATS, [I-D.ietf-rats-architecture]) 97 are workflows composed of roles and interactions, in which Verifiers 98 create Attestation Results about the trustworthiness of an Attester's 99 system component characteristics. The Verifier's assessment in the 100 form of Attestation Results is created based on Attestation Policies 101 and Evidence - trustable and tamper-evident Claims Sets about an 102 Attester's system component characteristics - created by an Attester. 103 The roles _Attester_ and _Verifier_, as well as the Conceptual 104 Messages _Evidence_ and _Attestation Results_ are terms defined by 105 the RATS Architecture [I-D.ietf-rats-architecture]. This documents 106 captures interaction models that can be used in specific RATS-related 107 solution documents. The primary focus of this document is the 108 conveyance of attestation Evidence. Specific goals of this document 109 are to: 111 o prevent inconsistencies in descriptions of these interaction 112 models in other documents (due to text cloning over time), 114 o enable to highlight an exact delta/divergence between the core set 115 of characteristics captured here in this document and variants of 116 these interaction models used in other specifications or 117 solutions, and to 119 o illustrate the application of Direct Anonymous Attestation (DAA) 120 for each of the interaction models described. 122 In summary, this document enables the specification and design of 123 trustworthy and privacy preserving conveyance methods for attestation 124 Evidence from an Attester to a Verifier. While the conveyance of 125 other Conceptual Messages is out-of-scope the methods described can 126 also be applied to the conveyance of Endorsements or Attestation 127 Results. 129 2. Terminology 131 This document uses the terms, roles, and concepts defined in 132 [I-D.ietf-rats-architecture]: 134 Attester, Verifier, Relying Party, Conceptual Message, Evidence, 135 Endorsement, Attestation Result, Appraisal Policy, Attesting 136 Environment, Target Environment 138 A PKIX Certificate is an X.509v3 format certificate as specified by 139 [RFC5280]. 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in 144 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 3. Disambiguation 149 The term "Remote Attestation" is a common expression and often 150 associated or connoted with certain properties. The term "Remote" in 151 this context does not necessarily refer to a remote entity in the 152 scope of network topologies or the Internet. It rather refers to a 153 decoupled system or entities that exchange the payload of the 154 Conceptual Message type called Evidence [I-D.ietf-rats-architecture]. 155 This conveyance can also be "local", if the Verifier is part of the 156 same entity as the Attester, e.g., separate system components of a 157 Composite Device (a single RATS Entity). Examples of these types of 158 co-located environments include: a Trusted Execution Environment 159 (TEE), Baseboard Management Controllers (BMCs), as well as other 160 physical or logical protected/isolated/shielded Computing 161 Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform 162 Modules (TPM)). 164 4. Scope and Intent 166 This document focuses on generic interaction models between Attesters 167 and Verifiers in order to convey Evidence. Complementary procedures, 168 functions, or services that are required for a complete semantic 169 binding of the concepts defined in [I-D.ietf-rats-architecture] are 170 out-of-scope of this document. Examples include: identity 171 establishment, key distribution and enrollment, time synchronization, 172 as well as certificate revocation. 174 Furthermore, any processes and duties that go beyond carrying out 175 remote attestation procedures are out-of-scope. For instance, using 176 the results of a remote attestation that are created by the Verifier, 177 e.g., how to triggering remediation actions or recovery processes, as 178 well as such remediation actions and recovery processes themselves, 179 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 5. Direct Anonymous Attestation 192 DAA [DAA] is a signature scheme used in RATS that allows preservation 193 of the privacy of users that are associated with an Attester (e.g. 194 its owner). Essentially, DAA can be seen as a group signature scheme 195 with the feature that given a DAA signature no-one can find out who 196 the signer is, i.e., the anonymity is not revocable. To be able to 197 sign anonymously an Attester has to obtain a credential from a DAA 198 Issuer. The DAA Issuer uses a private/public key pair to generate a 199 credential for an Attester and makes the public key (in the form of a 200 public key certificate) available to the verifier to enable them to 201 validate the DAA signature obtained as part of the Evidence. 203 In order to support these DAA signatures, the DAA Issuer MUST 204 associate a single key pair with each group of Attesters and use the 205 same key pair when creating the credentials for all of the Attesters 206 in this group. The DAA Issuer's public key certificate for the group 207 replaces the Attester Identity documents in the verification of the 208 Evidence (instead of unique Attester Identity documents). This is in 209 contrast to intuition that there has to be a unique Attester Identity 210 per device. 212 This document extends the duties of the Endorser role as defined by 213 the RATS architecture with respect to the provision of these Attester 214 Identity documents to Attesters. The existing duties of the Endorser 215 role and the duties of a DAA Issuer are quite similar as illustrated 216 in the following subsections. 218 5.1. Endorsers 220 Via its Attesting Environments, an Attester can only create Evidence 221 about its Target Environments. After being appraised to be 222 trustworthy, a Target Environment may become a new Attesting 223 Environment in charge of creating Evidence for further Target 224 Environments. [I-D.ietf-rats-architecture] explains this as Layered 225 Attestation. Layered Attestation has to start with an initial 226 Attesting Environment (i.e., there cannot be turtles all the way down 227 [turtles]). At this rock bottom of Layered Attestation, the 228 Attesting Environments are called Roots of Trust (RoT). An Attester 229 cannot create Evidence about its own RoTs by design. As a 230 consequence, a Verifier requires trustable statements about this 231 subset of Attesting Environments from a different source than the 232 Attester itself. The corresponding trustable statements are called 233 Endorsements and originate from external, trustable entities that 234 take on the role of an Endorser (e.g., supply chain entities). 236 5.2. Endorsers for Direct Anonymous Attestation 238 In order to enable DAA to be used, an Endorser role takes on the 239 duties of a DAA Issuer in addition to its already defined duties. 240 DAA Issuers offer zero-knowledge proofs based on public key 241 certificates used for a group of Attesters [DAA]. Effectively, these 242 certificates share the semantics of Endorsements. The differences 243 are: 245 o The associated private keys are used by the DAA Issuer to provide 246 an Attester with a credential that it can use to convince the 247 Verifier that its Evidence is valid. To keep their anonymity the 248 Attester randomises this credential each time that it is used. 250 o The Verifier can use the DAA Issuer's public key certificate, 251 together with the randomised credential from the Attester, to 252 confirm that the Evidence comes from a valid Attester. 254 o A credential is conveyed from an Endorser to an Attester together 255 with the transfer of the public key certificates from Endorser to 256 Verifier. 258 The zero-knowledge proofs required cannot be created by an Attester 259 alone - like the Endorsements of RoTs - and have to be created by a 260 trustable third entity - like an Endorser. Due to that vast semantic 261 overlap (XXX-mcr:explain), an Endorser in this document can convey 262 trustable third party statements both to a Verifier and an Attester. 264 6. Normative Prerequisites 266 In order to ensure an appropriate conveyance of Evidence, the 267 following set of prerequisites MUST be in place to support the 268 implementation of interaction models: 270 Attester Identity: The provenance of Evidence with respect to a 271 distinguishable Attesting Environment MUST be correct and 272 unambiguous. 274 An Attester Identity MAY be a unique identity, it MAY be included 275 in a zero-knowledge proof (ZKP), or it MAY be part of a group 276 signature, or it MAY be a randomised DAA credential. 278 Attestation Evidence Authenticity: Attestation Evidence MUST be 279 correct and authentic. 281 In order to provide proofs of authenticity, Attestation Evidence 282 SHOULD be cryptographically associated with an identity document 283 (e.g. an PKIX certificate or trusted key material, or a randomised 284 DAA credential), or SHOULD include a correct and unambiguous and 285 stable reference to an accessible identity document. 287 Authentication Secret: An Authentication Secret MUST be available 288 exclusively to an Attester's Attesting Environment. 290 The Attester MUST protect Claims with that Authentication Secret, 291 thereby proving the authenticity of the Claims included in 292 Evidence. The Authentication Secret MUST be established before 293 RATS can take place. 295 Evidence Freshness: Evidence MUST include an indicator about its 296 Freshness that can be understood by a Verifier. Analogously, 297 interaction models MUST support the conveyance of proofs of 298 freshness in a way that is useful to Verifiers and their appraisal 299 procedures. 301 Evidence Protection: Evidence MUST be a set of well-formatted and 302 well-protected Claims that an Attester can create and convey to a 303 Verifier in a tamper-evident manner. 305 7. Generic Information Elements 307 This section defines the information elements that are vital to all 308 kinds interaction models. Varying from solution to solution, generic 309 information elements can be either included in the scope of protocol 310 messages or can be included in their payload. Ultimately, the 311 following information elements are required by any kind of scalable 312 remote attestation procedure using one or more of the interaction 313 models provided. 315 Attester Identity ('attesterIdentity'): _mandatory_ 317 A statement about a distinguishable Attester made by an Endorser 318 without accompanying evidence about its validity - used as proof 319 of identity. 321 In DAA the Attester's identity is not revealed to the verifier. 322 The Attester is issued with a credential by the Endorser that is 323 randomised and then used to anonymously confirm the validity of 324 their evidence. The evidence is verified using the Endorser's 325 public key. 327 Authentication Secret IDs ('authSecID'): _mandatory_ 329 A statement representing an identifier list that MUST be 330 associated with corresponding Authentication Secrets used to 331 protect Evidence. In DAA, Authentication Secret IDs are 332 represented by the Endorser (DAA issuer)'s public key that MUST be 333 used to create DAA credentials for the corresponding 334 Authentication Secrets used to protect Evidence. 336 Each Authentication Secret is uniquely associated with a 337 distinguishable Attesting Environment. Consequently, an 338 Authentication Secret ID also identifies an Attesting Environment. 339 In DAA an Authentication Secret ID does not identify a unique 340 Attesting Environment but associated with a group of Attesting 341 Environments. This is because an Attesting Environment should not 342 be distinguishable and the DAA credential which represents the 343 Attesting Environment is randomised each time it used. 345 Handle ('handle'): _mandatory_ 347 A statement that is intended to uniquely distinguish received 348 Evidence and/or determine the Freshness of Evidence. 350 A Verifier can also use a Handle as an indicator for authenticity 351 or attestation provenance, as only Attesters and Verifiers that 352 are intended to exchange Evidence should have knowledge of the 353 corresponding Handles. Examples include Nonces or signed 354 timestamps. 356 Claims ('claims'): _mandatory_ 358 Claims are assertions that represent characteristics of an 359 Attester's Target Environment. 361 Claims are part Conceptual Message and are, for example, used to 362 appraise the integrity of Attesters via a Verifiers. The other 363 information elements in this section can be expressed as Claims in 364 any type of Conceptional Messages. 366 Reference Claims ('refClaims') _mandatory_ 368 Reference Claims are a specific subset of Appraisal Policies as 369 defined in [I-D.ietf-rats-architecture]. 371 Reference Claims are used to appraise the Claims received from an 372 Attester via appraisal by direct comparison. For example, 373 Reference Claims MAY be Reference Integrity Measurements (RIM) or 374 assertions that are implicitly trusted because they are signed by 375 a trusted authority (see Endorsements in 376 [I-D.ietf-rats-architecture]). Reference Claims typically 377 represent (trusted) Claim sets about an Attester's intended 378 platform operational state. 380 Claim Selection ('claimSelection'): _optional_ 382 A statement that represents a (sub-)set of Claims that can be 383 created by an Attester. 385 Claim Selections can act as filters that can specify the exact set 386 of Claims to be included in Evidence. An Attester MAY decide 387 whether or not to provide all Claims as requested via a Claim 388 Selection. 390 Evidence ('signedAttestationEvidence'): _mandatory_ 392 A set of Claims that consists of a list of Authentication Secret 393 IDs that each identifies an Authentication Secret in a single 394 Attesting Environment, the Attester Identity, Claims, and a 395 Handle. Attestation Evidence MUST cryptographically bind all of 396 these information elements. The Evidence MUST be protected via 397 the Authentication Secret. The Authentication Secret MUST be 398 trusted by the Verifier as authoritative. 400 Attestation Result ('attestationResult'): _mandatory_ 402 An Attestation Result is produced by the Verifier as the output of 403 the appraisal of Evidence. Attestation Results include condensed 404 assertions about integrity or other characteristics of the 405 corresponding Attester. 407 8. Interaction Models 409 The following subsections introduce and illustrate the interaction 410 models: 412 1. Challenge/Response Remote Attestation 414 2. Uni-Directional Remote Attestation 416 3. Streaming Remote Attestation 418 Each section starts with a sequence diagram illustrating the 419 interactions between Attester and Verifier. The other roles RATS 420 roles - mainly Relying Parties and Endorsers - are not relevant for 421 this interaction model. While the interaction models presented focus 422 on the conveyance of Evidence, future work could apply this to the 423 conveyance of other Conceptual Messages, namely Attestation Results, 424 Endorsements, or Appraisal Policies. 426 All interaction model have a strong focus on the use of a handle to 427 incorporate a proof of freshness. The ways these handles are 428 processed is the most prominent difference between the three 429 interaction models. 431 8.1. Challenge/Response Remote Attestation 433 .----------. .----------. 434 | Attester | | Verifier | 435 '----------' '----------' 436 | | 437 | | 438 valueGeneration(targetEnvironment) | 439 | => claims | 440 | | 441 | <------requestEvidence(handle, authSecIDs, claimSelection) | 442 | | 443 claimsCollection(claimSelection) | 444 | => collectedClaims | 445 | | 446 evidenceGeneration(handle, authSecIDs, collectedClaims) | 447 | => evidence | 448 | | 449 | returnEvidence-------------------------------------------> | 450 | returnEventLog-------------------------------------------> | 451 | | 452 | evidenceAppraisal(evidence, eventLog, refClaims) 453 | attestationResult <= | 454 | | 456 This Challenge/Response Remote Attestation procedure is initiated by 457 the Verifier, by sending a remote attestation request to the 458 Attester. A request includes a Handle, a list of Authentication 459 Secret IDs, and a Claim Selection. 461 In the Challenge/Response model, the handle is composed of qualifying 462 data in the form of a cryptographically strongly randomly generated, 463 and therefore unpredictable, nonce. The Verifier-generated nonce is 464 intended to guarantee Evidence freshness. 466 The list of Authentication Secret IDs selects the attestation keys 467 with which the Attester is requested to sign the Attestation 468 Evidence. Each selected key is uniquely associated with an Attesting 469 Environment of the Attester. As a result, a single Authentication 470 Secret ID identifies a single Attesting Environment. 472 Analogously, a particular set of Evidence originating from a 473 particular Attesting Environments in a composite device can be 474 requested via multiple Authentication Secret IDs. Methods to acquire 475 Authentication Secret IDs or mappings between Attesting Environments 476 to Authentication Secret IDs are out-of-scope of this document. 478 The Claim Selection narrows down the set of Claims collected and used 479 to create Evidence to those that the Verifier requires. If the Claim 480 Selection is omitted, then by default all Claims that are known and 481 available on the Attester MUST be used to create corresponding 482 Evidence. For example when performing a boot integrity evaluation, a 483 Verifier may only be requesting a particular subset of claims about 484 the Attester, such as Evidence about BIOS and firmware the Attester 485 booted up, and not include information about all currently running 486 software. 488 While it is crucial that Claims, the Handle, as well as the Attester 489 Identity information MUST be cryptographically bound to the signature 490 of Evidence, they may be presented in an encrypted form. 492 Cryptographic blinding MAY be used at this point. For further 493 reference see section Section 11. 495 As soon as the Verifier receives signed Evidence, it validates the 496 signature, the Attester Identity, as well as the Nonce, and appraises 497 the Claims. Appraisal procedures are application-specific and can be 498 conducted via comparison of the Claims with corresponding Reference 499 Claims, such as Reference Integrity Measurements. The final output 500 of the Verifier are Attestation Results. Attestation Results 501 constitute new Claims Sets about an Attester's properties and 502 characteristics that enables Relying Parties, for example, to assess 503 an Attester's trustworthiness. 505 8.2. Uni-Directional Remote Attestation 506 .----------. .----------. 507 | Attester | | Verifier | 508 '----------' '----------' 509 | | 510 valueGeneration(targetEnvironment) | 511 | => claims | 512 | | 513 | .--------------------. | 514 | <----------handle | | | 515 | | Handle Distributor | | 516 | | | handle----------> | 517 | '--------------------' | 518 | | 519 evidenceGeneration(handle, authSecIDs, collectedClaims) | 520 | => evidence | 521 | | 522 | pushEventLog---------------------------------------------> | 523 | pushEvidence---------------------------------------------> | 524 | | 525 | appraiseEvidence(evidence, eventLog, refClaims) 526 | evidenceAppraisal(evidence, refClaims) 527 | attestationResult <= | 528 ~ ~ 529 | | 530 valueGeneration(targetEnvironment) | 531 | => claimsDelta | 532 | | 533 evidenceGeneration(handle, authSecIDs, collectedClaims) | 534 | => evidence | 535 | | 536 | pushEventLogDelta----------------------------------------> | 537 | pushEvidence---------------------------------------------> | 538 | | 539 | appraiseEvidence(evidence, eventLogDelta, refClaims) 540 | evidenceAppraisal(evidence, refClaims) 541 | attestationResult <= | 542 | | 544 Uni-Directional Remote Attestation procedures can be initiated both 545 by the Attester and by the Verifier. Initiation by the Attester can 546 result in unsolicited pushes of Evidence to the Verifier. Initiation 547 by the Verifier always results in solicited pushes to the Verifier. 548 The Uni-Directional model uses the same information elements as the 549 Challenge/Response model. In the sequence diagram above, the 550 Attester initiates the conveyance of Evidence (comparable with a 551 RESTful POST operation or the emission of a beacon). While a request 552 of evidence from the Verifier would result in a sequence diagram more 553 similar to the Challenge/Response model (comparable with a RESTful 554 GET operation), the specific manner how handles are created and used 555 always remains as the distinguishing quality of this model. In the 556 Uni-Directional model, handles are composed of trustable signed 557 timestamps as shown in [I-D.birkholz-rats-tuda], potentially 558 including other qualifying data. The handles are created by an 559 external 3rd entity - the Handle Distributor - that includes a 560 trustworthy source of time and takes on the role of a Time Stamping 561 Authority (TSA, as initially defined in [RFC3161]). Timstamps 562 created from local clocks (absolute clocks using a global timescale, 563 as well as relative clocks, such as tick-counters) of Attesters and 564 Verifiers MUST be cryptographically bound to fresh Handles received 565 from the Handle Distributor. This binding provides a proof of 566 synchronization that MUST be included in every evidence created. 567 Correspondingly, evidence created for conveyance via this model 568 provides a proof that it was fresh at a certain point in time. 569 Effectively, this allows for series of evidence to be pushed to 570 multiple Verifiers, simultaniously. Methods to detect excessive time 571 drift that would mandate a fresh Handle to be received by the Handle 572 Distributor, as well as timing of handle distribution are out-of- 573 scope of this document. 575 8.3. Streaming Remote Attestation 576 .----------. .----------. 577 | Attester | | Verifier | 578 '----------' '----------' 579 | | 580 valueGeneration(targetEnvironment) | 581 | => claims | 582 | | 583 | <----subscribeEvidence(handle, authSecIDs, claimSelection) | 584 | subscriptionResult --------------------------------------> | 585 | | 586 evidenceGeneration(handle, authSecIDs, collectedClaims) | 587 | => evidence | 588 | | 589 | pushEventLog---------------------------------------------> | 590 | pushEvidence---------------------------------------------> | 591 | | 592 | evidenceAppraisal(evidence, eventLog, refClaims) 593 | attestationResult <= | 594 ~ ~ 595 | | 596 valueGeneration(targetEnvironment) | 597 | => claimsDelta | 598 | | 599 evidenceGeneration(handle, authSecIDs, collectedClaims) | 600 | => evidence | 601 | | 602 | pushEventLogDelta----------------------------------------> | 603 | pushEvidence---------------------------------------------> | 604 | | 605 | evidenceAppraisal(evidence, eventLogDelta, refClaims) 606 | attestationResult <= | 607 | | 609 Streaming Remote Attestation procedures require the setup of 610 subscription state. Setting up subscription state between a Verifier 611 and an Attester is conducted via a subscribe operation. This 612 subscribe operation is used to convey the handles required for 613 Evidence generation. Effectively, this allows for series of evidence 614 to be pushed to a Verifier similar to the Uni-Directional model. 615 While a Handle Distributor is not required in this model, it is also 616 limited to bi-lateral subscription relationships, in which each 617 Verifier has to create and provide its individual handle. Handles 618 provided by a specific subscribing Verifier MUST be used in Evidence 619 generation for that specific Verifier. The Streaming model uses the 620 same information elements as the Challenge/Response and the Uni- 621 Directional model. Methods to detect excessive time drift that would 622 mandate a refreshed Handle to be conveyed via another subscribe 623 operation are out-of-scope of this document. 625 9. Additional Application-Specific Requirements 627 Depending on the use cases covered, there can be additional 628 requirements. An exemplary subset is illustrated in this section. 630 9.1. Confidentiality 632 Confidentiality of exchanged attestation information may be 633 desirable. This requirement usually is present when communication 634 takes place over insecure channels, such as the public Internet. In 635 such cases, TLS may be uses as a suitable communication protocol that 636 preserves confidentiality. In private networks, such as carrier 637 management networks, it must be evaluated whether or not the 638 transport medium is considered confidential. 640 9.2. Mutual Authentication 642 In particular use cases mutual authentication may be desirable in 643 such a way that a Verifier also needs to prove its identity to the 644 Attester, instead of only the Attester proving its identity to the 645 Verifier. 647 9.3. Hardware-Enforcement/Support 649 Depending on given usage scenarios, hardware support for secure 650 storage of cryptographic keys, crypto accelerators, as well as 651 protected or isolated execution environments can be mandatory 652 requirements. Well-known technologies in support of these 653 requirements are roots of trusts, such as Hardware Security Modules 654 (HSM), Physically Unclonable Functions (PUFs), Shielded Secrets, or 655 Trusted Executions Environments (TEEs). 657 10. Implementation Status 659 Note to RFC Editor: Please remove this section as well as references 660 to [BCP205] before AUTH48. 662 This section records the status of known implementations of the 663 protocol defined by this specification at the time of posting of this 664 Internet-Draft, and is based on a proposal described in [BCP205]. 665 The description of implementations in this section is intended to 666 assist the IETF in its decision processes in progressing drafts to 667 RFCs. Please note that the listing of any individual implementation 668 here does not imply endorsement by the IETF. Furthermore, no effort 669 has been spent to verify the information presented here that was 670 supplied by IETF contributors. This is not intended as, and must not 671 be construed to be, a catalog of available implementations or their 672 features. Readers are advised to note that other implementations may 673 exist. 675 According to [BCP205], "this will allow reviewers and working groups 676 to assign due consideration to documents that have the benefit of 677 running code, which may serve as evidence of valuable experimentation 678 and feedback that have made the implemented protocols more mature. 679 It is up to the individual working groups to use this information as 680 they see fit". 682 10.1. Implementer 684 The open-source implementation was initiated and is maintained by the 685 Fraunhofer Institute for Secure Information Technology - SIT. 687 10.2. Implementation Name 689 The open-source implementation is named "CHAllenge-Response based 690 Remote Attestation" or in short: CHARRA. 692 10.3. Implementation URL 694 The open-source implementation project resource can be located via: 695 https://github.com/Fraunhofer-SIT/charra 697 10.4. Maturity 699 The code's level of maturity is considered to be "prototype". 701 10.5. Coverage and Version Compatibility 703 The current version (commit '847bcde') is aligned with the exemplary 704 specification of the CoAP FETCH bodies defined in section Appendix A 705 of this document. 707 10.6. License 709 The CHARRA project and all corresponding code and data maintained on 710 github are provided under the BSD 3-Clause "New" or "Revised" 711 license. 713 10.7. Implementation Dependencies 715 The implementation requires the use of the official Trusted Computing 716 Group (TCG) open-source Trusted Software Stack (TSS) for the Trusted 717 Platform Module (TPM) 2.0. The corresponding code and data is also 718 maintained on github and the project resources can be located via: 719 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 10.8. Contact 726 Michael Eckel (michael.eckel@sit.fraunhofer.de) 728 11. 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 12. Acknowledgments 744 Olaf Bergmann, Michael Richardson, and Ned Smith 746 13. Change Log 748 o Initial draft -00 750 o Changes from version 00 to version 01: 752 * Added details to the flow diagram 754 * Integrated comments from Ned Smith (Intel) 756 * Reorganized sections and 758 * Updated interaction model 760 * Replaced "claims" with "assertions" 762 * Added proof-of-concept CDDL for CBOR via CoAP based on a TPM 763 2.0 quote operation 765 o Changes from version 01 to version 02: 767 * Revised the relabeling of "claims" with "assertion" in 768 alignment with the RATS Architecture I-D. 770 * Added Implementation Status section 772 * Updated interaction model 774 * Text revisions based on changes in [I-D.ietf-rats-architecture] 775 and comments provided on rats@ietf.org. 777 o Changes from version 02 to version 00 RATS related document 779 * update of the challenge/response diagram 781 * minor rephrasing of Prerequisites section 783 * rephrasing to information elements and interaction model 784 section 786 o Changes from version 00 to version 01 788 * added Attestation Authenticity, updated Identity and Secret 790 * relabeled Secret ID to Authentication Secret ID + rephrasing 792 * relabeled Claim Selection to Assertion Selection + rephrasing 794 * relabeled Evidence to (Signed) Attestation Evidence 796 * Added Attestation Result and Reference Assertions 798 * update of the challenge/response diagram and expositional text 800 * added CDDL spec for CoAP FETCH operation proof-of-concept 802 o Changes from version 01 to version 02 804 * prepared the inclusion of additional reference models 806 * update to Introduction and Scope section 808 * major update to (Normative) Prerequisites 810 * relabeled Attestation Authenticity to Att. Evidence 811 Authenticity 813 * relabeled Assertion term back to Claim terms 814 * added BCP205 Implementation Status section related to 815 Appendix CDDL 817 o Changes from version 02 to version 03 819 * major refactoring to now accommodate three interaction models 821 * updated existing and added two new diagrams for models 823 * major refactoring of existing and adding of new diagram 824 description 826 * incorporated content about Direct Anonymous Attestation 828 * integrated comments from Michael Richardson 830 * updated roster 832 14. References 834 14.1. Normative References 836 [BCP205] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 837 Code: The Implementation Status Section", BCP 205, 838 RFC 7942, DOI 10.17487/RFC7942, July 2016, 839 . 841 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 842 Requirement Levels", BCP 14, RFC 2119, 843 DOI 10.17487/RFC2119, March 1997, 844 . 846 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 847 "Internet X.509 Public Key Infrastructure Time-Stamp 848 Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 849 2001, . 851 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 852 Housley, R., and W. Polk, "Internet X.509 Public Key 853 Infrastructure Certificate and Certificate Revocation List 854 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 855 . 857 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 858 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 859 October 2013, . 861 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 862 Application Protocol (CoAP)", RFC 7252, 863 DOI 10.17487/RFC7252, June 2014, 864 . 866 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 867 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 868 May 2017, . 870 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 871 Definition Language (CDDL): A Notational Convention to 872 Express Concise Binary Object Representation (CBOR) and 873 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 874 June 2019, . 876 14.2. Informative References 878 [DAA] Brickell, E., Camenisch, J., and L. Chen, "Direct 879 Anonymous Attestation", ACM Proceedings of the 11rd ACM 880 conference on Computer and Communications Security , 881 page 132-145, 2004. 883 [I-D.birkholz-rats-tuda] 884 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 885 "Time-Based Uni-Directional Attestation", draft-birkholz- 886 rats-tuda-02 (work in progress), March 2020. 888 [I-D.ietf-rats-architecture] 889 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 890 W. Pan, "Remote Attestation Procedures Architecture", 891 draft-ietf-rats-architecture-04 (work in progress), May 892 2020. 894 [turtles] Wikipedia, "Turrles all the way down", July 2020, 895 . 897 Appendix A. CDDL Specification for a simple CoAP Challenge/Response 898 Interaction 900 The following CDDL specification is an exemplary proof-of-concept to 901 illustrate a potential implementation of the Challenge/Response 902 Interaction Model. The transfer protocol used is CoAP using the 903 FETCH operation. The actual resource operated on can be empty. Both 904 the Challenge Message and the Response Message are exchanged via the 905 FETCH operation and corresponding FETCH Request and FETCH Response 906 body. 908 In this example, evidence is created via the root-of-trust for 909 reporting primitive operation "quote" that is provided by a TPM 2.0. 911 RAIM-Bodies = CoAP-FETCH-Body / CoAP-FETCH-Response-Body 913 CoAP-FETCH-Body = [ hello: bool, ; if true, the AK-Cert is conveyed 914 nonce: bytes, 915 pcr-selection: [ + [ tcg-hash-alg-id: uint .size 2, ; TPM2_ALG_ID 916 [ + pcr: uint .size 1 ], 917 ] 918 ], 919 ] 921 CoAP-FETCH-Response-Body = [ attestation-evidence: TPMS_ATTEST-quote, 922 tpm-native-signature: bytes, 923 ? ak-cert: bytes, ; attestation key certificate 924 ] 926 TPMS_ATTEST-quote = [ qualifiediSigner: uint .size 2, ;TPM2B_NAME 927 TPMS_CLOCK_INFO, 928 firmwareVersion: uint .size 8 929 quote-responses: [ * [ pcr: uint .size 1, 930 + [ pcr-value: bytes, 931 ? hash-alg-id: uint .size 2, 932 ], 933 ], 934 ? pcr-digest: bytes, 935 ], 936 ] 938 TPMS_CLOCK_INFO = [ clock: uint .size 8, 939 resetCounter: uint .size 4, 940 restartCounter: uint .size 4, 941 save: bool, 942 ] 944 Authors' Addresses 946 Henk Birkholz 947 Fraunhofer SIT 948 Rheinstrasse 75 949 Darmstadt 64295 950 Germany 952 Email: henk.birkholz@sit.fraunhofer.de 953 Michael Eckel 954 Fraunhofer SIT 955 Rheinstrasse 75 956 Darmstadt 64295 957 Germany 959 Email: michael.eckel@sit.fraunhofer.de 961 Christopher Newton 962 University of Surrey 964 Email: cn0016@surrey.ac.uk 966 Liqun Chen 967 University of Surrey 969 Email: liqun.chen@surrey.ac.uk