idnits 2.17.1 draft-birkholz-rats-reference-interaction-model-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 5 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 (January 07, 2020) is 1565 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Attester' is mentioned on line 257, but not defined == Missing Reference: 'Verifier' is mentioned on line 257, but not defined == Unused Reference: 'RFC8610' is defined on line 495, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-00 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: Standards Track Fraunhofer SIT 5 Expires: July 10, 2020 January 07, 2020 7 Reference Interaction Models for Remote Attestation Procedures 8 draft-birkholz-rats-reference-interaction-model-02 10 Abstract 12 This document defines interaction models for basic remote attestation 13 procedures. Different methods of conveying attestation evidence 14 securely are defined and illustrated. Analogously, the required 15 information elements used by conveyance protocols are defined and 16 illustrated. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 10, 2020. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 54 2. Disambiguation . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Normative Prerequisites . . . . . . . . . . . . . . . . . . . 3 57 5. Remote Attestation Interaction Model . . . . . . . . . . . . 4 58 5.1. Information Elements . . . . . . . . . . . . . . . . . . 4 59 5.2. Interaction Model . . . . . . . . . . . . . . . . . . . . 6 60 6. Further Context . . . . . . . . . . . . . . . . . . . . . . . 7 61 6.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 7 62 6.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 8 63 6.3. Hardware-Enforcement/Support . . . . . . . . . . . . . . 8 64 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 65 7.1. Implementer . . . . . . . . . . . . . . . . . . . . . . . 8 66 7.2. Implementation Name . . . . . . . . . . . . . . . . . . . 9 67 7.3. Implementation URL . . . . . . . . . . . . . . . . . . . 9 68 7.4. Maturity . . . . . . . . . . . . . . . . . . . . . . . . 9 69 7.5. Coverage and Version Compatibility . . . . . . . . . . . 9 70 7.6. License . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7.7. Implementation Dependencies . . . . . . . . . . . . . . . 9 72 7.8. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 8. Security and Privacy Considerations . . . . . . . . . . . . . 9 74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 75 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 78 11.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Appendix A. CDDL Specification for a simple CoAP 80 Challenge/Response Interaction . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 Remote ATtestation procedureS [I-D.ietf-rats-architecture] are 86 workflows composed of roles and interactions, in which a Verifier 87 creates assessments based on evidence about the trustworthiness of an 88 Attester's system component characteristics. The roles _Attester_ 89 and _Verifier_, as well as the message _Evidence_ are terms defined 90 by the RATS Architecture. The goal of this document is to enable the 91 design and adoption of secure conveyance methods for attestation 92 evidence from an Attester to a Verifier. 93 This document defines three [note: pub/sub & time-based are still 94 missing] reference interaction models that describe the conveyance of 95 evidence between Attester and Verifier in order to provide the basis 96 for reliable and believable appraisal of evidence by a Verifier. 98 1.1. Requirements notation 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in 103 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 2. Disambiguation 108 The term "Remote Attestation" is a common expression and often 109 associated with certain properties. The term "Remote" in this 110 context does not necessarily refer to a remote entity in the scope of 111 network topologies or the Internet. It rather refers to a decoupled 112 system or different Types of Environments 113 [I-D.ietf-rats-architecture], which also can be present locally as 114 separate system components of a composite device (in a single RATS 115 Entity). Examples include: a Trusted Execution Environment (TEE), 116 Baseboard Management Controllers (BMCs), as well as other physical or 117 logical protected/isolated/shielded Computing Environments. 119 3. Scope 121 This document focuses on generic interaction models between Verifiers 122 and Attesters. Complementary procedures, duties and functions that 123 are required for a complete semantic binding of RATS are not in 124 scope. Examples include: identity establishment, key distribution 125 and enrollment, as well as certificate revocation. 127 Furthermore, any processes and duties that go beyond carrying out 128 remote attestation procedures are out-of-scope. For instance, using 129 the results of a remote attestation that are created by the Verifier, 130 e.g., triggering remediation actions or recovery processes, as well 131 as the remediation actions and recovery processes themselves, is also 132 out-of-scope. 134 The definition of Reference Interaction Models for RATS uses the role 135 definitions of Attester and Verifier as defined in 136 [I-D.ietf-rats-architecture]. 138 4. Normative Prerequisites 140 Attester Identity: The provenance of Attestation Evidence with 141 respect to a distinguishable Attesting Environment MUST be correct 142 and unambiguous. 144 An Attester Identity MAY be a unique identity, or it MAY be 145 included in a zero-knowledge proof (ZKP), or it MAY be part of a 146 group signature. 148 Attestation Evidence: Attestation Evidence MUST be a set of well- 149 formatted and well-protected Claims that an Attester can create 150 and convey to a Verifier. 152 Attestation Evidence Authenticity: Attestation Evidence MUST be 153 correct and authentic. 155 Attestation Evidence, in order to provide proof of authenticity, 156 SHOULD be cryptographically associated with an identity document 157 (e.g. an X.509 certificate), or SHOULD include a correct and 158 unambiguous reference to an accessible identity document. 160 Authentication Secret: An Authentication Secret MUST be available 161 exclusively to an Attester's Attesting Environment. The Attester 162 MUST sign Claims with that Authentication Secret, thereby proving 163 the authenticity of the Claims included in the signed Attestation 164 Evidence. The Authentication Secret MUST be established before 165 RATS can take place. How it is established is out-of-scope for 166 this document. 168 5. Remote Attestation Interaction Model 170 This section defines the information elements that have to be 171 conveyed via a protocol, enabling the conveyance of Evidence between 172 Verifier and Attester, as well as the interaction model for a generic 173 challenge-response remote attestation scheme. 175 5.1. Information Elements 177 Attester Identity ('attesterIdentity'): _mandatory_ 179 A statement about a distinguishable Attester made by an entity 180 without accompanying evidence of its validity, used as proof of 181 identity. 183 Authentication Secret ID ('authSecID'): _mandatory_ 185 An identifier that MUST be associated with the Authentication 186 Secret which is used to sign evidence. 188 Nonce ('nonce'): _mandatory_ 190 The Nonce (number used once) is intended to be unique and 191 practically infeasible to guess. In this reference interaction 192 model the Nonce MUST be provided by the Verifier and MUST be used 193 as proof of freshness. With respect to conveyed evidence, it 194 ensures the result of an attestation activity to be created 195 recently, e. g. sent or derived by the challenge from the 196 Verifier. As such, the Nonce MUST be part of the signed 197 Attestation Evidence that is sent from the Attester to the 198 Verifier. 200 Claims ('claims'): _mandatory_ 202 Claims are assertions that represent characteristics of an 203 Attester. Claims compose attestation evidence and are, for 204 example, used to appraise the integrity of an Attester. Examples 205 are Claims about sensor data, policies that are active on the 206 entity, versions of composite firmware of a platform, running 207 software, routing tables, or information about a local time 208 source. 210 Reference Claims ('refClaims') _mandatory_ 212 Reference Claims are a specific subset of Appraisal Policies as 213 defined in [I-D.ietf-rats-architecture]. Reference Claims are 214 used to appraise the Claims received from an Attester via 215 appraisal by direct comparison. For example, Reference Claims MAY 216 be Reference Integrity Measurements (RIMs) or assertions that are 217 implicitly trusted because they are signed by a trusted authority 218 (see Endorsements in [I-D.ietf-rats-architecture]). RIMs 219 represent (trusted) Claim sets about an Attester's intended 220 platform operational state. 222 Claim Selection ('claimSelection'): _optional_ 224 An Attester MAY provide a selection of Claims in order to reduce 225 or increase retrieved assertions to those that are relevant to the 226 appraisal policies. Usually, all available Claims that are 227 available to the Attester SHOULD be conveyed. The Claim Selection 228 MAY be composed as complementary signed Claim sets or MAY be 229 encapsulated Claims in the signed Attestation Evidence. An 230 Attester MAY decide whether or not to provide all requested Claims 231 or not. An example of a Claim Selection is a Verifier requesting 232 (signed) RIMs from an Attester. 234 (Signed) Attestation Evidence ('signedAttestationEvidence'): _mandat 235 ory_ 237 Attestation Evidence consists of the Authentication Secret ID that 238 identifies an Authentication Secret, the Attester Identity, the 239 Claims, and the Verifier-provided Nonce. Attestation Evidence 240 MUST cryptographically bind all of those elements. The 241 Attestation Evidence MUST be signed by the Authentication Secret. 242 The Authentication Secret MUST be trusted by the Verifier as 243 authoritative. 245 Attestation Result ('attestationResult'): _mandatory_ 247 An Attestation Result is produced by the Verifier as the output of 248 the appraisal of Attestation Evidence. The Attestation Result 249 represents Claims about integrity and other characteristics of the 250 corresponding Attester. 252 5.2. Interaction Model 254 The following sequence diagram illustrates the reference remote 255 attestation procedure defined by this document. 257 [Attester] [Verifier] 258 | | 259 measureClaims(attestedEnvironment) | 260 | => claims | 261 | | 262 | <---------- requestEvidence(nonce, authSecID, claimSelection) | 263 | | 264 collectClaims(claimSelection) | 265 | => claims | 266 | | 267 signAttestationEvidence(authSecID, claims, nonce) | 268 | => signedAttestationEvidence | 269 | | 270 | signedAttestationEvidence ----------------------------------> | 271 | | 272 | appraiseAttestationEvidence(signedAttestationEvidence, refClaims) 273 | attestationResult <= | 274 | | 276 The remote attestation procedure is initiated by the Verifier, 277 sending an attestation request to the Attester. The attestation 278 request consists of a Nonce, a Authentication Secret ID, and a Claim 279 Selection. The Nonce guarantees attestation freshness. The 280 Authentication Secret ID selects the secret with which the Attester 281 is requested to sign the Attestation Evidence. The Claim Selection 282 narrows down or increases the amount of received Claims, if required. 283 If the Claim Selection is empty, then by default all Claims that are 284 available on the Attester MUST be signed and returned as Attestation 285 Evidence. For example, a Verifier may only be requesting a 286 particular subset of information about the Attester, such as evidence 287 about BIOS and firmware the Attester booted up with - and not include 288 information about all currently running software. 290 The Attester, after receiving the attestation request, collects the 291 corresponding Claims that have been measured beforehand to compose 292 the Attestation Evidence that the Verifier requested. In the case 293 that the Verifier did not provide a Claim Selection, the Attester 294 collects all information that can be used as complementary Claims in 295 the scope of the semantics of the remote attestation procedure. 296 Conclusively, the Attester creates Attestation Evidence by signing 297 the Attester Identity, the Claims, and the Nonce with the 298 Authentication Secret identified by the Authentication Secret ID. 299 The signed Attestation Evidence is transferred back to the Verifier. 301 It is crucial at this point that Claims, the Nonce, as well as the 302 Attester Identity information MUST be cryptographically bound to the 303 signature of the Attestation Evidence. It is not required for them 304 to be present in plain text, though. Cryptographic blinding MAY be 305 used at this point. For further reference see section Section 8. 307 As soon as the Verifier receives the signed Attestation Evidence, it 308 verifies the signature, the Attester Identity, the Nonce, and 309 appraises the Claims. This procedure is application-specific and can 310 be carried out by comparing the Claims with corresponding Reference 311 Claims, e.g., Reference Integrity Measurements (RIMs), or using other 312 appraisal policies. The final output of the Verifier are Attestation 313 Results. Attestation Results constitute new Claims about an 314 Attester's properties and characteristics that enables relying 315 parties, for example, to assess an Attester's trustworthiness. 317 6. Further Context 319 Depending on the use cases covered, there can be additional 320 requirements. An exemplary subset is illustrated in this section. 322 6.1. Confidentiality 324 Confidentiality of exchanged attestation information may be 325 desirable. This requirement usually is present when communication 326 takes place over insecure channels, such as the public Internet. In 327 such cases, TLS may be uses as a suitable communication protocol that 328 preserves confidentiality. In private networks, such as carrier 329 management networks, it must be evaluated whether or not the 330 transport medium is considered confidential. 332 6.2. Mutual Authentication 334 In particular use cases mutual authentication may be desirable in 335 such a way that a Verifier also needs to prove its identity to the 336 Attester, instead of only the Attester proving its identity to the 337 Verifier. 339 6.3. Hardware-Enforcement/Support 341 Depending on the requirements, hardware support for secure storage of 342 cryptographic keys, crypto accelerators, or protected or isolated 343 execution environments may be useful. Well-known technologies are 344 roots of trusts, such as Hardware Security Modules (HSM), Physically 345 Unclonable Functions (PUFs), Shielded Secrets, or Trusted Executions 346 Environments (TEEs). 348 7. Implementation Status 350 Note to RFC Editor: Please remove this section as well as references 351 to [BCP205] before AUTH48. 353 This section records the status of known implementations of the 354 protocol defined by this specification at the time of posting of this 355 Internet-Draft, and is based on a proposal described in [BCP205]. 356 The description of implementations in this section is intended to 357 assist the IETF in its decision processes in progressing drafts to 358 RFCs. Please note that the listing of any individual implementation 359 here does not imply endorsement by the IETF. Furthermore, no effort 360 has been spent to verify the information presented here that was 361 supplied by IETF contributors. This is not intended as, and must not 362 be construed to be, a catalog of available implementations or their 363 features. Readers are advised to note that other implementations may 364 exist. 366 According to [BCP205], "this will allow reviewers and working groups 367 to assign due consideration to documents that have the benefit of 368 running code, which may serve as evidence of valuable experimentation 369 and feedback that have made the implemented protocols more mature. 370 It is up to the individual working groups to use this information as 371 they see fit". 373 7.1. Implementer 375 The open-source implementation was initiated and is maintained by the 376 Fraunhofer Institute for Secure Information Technology - SIT. 378 7.2. Implementation Name 380 The open-source implementation is named "CHAllenge-Response based 381 Remote Attestation" or in short: CHARRA. 383 7.3. Implementation URL 385 The open-source implementation project resource can be located via: 386 https://github.com/Fraunhofer-SIT/charra 388 7.4. Maturity 390 The code's level of maturity is considered to be "prototype". 392 7.5. Coverage and Version Compatibility 394 The current version (commit '847bcde') is aligned with the exemplary 395 specification of the CoAP FETCH bodies defined in section Appendix A 396 of this document. 398 7.6. License 400 The CHARRA project and all corresponding code and data maintained on 401 github are provided under the BSD 3-Clause "New" or "Revised" 402 license. 404 7.7. Implementation Dependencies 406 The implementation requires the use of the official Trusted Computing 407 Group (TCG) open-source Trusted Software Stack (TSS) for the Trusted 408 Platform Module (TPM) 2.0. The corresponding code and data is also 409 maintained on github and the project resources can be located via: 410 https://github.com/tpm2-software/tpm2-tss/ 412 The implementation uses the Constrained Application Protocol 413 [RFC7252] (http://coap.technology/) and the Concise Binary Object 414 Representation [RFC7049] (https://cbor.io/). 416 7.8. Contact 418 Michael Eckel (michael.eckel@sit.fraunhofer.de) 420 8. Security and Privacy Considerations 422 In a remote attestation procedure the Verifier or the Attester MAY 423 want to cryptographically blind several attributes. For instance, 424 information can be part of the signature after applying a one-way 425 function (e. g. a hash function). 427 There is also a possibility to scramble the Nonce or Attester 428 Identity with other information that is known to both the Verifier 429 and Attester. A prominent example is the IP address of the Attester 430 that usually is known by the Attester itself as well as the Verifier. 431 This extra information can be used to scramble the Nonce in order to 432 counter certain types of relay attacks. 434 9. Acknowledgments 436 Olaf Bergmann and Ned Smith 438 10. Change Log 440 o Initial draft -00 442 o Changes from version 00 to version 01: 444 * Added details to the flow diagram 446 * Integrated comments from Ned Smith (Intel) 448 * Reorganized sections and 450 * Updated interaction model 452 * Replaced "claims" with "assertions" 454 * Added proof-of-concept CDDL for CBOR via CoAP based on a TPM 455 2.0 quote operation 457 o Changes from version 01 to version 02: 459 * Revised the relabeling of "claims" with "assertion" in 460 alignment with the RATS Architecture I-D. 462 * Added Implementation Status section 464 * Updated interaction model 466 * Text revisions based on changes in [I-D.ietf-rats-architecture] 467 and comments provided on rats@ietf.org. 469 11. References 470 11.1. Normative References 472 [BCP205] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 473 Code: The Implementation Status Section", BCP 205, 474 RFC 7942, DOI 10.17487/RFC7942, July 2016, 475 . 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, 479 DOI 10.17487/RFC2119, March 1997, 480 . 482 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 483 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 484 October 2013, . 486 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 487 Application Protocol (CoAP)", RFC 7252, 488 DOI 10.17487/RFC7252, June 2014, 489 . 491 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 492 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 493 May 2017, . 495 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 496 Definition Language (CDDL): A Notational Convention to 497 Express Concise Binary Object Representation (CBOR) and 498 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 499 June 2019, . 501 11.2. Informative References 503 [I-D.ietf-rats-architecture] 504 Birkholz, H., Thaler, D., Richardson, M., and N. Smith, 505 "Remote Attestation Procedures Architecture", draft-ietf- 506 rats-architecture-00 (work in progress), December 2019. 508 Appendix A. CDDL Specification for a simple CoAP Challenge/Response 509 Interaction 511 The following CDDL specification is an examplary proof-of-concept to 512 illustrate a potential implementation of the Reference Interaction 513 Model. The transfer protocol used is CoAP using the FETCH operation. 514 The actual resource operated on can be empty. Both the Challenge 515 Message and the Response Message are exchanged via the FETCH Request 516 and FETCH Response body. 518 In this example, the root-of-trust for reporting primitive operation 519 "quote" is provided by a TPM 2.0. 521 RAIM-Bodies = CoAP-FETCH-Body / CoAP-FETCH-Response-Body 523 CoAP-FETCH-Body = [ hello: bool, ; if true, the AK-Cert is conveyed 524 nonce: bytes, 525 pcr-selection: [ + [ tcg-hash-alg-id: uint .size 2, ; TPM2_ALG_ID 526 [ + pcr: uint .size 1 ], 527 ] 528 ], 529 ] 531 CoAP-FETCH-Response-Body = [ attestation-evidence: TPMS_ATTEST-quote, 532 tpm-native-signature: bytes, 533 ? ak-cert: bytes, ; attestation key certificate 534 ] 536 TPMS_ATTEST-quote = [ qualifiediSigner: uint .size 2, ;TPM2B_NAME 537 TPMS_CLOCK_INFO, 538 firmwareVersion: uint .size 8 539 quote-responses: [ * [ pcr: uint .size 1, 540 + [ pcr-value: bytes, 541 ? hash-alg-id: uint .size 2, 542 ], 543 ], 544 ? pcr-digest: bytes, 545 ], 546 ] 548 TPMS_CLOCK_INFO = [ clock: uint .size 8, 549 resetCounter: uint .size 4, 550 restartCounter: uint .size 4, 551 save: bool, 552 ] 554 Authors' Addresses 556 Henk Birkholz 557 Fraunhofer SIT 558 Rheinstrasse 75 559 Darmstadt 64295 560 Germany 562 Email: henk.birkholz@sit.fraunhofer.de 563 Michael Eckel 564 Fraunhofer SIT 565 Rheinstrasse 75 566 Darmstadt 64295 567 Germany 569 Email: michael.eckel@sit.fraunhofer.de