| RATS Working Group | M. Richardson |
| Internet-Draft | Sandelman Software Works |
| Intended status: Informational | June 19, 2019 |
| Expires: December 21, 2019 |
Use cases for Remote Attestation common encodings
draft-richardson-rats-usecases-02
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 to describe possible future use cases that would be enabled by common formats.
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 December 21, 2019.
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 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.
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 for the common RATS technologies 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.
This document will probably not deal with use cases from an end-user point of view, but rather on the technology verticals that wish to use RATS concepts (such as EAT) in their deployments.
End-user use cases that would either directly leverage RATS technology, or would serve to inform technology choices are welcome, however.
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)"
Platform attestions generally come in two categories. This document will attempt to indicate for a particular attestion technology falls into this.
A static attestion says something about the platform on which the code is running.
A session attestion says something about how the shared session key was created.
The term "statement" is used as the generic term for the semantic content which is being attested to.
This document is not a standards track document and does not make any normative protocol requirements using terminology described in [RFC2119].
The following specifications have been convered in this document:
This document will be expanded to include summaries from:
And any additional sources suggested.
The TCG is trying to solve the problem of knowing if a networking device should be part of a network, if it belongs to the operator, and if it is running approriate software.
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:
Service providers and enterprises deploy hundreds of routers, many of them in remote locations where they're difficult to access or secure. The point of remote attestation is to:
The use case described is to be able to monitor the authenticity of software versions and configurations running on each device. This allows owners and auditors to detect deviation from approved software and firmware versions and configurations, potentially identifying infected devices.
Attestation may be performed by network management systems. Networking Equipment is often highly interconnected, so it's also possible that attestation could be performed by neighboring devices.
Specifically listed to be out of scope includes: Linux processes, assemblies of hardware/software created by end-customers, and equipment that is sleepy (check term).
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:
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.
[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.
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.
Android 9 on Pixel 2 and 3 can provided protected confirmation messages. This uses hardware access from the TPM/TEE to display a message directly to the user, and receives confirmation directly from the user. A hash of the contents of the message can provided in an attestation that the device provides.
In addition, the Android Keystore provides attestion information about itself for use by FIDO.
QUOTE: Finally, the Verified Boot state is included in key attestation certificates (provided by Keymaster/Strongbox) in the deviceLocked and verifiedBootState fields, which can be verified by apps as well as passed onto backend services to remotely verify boot integrity [**21]
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:
FIDO2 had a Key Attestion Format [fidoattestation], and a Signature Format [fidosignature], but these have been combined into the W3C document [fido_w3c] specification.
A FIDO use case involves a relying party that having a attestion on the biometric system that identifies a human. It is the state of the biometric system that is being attested to, not the identity of the human.
FIDO does provides a transport in the form of the WebAuthn and FIDO CTAP protocols.
According to [fidotechnote] FIDO uses attestion to make claims about the kind of device which is be used to enroll. Keypairs are generated on a per-device model basis, with a certificate having a trust chain that leads back to a well-known root certificate. It is expected that as many as 100,000 devices in a production run would have the same public and private key pair. One assumes that this is stored in a tamper-proof TPM so it is relatively difficult to get this key out. The use of this key attests to the the device type, and the kind of protections for keys that the relying party may assume, not to the identity of the end user.
TBD
TBD.
TBD.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [android_security] | Kralevich, R., "The Android Platform Security Model", n.d.. |
| [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.. |
| [fidotechnote] | FIDO Alliance, ., "FIDO TechNotes: The Truth about Attestation", 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", Internet-Draft draft-tschofenig-rats-psa-token-01, April 2019. |
| [keystore] | Google, ., "Android Keystore System", n.d.. |