idnits 2.17.1 draft-birkholz-rats-reference-interaction-model-00.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 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2019) is 1865 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Attester' is mentioned on line 212, but not defined == Missing Reference: 'Verifier' is mentioned on line 212, but not defined == Outdated reference: A later version (-03) exists of draft-birkholz-rats-architecture-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TBD H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Informational M. Eckel 5 Expires: September 13, 2019 Huawei 6 March 12, 2019 8 Reference Interaction Model for Challenge-Response-based Remote 9 Attestation 10 draft-birkholz-rats-reference-interaction-model-00 12 Abstract 14 This document defines an interaction model for a basic remote 15 attestation procedure. Additionally, the required information 16 elements are 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 September 13, 2019. 35 Copyright Notice 37 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . 2 54 2. Disambiguation . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Component Roles . . . . . . . . . . . . . . . . . . . . . . . 3 57 5. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 3 58 6. Remote Attestation Interaction Model . . . . . . . . . . . . 4 59 6.1. Information Elements . . . . . . . . . . . . . . . . . . 4 60 7. Interaction Model . . . . . . . . . . . . . . . . . . . . . . 5 61 8. Further Context . . . . . . . . . . . . . . . . . . . . . . . 6 62 8.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 6 63 8.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 6 64 8.3. Hardware-Enforcement/Support . . . . . . . . . . . . . . 7 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 67 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 12.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 Remote attestation procedures (RATS) are a combination of activities, 76 in which a Verifier creates assertions about claims of integrity and 77 about the characteristics of other system entities by the appraisal 78 of corresponding signed claims (evidence). In this document, a 79 reference interaction model for a generic challenge-response-based 80 remote attestation procedure is provided. The minimum set of 81 components, roles and information elements that have to be conveyed 82 between Verifier and Attester are defined as a standard reference to 83 derive more complex RATS from. 85 1.1. Requirements notation 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 89 "OPTIONAL" in this document are to be interpreted as described in RFC 90 2119, BCP 14 [RFC2119]. 92 2. Disambiguation 94 The term "Remote Attestation" is a common expression and often 95 associated with certain properties. The term "Remote" in this 96 context does not necessarily refer to a remote system entity in the 97 scope of network topologies or the Internet. It rather refers to a 98 decoupled system or different computing context, which also could be 99 present locally as components of a composite device. Examples 100 include: a Trusted Execution Environment (TEE), Baseboard Management 101 Controllers (BMCs), as well as other physical or logical protected/ 102 isolated execution environments. 104 3. Scope 106 This document focuses on a generic interaction model between 107 Verifiers and Attesters. Complementary processes, functions and 108 activities that are required for a complete semantic binding of RATS 109 are not in scope. Examples include: identity establishment, key 110 enrollment, and certificate revocation. Furthermore, any processes 111 and activities that go beyond carrying out the remote attestation 112 process are out of scope. For instance, using the result of a remote 113 attestation that is emitted by the Verifier, such as triggering 114 remediation actions and recovery processes, as well as the 115 remediation actions and recovery processes themselves, are out of 116 scope. 118 4. Component Roles 120 The Reference Interaction Model for Challenge-Response-based Remote 121 Attestation is based on the standard roles defined in 122 [I-D.birkholz-rats-architecture]: 124 Attester: The role that designates the subject of the remote 125 attestation. A system entity that is the provider of evidence 126 takes on the role of an Attester. 128 Verifier: The role that designates the system entity and that is the 129 appraiser of evidence provided by the Attester. A system entity 130 that is the consumer of evidence takes on the role of a Verifier. 132 5. Prerequisites 134 Identity: An Attester must have a unique Identity in such a way that 135 a Verifier can uniquely identify an Attester. This Identity MUST 136 be part of the signed claims (attestation evidence) that the 137 Attester conveys to the Verifier. 139 Secret: A Secret that is present on the Attester and that a Verifier 140 can identify by its Secret ID, e.g. a public key. This Secret 141 MUST be established before a remote attestation procedure can take 142 place. How this Secret is established is out of scope for this 143 reference model. 145 6. Remote Attestation Interaction Model 147 This section defines the information elements that have to be 148 conveyed via a protocol, enabling the conveyance of Evidence between 149 Verifier and Attester, as well as the interaction model for a generic 150 challenge-response scheme. 152 6.1. Information Elements 154 Nonce: mandatory 156 The Nonce (number used once) is a number intended to be unique and 157 intended to be effectively infeasible to guess. In this reference 158 interaction model it MUST be provided by the Verifier and MUST be 159 used as a proof of freshness, with respect to conveyed evidence 160 ensuring that the result of an attestation activity was created 161 recently (i. e. triggered by the challenge emitted by the 162 Verifier). As such, the Nonce MUST be part of the signed evidence 163 sent by the Attester to the Verifier. 165 Secret ID: mandatory 167 An identifier that MUST be associated with the Secret which is 168 used to sign the evidence. 170 Evidence: mandatory 172 The signed claims that are required to enable integrity proving of 173 the corresponding characteristics of the Attester. Examples of 174 claims included in attestation evidence are claims about sensor 175 data, policies that are active on the system entity, versions of 176 composite firmware of a platform, running software, routing 177 tables, or information about a local time source. Attestation 178 evidence must be cryptographically bound to the Verifier-provided 179 Nonce, the Identity of the Attester, as well as to the Secret 180 identified by the Secret ID. 182 Claim Selection: optional 184 An Attester MAY provide a selection of claims that are relevant to 185 the appraisal conducted by the Verifier in order to prove 186 correctness of the (integrity) claims created by the Attester. 187 Usually, all available claims that are available to the Attester 188 SHOULD be conveyed. This claim selection can be composed as 189 complementary signed claims or can be encapsulated claims in the 190 signed evidence that composes the evidence about integrity. This 191 information element is optional in order to enable a Verifier to 192 narrow down or increase the amount of received evidence. An 193 Attester MAY decide whether or not to provide the requested claims 194 or not. In either case, the claim selection MUST be 195 cryptographically bound to the signed claim set. An example for a 196 claim selection is that a Verifier can request from an Attester 197 (signed) Reference Integrity Measurements (RIMs), which represent 198 a claim about the intended platform operational state of the 199 Attester. 201 Identity: mandatory 203 A statement about a distinguishable Attester made by an entity 204 without accompanying evidence of its validity, used as proof of 205 identity. 207 7. Interaction Model 209 The following sequence diagram illustrates the reference remote 210 attestation procedure defined by this document. 212 [Attester] [Verifier] 213 | | 214 | <--- requestAttestation(nonce, secretID, claimSelection) | 215 | | 216 collectClaims(claimSelection) | 217 | ===> claims | 218 | | 219 signEvidence(claims, secretID, nonce, identity) | 220 | ===> evidence, signature | 221 | | 222 | evidence, signature, identity -------------------------> | 223 | | 224 | appraise(evidence, signature, identity, nonce) 225 | appraisalResult <=== | 226 | | 228 The remote attestation procedure is initiated by the Verifier, 229 sending an attestation request to the Attester. The attestation 230 request consists of a Nonce, a Secret ID, and a Claim Selection. The 231 Nonce guarantees attestation freshness. The Secret ID selects the 232 secret the Attester is requested to sign the Evidence with. The 233 Claim Selection narrows down or increases the amount of received 234 Evidence, if required. If the Claim Selection is empty, then by 235 default all claims that are available on the system of the Attester 236 SHOULD be signed and returned as Evidence. For example, the Verifier 237 is only interested in particular information about the Attester, such 238 as whether the device booted up in a known state, and not include 239 information about all currently running software. 241 The Attester, after receiving the attestation request, collects the 242 corresponding claims to compose the evidence the Verifier requested-- 243 or, in case the Verifier did not provide a claim selection, the 244 Attester collects all information that can be used as complementary 245 claims in the scope of the semantics of the remote attestation 246 procedure. After that, the Attester signs the evidence with the 247 secret identified by the secret ID, including the nonce and the 248 identity information. Then the Attester sends the output back to the 249 Verifier. Important at this point is that the nonce as well as the 250 identity information must be cryptographically bound to the 251 signature, i. e. it is not required for them to be present in plain 252 text. For instance, those information can be part of the signature 253 after a one-way function (e. g. a hash function) was applied to them. 254 There is also a possibility to scramble the nonce or identity with 255 other information that is known to both the Verifier and Attester. A 256 prominent example is the IP address of the Attester that usually is 257 known by the Attester as well as the Verifier. This extra 258 information can be used to scramble the Nonce in order to counter 259 certain types of relay attacks. As soon as the Verifier receives the 260 evidence, it appraises it, including the verification of the 261 signature, the identity, the nonce, and the claims included in the 262 evidence. This process is application-specific and can be done by e. 263 g. comparing the claims to known (good), expected reference claims, 264 such as Reference Integrity Measurements (RIMs), or evaluating it in 265 other ways. The final output, the appraisal result (also referred to 266 as attestation result), is a new claim about properties of the 267 Attester, i. e. whether or not it is compliant to policies, or even 268 can be "trusted". 270 8. Further Context 272 Depending on the use cases to cover there may be additional 273 requirements. 275 8.1. Confidentiality 277 Use confidential communication to exchange attestation information. 278 This requirement usually is present when communication happens over 279 insecure channels, such as the public Internet. Speaking of a 280 suitable communication protocol, TLS is a good candidate. In private 281 networks, such as carrier management networks, it must be evaluated 282 whether or not the transport medium is considered confidential. 284 8.2. Mutual Authentication 286 In particular use cases mutual authentication may be desirable in 287 such a way that a Verifier also needs to prove its identity to the 288 Attester instead of only the Attester proving its identity to the 289 Verifier. 291 8.3. Hardware-Enforcement/Support 293 In particular use cases hardware support can be desirable. Depending 294 on the requirements those can be secure storage of cryptographic 295 keys, crypto accelerators, or protected or isolated execution 296 environments. Well-known technologies are Hardware Security Modules 297 (HSM), Physical Unclonable Functions (PUFs), Shielded Secrets, 298 Trusted Executions Environments (TEEs), etc. 300 9. Security Considerations 302 There are always some. 304 10. Acknowledgements 306 Very likely. 308 11. Change Log 310 Initial draft -00 312 Changes from version 00 to version 01: 314 Added details to the flow diagram 316 12. References 318 12.1. Normative References 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, 322 DOI 10.17487/RFC2119, March 1997, 323 . 325 12.2. Informative References 327 [I-D.birkholz-rats-architecture] 328 Birkholz, H., Wiseman, M., Tschofenig, H., and N. Smith, 329 "Architecture and Reference Terminology for Remote 330 Attestation Procedures", draft-birkholz-rats- 331 architecture-00 (work in progress), October 2018. 333 Authors' Addresses 335 Henk Birkholz 336 Fraunhofer SIT 337 Rheinstrasse 75 338 Darmstadt 64295 339 Germany 341 Email: henk.birkholz@sit.fraunhofer.de 343 Michael Eckel 344 Huawei Technologies 345 Feldbergstrasse 78 346 Darmstadt 64293 347 Germany 349 Email: michael.eckel@huawei.com