< draft-richardson-rats-usecases-03.txt   draft-richardson-rats-usecases-04.txt >
RATS Working Group M. Richardson RATS Working Group M. Richardson
Internet-Draft Sandelman Software Works Internet-Draft Sandelman Software Works
Intended status: Informational C. Wallace Intended status: Informational C. Wallace
Expires: January 9, 2020 Red Hound Software Expires: January 9, 2020 Red Hound Software
W. Pan W. Pan
Huawei Technologies Huawei Technologies
July 08, 2019 July 08, 2019
Use cases for Remote Attestation common encodings Use cases for Remote Attestation common encodings
draft-richardson-rats-usecases-03 draft-richardson-rats-usecases-04
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 initially 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 the IETF RATS Working Group.
The document aspires to describe possible future use cases that would The document aspires to describe possible future 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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Static attestations . . . . . . . . . . . . . . . . . . . 4 2.1. Static attestations . . . . . . . . . . . . . . . . . . . 4
2.2. Session attestations . . . . . . . . . . . . . . . . . . 4 2.2. Session attestations . . . . . . . . . . . . . . . . . . 4
2.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Hardware Root Of Trust . . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Overview of Sources of Use Cases . . . . . . . . . . . . . . 4 4. Overview of Sources of Use Cases . . . . . . . . . . . . . . 4
5. Use case summaries . . . . . . . . . . . . . . . . . . . . . 4 5. Use case summaries . . . . . . . . . . . . . . . . . . . . . 5
5.1. Device Capabilities/Firmware Attestation . . . . . . . . 5 5.1. Device Capabilities/Firmware Attestation . . . . . . . . 5
5.1.1. Relying on an Attestation Server . . . . . . . . . . 5 5.1.1. Relying on an Attestation Server . . . . . . . . . . 5
5.1.2. Autonomous Relying Party . . . . . . . . . . . . . . 5 5.1.2. Autonomous Relying Party . . . . . . . . . . . . . . 5
5.1.3. Proxy Root of Trust . . . . . . . . . . . . . . . . . 5 5.1.3. Proxy Root of Trust . . . . . . . . . . . . . . . . . 5
5.1.4. network scaling - small . . . . . . . . . . . . . . . 5 5.1.4. network scaling - small . . . . . . . . . . . . . . . 6
5.1.5. network scaling - medium . . . . . . . . . . . . . . 5 5.1.5. network scaling - medium . . . . . . . . . . . . . . 6
5.1.6. network scaling - large . . . . . . . . . . . . . . . 6 5.1.6. network scaling - large . . . . . . . . . . . . . . . 6
5.1.7. Computation characteristics . . . . . . . . . . . . . 6 5.2. Hardware resiliency / watchdogs . . . . . . . . . . . . . 6
5.2. Cryptographic Key Attestation . . . . . . . . . . . . . . 6 5.3. IETF TEEP WG use case . . . . . . . . . . . . . . . . . . 7
5.2.1. Device Type Attestation . . . . . . . . . . . . . . . 7 5.4. Confidential Machine Learning (ML) model . . . . . . . . 7
5.2.2. Key storage attestation . . . . . . . . . . . . . . . 7 5.5. Critical infrastructure . . . . . . . . . . . . . . . . . 7
5.2.3. End user authorization . . . . . . . . . . . . . . . 7 5.5.1. Computation characteristics . . . . . . . . . . . . . 7
5.3. Geographic attestation . . . . . . . . . . . . . . . . . 8 5.6. Cryptographic Key Attestation . . . . . . . . . . . . . . 8
5.3.1. I am here . . . . . . . . . . . . . . . . . . . . . . 8 5.6.1. Device Type Attestation . . . . . . . . . . . . . . . 8
5.3.2. I am near . . . . . . . . . . . . . . . . . . . . . . 8 5.6.2. Key storage attestation . . . . . . . . . . . . . . . 8
5.3.3. You are here . . . . . . . . . . . . . . . . . . . . 8 5.6.3. End user authorization . . . . . . . . . . . . . . . 9
5.4. Connectivity attestation . . . . . . . . . . . . . . . . 9 5.7. Geographic attestation . . . . . . . . . . . . . . . . . 9
6. Technology users for RATS . . . . . . . . . . . . . . . . . . 9 5.7.1. I am here . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Trusted Computing Group (TCG) . . . . . . . . . . . . . . 9 5.7.2. I am near . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Android Keystore system . . . . . . . . . . . . . . . . . 10 5.7.3. You are here . . . . . . . . . . . . . . . . . . . . 10
6.3. Fast IDentity Online (FIDO) Alliance . . . . . . . . . . 11 5.8. Connectivity attestation . . . . . . . . . . . . . . . . 10
7. Examples of Existing Attestation Formats. . . . . . . . . . . 12 6. Technology users for RATS . . . . . . . . . . . . . . . . . . 10
7.1. Android Keystore . . . . . . . . . . . . . . . . . . . . 12 6.1. Trusted Computing Group (TCG) . . . . . . . . . . . . . . 10
7.1.1. TEE . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Android Keystore system . . . . . . . . . . . . . . . . . 12
7.1.2. Secure Element . . . . . . . . . . . . . . . . . . . 18 6.3. Fast IDentity Online (FIDO) Alliance . . . . . . . . . . 12
7.2. Windows 10 TPM . . . . . . . . . . . . . . . . . . . . . 22 7. Examples of Existing Attestation Formats. . . . . . . . . . . 14
7.2.1. Attestation statement . . . . . . . . . . . . . . . . 24 7.1. Android Keystore . . . . . . . . . . . . . . . . . . . . 14
7.3. Yubikey . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.1.1. TEE . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.3.1. Yubikey 4 . . . . . . . . . . . . . . . . . . . . . . 27 7.1.2. Secure Element . . . . . . . . . . . . . . . . . . . 19
7.3.2. Yubikey 5 . . . . . . . . . . . . . . . . . . . . . . 29 7.2. Windows 10 TPM . . . . . . . . . . . . . . . . . . . . . 24
8. Privacy Considerations. . . . . . . . . . . . . . . . . . . . 30 7.2.1. Attestation statement . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7.3. Yubikey . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 7.3.1. Yubikey 4 . . . . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 7.3.2. Yubikey 5 . . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. Privacy Considerations. . . . . . . . . . . . . . . . . . . . 31
12.1. Normative References . . . . . . . . . . . . . . . . . . 31 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31
12.2. Informative References . . . . . . . . . . . . . . . . . 31 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 32 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
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 for the common This document exists as place to collect use cases for the common
RATS technologies in support of the IETF RATS charter point 1. This 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 document is not expected to be published as an RFC, but remain open
as a working document. It could become an appendix to provide as a working document. It could become an appendix to provide
motivation for a protocol standards 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. However, the
end-user use cases for these verticales will be explained.
End-user use cases that would either directly leverage RATS End-user use cases that would either directly leverage RATS
technology, or would serve to inform technology choices are welcome, technology, or would serve to inform technology choices are welcome,
however. however.
2. Terminology 2. Terminology
Critical to dealing with and constrasting different technologies is Critical to dealing with and contrasting different technologies is to
to collect terms with are compatible, to distinguish those terms collect terms which are compatible, to distinguish those terms which
which are similar but used in different ways. 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 attestations generally come in two categories. This Platform attestations generally come in two categories. This
document will attempt to indicate for a particular attestation document will attempt to indicate for a particular attestation
technology falls into this. technology falls into this.
2.1. Static attestations 2.1. Static attestations
A static attestation says something about the platform on which the A static attestation says something about the platform on which the
code is running. code is running.
2.2. Session attestations 2.2. Session attestations
A session attestation says something about how the shared session key A session attestation says something about how a session key used in
was created. a connection such as TLS connection was created. It is usually the
result of evaluating attestations that are attached to the
certificates used to create such a session.
2.3. Statements 2.3. Statements
The term "statement" is used as the generic term for the semantic The term "statement" is used as the generic term for the semantic
content which is being attested to. content which is being attested to.
2.4. Hardware Root Of Trust
(TBD: Seeking something useful here.)
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 4, line 45 skipping to change at page 4, line 51
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]
o Intel SGX attestation [intelsgx]
o Windows Defender System Guard attestation [windowsdefender]
o Windows Device Health Attestation [windowshealth]
o Azure Sphere Attestation [azureattestation]:
https://azure.microsoft.com/enus/resources/azure-sphere-device-
authentication-andattestation-service/en-us/
o IETF NEA WG [RFC5209]
And any additional sources suggested. And any additional sources suggested.
5. Use case summaries 5. Use case summaries
This section lists a series of cases where an attestation is done. This section lists a series of cases where an attestation is done.
5.1. Device Capabilities/Firmware Attestation 5.1. Device Capabilities/Firmware Attestation
A network operator wants to know the qualities of the hardware and A network operator wants to know the qualities of the hardware and
software on the machines attached to their network. The process software on the machines attached to their network. The process
skipping to change at page 6, line 18 skipping to change at page 6, line 35
can be setup via proxy attestations. can be setup via proxy attestations.
5.1.6. network scaling - large 5.1.6. network scaling - large
An entire network of systems need to be continuously attested. This An entire network of systems need to be continuously attested. This
could be all of the smartphones on an LTE network, or every desktop could be all of the smartphones on an LTE network, or every desktop
system in a worldwide enterprise. The network operator wishes to do system in a worldwide enterprise. The network operator wishes to do
this in order maintain identities of connected devices more than to this in order maintain identities of connected devices more than to
validate correct firmware, but both situations are reasonable. validate correct firmware, but both situations are reasonable.
5.1.7. Computation characteristics 5.2. Hardware resiliency / watchdogs
One significant problem is malware that holds a device hostage and
does not allow it to reboot to prevent updates to be applied. This
is a significant problem, because it allows a fleet of devices to be
held hostage for ransom. Within CyRes the TCG is defining hardware
Attention Triggers that force a periodical reboot in hardware.
This can be implemented by forcing a reboot unless attestation to an
Attestation Server succeeds within the period interval, and having a
reboot do remediation by bringing a device into compliance, including
installation of patches as needed.
This is unlike the previous section on Device Attestation in that the
attestation comes from a network operator, as to the device's need to
continue operating, and is evaluated by trusted firmware (the relying
party), which resets a watchdog timer.
5.3. IETF TEEP WG use case
The "Trusted Application Manager (TAM)" server wants to verify the
state of a TEE, or applications in the TEE, of a device. The TEE
attests to the TAM, which can then decide whether to install
sensitive data in the TEE, or whether the TEE is out of compliance
and the TAM needs to install updated code in the TEE to bring it back
into compliance with the TAM's policy.
5.4. Confidential Machine Learning (ML) model
Microsoft talked about this category of use cases at the recent
Microsoft //build conference.
An example use case is where a device manufacturer wants to protect
its intellectual property in terms of the ML model it developed and
that runs in the devices that its customers purchased, and it wants
to prevent attackers, potentially including the customer themselves,
from seeing the details of the model. This works by having some
protected environment (e.g., a hardware TEE) in the device attest to
some manufacturer's service, which if attestation succeeds, then the
manufacturer service releases the model, or a key to decrypt the
model, to the requester. If a hardware TEE is involved, then this
use case overlaps with the TEEP use case.
5.5. Critical infrastructure
When a protocol operation can affect some critical system, the device
attached to the critical equipment wants some assurance that the
requester has not been compromised. As such, attestation can be used
to only accept commands from requesters that are within policy.
Hardware attestation in particular, especially in conjunction with a
TEE on the requester side, can provide protection against many types
of malware.
5.5.1. Computation characteristics
A group of enterprises organized as a consortium seeks to deploy A group of enterprises organized as a consortium seeks to deploy
computing node s as the basis of their shared blockchain system. computing node s as the basis of their shared blockchain system.
Each member of the consortium must forward an equal number of Each member of the consortium must forward an equal number of
computing nodes to participate in the P2P network of nodes that form computing nodes to participate in the P2P network of nodes that form
the basis of the blockchain system. In order to prevent the various the basis of the blockchain system. In order to prevent the various
issues (e.g. concentration of hash power, anonymous mining nodes) issues (e.g. concentration of hash power, anonymous mining nodes)
found in other blockchain systems, each computing node must comply to found in other blockchain systems, each computing node must comply to
a predefined allowable manifest of system hardware, software and a predefined allowable manifest of system hardware, software and
firmware, as agreed to by the membership of the consortium. Thus, a firmware, as agreed to by the membership of the consortium. Thus, a
skipping to change at page 6, line 47 skipping to change at page 8, line 21
relying party. The attestation may be requested online by another relying party. The attestation may be requested online by another
entity within the consortium, but not by other parties. The entity within the consortium, but not by other parties. The
attestation needs to be compact and interoperable and may be included attestation needs to be compact and interoperable and may be included
in the blockchain itself at the completion of the consensus in the blockchain itself at the completion of the consensus
algorithm. algorithm.
The attestation will need to start in a hardware RoT in order to The attestation will need to start in a hardware RoT in order to
validate if the system is running real hardware rather than running a validate if the system is running real hardware rather than running a
virtual machine. virtual machine.
5.2. Cryptographic Key Attestation 5.6. Cryptographic Key Attestation
The relying party wants to know how secure a private key that The relying party wants to know how secure a private key that
identifies an entity is. Unlike the network attestation, the relying identifies an entity is. Unlike the network attestation, the relying
party is not part of the network infrastructure, nor do they party is not part of the network infrastructure, nor do they
necessarily have a business relationship (such as ownership) over the necessarily have a business relationship (such as ownership) over the
end device. end device.
5.2.1. Device Type Attestation 5.6.1. Device Type Attestation
This use case convinces the relying party of the characteristics of a This use case convinces the relying party of the characteristics of a
device. For privacy reasons, it might not identify the actual device device. For privacy reasons, it might not identify the actual device
itself, but rather the class of device. The relying party can itself, but rather the class of device. The relying party can
understand from either in-band (claims) or out-of-band (model understand from either in-band (claims) or out-of-band (model
numbers, which may be expressed as a claim) whether the device has numbers, which may be expressed as a claim) whether the device has
features such as a hardware TPM, software TPM via TEE, or software features such as a hardware TPM, software TPM via TEE, or software
TPM without TEE. Other details such as the availability of finger- TPM without TEE. Other details such as the availability of finger-
print readers or HDMI outputs may also be inferred. print readers or HDMI outputs may also be inferred.
5.2.2. Key storage attestation 5.6.2. Key storage attestation
This use case convinces the relying party only about the provenance This use case convinces the relying party only about the provenance
of a private key by providing claims of the storage security of the of a private key by providing claims of the storage security of the
private key. This can be conceived as a subset of the previous case, private key. This can be conceived as a subset of the previous case,
but may be apply very specifically to just a keystore. Additional but may be apply very specifically to just a keystore. Additional
details associated with the private key may be provided as well, details associated with the private key may be provided as well,
including limitations on usage of the key. including limitations on usage of the key.
Key storage attestations may be consumed by systems provisioning Key storage attestations may be consumed by systems provisioning
public key certificates for devices or human users. In these cases, public key certificates for devices or human users. In these cases,
attestations may be incorporated into certificate request protocols attestations may be incorporated into certificate request protocols
(e.g., EST {#rfc7030}, CMP {#rfc4210}, ACME {#rfc8555}, SCEP (e.g., EST {#rfc7030}, CMP {#rfc4210}, ACME {#rfc8555}, SCEP
[I-D.gutmann-scep], etc.) and processed by registration authorities [I-D.gutmann-scep], etc.) and processed by registration authorities
or certification authorities prior to determining contents for any or certification authorities prior to determining contents for any
issued certificate. issued certificate.
5.2.3. End user authorization 5.6.3. End user authorization
This use case convinces the relying party that the digital signatures This use case convinces the relying party that the digital signatures
made by the indicated key pair were done with the approval of the made by the indicated key pair were done with the approval of the
end-user operator. This may also be considered possible subset of end-user operator. This may also be considered possible subset of
the device attestation above, but the attestation may be on a case- the device attestation above, but the attestation may be on a case-
by-case basis. The nature of the approval by the end-user would be by-case basis. The nature of the approval by the end-user would be
indicated. Examples include: the user unlocked the device, the user indicated. Examples include: the user unlocked the device, the user
viewed some message and acknowledge it inside an app, the message was viewed some message and acknowledge it inside an app, the message was
displayed to the user via out-of-app control mechanism. The displayed to the user via out-of-app control mechanism. The
acknowledgements could include selecting options on the screen, acknowledgements could include selecting options on the screen,
pushing physical buttons, scanning fingerprints, proximity to other pushing physical buttons, scanning fingerprints, proximity to other
devices (via bluetooth beacons, chargers, etc) devices (via bluetooth beacons, chargers, etc)
5.3. Geographic attestation 5.7. Geographic attestation
The relying party wants to know the physical location (on the planet The relying party wants to know the physical location (on the planet
earth) of the device. This may be provided directly by a earth) of the device. This may be provided directly by a
GPS/GLONASS/Galileo module that is incorporated into a TPM. This may GPS/GLONASS/Galileo module that is incorporated into a TPM. This may
also be provided by collecting other proximity messages from other also be provided by collecting other proximity messages from other
device that the relying party can form a trust relationship with. device that the relying party can form a trust relationship with.
5.3.1. I am here 5.7.1. I am here
The simplest use case is the claim of some specific coordinates. The simplest use case is the claim of some specific coordinates.
5.3.2. I am near 5.7.2. I am near
The second use case is the claim that some other devices are nearby. The second use case is the claim that some other devices are nearby.
This may be absolute ("I am near device X, which claims to be at This may be absolute ("I am near device X, which claims to be at
location A"), or just relative, ("I am near device X"). This use location A"), or just relative, ("I am near device X"). This use
could use "I am here" or "I am near" claims from a 1:1 basis with could use "I am here" or "I am near" claims from a 1:1 basis with
device X, or use some other protocol. The nature of how the device X, or use some other protocol. The nature of how the
proximity was established would be part of this claim. In order to proximity was established would be part of this claim. In order to
defeat a variety of mechanisms that might attempt to proxy defeat a variety of mechanisms that might attempt to proxy
("wormhole") radio communications, highly precise clocks may be ("wormhole") radio communications, highly precise clocks may be
required, and there may also have to be attestations as to the required, and there may also have to be attestations as to the
skipping to change at page 8, line 40 skipping to change at page 10, line 10
An additional example of being near would be for the case where two An additional example of being near would be for the case where two
smartphones can establish that they are together by recording a smartphones can establish that they are together by recording a
common random movement, such as both devices being shaken together. common random movement, such as both devices being shaken together.
Each device may validate the claim from the other (in a disconnected Each device may validate the claim from the other (in a disconnected
fashion), or a third party may validate the claim as the relying fashion), or a third party may validate the claim as the relying
party. party.
This could be used to establish that a medical professional was in This could be used to establish that a medical professional was in
proximity of a patient with implanted devices who needs help. proximity of a patient with implanted devices who needs help.
5.3.3. You are here 5.7.3. You are here
A third way to establish location is for a third party to communicate A third way to establish location is for a third party to communicate
directly with the relying party. The nature of how this trust is directly with the relying party. The nature of how this trust is
established (and whether it is done recursively) is outside of the established (and whether it is done recursively) is outside of the
scope here. What is critical is that the identity of "You" can be scope here. What is critical is that the identity of "You" can be
communicated through the third party in a way that the relying party communicated through the third party in a way that the relying party
can use, but other intermediaries can not view. can use, but other intermediaries can not view.
5.4. Connectivity attestation 5.8. Connectivity attestation
The relying party wants to know what devices are connected. A The relying party wants to know what devices are connected. A
typical situation would be a media owner needing to know what TV typical situation would be a media owner needing to know what TV
device is connected via HDMI and if High-bandwidth Digital Content device is connected via HDMI and if High-bandwidth Digital Content
Protection (HDCP) is intact. Protection (HDCP) is intact.
6. Technology users for RATS 6. Technology users for RATS
6.1. Trusted Computing Group (TCG) 6.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 of a network, if it belongs to the operator, device should be part of a network, if it belongs to the operator,
and if it is running approriate software. The work covers most of and if it is running appropriate software. The work covers most of
the use cases in Section 5.1. the use cases in Section 5.1.
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 the firmware is provided by the device manufacturer
o that there is a manufacturer installed hardware root of trust o there is a manufacturer installed hardware root of trust (such as
(such as a TPM and boot room) a TPM and boot room)
Service providers and enterprises deploy hundreds of routers, many of Service providers and enterprises deploy hundreds of routers, many of
them in remote locations where they're difficult to access or secure. them in remote locations where they're difficult to access or secure.
The point of remote attestation is to: The point of remote attestation is to:
o identify a remote box in a way that's hard to spoof o identify a remote box in a way that's hard to spoof
o report the inventory of software was launched on the box in a way o report the inventory of software was launched on the box in a way
that can not be spoofed that can not be spoofed
The use case described is to be able to monitor the authenticity of The use case described is to be able to monitor the authenticity of
software versions and configurations running on each device. This software versions and configurations running on each device. This
allows owners and auditors to detect deviation from approved software allows owners and auditors to detect deviation from approved software
and firmware versions and configurations, potentially identifying and firmware versions and configurations, potentially identifying
infected devices. infected devices. [RFC5209]
Attestation may be performed by network management systems. Attestation may be performed by network management systems.
Networking Equipment is often highly interconnected, so it's also Networking Equipment is often highly interconnected, so it's also
possible that attestation could be performed by neighboring devices. possible that attestation could be performed by neighboring devices.
Specifically listed to be out of scope for the first generation Specifically listed to be out of scope for the first generation
includes: Linux processes, assemblies of hardware/software created by includes: Linux processes, assemblies of hardware/software created by
end-customers, and equipment that is sleepy. There is an intention end-customers, and equipment that is sleepy. There is an intention
to cover some of these are topics in future versions of the to cover some of these are topics in future versions of the
documents. documents.
The TCG Attestation leverages the TPM to make a series of The TCG Attestation leverages the TPM to make a series of
measurements during the boot process, and to have the TPM sign those measurements during the boot process, and to have the TPM sign those
measurements. The resulting "PCG" hashes are then available to an measurements. The resulting "PCG" hashes are then available to an
external verifier. external verifier.
The TCG uses the following terminology: The TCG uses the following terminology:
o Device Manufacuter o Device Manufacturer
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) o "Explicit Attestation" is the TCG term for a static (platform)
statement. attestation
o "Implicit Attestation" is the TCG term for a session statement. o "Implicit Attestation" is the TCG term for a session attestation
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 Attestation Key (IAK), which is provisioned o devices have a Initial Attestation Key (IAK), which is provisioned
at the same time as the IDevID. at the same time as the IDevID [ieee802-1AR]
o PCR - Platform Configuration Registry (deals with hash chains) o PCR - Platform Configuration Registry (deals with hash chains)
The TCG document builds upon a number of IETF technologies: SNMP The TCG document builds upon a number of IETF technologies: SNMP
(Attestation MIB), YANG, XML, JSON, CBOR, NETCONF, RESTCONF, CoAP, (Attestation MIB), YANG, XML, JSON, CBOR, NETCONF, RESTCONF, CoAP,
TLS and SSH. The TCG document leverages the 802.1AR IDevID and TLS and SSH. The TCG document leverages the 802.1AR IDevID and
LDevID processes. LDevID processes.
6.2. Android Keystore system 6.2. Android Keystore system
[keystore] describes a system used in smart phones that run the [keystore] describes a system used in smart phones that run the
Android operation system. The system is primarily a software Android operation system. The system is primarily a software
container to contain and control access to cryptographic keys, and container to contain and control access to cryptographic keys, and
skipping to change at page 11, line 5 skipping to change at page 12, line 17
LDevID processes. LDevID processes.
6.2. Android Keystore system 6.2. Android Keystore system
[keystore] describes a system used in smart phones that run the [keystore] describes a system used in smart phones that run the
Android operation system. The system is primarily a software Android operation system. The system is primarily a software
container to contain and control access to cryptographic keys, and container to contain and control access to cryptographic keys, and
therefore provides many of the same functions that a hardware Trusted therefore provides many of the same functions that a hardware Trusted
Platform Module might provide. Platform Module might provide.
The uses described in section Section 5.2 are the primary focus. The uses described in section Section 5.6 are the primary focus.
On hardware which is supported, the Android Keystore will make use of On hardware which is supported, the Android Keystore will make use of
whatever trusted hardware is available, including use of Trusted whatever trusted hardware is available, including use of a Trusted
Execution Environment (TEE) or Secure Element (SE). The Keystore Execution Environment (TEE) or Secure Element (SE). The Keystore
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 attestation. provide some kind of attestation.
skipping to change at page 11, line 43 skipping to change at page 13, line 7
integrity integrity
6.3. Fast IDentity Online (FIDO) Alliance 6.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.
The use cases of Section 5.2 are primary. The use cases of Section 5.6 are primary.
FIDO specifications extend to various hardware second factor FIDO specifications extend to various hardware second factor
authentication devices. authentication devices.
Terminology includes: Terminology includes:
o "relying party" validates a claim o "relying party" validates a claim
o "relying party application" makes FIDO Authn calls o "relying party application" makes FIDO Authn calls
o "browser" provides Web Authentication JS API
o "browser" provides the Web Authentication JS API
o "platform" is the base system o "platform" is the base system
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 Attestation Format [fidoattestation], and a Signature FIDO2 had a Key Attestation 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.
A FIDO use case involves a relying party having an attestation on the A FIDO use case involves the relying party receiving a device
biometric system that identifies a human. It is the state of the attestation about the biometric system that performs the identication
biometric system that is being attested to, not the identity of the of the human. It is the state of the biometric system that is being
human! 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 attestation to make claims According to [fidotechnote] FIDO uses attestation to make claims
about the kind of device which is be used to enroll. Keypairs are 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 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 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 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 have the same public and private key pair. One assumes that this is
skipping to change at page 31, line 20 skipping to change at page 32, line 35
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>.
12.2. Informative References 12.2. Informative References
[android_security] [android_security]
Kralevich, R., "The Android Platform Security Model", Kralevich, R., "The Android Platform Security Model",
n.d., <https://arxiv.org/pdf/1904.05572.pdf>. n.d., <https://arxiv.org/pdf/1904.05572.pdf>.
[azureattestation]
Microsoft, ., "Azure Sphere Attestation", n.d.,
<https://azure.microsoft.com/enus/resources/
azure-sphere-device-authentication-andattestation-service/
en-us/>.
[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.,
skipping to change at page 32, line 5 skipping to change at page 33, line 25
[I-D.gutmann-scep] [I-D.gutmann-scep]
Gutmann, P., "Simple Certificate Enrolment Protocol", Gutmann, P., "Simple Certificate Enrolment Protocol",
draft-gutmann-scep-14 (work in progress), June 2019. draft-gutmann-scep-14 (work in progress), June 2019.
[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-01 (work in Token", draft-tschofenig-rats-psa-token-01 (work in
progress), April 2019. progress), April 2019.
[ieee802-1AR]
IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier",
2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>.
[intelsgx]
Intel, ., "Intel(R) Software Guard Extensions: Attestation
& Provisioning Services", n.d.,
<https://software.intel.com/en-us/sgx/
attestation-services>.
[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>.
[keystore_attestation] [keystore_attestation]
Google, ., "Verifying hardware-backed key pairs with Key Google, ., "Verifying hardware-backed key pairs with Key
Attestation", n.d., Attestation", n.d.,
<https://developer.android.com/training/articles/ <https://developer.android.com/training/articles/
security-key-attestation>. security-key-attestation>.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate "Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210, Management Protocol (CMP)", RFC 4210,
DOI 10.17487/RFC4210, September 2005, DOI 10.17487/RFC4210, September 2005,
<https://www.rfc-editor.org/info/rfc4210>. <https://www.rfc-editor.org/info/rfc4210>.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
<https://www.rfc-editor.org/info/rfc5209>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>. <https://www.rfc-editor.org/info/rfc8555>.
[windowsdefender]
Microsoft, ., "Windows Defender System Guard attestation",
n.d., <https://www.microsoft.com/security/blog/2018/04/19/
introducing-windows-defender-system-guard-runtime-
attestation/>.
[windowshealth]
Microsoft, ., "Windows Device Health Attestation", n.d.,
<https://docs.microsoft.com/en-us/windowsserver/security/
device-health-attestation>.
[yubikey_attestation] [yubikey_attestation]
Yubico, ., "PIV Attestation", n.d., Yubico, ., "PIV Attestation", n.d.,
<https://developers.yubico.com/PIV/Introduction/ <https://developers.yubico.com/PIV/Introduction/
PIV_attestation.html>. PIV_attestation.html>.
Appendix A. Changes Appendix A. Changes
o created new section for target use cases o created new section for target use cases
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. 41 change blocks. 
77 lines changed or deleted 179 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/