idnits 2.17.1 draft-birkholz-reference-ra-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 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 (January 02, 2019) is 1934 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: July 6, 2019 Huawei 6 January 02, 2019 8 Reference Interaction Model for Challenge-Response-based Remote 9 Attestation 10 draft-birkholz-reference-ra-interaction-model-01 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 July 6, 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 . . . . . . . . . . . . . . . . . . . . . 7 63 8.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . 8 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 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 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 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-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 claim set (attestation evidence) that the 137 Attester conveys to the Verifier. 139 Shared Secret: A Shared Secret between the Verifier and the 140 Attester. 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 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 claim 163 set that composes the attestation evidence sent by the Attester 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 Attester. 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 Attester, as well as 181 to the Shared Secret identified by the Shared Secret ID. 183 Additional Info: optional 185 An Attester 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 Attester. Usually, all information associated with the signed 189 claim set that is available to the Attester 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 Attester 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 Attester are (signed) 199 Reference Integrity Measurements (RIMs). 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 | ---+ | 217 +-+-+ | collectClaims(claimSelection) | 218 | |<-+ | 219 | |--+ | 220 +-+-+ | claimSet | 221 | <--+ | 222 | | 223 | ---+ | 224 +-+-+ | signClaims(claims, nonce, secretID, identity) | 225 | |<-+ | 226 | |--+ | 227 +-+-+ | signedEvidence | 228 | <--+ | 229 | | 230 | returnResult(evidence, signature, identity)i----------> | 231 | | 232 | +--- | 233 | appraise(evidence, signature, identity, nonce) | +-+-+ 234 | +->| | 235 | +--| | 236 | appraisalResult | +-+-+ 237 | +--> | 238 | | 240 The remote attestation procedure is initiated by the Verifier, 241 sending an attestation request to the Attester. The attestation 242 request consists of a Nonce, a Shared Secret ID, and an optional 243 Additional Info part. The Nonce guarantees attestation freshness. 244 The Shared Secret ID selects the shared secret the Attester is 245 requested to sign its response with. The Additional Info part is 246 optional in order to narrow down or increase the scope of received 247 evidence, if required. For example, the Verifier is only interested 248 in particular information about the Attester, such as whether the 249 device booted up in a known state, and not include information about 250 all currently running software. 252 The Attester, after receiving the attestation request, collects the 253 corresponding integrity claims to compose the evidence the Verifier 254 requested--or, in case the Verifier did not include any Additional 255 Info, the Attester collects all information that can be used as 256 complementary claims in the scope of the semantics of the remote 257 attestation procedure. After that, the Attester signs the Evidence 258 with the Shared Secret including the Nonce and the Identity 259 information, and sends the output back to the Verifier. Important at 260 this point is that the Nonce as well as the Identity information must 261 be cryptographically bound to the signature, i.e. it is not required 262 for them to be present in plain-text. For instance, those 263 information can be part of the signature after a one-way function 264 (e.g. a hash function) was applied to them. There is also a 265 possibility to scramble the Nonce or Identity with other information 266 that is known to both the Verifier and Attester. A prominent example 267 is the IP address of the Attester that usually is known by the 268 Attester as well as the Verifier. This extra information can be used 269 to scramble the Nonce in order to counter a certain type of relay 270 attacks. As soon as the Verifier receives the attestation evidence 271 data, it appraises the signed evidence, the Identity as well as the 272 claims in the claim set. This process is application-specific and 273 can be done by e.g. comparing the claim set to known (good), expected 274 reference claims, such as a Reference Integrity Measurement Manifest 275 (RIMs), or evaluating it in other ways. The final output, also 276 referred to as Attestation Result, is a new claim about properties of 277 the Attester, i.e. whether or not it is compliant to the policies, or 278 even "trusted". 280 8. Further Context 282 Depending on the use cases to cover there may be additional 283 requirements. 285 8.1. Confidentiality 287 Use confidential communication to exchange attestation information. 288 This requirement usually is present when communication happens over 289 insecure channels, such as the public Internet. Speaking of a 290 suitable communication protocol, TLS is a good candidate. In private 291 networks, such as carrier management networks, it must be evaluated 292 whether or not the transport medium is considered confidential. 294 8.2. Mutual Authentication 296 In particular use cases mutual authentication may be desirable in 297 such a way that a Verifier also needs to prove its identity to the 298 Attester instead of only the Attester proving its identity to the 299 Verifier. 301 8.3. Hardware-Enforcement/Support 303 In particular use cases hardware support can be desirable. Depending 304 on the requirements those can be secure storage of cryptographic 305 keys, crypto accelerators, or protected or isolated execution 306 environments. Well-known technologies are Hardware Security Modules 307 (HSM), Physical Unclonable Functions (PUFs), Shielded Secrets, 308 Trusted Executions Environments (TEEs), etc. 310 9. Security Considerations 312 There are always some. 314 10. Acknowledgements 316 Very likely. 318 11. Change Log 320 Initial draft -00 322 Changes from version 00 to version 01: 324 Added details to the flow diagram 326 12. References 328 12.1. Normative References 330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, 332 DOI 10.17487/RFC2119, March 1997, 333 . 335 12.2. Informative References 337 [I-D.birkholz-rats-architecture] 338 Birkholz, H., Wiseman, M., Tschofenig, H., and N. Smith, 339 "Architecture and Reference Terminology for Remote 340 Attestation Procedures", draft-birkholz-rats- 341 architecture-00 (work in progress), October 2018. 343 Authors' Addresses 345 Henk Birkholz 346 Fraunhofer SIT 347 Rheinstrasse 75 348 Darmstadt 64295 349 Germany 351 Email: henk.birkholz@sit.fraunhofer.de 353 Michael Eckel 354 Huawei Technologies 355 Feldbergstrasse 78 356 Darmstadt 64293 357 Germany 359 Email: michael.eckel@huawei.com