idnits 2.17.1 draft-birkholz-rats-reference-interaction-model-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 6 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, 2019) is 1726 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Attester' is mentioned on line 240, but not defined == Missing Reference: 'Verifier' is mentioned on line 240, but not defined == Outdated reference: A later version (-03) exists of draft-birkholz-rats-architecture-01 Summary: 3 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, 2020 July 08, 2019 7 Reference Interaction Model for Challenge-Response-based Remote 8 Attestation 9 draft-birkholz-rats-reference-interaction-model-01 11 Abstract 13 This document defines an interaction model for a basic remote 14 attestation procedure. Additionally, the required information 15 elements are illustrated. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 9, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 2 53 2. Disambiguation . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Component Roles . . . . . . . . . . . . . . . . . . . . . . . 3 56 5. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 3 57 6. Remote Attestation Interaction Model . . . . . . . . . . . . 4 58 6.1. Information Elements . . . . . . . . . . . . . . . . . . 4 59 6.2. Interaction Model . . . . . . . . . . . . . . . . . . . . 6 60 7. Further Context . . . . . . . . . . . . . . . . . . . . . . . 7 61 7.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 7 62 7.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 7 63 7.3. Hardware-Enforcement/Support . . . . . . . . . . . . . . 7 64 8. Security and Privacy Considerations . . . . . . . . . . . . . 8 65 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 66 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 11.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Appendix A. CDDL Specification for a simple CoAP 71 Challenge/Response Interaction . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 Remote attestation procedures (RATS) are a combination of activities, 77 in which a Verifier creates assertions about assertions of integrity 78 and about characteristics of other system entities by the appraisal 79 of corresponding signed assertions (evidence). In this document, a 80 reference interaction model for a generic challenge-response-based 81 remote attestation procedure is provided. The minimum set of 82 components, roles and information elements that have to be conveyed 83 between Verifier and Attester are defined as a standard reference to 84 derive more complex RATS from. 86 1.1. Requirements notation 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 90 "OPTIONAL" in this document are to be interpreted as described in 91 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 92 capitals, as shown here. 94 2. Disambiguation 96 The term "Remote Attestation" is a common expression and often 97 associated with certain properties. The term "Remote" in this 98 context does not necessarily refer to a remote system entity in the 99 scope of network topologies or the Internet. It rather refers to a 100 decoupled system or different computing context, which also could be 101 present locally as components of a composite device. Examples 102 include: a Trusted Execution Environment (TEE), Baseboard Management 103 Controllers (BMCs), as well as other physical or logical protected/ 104 isolated execution environments. 106 3. Scope 108 This document focuses on a generic interaction model between 109 Verifiers and Attesters. Complementary processes, functions and 110 activities that are required for a complete semantic binding of RATS 111 are not in scope. Examples include: identity establishment, key 112 enrollment, and certificate revocation. Furthermore, any processes 113 and activities that go beyond carrying out the remote attestation 114 process are out of scope. For instance, using the result of a remote 115 attestation that is emitted by the Verifier, such as triggering 116 remediation actions and recovery processes, as well as the 117 remediation actions and recovery processes themselves, are out of 118 scope. 120 4. Component Roles 122 The Reference Interaction Model for Challenge-Response-based Remote 123 Attestation is based on the standard roles defined in 124 [I-D.birkholz-rats-architecture]: 126 Attester: The role that designates the subject of the remote 127 attestation. A system entity that is the provider of evidence 128 takes on the role of an Attester. 130 Verifier: The role that designates the system entity and that is the 131 appraiser of evidence provided by the Attester. A system entity 132 that is the consumer of evidence takes on the role of a Verifier. 134 5. Prerequisites 136 Attester Identity: 138 Attestation Authenticity: An Attestation MUST be authentic. 140 An attestation, in order to be authentic, MAY This Identity MUST 141 be part of the signed assertions (attestation evidence) that the 142 Attester conveys to the Verifier. An Identity MAY be a unique 143 identity or it MAY be included in a zero-knowledge proof (ZKP) or 144 be part of a group signature. 146 Authentication Secret: An Authentication Secret MUST be present on 147 the Attester. The Attester MUST sign assertions with that 148 Authentication Secret, proving the authenticity of the assertions. 149 The Authentication Secret MUST be established before a remote 150 attestation procedure can take place. How it is established is 151 out of scope for this reference model. 153 6. Remote Attestation Interaction Model 155 This section defines the information elements that have to be 156 conveyed via a protocol, enabling the conveyance of Evidence between 157 Verifier and Attester, as well as the interaction model for a generic 158 challenge-response remote attestation scheme. 160 6.1. Information Elements 162 Attester Identity ('attesterIdentity'): _mandatory_ 164 A statement about a distinguishable Attester made by an entity 165 without accompanying evidence of its validity, used as proof of 166 identity. 168 Authentication Secret ID ('authSecID'): _mandatory_ 170 An identifier that MUST be associated with the Authentication 171 Secret which is used to sign evidence. 173 Nonce ('nonce'): _mandatory_ 175 The Nonce (number used once) is intended to be unique and 176 practically infeasible to guess. In this reference interaction 177 model the Nonce MUST be provided by the Verifier and MUST be used 178 as proof of freshness. With respect to conveyed evidence, it 179 ensures the result of an attestation activity to be created 180 recently, e. g. sent or derived by the challenge from the 181 Verifier. As such, the Nonce MUST be part of the signed 182 Attestation Evidence that is sent from the Attester to the 183 Verifier. 185 Assertions ('assertions'): _mandatory_ 187 Assertions represent characteristics of an Attester. They are 188 required for proving the integrity of an Attester. Examples are 189 assertions about sensor data, policies that are active on the 190 system entity, versions of composite firmware of a platform, 191 running software, routing tables, or information about a local 192 time source. 194 Reference Assertions ('refAssertions') _mandatory_ 196 Reference Assertions are used to verify the assertions received 197 from an Attester in an attestation verification process. For 198 example, Reference Assertions MAY be Reference Integrity 199 Measurements (RIMs) or assertions that are implicitly trusted 200 because they are signed by a trusted authority. RIMs represent 201 (trusted) assertions about the intended platform operational state 202 of the Attester. 204 Assertion Selection ('assertionSelection'): _optional_ 206 An Attester MAY provide a selection of assertions in order to 207 reduce or increase retrieved assertions to those that are relevant 208 to the conducted appraisal. Usually, all available assertions 209 that are available to the Attester SHOULD be conveyed. The 210 Assertion Selection MAY be composed as complementary signed 211 assertions or MAY be encapsulated assertions in the signed 212 Attestation Evidence. An Attester MAY decide whether or not to 213 provide all requested assertions or not. An example for an 214 Assertion Selection is a Verifier requesting (signed) RIMs from an 215 Attester. 217 (Signed) Attestation Evidence ('signedAttestationEvidence'): _mandat 218 ory_ 220 Attestation Evidence consists of the Authentication Secret ID that 221 identifies an Authentication Secret, the Attester Identity, the 222 Assertions, and the Verifier-provided Nonce. Attestation Evidence 223 MUST cryptographically bind all of those elements. The 224 Attestation Evidence MUST be signed by the Authentication Secret. 225 The Authentication Secret MUST be trusted by the Verifier as 226 authoritative. 228 Attestation Result ('attestationResult'): _mandatory_ 230 An Attestation Result is produced by the Verifier as a result of a 231 Verification of Attestation Evidence. The Attestation Result 232 represents assertions about integrity and other characteristics of 233 the corresponding Attester. 235 6.2. Interaction Model 237 The following sequence diagram illustrates the reference remote 238 attestation procedure defined by this document. 240 [Attester] [Verifier] 241 | | 242 | <--- requestAttestation(nonce, authSecID, assertionSelection) | 243 | | 244 collectAssertions(assertionSelection) | 245 | => assertions | 246 | | 247 signAttestationEvidence(authSecID, assertions, nonce) | 248 | => signedAttestationEvidence | 249 | | 250 | signedAttestationEvidence ----------------------------------> | 251 | | 252 | verifyAttestationEvidence(signedAttestationEvidence, refAssertions) 253 | attestationResult <= | 254 | | 256 The remote attestation procedure is initiated by the Verifier, 257 sending an attestation request to the Attester. The attestation 258 request consists of a Nonce, a Authentication Secret ID, and an 259 Assertion Selection. The Nonce guarantees attestation freshness. 260 The Authentication Secret ID selects the secret with which the 261 Attester is requested to sign the Attestation Evidence. The 262 Assertions Selection narrows down or increases the amount of received 263 Assertions, if required. If the Assertions Selection is empty, then 264 by default all assertions that are available on the system of the 265 Attester SHOULD be signed and returned as Attestation Evidence. For 266 example, a Verifier may only be interested in particular information 267 about the Attester, such as proof of with which BIOS and firmware it 268 booted up, and not include information about all currently running 269 software. 271 The Attester, after receiving the attestation request, collects the 272 corresponding Assertions to compose the Attestation Evidence that the 273 Verifier requested--or, in case the Verifier did not provide an 274 Assertions Selection, the Attester collects all information that can 275 be used as complementary Assertions in the scope of the semantics of 276 the remote attestation procedure. After that, the Attester produces 277 Attestation Evidence by signing the Attester Identity, the 278 Assertions, and the Nonce with the Authentication Secret identified 279 by the Authentication Secret ID. Then the Attester sends the signed 280 Attestation Evidence back to the Verifier. 282 Important at this point is that Assertions, the Nonce as well as the 283 Attester Identity information MUST be cryptographically bound to the 284 signature of the Attestation Evidence. It is not required for them 285 to be present in plain text, though. Cryptographic blinding MAY be 286 used at this point. For further reference see Security and Privacy 287 Considerations (Section 8) 289 As soon as the Verifier receives the signed Attestation Evidence, it 290 verifies the signature, the Attester Identity, the Nonce, and the 291 Assertions. This process is application-specific and can be carried 292 out by, e. g., comparing the Assertions to known (good), expected 293 Reference Assertions, such as Reference Integrity Measurements 294 (RIMs), or evaluating it in other ways. The final output of the 295 Verifier is the Attestation Result. It constitutes an new assertion 296 about properties and characteristics of the Attester, i. e. whether 297 or not it is compliant to policies, or even can be "trusted". 299 7. Further Context 301 Depending on the use cases to cover, there may be additional 302 requirements. Some of them are mentioned in this section. 304 7.1. Confidentiality 306 Confidentiality of exchanged attestation information may be 307 desirable. This requirement usually is present when communication 308 takes place over insecure channels, such as the public Internet. In 309 such cases, TLS may be uses as a suitable communication protocol that 310 preserves confidentiality. In private networks, such as carrier 311 management networks, it must be evaluated whether or not the 312 transport medium is considered confidential. 314 7.2. Mutual Authentication 316 In particular use cases mutual authentication may be desirable in 317 such a way that a Verifier also needs to prove its identity to the 318 Attester, instead of only the Attester proving its identity to the 319 Verifier. 321 7.3. Hardware-Enforcement/Support 323 Depending on the requirements, hardware support for secure storage of 324 cryptographic keys, crypto accelerators, or protected or isolated 325 execution environments may be useful. Well-known technologies are 326 Hardware Security Modules (HSM), Physically Unclonable Functions 327 (PUFs), Shielded Secrets, and Trusted Executions Environments (TEEs). 329 8. Security and Privacy Considerations 331 In a remote attestation process the Verifier or the Attester MAY want 332 to cryptographically blind several attributes. For instance, 333 information can be part of the signature after applying a one-way 334 function (e. g. a hash function). 336 There is also a possibility to scramble the Nonce or Attester 337 Identity with other information that is known to both the Verifier 338 and Attester. A prominent example is the IP address of the Attester 339 that usually is known by the Attester itself as well as the Verifier. 340 This extra information can be used to scramble the Nonce in order to 341 counter certain types of relay attacks. 343 9. Acknowledgments 345 Very likely. 347 10. Change Log 349 o Initial draft -00 351 o Changes from version 00 to version 01: 353 * Added details to the flow diagram 355 o Changes from version 01 to version 02: 357 * Integrated comments from Ned Smith (Intel) 359 * Reorganized sections and 361 * Updated interaction model 363 o Changes from version 02 to version 03: 365 * Replaced "claims" with "assertions" 367 * Added proof-of-concept CDDL for CBOR via CoAP based on a TPM 368 2.0 quote operation 370 11. References 372 11.1. Normative References 374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 375 Requirement Levels", BCP 14, RFC 2119, 376 DOI 10.17487/RFC2119, March 1997, 377 . 379 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 380 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 381 May 2017, . 383 11.2. Informative References 385 [I-D.birkholz-rats-architecture] 386 Birkholz, H., Wiseman, M., Tschofenig, H., and N. Smith, 387 "Architecture and Reference Terminology for Remote 388 Attestation Procedures", draft-birkholz-rats- 389 architecture-01 (work in progress), March 2019. 391 Appendix A. CDDL Specification for a simple CoAP Challenge/Response 392 Interaction 394 The following CDDL specification is an examplary proof-of-concept to 395 illustrate a potential implementation of the Reference Interaction 396 Model. The transfer protocol used is CoAP using the FETCH operation. 397 The actual resource operated on can be empty. Both the Challenge 398 Message and the Response Message are exchanged via the FETCH Request 399 and FETCH Response body. 401 In this example, the root-of-trust for reporting primitive operation 402 "quote" is provided by a TPM 2.0. 404 RAIM-Bodies = CoAP-FETCH-Body / CoAP-FETCH-Response-Body 406 CoAP-FETCH-Body = [ hello: bool, ; if true, the AK-Cert is conveyed 407 nonce: bytes, 408 pcr-selection: [ + [ tcg-hash-alg-id: uint .size 2, ; TPM2_ALG_ID 409 [ + pcr: uint .size 1 ], 410 ] 411 ], 412 ] 414 CoAP-FETCH-Response-Body = [ attestation-evidence: TPMS_ATTEST-quote, 415 tpm-native-signature: bytes, 416 ? ak-cert: bytes, ; attestation key certificate 417 ] 419 TPMS_ATTEST-quote = [ qualifiediSigner: uint .size 2, ;TPM2B_NAME 420 TPMS_CLOCK_INFO, 421 firmwareVersion: uint .size 8 422 quote-responses: [ * [ pcr: uint .size 1, 423 + [ pcr-value: bytes, 424 ? hash-alg-id: uint .size 2, 425 ], 426 ], 427 ? pcr-digest: bytes, 428 ], 429 ] 431 TPMS_CLOCK_INFO = [ clock: uint .size 8, 432 resetCounter: uint .size 4, 433 restartCounter: uint .size 4, 434 save: bool, 435 ] 437 Authors' Addresses 439 Henk Birkholz 440 Fraunhofer SIT 441 Rheinstrasse 75 442 Darmstadt 64295 443 Germany 445 Email: henk.birkholz@sit.fraunhofer.de 446 Michael Eckel 447 Fraunhofer SIT 448 Rheinstrasse 75 449 Darmstadt 64295 450 Germany 452 Email: michael.eckel@sit.fraunhofer.de