RATS Working Group M. Richardson Internet-Draft Sandelman Software Works Intended status: Informational March 11, 2019 Expires: September 12, 2019 Use cases for Remote Attestation common encodings draft-richardson-rats-usecases-00 Abstract This document details mechanisms created for performing Remote Attestation that have been used in a number of industries. The document intially focuses on existing industry verticals, mapping terminology used in those specifications to the more abstract terminology used by RATS. The document (aspires) goes on to go on to describe possible future use cases that would be enabled by common formats. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 12, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Richardson Expires September 12, 2019 [Page 1] Internet-Draft useful RATS March 2019 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 4. Overview of Sources of Use Cases . . . . . . . . . . . . . . 3 5. Use case summaries . . . . . . . . . . . . . . . . . . . . . 3 5.1. Trusted Computing Group (TCG) . . . . . . . . . . . . . . 3 5.2. Android Keystore system . . . . . . . . . . . . . . . . . 4 5.3. Fast IDentity Online (FIDO) Alliance . . . . . . . . . . 5 6. Privacy Considerations. . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The recently chartered IETF RATS WG intends to create a system of attestations that can be shared across a multitude of different users. This document exists as place to collect use cases in support of the IETF RATS charter point 1. This document is not expected to be published as an RFC, but remain open as a working document. It could become an appendix to provide motivation for a protocol standards document. 2. Terminology Critical to dealing with and constrasting different technologies is to collect terms with are compatible, to distinguish those terms which are similar but used in different ways. This section will grow to include forward and external references to terms which have been seen. When terms need to be disambiguated they will be prefixed with their source, such as "TCG(claim)" or "FIDO(relying party)" Richardson Expires September 12, 2019 [Page 2] Internet-Draft useful RATS March 2019 3. Requirements Language This document is not a standards track document and does not make any normative protocol requirements using terminology described in [RFC2119]. 4. Overview of Sources of Use Cases The following specifications have been convered in this document: o The Trusted Computing Group "Network Attestation System" (private document) o Android Keystore o Fast Identity Online (FIDO) Alliance attestation, This document will be expanded to include summaries from: o Trusted Computing Group (TCG) Trusted Platform Module (TPM)/Trusted Software Stack (TSS) o ARM "Platform Security Architecture" [I-D.tschofenig-rats-psa-token] 5. Use case summaries 5.1. Trusted Computing Group (TCG) This proposal is a work-in-progress, and is available to TCG members only. The goal is to be multi-vendor, scalable and extensible. The proposal intentionally limits itself to: o "non-privacy-preserving applications (i.e., networking, Industrial IoT )", o that the firmware is provided by the device manufacturer o that there is a physical Trusted Platform Module (TPM) The proposal is intended to provide an assurance to a network operator that the equipment on _their_ network can be reliably identified. Specifically listed to be out of scope includes: Linux processes, assemblies of hardware/software created by end-customers, and equipment that is sleepy. Richardson Expires September 12, 2019 [Page 3] Internet-Draft useful RATS March 2019 The TCG Attestion leverages the TPM to make a series of measurements during the boot process, and to have the TPM sign those measurements. The resulting "PCG" hashes are then available to an external verifier. The TCG uses the following terminology: o Device Manufacuter o Attester ("device under attestation") o Verifier (Network Management Station) o Reference Integrity Measurements (RIM), which are signed my device manufacturer and integrated into firmware. o Quotes: measured values (having been signed), and RIMs o Reference Integrity Values (RIV) o devices have a Initial Attestion Key (IAK), which is provisioned at the same time as the IDevID. o PCR ? o PCG ? The TCG document builds upon a number of IETF technologies: SNMP (Attestion MIB), YANG, XML, JSON, CBOR, NETCONF, RESTCONF, CoAP, TLS and SSH. The TCG document leverages the 802.1AR IDevID and LDevID processes. 5.2. Android Keystore system [keystore] describes a system used in smart phones that run the Android operation system. The system is primarily a software container to contain and control access to cryptographic keys, and therefore provides many of the same functions that a hardware Trusted Platform Module might provide. On hardware which is supported, the Android Keystore will make use of whatever trusted hardware is available, including use of Trusted Execution Environment (TEE) or Secure Element (SE)). The Keystore therefore abstracts the hardware, and guarantees to applications that the same APIs can be used on both more and less capable devices. Richardson Expires September 12, 2019 [Page 4] Internet-Draft useful RATS March 2019 A great deal of focus from the Android Keystore seems to be on providing fine-grained authorization of what keys can be used by which applications. XXX - clearly there must be additional (intended?) use cases that provide some kind of attestion. 5.3. Fast IDentity Online (FIDO) Alliance The FIDO Alliance [fido] has a number of specifications aimed primarily at eliminating the need for passwords for authentication to online services. The goal is to leverage asymmetric cryptographic operations in common browser and smart-phone platforms so that users can easily authentication. FIDO specifications extend to various hardware second factor authentication devices. Terminology includes: o "relying party" validates a claim o "relying party application" makes FIDO Authn calls o "browser" provides Web Authentication JS API o "platform" is the base system o "internal authenticator" is some credential built-in to the device o "external authenticator" may be connected by USB, bluetooth, wifi, and may be an stand-alone device, USB connected key, phone or watch. FIDO2 had a Key Attestion Format [fidoattestation], and a Signature Format [fidosignature], but these have been combined into the W3C document [fido_w3c] specification. This specification is very much focused on authenticating user from devices with humans attached to them. 6. Privacy Considerations. TBD Richardson Expires September 12, 2019 [Page 5] Internet-Draft useful RATS March 2019 7. Security Considerations TBD. 8. IANA Considerations TBD. 9. Acknowledgements 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 10.2. Informative References [fido] FIDO Alliance, ., "FIDO Specification Overview", n.d., . [fido_w3c] W3C, ., "Web Authentication: An API for accessing Public Key Credentials Level 1", n.d., . [fidoattestation] FIDO Alliance, ., "FIDO 2.0: Key Attestation", n.d., . [fidosignature] FIDO Alliance, ., "FIDO 2.0: Signature Format", n.d., . [I-D.tschofenig-rats-psa-token] Tschofenig, H., Frost, S., Brossard, M., and A. Shaw, "Arm's Platform Security Architecture (PSA) Attestation Token", draft-tschofenig-rats-psa-token-00 (work in progress), March 2019. Richardson Expires September 12, 2019 [Page 6] Internet-Draft useful RATS March 2019 [keystore] Google, ., "Android Keystore System", n.d., . Author's Address Michael Richardson Sandelman Software Works Email: mcr+ietf@sandelman.ca Richardson Expires September 12, 2019 [Page 7]