idnits 2.17.1 draft-ietf-rats-architecture-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 : ---------------------------------------------------------------------------- ** There are 22 instances of too long lines in the document, the longest one being 34 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 (17 December 2019) is 1591 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC4949' on line 124 looks like a reference -- Missing reference section? 'EDITORIAL NOTE' on line 137 looks like a reference Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Informational D. Thaler 5 Expires: 19 June 2020 Microsoft 6 M. Richardson 7 Sandelman Software Works 8 N. Smith 9 Intel 10 17 December 2019 12 Remote Attestation Procedures Architecture 13 draft-ietf-rats-architecture-00 15 Abstract 17 In network protocol exchanges, it is often the case that one entity 18 (a relying party) requires evidence about a remote peer to assess the 19 peer's trustworthiness, and a way to appraise such evidence. The 20 evidence is typically a set of claims about its software and hardware 21 platform. This document describes an architecture for such remote 22 attestation procedures (RATS). 24 Note to Readers 26 Discussion of this document takes place on the RATS Working Group 27 mailing list (rats@ietf.org), which is archived at 28 https://mailarchive.ietf.org/arch/browse/rats/ 29 (https://mailarchive.ietf.org/arch/browse/rats/). 31 Source for this draft and an issue tracker can be found at 32 https://github.com/ietf-rats-wg/architecture (https://github.com/ 33 ietf-rats-wg/architecture). 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 19 June 2020. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Simplified BSD License text 62 as described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 69 3. Reference Use Cases . . . . . . . . . . . . . . . . . . . . . 4 70 4. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 71 5. Topological Models . . . . . . . . . . . . . . . . . . . . . 5 72 6. Two Types of Environments . . . . . . . . . . . . . . . . . . 5 73 7. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 8. Conceptual Messages . . . . . . . . . . . . . . . . . . . . . 6 75 9. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 77 11. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 79 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 80 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 83 1. Introduction 85 2. Terminology 87 The document defines the term "Remote Attestation" as follows: A 88 process by which one entity (the "Attester") provides evidence about 89 its identity and state to another remote entity (the "Relying 90 Party"), which then assesses the Attester's trustworthiness for the 91 Relying Party's own purposes. 93 This document then uses the following terms: 95 * Appraisal Policy for Evidence: A set of rules that direct how a 96 verifier evaluates the validity of information about an Attester. 97 Compare /security policy/ in [RFC4949]. 99 * Appraisal Policy for Attestation Result: A set of rules that 100 direct how a Relying Party evaluates the validity of information 101 about an Attester. Compare /security policy/ in [RFC4949]. 103 * Attestation Result: The evaluation results generated by a 104 Verifier, typically including information about an Attester, where 105 the Verifier vouches for the validity of the results. 107 * Attester: An entity whose attributes must be evaluated in order to 108 determine whether the entity is considered trustworthy, such as 109 when deciding whether the entity is authorized to perform some 110 operation. 112 * Endorsement: A secure statement that some entity (typically a 113 manufacturer) vouches for the integrity of an Attester's signing 114 capability. 116 * Endorser: An entity that creates Endorsements that can be used to 117 help evaluate trustworthiness of Attesters. 119 * Evidence: A set of information about an Attester that is to be 120 evaluated by a Verifier. 122 * Relying Party: An entity that depends on the validity of 123 information about another entity, typically for purposes of 124 authorization. Compare /relying party/ in [RFC4949]. 126 * Relying Party Owner: An entity, such as an administrator, that is 127 authorized to configure Appraisal Policy for Attestation Results 128 in a Relying Party. 130 * Verifier: An entity that evaluates the validity of Evidence about 131 an Attester. 133 * Verifier Owner: An entity, such as an administrator, that is 134 authorized to configure Appraisal Policy for Evidence in a 135 Verifier. 137 [EDITORIAL NOTE] 139 The term Attestation and Remote Attestation are not defined in this 140 document, at this time. This document will include pointers to 141 industry uses of the terms, in an attempt to gain consensus around 142 the term, and be consistent with the charter text defining this term. 144 3. Reference Use Cases 146 148 4. Architectural Overview 150 Figure 1 depicts the data that flows between different roles, 151 independent of protocol or use case. 153 ************ ************ ***************** 154 * Endorser * * Verifier * * Relying Party * 155 ************ * Owner * * Owner * 156 | ************ ***************** 157 | | | 158 Endorsements| | | 159 | |Appraisal | 160 | |Policy for | 161 | |Evidence | Appraisal 162 | | | Policy for 163 | | | Attestation 164 | | | Result 165 v v | 166 .-----------------. | 167 .----->| Verifier |------. | 168 | '-----------------' | | 169 | | | 170 | Attestation| | 171 | Results | | 172 | Evidence | | 173 | | | 174 | v v 175 .----------. .-----------------. 176 | Attester | | Relying Party | 177 '----------' '-----------------' 179 Figure 1: Conceptual Data Flow 181 An Attester creates Evidence that is conveyed to a Verifier. 183 The Verifier uses the Evidence, and any Endorsements from Endorsers, 184 by applying an Evidence Appraisal Policy to assess the 185 trustworthiness of the Attester, and generates Attestation Results 186 for use by Relying Parties. The Evidence Appraisal Policy might be 187 obtained from an Endorser along with the Endorsements, or might be 188 obtained via some other mechanism such as being configured in the 189 Verifier by an administrator. 191 The Relying Party uses Attestation Results by applying its own 192 Appraisal Policy to make application-specific decisions such as 193 authorization decisions. The Attestation Result Appraisal Policy 194 might, for example, be configured in the Relying Party by an 195 administrator. 197 5. Topological Models 199 202 6. Two Types of Environments 204 An Attester consists of at least one Attesting Environment and 205 Attested Environment. In some implementations, the Attesting and 206 Attested Environments might be combined. Other implementations might 207 have multiple Attesting and Attested Environments. 209 212 7. Trust Model 214 The scope of this document is scenarios for which a Relying Party 215 trusts a Verifier that can evaluate the trustworthiness of 216 information about an Attester. Such trust might come by the Relying 217 Party trusting the Verifier (or its public key) directly, or might 218 come by trusting an entity (e.g., a Certificate Authority) that is in 219 the Verifier's certificate chain. The Relying Party might implicitly 220 trust a Verifier (such as in the Verifying Relying Party 221 combination). Or, for a stronger level of security, the Relying 222 Party might require that the Verifier itself provide information 223 about itself that the Relying Party can use to evaluate the 224 trustworthiness of the Verifier before accepting its Attestation 225 Results. 227 In solutions following the background-check model, the Attester is 228 assumed to trust the Verifier (again, whether directly or indirectly 229 via a Certificate Authority that it trusts), since the Attester 230 relies on an Attestation Result it obtains from the Verifier, in 231 order to access resources. 233 The Verifier trusts (or more specifically, the Verifier's security 234 policy is written in a way that configures the Verifier to trust) a 235 manufacturer, or the manufacturer's hardware, so as to be able to 236 evaluate the trustworthiness of that manufacturer's devices. In 237 solutions with weaker security, a Verifier might be configured to 238 implicitly trust firmware or even software (e.g., a hypervisor). 240 That is, it might evaluate the trustworthiness of an application 241 component, or operating system component or service, under the 242 assumption that information provided about it by the lower-layer 243 hypervisor or firmware is true. A stronger level of security comes 244 when information can be vouched for by hardware or by ROM code, 245 especially if such hardware is physically resistant to hardware 246 tampering. The component that is implicitly trusted is often 247 referred to as a Root of Trust. 249 8. Conceptual Messages 251 254 Evidence Attestation Results 256 .--------------. CWT CWT .-------------------. 257 | Attester-A |------------. .----------->| Relying Party V | 258 '--------------' v | `-------------------' 259 .--------------. JWT .------------. JWT .-------------------. 260 | Attester-B |-------->| Verifier |-------->| Relying Party W | 261 '--------------' | | `-------------------' 262 .--------------. X.509 | | X.509 .-------------------. 263 | Attester-C |-------->| |-------->| Relying Party X | 264 '--------------' | | `-------------------' 265 .--------------. TPM | | TPM .-------------------. 266 | Attester-D |-------->| |-------->| Relying Party Y | 267 '--------------' '------------' `-------------------' 268 .--------------. other ^ | other .-------------------. 269 | Attester-E |------------' '----------->| Relying Party Z | 270 '--------------' `-------------------' 272 Figure 2: Multiple Attesters and Relying Parties with Different 273 Formats 275 9. Freshness 277 279 10. Privacy Considerations 281 The conveyance of Evidence and the resulting Attestation Results 282 reveal a great deal of information about the internal state of a 283 device. In many cases, the whole point of the Attestation process is 284 to provide reliable information about the type of the device and the 285 firmware/software that the device is running. This information is 286 particularly interesting to many attackers. For example, knowing 287 that a device is running a weak version of firmware provides a way to 288 aim attacks better. 290 Protocols that convey Evidence or Attestation Results are responsible 291 for detailing what kinds of information are disclosed, and to whom 292 they are exposed. 294 11. Security Considerations 296 299 12. IANA Considerations 301 This document does not require any actions by IANA. 303 13. Acknowledgments 305 Special thanks go to David Wooten, Joerg Borchert, Hannes Tschofenig, 306 Laurence Lundblade, Diego Lopez, Jessica Fitzgerald-McKay, Frank Xia, 307 and Nancy Cam-Winget. 309 14. Contributors 311 Thomas Hardjono created older versions of the terminology section in 312 collaboration with Ned Smith. Eric Voit provided the conceptual 313 separation between Attestation Provision Flows and Attestation 314 Evidence Flows. Monty Wisemen created the content structure of the 315 first three architecture drafts. Carsten Bormann provided many of 316 the motivational building blocks with respect to the Internet Threat 317 Model. 319 Authors' Addresses 321 Henk Birkholz 322 Fraunhofer SIT 323 Rheinstrasse 75 324 64295 Darmstadt 325 Germany 326 Email: henk.birkholz@sit.fraunhofer.de 328 Dave Thaler 329 Microsoft 330 United States of America 332 Email: dthaler@microsoft.com 334 Michael Richardson 335 Sandelman Software Works 336 Canada 338 Email: mcr+ietf@sandelman.ca 340 Ned Smith 341 Intel Corporation 342 United States of America 344 Email: ned.smith@intel.com