idnits 2.17.1 draft-birkholz-reference-ra-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 (July 03, 2018) is 2095 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Attestor' is mentioned on line 212, but not defined == Missing Reference: 'Verifier' is mentioned on line 212, but not defined == Outdated reference: A later version (-02) exists of draft-birkholz-attestation-terminology-01 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: January 4, 2019 Huawei 6 July 03, 2018 8 Reference Interaction Model for Challenge-Response-based Remote 9 Attestation 10 draft-birkholz-reference-ra-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 January 4, 2019. 35 Copyright Notice 37 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . 7 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 claim sets (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 Attestor 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 Attestors. 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 revocation. Furthermore, any processes and 111 activities that go beyond carrying out the remote attestation process 112 are out of scope. For instance, using the result or claim of a 113 remote attestation that is emitted by the Verifier, such as 114 triggering 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-attestation-terminology]: 124 Attestor: 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 Attestor. 128 Verifier: The role that designates the system entity and that is the 129 appraiser of evidence provided by the Attestor. A system entity 130 that is the consumer of evidence takes on the role of a Verifier. 132 5. Prerequisites 134 Identity: An Attestor must have a unique Identity in such a way that 135 a Verifier can uniquely identify an Attestor. This Identity MUST 136 be part of the signed claim set (attestation evidence) that the 137 Attestor conveys to the Verifier. 139 Shared Secret: A Shared Secret between the Verifier and the 140 Attestor. This secret MUST be established between the two 141 entities before a remote attestation procedure can take place. 142 How this Shared 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 Attestor, 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 claim 163 set that composes the attestation evidence sent by the Attestor to 164 the Verifier. 166 Shared Secret ID: mandatory 168 An identifier that MUST be associated with the Shared Secret which 169 is used to sign the attestation evidence claim set. 171 Attestation Evidence: mandatory 173 The signed minimal claim set that is required to enable integrity 174 proving of the corresponding characteristics of the Attestor. 175 Examples of claims included in attestation evidence are claims 176 about sensor data, policies that are active on the system entity, 177 versions of a platform's composite firmware, running software, 178 routing tables, or information about a local time source. 179 Attestation evidence must be cryptographically bound to the 180 Verifier-provided Nonce, the Identity of the Attestor, as well as 181 to the Shared Secret identified by the Shared Secret ID. 183 Additional Info: optional 185 An Attestor MAY provide additional information or metadata that 186 are relevant to the appraisal conducted by the Verifier in order 187 to prove correctness of the integrity claims created by the 188 Attestor. Usually, all information associated with the signed 189 claim set that is available to the Attestor SHOULD be conveyed. 190 This additional information can be composed as complementary 191 signed claim sets or can be encapsulated claim sets in the signed 192 claim set that composes the evidence about integrity. This 193 information element is optional in order to enable a Verifier to 194 request additional information. An Attestor MAY decide whether or 195 not to provide that additional information or not. In either 196 case, all additional information MUST be cryptographically bound 197 to the signed claim set. An example for additional information 198 that a Verifier can request from an Attestor are (signed) 199 Reference Integrity Measurements (RIMs). 201 Identity: mandatory 203 A statement about a distinguishable Attestor 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 [Attestor] [Verifier] 213 | | 214 | <------------ Nonce, Shared Secret ID, [Additonal Info] | 215 | | 216 Collect Integrity Claims | 217 | | 218 Sign Claim Set (Evidence) | 219 | | 220 | Evidence, Identity, Nonce, Signature -----------------> | 221 | | 222 | Appraise Evidence 223 | | 225 The remote attestation procedure is initiated by the Verifier, 226 sending an attestation request to the Attestor. The attestation 227 request consists of a Nonce, a Shared Secret ID, and an optional 228 Additional Info part. The Nonce guarantees attestation freshness. 229 The Shared Secret ID selects the shared secret the Attestor is 230 requested to sign its response with. The Additional Info part is 231 optional in order to narrow down or increase the scope of received 232 evidence, if required. For example, the Verifier is only interested 233 in particular information about the Attestor, such as whether the 234 device booted up in a known state, and not include information about 235 all currently running software. 237 The Attestor, after receiving the attestation request, collects the 238 corresponding integrity claims to compose the evidence the Verifier 239 requested--or, in case the Verifier did not include any Additional 240 Info, the Attestor collects all information that can be used as 241 complementary claims in the scope of the semantics of the remote 242 attestation procedure. After that, the Attestor signs the Evidence 243 with the Shared Secret including the Nonce and the Identity 244 information, and sends the output back to the Verifier. Important at 245 this point is that the Nonce as well as the Identity information must 246 be cryptographically bound to the signature, i.e. it is not required 247 for them to be present in plain-text. For instance, those 248 information can be part of the signature after a one-way function 249 (e.g. a hash function) was applied to them. There is also a 250 possibility to scramble the Nonce or Identity with other information 251 that is known to both the Verifier and Attestor. A prominent example 252 is the IP address of the Attestor that usually is known by the 253 Attestor as well as the Verifier. This extra information can be used 254 to scramble the Nonce in order to counter a certain type of relay 255 attacks. As soon as the Verifier receives the attestation evidence 256 data, it appraises the signed evidence, the Identity as well as the 257 claims in the claim set. This process is application-specific and 258 can be done by e.g. comparing the claim set to known (good), expected 259 reference claims, such as a Reference Integrity Measurement Manifest 260 (RIMs), or evaluating it in other ways. The final output, also 261 referred to as Attestation Result, is a new claim about properties of 262 the Attestor, i.e. whether or not it is compliant to the policies, or 263 even "trusted". 265 8. Further Context 267 Depending on the use cases to cover there may be additional 268 requirements. 270 8.1. Confidentiality 272 Use confidential communication to exchange attestation information. 273 This requirement usually is present when communication happens over 274 insecure channels, such as the public Internet. Speaking of a 275 suitable communication protocol, TLS is a good candidate. In private 276 networks, such as carrier management networks, it must be evaluated 277 whether or not the transport medium is considered confidential. 279 8.2. Mutual Authentication 281 In particular use cases mutual authentication may be desirable in 282 such a way that a Verifier also needs to prove its identity to the 283 Attestor instead of only the Attestor proving its identity to the 284 Verifier. 286 8.3. Hardware-Enforcement/Support 288 In particular use cases hardware support can be desirable. Depending 289 on the requirements those can be secure storage of cryptographic 290 keys, crypto accelerators, or protected or isolated execution 291 environments. Well-known technologies are Hardware Security Modules 292 (HSM), Physical Unclonable Functions (PUFs), Shielded Secrets, 293 Trusted Executions Environments (TEEs), etc. 295 9. Security Considerations 297 There are always some. 299 10. Acknowledgements 301 Very likely. 303 11. Change Log 305 Initial draft -00 307 12. References 309 12.1. Normative References 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, 313 DOI 10.17487/RFC2119, March 1997, 314 . 316 12.2. Informative References 318 [I-D.birkholz-attestation-terminology] 319 Birkholz, H., Wiseman, M., and H. Tschofenig, "Reference 320 Terminology for Remote Attestation Procedures", draft- 321 birkholz-attestation-terminology-01 (work in progress), 322 January 2018. 324 Authors' Addresses 326 Henk Birkholz 327 Fraunhofer SIT 328 Rheinstrasse 75 329 Darmstadt 64295 330 Germany 332 Email: henk.birkholz@sit.fraunhofer.de 333 Michael Eckel 334 Huawei Technologies 335 Feldbergstrasse 78 336 Darmstadt 64293 337 Germany 339 Email: michael.eckel@huawei.com