idnits 2.17.1 draft-richardson-rats-usecases-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 28, 2019) is 1855 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-tschofenig-rats-psa-token-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Informational March 28, 2019 5 Expires: September 29, 2019 7 Use cases for Remote Attestation common encodings 8 draft-richardson-rats-usecases-01 10 Abstract 12 This document details mechanisms created for performing Remote 13 Attestation that have been used in a number of industries. The 14 document intially focuses on existing industry verticals, mapping 15 terminology used in those specifications to the more abstract 16 terminology used by RATS. 18 The document (aspires) goes on to go on to describe possible future 19 use cases that would be enabled by common formats. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 29, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 4. Overview of Sources of Use Cases . . . . . . . . . . . . . . 3 59 5. Use case summaries . . . . . . . . . . . . . . . . . . . . . 3 60 5.1. Trusted Computing Group (TCG) . . . . . . . . . . . . . . 3 61 5.2. Android Keystore system . . . . . . . . . . . . . . . . . 5 62 5.3. Fast IDentity Online (FIDO) Alliance . . . . . . . . . . 5 63 6. Privacy Considerations. . . . . . . . . . . . . . . . . . . . 6 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 10.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 7 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 The recently chartered IETF RATS WG intends to create a system of 76 attestations that can be shared across a multitude of different 77 users. 79 This document exists as place to collect use cases in support of the 80 IETF RATS charter point 1. This document is not expected to be 81 published as an RFC, but remain open as a working document. It could 82 become an appendix to provide motivation for a protocol standards 83 document. 85 2. Terminology 87 Critical to dealing with and constrasting different technologies is 88 to collect terms with are compatible, to distinguish those terms 89 which are similar but used in different ways. 91 This section will grow to include forward and external references to 92 terms which have been seen. When terms need to be disambiguated they 93 will be prefixed with their source, such as "TCG(claim)" or 94 "FIDO(relying party)" 96 3. Requirements Language 98 This document is not a standards track document and does not make any 99 normative protocol requirements using terminology described in 100 [RFC2119]. 102 4. Overview of Sources of Use Cases 104 The following specifications have been convered in this document: 106 o The Trusted Computing Group "Network Attestation System" (private 107 document) 109 o Android Keystore 111 o Fast Identity Online (FIDO) Alliance attestation, 113 This document will be expanded to include summaries from: 115 o Trusted Computing Group (TCG) Trusted Platform Module 116 (TPM)/Trusted Software Stack (TSS) 118 o ARM "Platform Security Architecture" 119 [I-D.tschofenig-rats-psa-token] 121 5. Use case summaries 123 5.1. Trusted Computing Group (TCG) 125 The TCG is trying to solve the problem of knowing if a networking 126 device should be part a network. If it belongs to the operator, and 127 if it running approriate software. 129 This proposal is a work-in-progress, and is available to TCG members 130 only. The goal is to be multi-vendor, scalable and extensible. The 131 proposal intentionally limits itself to: 133 o "non-privacy-preserving applications (i.e., networking, Industrial 134 IoT )", 136 o that the firmware is provided by the device manufacturer 138 o that there is a manufacturer installed hardware root of trust 139 (such as a TPM and boot room) 141 Service providers and enterprises deploy hundreds of routers, many of 142 them in remote locations where they're difficult to access or secure. 143 The point of remote attestation is to: 145 o identify a remote box in a way that's hard to spoof 147 o report the inventory of software was launched on the box in a way 148 that can not be spoofed 150 The use case described is to be able to monitor the authenticity of 151 software versions and configurations running on each device. This 152 allows owners and auditors to detect deviation from approved software 153 and firmware versions and configurations, potentially identifying 154 infected devices. 156 Attestation may be performed by network management systems. 157 Networking Equipment is often highly interconnected, so it's also 158 possible that attestation could be performed by neighboring devices. 160 Specifically listed to be out of scope includes: Linux processes, 161 assemblies of hardware/software created by end-customers, and 162 equipment that is sleepy (check term). 164 The TCG Attestion leverages the TPM to make a series of measurements 165 during the boot process, and to have the TPM sign those measurements. 166 The resulting "PCG" hashes are then available to an external 167 verifier. 169 The TCG uses the following terminology: 171 o Device Manufacuter 173 o Attester ("device under attestation") 175 o Verifier (Network Management Station) 177 o Reference Integrity Measurements (RIM), which are signed my device 178 manufacturer and integrated into firmware. 180 o Quotes: measured values (having been signed), and RIMs 182 o Reference Integrity Values (RIV) 184 o devices have a Initial Attestion Key (IAK), which is provisioned 185 at the same time as the IDevID. 187 o PCR - Platform Configuration Registry (deals with hash chains) 189 The TCG document builds upon a number of IETF technologies: SNMP 190 (Attestion MIB), YANG, XML, JSON, CBOR, NETCONF, RESTCONF, CoAP, TLS 191 and SSH. The TCG document leverages the 802.1AR IDevID and LDevID 192 processes. 194 5.2. Android Keystore system 196 [keystore] describes a system used in smart phones that run the 197 Android operation system. The system is primarily a software 198 container to contain and control access to cryptographic keys, and 199 therefore provides many of the same functions that a hardware Trusted 200 Platform Module might provide. 202 On hardware which is supported, the Android Keystore will make use of 203 whatever trusted hardware is available, including use of Trusted 204 Execution Environment (TEE) or Secure Element (SE)). The Keystore 205 therefore abstracts the hardware, and guarantees to applications that 206 the same APIs can be used on both more and less capable devices. 208 A great deal of focus from the Android Keystore seems to be on 209 providing fine-grained authorization of what keys can be used by 210 which applications. 212 XXX - clearly there must be additional (intended?) use cases that 213 provide some kind of attestion. 215 5.3. Fast IDentity Online (FIDO) Alliance 217 The FIDO Alliance [fido] has a number of specifications aimed 218 primarily at eliminating the need for passwords for authentication to 219 online services. The goal is to leverage asymmetric cryptographic 220 operations in common browser and smart-phone platforms so that users 221 can easily authentication. 223 FIDO specifications extend to various hardware second factor 224 authentication devices. 226 Terminology includes: 228 o "relying party" validates a claim 230 o "relying party application" makes FIDO Authn calls 232 o "browser" provides Web Authentication JS API 234 o "platform" is the base system 236 o "internal authenticator" is some credential built-in to the device 238 o "external authenticator" may be connected by USB, bluetooth, wifi, 239 and may be an stand-alone device, USB connected key, phone or 240 watch. 242 FIDO2 had a Key Attestion Format [fidoattestation], and a Signature 243 Format [fidosignature], but these have been combined into the W3C 244 document [fido_w3c] specification. 246 The FIDO use case involves a relying party that wants to have the HW/ 247 SW implementation does a biometric check on the human to be strongly 248 attested. 250 FIDO does provides a transport in the form of the WebAuthn and FIDO 251 CTAP protocols. 253 6. Privacy Considerations. 255 TBD 257 7. Security Considerations 259 TBD. 261 8. IANA Considerations 263 TBD. 265 9. Acknowledgements 267 10. References 269 10.1. Normative References 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, 273 DOI 10.17487/RFC2119, March 1997, 274 . 276 10.2. Informative References 278 [fido] FIDO Alliance, ., "FIDO Specification Overview", n.d., 279 . 281 [fido_w3c] 282 W3C, ., "Web Authentication: An API for accessing Public 283 Key Credentials Level 1", n.d., 284 . 286 [fidoattestation] 287 FIDO Alliance, ., "FIDO 2.0: Key Attestation", n.d., 288 . 291 [fidosignature] 292 FIDO Alliance, ., "FIDO 2.0: Signature Format", n.d., 293 . 296 [I-D.tschofenig-rats-psa-token] 297 Tschofenig, H., Frost, S., Brossard, M., and A. Shaw, 298 "Arm's Platform Security Architecture (PSA) Attestation 299 Token", draft-tschofenig-rats-psa-token-00 (work in 300 progress), March 2019. 302 [keystore] 303 Google, ., "Android Keystore System", n.d., 304 . 307 Appendix A. Changes 309 o added comments from Guy, Jessica, Henk and Ned on TCG description. 311 Author's Address 313 Michael Richardson 314 Sandelman Software Works 316 Email: mcr+ietf@sandelman.ca