< draft-richardson-rats-usecases-01.txt   draft-richardson-rats-usecases-02.txt >
RATS Working Group M. Richardson RATS Working Group M. Richardson
Internet-Draft Sandelman Software Works Internet-Draft Sandelman Software Works
Intended status: Informational March 28, 2019 Intended status: Informational June 19, 2019
Expires: September 29, 2019 Expires: December 21, 2019
Use cases for Remote Attestation common encodings Use cases for Remote Attestation common encodings
draft-richardson-rats-usecases-01 draft-richardson-rats-usecases-02
Abstract Abstract
This document details mechanisms created for performing Remote This document details mechanisms created for performing Remote
Attestation that have been used in a number of industries. The Attestation that have been used in a number of industries. The
document intially focuses on existing industry verticals, mapping document intially focuses on existing industry verticals, mapping
terminology used in those specifications to the more abstract terminology used in those specifications to the more abstract
terminology used by RATS. terminology used by RATS.
The document (aspires) goes on to go on to describe possible future The document aspires to describe possible future use cases that would
use cases that would be enabled by common formats. be enabled by common formats.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 29, 2019. This Internet-Draft will expire on December 21, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Static attestions . . . . . . . . . . . . . . . . . . . . 3
2.2. Session attestions . . . . . . . . . . . . . . . . . . . 3
2.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
4. Overview of Sources of Use Cases . . . . . . . . . . . . . . 3 4. Overview of Sources of Use Cases . . . . . . . . . . . . . . 3
5. Use case summaries . . . . . . . . . . . . . . . . . . . . . 3 5. Use case summaries . . . . . . . . . . . . . . . . . . . . . 4
5.1. Trusted Computing Group (TCG) . . . . . . . . . . . . . . 3 5.1. Trusted Computing Group (TCG) . . . . . . . . . . . . . . 4
5.2. Android Keystore system . . . . . . . . . . . . . . . . . 5 5.2. Android Keystore system . . . . . . . . . . . . . . . . . 5
5.3. Fast IDentity Online (FIDO) Alliance . . . . . . . . . . 5 5.3. Fast IDentity Online (FIDO) Alliance . . . . . . . . . . 6
6. Privacy Considerations. . . . . . . . . . . . . . . . . . . . 6 6. Privacy Considerations. . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The recently chartered IETF RATS WG intends to create a system of The recently chartered IETF RATS WG intends to create a system of
attestations that can be shared across a multitude of different attestations that can be shared across a multitude of different
users. users.
This document exists as place to collect use cases in support of the This document exists as place to collect use cases for the common
IETF RATS charter point 1. This document is not expected to be RATS technologies in support of the IETF RATS charter point 1. This
published as an RFC, but remain open as a working document. It could document is not expected to be published as an RFC, but remain open
become an appendix to provide motivation for a protocol standards as a working document. It could become an appendix to provide
document. 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.
2. Terminology 2. Terminology
Critical to dealing with and constrasting different technologies is Critical to dealing with and constrasting different technologies is
to collect terms with are compatible, to distinguish those terms to collect terms with are compatible, to distinguish those terms
which are similar but used in different ways. which are similar but used in different ways.
This section will grow to include forward and external references to This section will grow to include forward and external references to
terms which have been seen. When terms need to be disambiguated they terms which have been seen. When terms need to be disambiguated they
will be prefixed with their source, such as "TCG(claim)" or will be prefixed with their source, such as "TCG(claim)" or
"FIDO(relying party)" "FIDO(relying party)"
Platform attestions generally come in two categories. This document
will attempt to indicate for a particular attestion technology falls
into this.
2.1. Static attestions
A static attestion says something about the platform on which the
code is running.
2.2. Session attestions
A session attestion says something about how the shared session key
was created.
2.3. Statements
The term "statement" is used as the generic term for the semantic
content which is being attested to.
3. Requirements Language 3. Requirements Language
This document is not a standards track document and does not make any This document is not a standards track document and does not make any
normative protocol requirements using terminology described in normative protocol requirements using terminology described in
[RFC2119]. [RFC2119].
4. Overview of Sources of Use Cases 4. Overview of Sources of Use Cases
The following specifications have been convered in this document: The following specifications have been convered in this document:
skipping to change at page 3, line 30 skipping to change at page 4, line 11
o Fast Identity Online (FIDO) Alliance attestation, o Fast Identity Online (FIDO) Alliance attestation,
This document will be expanded to include summaries from: This document will be expanded to include summaries from:
o Trusted Computing Group (TCG) Trusted Platform Module o Trusted Computing Group (TCG) Trusted Platform Module
(TPM)/Trusted Software Stack (TSS) (TPM)/Trusted Software Stack (TSS)
o ARM "Platform Security Architecture" o ARM "Platform Security Architecture"
[I-D.tschofenig-rats-psa-token] [I-D.tschofenig-rats-psa-token]
And any additional sources suggested.
5. Use case summaries 5. Use case summaries
5.1. Trusted Computing Group (TCG) 5.1. Trusted Computing Group (TCG)
The TCG is trying to solve the problem of knowing if a networking The TCG is trying to solve the problem of knowing if a networking
device should be part a network. If it belongs to the operator, and device should be part of a network, if it belongs to the operator,
if it running approriate software. and if it is running approriate software.
This proposal is a work-in-progress, and is available to TCG members 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 only. The goal is to be multi-vendor, scalable and extensible. The
proposal intentionally limits itself to: proposal intentionally limits itself to:
o "non-privacy-preserving applications (i.e., networking, Industrial o "non-privacy-preserving applications (i.e., networking, Industrial
IoT )", IoT )",
o that the firmware is provided by the device manufacturer o that the firmware is provided by the device manufacturer
skipping to change at page 4, line 37 skipping to change at page 5, line 22
verifier. verifier.
The TCG uses the following terminology: The TCG uses the following terminology:
o Device Manufacuter o Device Manufacuter
o Attester ("device under attestation") o Attester ("device under attestation")
o Verifier (Network Management Station) o Verifier (Network Management Station)
o "Explicit Attestation" is the TCG term for a static (platform)
statement.
o "Implicit Attestation" is the TCG term for a session statement.
o Reference Integrity Measurements (RIM), which are signed my device o Reference Integrity Measurements (RIM), which are signed my device
manufacturer and integrated into firmware. manufacturer and integrated into firmware.
o Quotes: measured values (having been signed), and RIMs o Quotes: measured values (having been signed), and RIMs
o Reference Integrity Values (RIV) o Reference Integrity Values (RIV)
o devices have a Initial Attestion Key (IAK), which is provisioned o devices have a Initial Attestion Key (IAK), which is provisioned
at the same time as the IDevID. at the same time as the IDevID.
skipping to change at page 5, line 26 skipping to change at page 6, line 18
therefore abstracts the hardware, and guarantees to applications that therefore abstracts the hardware, and guarantees to applications that
the same APIs can be used on both more and less capable devices. 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 A great deal of focus from the Android Keystore seems to be on
providing fine-grained authorization of what keys can be used by providing fine-grained authorization of what keys can be used by
which applications. which applications.
XXX - clearly there must be additional (intended?) use cases that XXX - clearly there must be additional (intended?) use cases that
provide some kind of attestion. 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]
5.3. Fast IDentity Online (FIDO) Alliance 5.3. Fast IDentity Online (FIDO) Alliance
The FIDO Alliance [fido] has a number of specifications aimed The FIDO Alliance [fido] has a number of specifications aimed
primarily at eliminating the need for passwords for authentication to primarily at eliminating the need for passwords for authentication to
online services. The goal is to leverage asymmetric cryptographic online services. The goal is to leverage asymmetric cryptographic
operations in common browser and smart-phone platforms so that users operations in common browser and smart-phone platforms so that users
can easily authentication. can easily authentication.
FIDO specifications extend to various hardware second factor FIDO specifications extend to various hardware second factor
authentication devices. authentication devices.
skipping to change at page 6, line 9 skipping to change at page 7, line 14
o "internal authenticator" is some credential built-in to the device o "internal authenticator" is some credential built-in to the device
o "external authenticator" may be connected by USB, bluetooth, wifi, o "external authenticator" may be connected by USB, bluetooth, wifi,
and may be an stand-alone device, USB connected key, phone or and may be an stand-alone device, USB connected key, phone or
watch. watch.
FIDO2 had a Key Attestion Format [fidoattestation], and a Signature FIDO2 had a Key Attestion Format [fidoattestation], and a Signature
Format [fidosignature], but these have been combined into the W3C Format [fidosignature], but these have been combined into the W3C
document [fido_w3c] specification. document [fido_w3c] specification.
The FIDO use case involves a relying party that wants to have the HW/ A FIDO use case involves a relying party that having a attestion on
SW implementation does a biometric check on the human to be strongly the biometric system that identifies a human. It is the state of the
attested. 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 FIDO does provides a transport in the form of the WebAuthn and FIDO
CTAP protocols. 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.
6. Privacy Considerations. 6. Privacy Considerations.
TBD TBD
7. Security Considerations 7. Security Considerations
TBD. TBD.
8. IANA Considerations 8. IANA Considerations
skipping to change at page 6, line 31 skipping to change at page 8, line 4
TBD. TBD.
8. IANA Considerations 8. IANA Considerations
TBD. TBD.
9. Acknowledgements 9. Acknowledgements
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
10.2. Informative References 10.2. Informative References
[android_security]
Kralevich, R., "The Android Platform Security Model",
n.d., <https://arxiv.org/pdf/1904.05572.pdf>.
[fido] FIDO Alliance, ., "FIDO Specification Overview", n.d., [fido] FIDO Alliance, ., "FIDO Specification Overview", n.d.,
<https://fidoalliance.org/specifications/>. <https://fidoalliance.org/specifications/>.
[fido_w3c] [fido_w3c]
W3C, ., "Web Authentication: An API for accessing Public W3C, ., "Web Authentication: An API for accessing Public
Key Credentials Level 1", n.d., Key Credentials Level 1", n.d.,
<https://www.w3.org/TR/webauthn-1/>. <https://www.w3.org/TR/webauthn-1/>.
[fidoattestation] [fidoattestation]
FIDO Alliance, ., "FIDO 2.0: Key Attestation", n.d., FIDO Alliance, ., "FIDO 2.0: Key Attestation", n.d.,
<https://fidoalliance.org/specs/fido-v2.0-ps-20150904/ <https://fidoalliance.org/specs/fido-v2.0-ps-20150904/
fido-key-attestation-v2.0-ps-20150904.html>. fido-key-attestation-v2.0-ps-20150904.html>.
[fidosignature] [fidosignature]
FIDO Alliance, ., "FIDO 2.0: Signature Format", n.d., FIDO Alliance, ., "FIDO 2.0: Signature Format", n.d.,
<https://fidoalliance.org/specs/fido-v2.0-ps-20150904/ <https://fidoalliance.org/specs/fido-v2.0-ps-20150904/
fido-signature-format-v2.0-ps-20150904.html>. fido-signature-format-v2.0-ps-20150904.html>.
[fidotechnote]
FIDO Alliance, ., "FIDO TechNotes: The Truth about
Attestation", n.d., <https://fidoalliance.org/
fido-technotes-the-truth-about-attestation/>.
[I-D.tschofenig-rats-psa-token] [I-D.tschofenig-rats-psa-token]
Tschofenig, H., Frost, S., Brossard, M., and A. Shaw, Tschofenig, H., Frost, S., Brossard, M., and A. Shaw,
"Arm's Platform Security Architecture (PSA) Attestation "Arm's Platform Security Architecture (PSA) Attestation
Token", draft-tschofenig-rats-psa-token-00 (work in Token", draft-tschofenig-rats-psa-token-01 (work in
progress), March 2019. progress), April 2019.
[keystore] [keystore]
Google, ., "Android Keystore System", n.d., Google, ., "Android Keystore System", n.d.,
<https://developer.android.com/training/articles/ <https://developer.android.com/training/articles/
keystore>. keystore>.
Appendix A. Changes Appendix A. Changes
o added comments from Guy, Jessica, Henk and Ned on TCG description. o added comments from Guy, Jessica, Henk and Ned on TCG description.
 End of changes. 19 change blocks. 
32 lines changed or deleted 104 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/