idnits 2.17.1 draft-ietf-rats-reference-interaction-models-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (October 23, 2020) is 1279 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8610' is defined on line 881, 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-03 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-07 == Outdated reference: A later version (-14) exists of draft-ietf-rats-tpm-based-network-device-attest-04 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: April 26, 2021 C. Newton 6 L. Chen 7 University of Surrey 8 October 23, 2020 10 Reference Interaction Models for Remote Attestation Procedures 11 draft-ietf-rats-reference-interaction-models-01 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 in the context of the 22 Attester, Endorser, and Verifier role. 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 April 26, 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 . . . . . . . . . . . 12 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 . . . . . . . . . . . 21 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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 - generated by an 103 Attester. The roles _Attester_ and _Verifier_, as well as the 104 Conceptual Messages _Evidence_ and _Attestation Results_ are concepts 105 defined by the RATS Architecture [I-D.ietf-rats-architecture]. This 106 document defines interaction models that can be used in specific 107 RATS-related solution documents. The primary focus of this document 108 is the conveyance of attestation Evidence. The reference models 109 defined can also be applied to the conveyance of other Conceptual 110 Messages in RATS. Specific goals of this document are to: 112 o prevent inconsistencies in descriptions of interaction models in 113 other documents (due to text cloning and evolution over time), 115 o enable to highlight an exact delta/divergence between the core set 116 of characteristics captured here in this document and variants of 117 these interaction models used in other specifications or 118 solutions, and to 120 o illustrate the application of Direct Anonymous Attestation (DAA) 121 for the defined set of reference models. 123 In summary, this document enables the specification and design of 124 trustworthy and privacy preserving conveyance methods for attestation 125 Evidence from an Attester to a Verifier. While the conveyance of 126 other Conceptual Messages is out-of-scope the methods described can 127 also be applied to the conveyance of, for example, Endorsements or 128 Attestation Results. 130 2. Terminology 132 This document uses the following set of terms, roles, and concepts as 133 defined in [I-D.ietf-rats-architecture]: 135 Attester, Verifier, Relying Party, Conceptual Message, Evidence, 136 Endorsement, Attestation Result, Appraisal Policy, Attesting 137 Environment, Target Environment 139 A PKIX Certificate is an X.509v3 format certificate as specified by 140 [RFC5280]. 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in 145 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 3. Disambiguation 150 The term "Remote Attestation" is a common expression and often 151 associated or connoted with certain properties. The term "Remote" in 152 this context does not necessarily refer to a remote entity in the 153 scope of network topologies or the Internet. It rather refers to a 154 decoupled system or entities that exchange the payload of the 155 Conceptual Message type called Evidence [I-D.ietf-rats-architecture]. 156 This conveyance can also be "Local", if the Verifier role is part of 157 the same entity as the Attester role, e.g., separate system 158 components of the same Composite Device (a single RATS entity). 159 Examples of these types of co-located environments include: a Trusted 160 Execution Environment (TEE), Baseboard Management Controllers (BMCs), 161 as well as other physical or logical protected/isolated/shielded 162 Computing Environments (e.g. embedded Secure Elements (eSE) or 163 Trusted Platform Modules (TPM)). Readers of this document should be 164 familiar with the concept of Layered Attestation as described in 165 Section 4.3 Two Types of Environments of an Attester in 166 [I-D.ietf-rats-architecture] and the definition of Attestation as 167 described in [I-D.ietf-rats-tpm-based-network-device-attest]. 169 4. Scope and Intent 171 This document focuses on generic interaction models between Attesters 172 and Verifiers in order to convey Evidence. Complementary procedures, 173 functions, or services that are required for a complete semantic 174 binding of the concepts defined in [I-D.ietf-rats-architecture] are 175 out-of-scope of this document. Examples include: identity 176 establishment, key distribution and enrollment, time synchronization, 177 as well as certificate revocation. 179 Furthermore, any processes and duties that go beyond carrying out 180 remote attestation procedures are out-of-scope. For instance, using 181 the results of a remote attestation that are created by the Verifier, 182 e.g., how to triggering remediation actions or recovery processes, as 183 well as such remediation actions and recovery processes themselves, 184 are also out-of-scope. 186 The interaction models illustrated in this document are intended to 187 provide a stable basis and reference for other solutions documents 188 inside or outside the IETF. Solution documents of any kind can 189 reference the interaction models in order to avoid text clones and to 190 avoid the danger of subtle discrepancies. Analogously, deviations 191 from the generic model descriptions in this document can be 192 illustrated in solutions documents to highlight distinct 193 contributions. 195 5. Direct Anonymous Attestation 197 DAA [DAA] is a signature scheme used in RATS that allows preservation 198 of the privacy of users that are associated with an Attester (e.g. 199 its owner). Essentially, DAA can be seen as a group signature scheme 200 with the feature that given a DAA signature no-one can find out who 201 the signer is, i.e., the anonymity is not revocable. To be able to 202 sign anonymously an Attester has to obtain a credential from a DAA 203 Issuer. The DAA Issuer uses a private/public key pair to generate a 204 credential for an Attester and makes the public key (in the form of a 205 public key certificate) available to the verifier in order to enable 206 them to validate the DAA signature obtained as part of the Evidence. 208 In order to support these DAA signatures, the DAA Issuer MUST 209 associate a single key pair with each group of Attesters and use the 210 same key pair when creating the credentials for all of the Attesters 211 in this group. The DAA Issuer's public key certificate used by a 212 group of Attesters replaces the individual Attester Identity 213 documents during authenticity validation as a part of the appraisal 214 of Evidence conducted by a Verifier. This is in contrast to 215 intuition that there has to be a unique Attester Identity per device. 217 This document extends the duties of the Endorser role as defined by 218 the RATS architecture with respect to the provision of these Attester 219 Identity documents to Attesters. The existing duties of the Endorser 220 role and the duties of a DAA Issuer are quite similar as illustrated 221 in the following subsections. 223 5.1. Endorsers 225 Via its Attesting Environments, an Attester only generates Evidence 226 about its Target Environments. After being appraised to be 227 trustworthy, a Target Environment may become a new Attesting 228 Environment in charge of generating Evidence for further Target 229 Environments. [I-D.ietf-rats-architecture] explains this as Layered 230 Attestation. Layered Attestation has to start with an initial 231 Attesting Environment. In essence, there cannot be turtles all the 232 way down [turtles]. At this rock bottom of Layered Attestation, the 233 Attesting Environments are always called Roots of Trust (RoT). An 234 Attester cannot generate Evidence about its own RoTs by design. As a 235 consequence, a Verifier requires trustable statements about this 236 subset of Attesting Environments from a different source than the 237 Attester itself. The corresponding trustable statements are called 238 Endorsements and originate from external, trustable entities that 239 take on the role of an Endorser (e.g., supply chain entities). 241 5.2. Endorsers for Direct Anonymous Attestation 243 In order to enable the use of DAA, an Endorser role takes on the 244 duties of a DAA Issuer in addition to its already defined duties. 245 DAA Issuers offer zero-knowledge proofs based on public key 246 certificates used for a group of Attesters [DAA]. Effectively, these 247 certificates share the semantics of Endorsements, with the following 248 exceptions: 250 o The associated private keys are used by the DAA Issuer to provide 251 an Attester with a credential that it can use to convince the 252 Verifier that its Evidence is valid. To keep their anonymity the 253 Attester randomizes this credential each time that it is used. 255 o The Verifier can use the DAA Issuer's public key certificate, 256 together with the randomized credential from the Attester, to 257 confirm that the Evidence comes from a valid Attester. 259 o A credential is conveyed from an Endorser to an Attester in 260 combination with the conveyance of the public key certificates 261 from Endorser to Verifier. 263 The zero-knowledge proofs required cannot be created by an Attester 264 alone - like the Endorsements of RoTs - and have to be created by a 265 trustable third entity - like an Endorser. Due to that semantic 266 overlap, the Endorser role is augmented via the definition of DAA 267 duties as defined below. This augmentation enables the Endorser to 268 convey trustable third party statements both to Verifier roles and 269 Attester roles. 271 6. Normative Prerequisites 273 In order to ensure an appropriate conveyance of Evidence via 274 interaction models in general, the following set of prerequisites 275 MUST be in place to support the implementation of interaction models: 277 Attester Identity: The provenance of Evidence with respect to a 278 distinguishable Attesting Environment MUST be correct and 279 unambiguous. 281 An Attester Identity MAY be a unique identity, it MAY be included 282 in a zero-knowledge proof (ZKP), or it MAY be part of a group 283 signature, or it MAY be a randomised DAA credential. 285 Attestation Evidence Authenticity: Attestation Evidence MUST be 286 correct and authentic. 288 In order to provide proofs of authenticity, Attestation Evidence 289 SHOULD be cryptographically associated with an identity document 290 (e.g. an PKIX certificate or trusted key material, or a randomised 291 DAA credential), or SHOULD include a correct and unambiguous and 292 stable reference to an accessible identity document. 294 Authentication Secret: An Authentication Secret MUST be available 295 exclusively to an Attester's Attesting Environment. 297 The Attester MUST protect Claims with that Authentication Secret, 298 thereby proving the authenticity of the Claims included in 299 Evidence. The Authentication Secret MUST be established before 300 RATS can take place. 302 Evidence Freshness: Evidence MUST include an indicator about its 303 freshness that can be understood by a Verifier. Analogously, 304 interaction models MUST support the conveyance of proofs of 305 freshness in a way that is useful to Verifiers and their appraisal 306 procedures. 308 Evidence Protection: Evidence MUST be a set of well-formatted and 309 well-protected Claims that an Attester can create and convey to a 310 Verifier in a tamper-evident manner. 312 7. Generic Information Elements 314 This section defines the information elements that are vital to all 315 kinds interaction models. Varying from solution to solution, generic 316 information elements can be either included in the scope of protocol 317 messages (instantiating Conceptual Messages) or can be included in 318 additional protocol parameters or payload. Ultimately, the following 319 information elements are required by any kind of scalable remote 320 attestation procedure using one or more of the interaction models 321 provided. 323 Attester Identity ('attesterIdentity'): _mandatory_ 325 A statement about a distinguishable Attester made by an Endorser 326 without accompanying evidence about its validity - used as proof 327 of identity. 329 In DAA, the Attester's identity is not revealed to the verifier. 330 The Attester is issued with a credential by the Endorser that is 331 randomised and then used to anonymously confirm the validity of 332 their evidence. The evidence is verified using the Endorser's 333 public key. 335 Authentication Secret IDs ('authSecID'): _mandatory_ 337 A statement representing an identifier list that MUST be 338 associated with corresponding Authentication Secrets used to 339 protect Evidence. 341 In DAA, Authentication Secret IDs are represented by the Endorser 342 (DAA issuer)'s public key that MUST be used to create DAA 343 credentials for the corresponding Authentication Secrets used to 344 protect Evidence. 346 Each Authentication Secret is uniquely associated with a 347 distinguishable Attesting Environment. Consequently, an 348 Authentication Secret ID also identifies an Attesting Environment. 350 In DAA, an Authentication Secret ID does not identify a unique 351 Attesting Environment but associated with a group of Attesting 352 Environments. This is because an Attesting Environment should not 353 be distinguishable and the DAA credential which represents the 354 Attesting Environment is randomised each time it used. 356 Handle ('handle'): _mandatory_ 358 A statement that is intended to uniquely distinguish received 359 Evidence and/or determine the freshness of Evidence. 361 A Verifier can also use a Handle as an indicator for authenticity 362 or attestation provenance, as only Attesters and Verifiers that 363 are intended to exchange Evidence should have knowledge of the 364 corresponding Handles. Examples include Nonces or signed 365 timestamps. 367 Claims ('claims'): _mandatory_ 369 Claims are assertions that represent characteristics of an 370 Attester's Target Environment. 372 Claims are part Conceptual Message and are, for example, used to 373 appraise the integrity of Attesters via a Verifiers. The other 374 information elements in this section can be expressed as Claims in 375 any type of Conceptional Messages. 377 Reference Claims ('refClaims') _mandatory_ 378 Reference Claims are components of Reference Values as defined in 379 [I-D.ietf-rats-architecture]. [Editor's Note: Definition might 380 become obsolete, if replaced by Reference Values. Is there a 381 difference between Claims and Values here? Analogously, why is 382 not named Reference Claims in the RATS arch?] 384 Reference Claims are used to appraise the Claims received from an 385 Attester via appraisal by direct comparison. For example, 386 Reference Claims MAY be Reference Integrity Measurements (RIM) or 387 assertions that are implicitly trusted because they are signed by 388 a trusted authority (see Endorsements in 389 [I-D.ietf-rats-architecture]). Reference Claims typically 390 represent (trusted) Claim sets about an Attester's intended 391 platform operational state. 393 Claim Selection ('claimSelection'): _optional_ 395 A statement that represents a (sub-)set of Claims that can be 396 created by an Attester. 398 Claim Selections can act as filters that can specify the exact set 399 of Claims to be included in Evidence. An Attester MAY decide 400 whether or not to provide all Claims as requested via a Claim 401 Selection. 403 Evidence ('signedAttestationEvidence'): _mandatory_ 405 A set of Claims that consists of a list of Authentication Secret 406 IDs that each identifies an Authentication Secret in a single 407 Attesting Environment, the Attester Identity, Claims, and a 408 Handle. Attestation Evidence MUST cryptographically bind all of 409 these information elements. Evidence MUST be protected via an 410 Authentication Secret. The Authentication Secret MUST be trusted 411 by the Verifier as authoritative. 413 Attestation Result ('attestationResult'): _mandatory_ 415 An Attestation Result is produced by the Verifier as the output of 416 the appraisal of Evidence. Attestation Results include condensed 417 assertions about integrity or other characteristics of the 418 corresponding Attester that are digestable by Relying Parties. 420 8. Interaction Models 422 The following subsections introduce and illustrate the interaction 423 models: 425 1. Challenge/Response Remote Attestation 426 2. Uni-Directional Remote Attestation 428 3. Streaming Remote Attestation 430 Each section starts with a sequence diagram illustrating the 431 interactions between Attester and Verifier. While the interaction 432 models presented focus on the conveyance of Evidence, the intention 433 of this document is in support of future work that applies the 434 presented models to the conveyance of other Conceptual Messages, 435 namely Attestation Results, Endorsements, Reference Values, or 436 Appraisal Policies. 438 All interaction models have a strong focus on the use of a handle to 439 incorporate a type of proof of freshness. The ways these handles are 440 processed is the most prominent difference between the three 441 interaction models. 443 8.1. Challenge/Response Remote Attestation 445 .----------. .----------. 446 | Attester | | Verifier | 447 '----------' '----------' 448 | | 449 | | 450 valueGeneration(targetEnvironment) | 451 | => claims | 452 | | 453 | <------requestEvidence(handle, authSecIDs, claimSelection) | 454 | | 455 claimsCollection(claimSelection) | 456 | => collectedClaims | 457 | | 458 evidenceGeneration(handle, authSecIDs, collectedClaims) | 459 | => evidence | 460 | | 461 | returnEvidence-------------------------------------------> | 462 | returnEventLog-------------------------------------------> | 463 | | 464 | evidenceAppraisal(evidence, eventLog, refClaims) 465 | attestationResult <= | 466 | | 468 This Challenge/Response Remote Attestation procedure is initiated by 469 the Verifier, by sending a remote attestation request to the 470 Attester. A request includes a Handle, a list of Authentication 471 Secret IDs, and a Claim Selection. 473 In the Challenge/Response model, the handle is composed of qualifying 474 data in the form of a cryptographically strongly randomly generated, 475 and therefore unpredictable, nonce. The Verifier-generated nonce is 476 intended to guarantee Evidence freshness. 478 The list of Authentication Secret IDs selects the attestation keys 479 with which the Attester is requested to sign the Attestation 480 Evidence. Each selected key is uniquely associated with an Attesting 481 Environment of the Attester. As a result, a single Authentication 482 Secret ID identifies a single Attesting Environment. 484 Analogously, a particular set of Evidence originating from a 485 particular Attesting Environments in a composite device can be 486 requested via multiple Authentication Secret IDs. Methods to acquire 487 Authentication Secret IDs or mappings between Attesting Environments 488 to Authentication Secret IDs are out-of-scope of this document. 490 The Claim Selection narrows down the set of Claims collected and used 491 to create Evidence to those that the Verifier requires. If the Claim 492 Selection is omitted, then by default all Claims that are known and 493 available on the Attester MUST be used to create corresponding 494 Evidence. For example when performing a boot integrity evaluation, a 495 Verifier may only be requesting a particular subset of claims about 496 the Attester, such as Evidence about BIOS and firmware the Attester 497 booted up, and not include information about all currently running 498 software. 500 While it is crucial that Claims, the Handle, as well as the Attester 501 Identity information MUST be cryptographically bound to the signature 502 of Evidence, they may be presented in an encrypted form. 504 Cryptographic blinding MAY be used at this point. For further 505 reference see section Section 11. 507 As soon as the Verifier receives signed Evidence, it validates the 508 signature, the Attester Identity, as well as the Nonce, and appraises 509 the Claims. Appraisal procedures are application-specific and can be 510 conducted via comparison of the Claims with corresponding Reference 511 Claims, such as Reference Integrity Measurements. The final output 512 of the Verifier are Attestation Results. Attestation Results 513 constitute new Claims Sets about an Attester's properties and 514 characteristics that enables Relying Parties, for example, to assess 515 an Attester's trustworthiness. 517 8.2. Uni-Directional Remote Attestation 519 .----------. .----------. 520 | Attester | | Verifier | 521 '----------' '----------' 522 | | 523 valueGeneration(targetEnvironment) | 524 | => claims | 525 | | 526 | .--------------------. | 527 | <----------handle | | | 528 | | Handle Distributor | | 529 | | | handle----------> | 530 | '--------------------' | 531 | | 532 evidenceGeneration(handle, authSecIDs, collectedClaims) | 533 | => evidence | 534 | | 535 | pushEventLog---------------------------------------------> | 536 | pushEvidence---------------------------------------------> | 537 | | 538 | appraiseEvidence(evidence, eventLog, refClaims) 539 | attestationResult <= | 540 ~ ~ 541 | | 542 valueGeneration(targetEnvironment) | 543 | => claimsDelta | 544 | | 545 evidenceGeneration(handle, authSecIDs, collectedClaims) | 546 | => evidence | 547 | | 548 | pushEventLogDelta----------------------------------------> | 549 | pushEvidence---------------------------------------------> | 550 | | 551 | appraiseEvidence(evidence, eventLogDelta, refClaims) 552 | attestationResult <= | 553 | | 555 Uni-Directional Remote Attestation procedures can be initiated both 556 by the Attester and by the Verifier. Initiation by the Attester can 557 result in unsolicited pushes of Evidence to the Verifier. Initiation 558 by the Verifier always results in solicited pushes to the Verifier. 559 The Uni-Directional model uses the same information elements as the 560 Challenge/Response model. In the sequence diagram above, the 561 Attester initiates the conveyance of Evidence (comparable with a 562 RESTful POST operation or the emission of a beacon). While a request 563 of evidence from the Verifier would result in a sequence diagram more 564 similar to the Challenge/Response model (comparable with a RESTful 565 GET operation), the specific manner how handles are created and used 566 always remains as the distinguishing quality of this model. In the 567 Uni-Directional model, handles are composed of trustable signed 568 timestamps as shown in [I-D.birkholz-rats-tuda], potentially 569 including other qualifying data. The handles are created by an 570 external 3rd entity - the Handle Distributor - that includes a 571 trustworthy source of time and takes on the role of a Time Stamping 572 Authority (TSA, as initially defined in [RFC3161]). Timstamps 573 created from local clocks (absolute clocks using a global timescale, 574 as well as relative clocks, such as tick-counters) of Attesters and 575 Verifiers MUST be cryptographically bound to fresh Handles received 576 from the Handle Distributor. This binding provides a proof of 577 synchronization that MUST be included in every evidence created. 578 Correspondingly, evidence created for conveyance via this model 579 provides a proof that it was fresh at a certain point in time. 580 Effectively, this allows for series of evidence to be pushed to 581 multiple Verifiers, simultaniously. Methods to detect excessive time 582 drift that would mandate a fresh Handle to be received by the Handle 583 Distributor, as well as timing of handle distribution are out-of- 584 scope of this document. 586 8.3. Streaming Remote Attestation 587 .----------. .----------. 588 | Attester | | Verifier | 589 '----------' '----------' 590 | | 591 valueGeneration(targetEnvironment) | 592 | => claims | 593 | | 594 | <----subscribeEvidence(handle, authSecIDs, claimSelection) | 595 | subscriptionResult --------------------------------------> | 596 | | 597 evidenceGeneration(handle, authSecIDs, collectedClaims) | 598 | => evidence | 599 | | 600 | pushEventLog---------------------------------------------> | 601 | pushEvidence---------------------------------------------> | 602 | | 603 | evidenceAppraisal(evidence, eventLog, refClaims) 604 | attestationResult <= | 605 ~ ~ 606 | | 607 valueGeneration(targetEnvironment) | 608 | => claimsDelta | 609 | | 610 evidenceGeneration(handle, authSecIDs, collectedClaims) | 611 | => evidence | 612 | | 613 | pushEventLogDelta----------------------------------------> | 614 | pushEvidence---------------------------------------------> | 615 | | 616 | evidenceAppraisal(evidence, eventLogDelta, refClaims) 617 | attestationResult <= | 618 | | 620 Streaming Remote Attestation procedures require the setup of 621 subscription state. Setting up subscription state between a Verifier 622 and an Attester is conducted via a subscribe operation. This 623 subscribe operation is used to convey the handles required for 624 Evidence generation. Effectively, this allows for series of evidence 625 to be pushed to a Verifier similar to the Uni-Directional model. 626 While a Handle Distributor is not required in this model, it is also 627 limited to bi-lateral subscription relationships, in which each 628 Verifier has to create and provide its individual handle. Handles 629 provided by a specific subscribing Verifier MUST be used in Evidence 630 generation for that specific Verifier. The Streaming model uses the 631 same information elements as the Challenge/Response and the Uni- 632 Directional model. Methods to detect excessive time drift that would 633 mandate a refreshed Handle to be conveyed via another subscribe 634 operation are out-of-scope of this document. 636 9. Additional Application-Specific Requirements 638 Depending on the use cases covered, there can be additional 639 requirements. An exemplary subset is illustrated in this section. 641 9.1. Confidentiality 643 Confidentiality of exchanged attestation information may be 644 desirable. This requirement usually is present when communication 645 takes place over insecure channels, such as the public Internet. In 646 such cases, TLS may be uses as a suitable communication protocol that 647 preserves confidentiality. In private networks, such as carrier 648 management networks, it must be evaluated whether or not the 649 transport medium is considered confidential. 651 9.2. Mutual Authentication 653 In particular use cases mutual authentication may be desirable in 654 such a way that a Verifier also needs to prove its identity to the 655 Attester, instead of only the Attester proving its identity to the 656 Verifier. 658 9.3. Hardware-Enforcement/Support 660 Depending on given usage scenarios, hardware support for secure 661 storage of cryptographic keys, crypto accelerators, as well as 662 protected or isolated execution environments can be mandatory 663 requirements. Well-known technologies in support of these 664 requirements are roots of trusts, such as Hardware Security Modules 665 (HSM), Physically Unclonable Functions (PUFs), Shielded Secrets, or 666 Trusted Executions Environments (TEEs). 668 10. Implementation Status 670 Note to RFC Editor: Please remove this section as well as references 671 to [BCP205] before AUTH48. 673 This section records the status of known implementations of the 674 protocol defined by this specification at the time of posting of this 675 Internet-Draft, and is based on a proposal described in [BCP205]. 676 The description of implementations in this section is intended to 677 assist the IETF in its decision processes in progressing drafts to 678 RFCs. Please note that the listing of any individual implementation 679 here does not imply endorsement by the IETF. Furthermore, no effort 680 has been spent to verify the information presented here that was 681 supplied by IETF contributors. This is not intended as, and must not 682 be construed to be, a catalog of available implementations or their 683 features. Readers are advised to note that other implementations may 684 exist. 686 According to [BCP205], "this will allow reviewers and working groups 687 to assign due consideration to documents that have the benefit of 688 running code, which may serve as evidence of valuable experimentation 689 and feedback that have made the implemented protocols more mature. 690 It is up to the individual working groups to use this information as 691 they see fit". 693 10.1. Implementer 695 The open-source implementation was initiated and is maintained by the 696 Fraunhofer Institute for Secure Information Technology - SIT. 698 10.2. Implementation Name 700 The open-source implementation is named "CHAllenge-Response based 701 Remote Attestation" or in short: CHARRA. 703 10.3. Implementation URL 705 The open-source implementation project resource can be located via: 706 https://github.com/Fraunhofer-SIT/charra 708 10.4. Maturity 710 The code's level of maturity is considered to be "prototype". 712 10.5. Coverage and Version Compatibility 714 The current version ('1bcb469') implements a challenge/response 715 interaction model and is aligned with the exemplary specification of 716 the CoAP FETCH bodies defined in Section Appendix A of this document. 718 10.6. License 720 The CHARRA project and all corresponding code and data maintained on 721 github are provided under the BSD 3-Clause "New" or "Revised" 722 license. 724 10.7. Implementation Dependencies 726 The implementation requires the use of the official Trusted Computing 727 Group (TCG) open-source Trusted Software Stack (TSS) for the Trusted 728 Platform Module (TPM) 2.0. The corresponding code and data is also 729 maintained on github and the project resources can be located via: 730 https://github.com/tpm2-software/tpm2-tss/ 731 The implementation uses the Constrained Application Protocol 732 [RFC7252] (http://coap.technology/) and the Concise Binary Object 733 Representation [RFC7049] (https://cbor.io/). 735 10.8. Contact 737 Michael Eckel (michael.eckel@sit.fraunhofer.de) 739 11. Security and Privacy Considerations 741 In a remote attestation procedure the Verifier or the Attester MAY 742 want to cryptographically blind several attributes. For instance, 743 information can be part of the signature after applying a one-way 744 function (e. g. a hash function). 746 There is also a possibility to scramble the Nonce or Attester 747 Identity with other information that is known to both the Verifier 748 and Attester. A prominent example is the IP address of the Attester 749 that usually is known by the Attester itself as well as the Verifier. 750 This extra information can be used to scramble the Nonce in order to 751 counter certain types of relay attacks. 753 12. Acknowledgments 755 Olaf Bergmann, Michael Richardson, and Ned Smith 757 13. Change Log 759 o Initial draft -00 761 o Changes from version 00 to version 01: 763 * Added details to the flow diagram 765 * Integrated comments from Ned Smith (Intel) 767 * Reorganized sections and 769 * Updated interaction model 771 * Replaced "claims" with "assertions" 773 * Added proof-of-concept CDDL for CBOR via CoAP based on a TPM 774 2.0 quote operation 776 o Changes from version 01 to version 02: 778 * Revised the relabeling of "claims" with "assertion" in 779 alignment with the RATS Architecture I-D. 781 * Added Implementation Status section 783 * Updated interaction model 785 * Text revisions based on changes in [I-D.ietf-rats-architecture] 786 and comments provided on rats@ietf.org. 788 o Changes from version 02 to version 00 RATS related document 790 * update of the challenge/response diagram 792 * minor rephrasing of Prerequisites section 794 * rephrasing to information elements and interaction model 795 section 797 o Changes from version 00 to version 01 799 * added Attestation Authenticity, updated Identity and Secret 801 * relabeled Secret ID to Authentication Secret ID + rephrasing 803 * relabeled Claim Selection to Assertion Selection + rephrasing 805 * relabeled Evidence to (Signed) Attestation Evidence 807 * Added Attestation Result and Reference Assertions 809 * update of the challenge/response diagram and expositional text 811 * added CDDL spec for CoAP FETCH operation proof-of-concept 813 o Changes from version 01 to version 02 815 * prepared the inclusion of additional reference models 817 * update to Introduction and Scope section 819 * major update to (Normative) Prerequisites 821 * relabeled Attestation Authenticity to Att. Evidence 822 Authenticity 824 * relabeled Assertion term back to Claim terms 825 * added BCP205 Implementation Status section related to 826 Appendix CDDL 828 o Changes from version 02 to version 03 830 * major refactoring to now accommodate three interaction models 832 * updated existing and added two new diagrams for models 834 * major refactoring of existing and adding of new diagram 835 description 837 * incorporated content about Direct Anonymous Attestation 839 * integrated comments from Michael Richardson 841 * updated roster 843 14. References 845 14.1. Normative References 847 [BCP205] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 848 Code: The Implementation Status Section", BCP 205, 849 RFC 7942, DOI 10.17487/RFC7942, July 2016, 850 . 852 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 853 Requirement Levels", BCP 14, RFC 2119, 854 DOI 10.17487/RFC2119, March 1997, 855 . 857 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 858 "Internet X.509 Public Key Infrastructure Time-Stamp 859 Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 860 2001, . 862 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 863 Housley, R., and W. Polk, "Internet X.509 Public Key 864 Infrastructure Certificate and Certificate Revocation List 865 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 866 . 868 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 869 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 870 October 2013, . 872 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 873 Application Protocol (CoAP)", RFC 7252, 874 DOI 10.17487/RFC7252, June 2014, 875 . 877 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 878 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 879 May 2017, . 881 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 882 Definition Language (CDDL): A Notational Convention to 883 Express Concise Binary Object Representation (CBOR) and 884 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 885 June 2019, . 887 14.2. Informative References 889 [DAA] Brickell, E., Camenisch, J., and L. Chen, "Direct 890 Anonymous Attestation", ACM Proceedings of the 11rd ACM 891 conference on Computer and Communications Security , 892 page 132-145, 2004. 894 [I-D.birkholz-rats-tuda] 895 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 896 "Time-Based Uni-Directional Attestation", draft-birkholz- 897 rats-tuda-03 (work in progress), July 2020. 899 [I-D.ietf-rats-architecture] 900 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 901 W. Pan, "Remote Attestation Procedures Architecture", 902 draft-ietf-rats-architecture-07 (work in progress), 903 October 2020. 905 [I-D.ietf-rats-tpm-based-network-device-attest] 906 Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- 907 based Network Device Remote Integrity Verification", 908 draft-ietf-rats-tpm-based-network-device-attest-04 (work 909 in progress), September 2020. 911 [turtles] Rudnicki, R., "Turtles All the Way Down: Foundation, 912 Edifice, and Ruin in Faulkner and McCarthy", The Faulkner 913 Journal 25.2, DOI 10.1353/fau.2010.0002, 2010. 915 Appendix A. CDDL Specification for a simple CoAP Challenge/Response 916 Interaction 918 The following CDDL specification is an exemplary proof-of-concept to 919 illustrate a potential implementation of the Challenge/Response 920 Interaction Model. The transfer protocol used is CoAP using the 921 FETCH operation. The actual resource operated on can be empty. Both 922 the Challenge Message and the Response Message are exchanged via the 923 FETCH operation and corresponding FETCH Request and FETCH Response 924 body. 926 In this example, evidence is created via the root-of-trust for 927 reporting primitive operation "quote" that is provided by a TPM 2.0. 929 RAIM-Bodies = CoAP-FETCH-Body / CoAP-FETCH-Response-Body 931 CoAP-FETCH-Body = [ hello: bool, ; if true, the AK-Cert is conveyed 932 nonce: bytes, 933 pcr-selection: [ + [ tcg-hash-alg-id: uint .size 2, ; TPM2_ALG_ID 934 [ + pcr: uint .size 1 ], 935 ] 936 ], 937 ] 939 CoAP-FETCH-Response-Body = [ attestation-evidence: TPMS_ATTEST-quote, 940 tpm-native-signature: bytes, 941 ? ak-cert: bytes, ; attestation key certificate 942 ] 944 TPMS_ATTEST-quote = [ qualifiediSigner: uint .size 2, ;TPM2B_NAME 945 TPMS_CLOCK_INFO, 946 firmwareVersion: uint .size 8 947 quote-responses: [ * [ pcr: uint .size 1, 948 + [ pcr-value: bytes, 949 ? hash-alg-id: uint .size 2, 950 ], 951 ], 952 ? pcr-digest: bytes, 953 ], 954 ] 956 TPMS_CLOCK_INFO = [ clock: uint .size 8, 957 resetCounter: uint .size 4, 958 restartCounter: uint .size 4, 959 save: bool, 960 ] 962 Authors' Addresses 964 Henk Birkholz 965 Fraunhofer SIT 966 Rheinstrasse 75 967 Darmstadt 64295 968 Germany 970 Email: henk.birkholz@sit.fraunhofer.de 972 Michael Eckel 973 Fraunhofer SIT 974 Rheinstrasse 75 975 Darmstadt 64295 976 Germany 978 Email: michael.eckel@sit.fraunhofer.de 980 Christopher Newton 981 University of Surrey 983 Email: cn0016@surrey.ac.uk 985 Liqun Chen 986 University of Surrey 988 Email: liqun.chen@surrey.ac.uk