| RATS Working Group | H. Birkholz |
| Internet-Draft | Fraunhofer SIT |
| Intended status: Standards Track | M. Wiseman |
| Expires: May 7, 2020 | GE Global Research |
| H. Tschofenig | |
| ARM Ltd. | |
| N. Smith | |
| Intel | |
| M. Richardson | |
| Sandelman Software Works | |
| November 04, 2019 |
Remote Attestation Procedures Architecture
draft-birkholz-rats-architecture-03
An entity (a relying party) requires a source of truth and evidence about a remote peer to assess the peer’s trustworthiness. The evidence is typically a believable set of claims about its host, software or hardware platform. This document describes an architecture for such remote attestation procedures (RATS).
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 May 7, 2020.
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.
Remote Attestation provides a way for an entity (the Relying Party) to determine the health and provenance of an endpoint/host (the Attester). Knowledge of the health of the endpoint allows for a determination of trustworthiness of the endpoint.
The IETF has long spent it’s time focusing on threats to the communication channel (see [RFC3552] and [DOLEV-YAO]), assuming that endpoints could be trusted and were under the observation of trusted, well-trained professionals. This assumption has not been true since the days of the campus mini-computer. For some time after the desktop PC became ubiquitous, the threat to the endpoints has been dealt with as an internal matter, with generally poor results. Enterprises have done some deployment of Network Endpoint Assessment ([RFC5209]) to assess the security posture about an endpoint, but it has not been ubiquitous.
The movement towards personal mobile devices (“smartphones”) and the continuing threat from unmanaged residential desktops has resulted in a renewed interest in standardizing internet-scale endpoint remote attestation. Additionally, the rise of the Internet of Things (IoT) has made this issue even more critical: some skeptics have even renamed it to the Internet of Threats [iothreats] :-) IoT devices have poor or non-existent user interfaces, as such as there are not even good ways to assess the health of the devices manually: a need to determine the health via remote attestation is now critical.
In addition to the health of the device, knowledge of its provenance helps to determine the level of trust, and prevents attacks to the supply chain.
The Trusted Platform Module (TPM) is now a commonly available peripheral on many commodity compute platforms, both servers and desktops. Smartphones commonly have either an actual TPM, or have the ability to emulate one in software running in a Trusted Execution Environment [I-D.ietf-teep-architecture]. There are now few barriers to creating a standards-based system for remote attestation procedures.
A number of niche solutions have emerged that provide for use-case specific remote attestation, but none have the generality needed to be used across the Internet.
The architecture described in this document (along with the accompanying solution and reference documents) enables the use of common formats for communicating Claims about an Attester to a Relying Party. [FIXME Attester? Flows? To what end?]
Existing transports were not designed to carry attestation Claims. It is therefore necessary to design serializations of Claims that fit into a variety of transports, for instance: X.509 certificates, TLS negotiations, YANG modules or EtherNet/IP. There are also new, greenfield uses for remote attestation. Transport and serialization of these can be done without retrofitting. This is (will be) described in [INSERT reference to adopted document on transport].
While it is not anticipated that the existing niche solutions described in the use cases section Section 3 will exchange claims directly, the use of a common format enables common code. As some of the code needs to be in intentionally hard to modify trusted modules, the use of a common formats and transfer protocols significantly reduces the cost of adoption to all parties. This commonality also significantly reduces the incidence of critical bugs.
In some environments the collection of Evidence by the Attester to be provided to the Verifier is part of an existing protocol: this document does not change that, rather embraces those legacy mechanisms as part of the specification. This is an evolutionary path forward, not revolutionary. Yet in other greenfield environments, there is a desire to have a standard for Evidence as well as for Attestation Results, and this architecture outlines how that is done.
This introduction gives an overview of the message flows and roles involved. Following this, is a terminology section that is referenced normatively by other documents and is a key part of this document. There is then a section on use cases and how they leverage the roles and workflows described.
In this document, terms defined within this document are consistently Capitalized [work in progress. please raise issues, if there are Blatant inconsistencies].
Current verticals that use remote attestation include:
The logical information flow is from Attester to Verifier to Relying Party. There are variations presented below on how this integrates into actual protocols.
************
* Asserter *
************
|
|
|Known-Good-Values
|Endorsements
|
v
.---------------.
| Verifier |
.--------->| |----------.
| | | |
| '---------------' |
| |
|Evidence |Attestation Results
| |(Claims)
| |
| v
.---------------. .---------------.
| Attester | | Relying Party |
| | | |
| | | |
'---------------' '---------------'
Figure 1: RATS Workflow
In the architecture shown above, specific content items (payload conveyed in message flows) are identified:
Attestation Results are the output of RATS.
Assessment of Attestation Results is be multi-faceted and out-of-scope for the architecture.
If appropriate Endorsements about the Attester are available, Known-Good-Values about the Attester are available, and if the Attester is capable of creating believable Evidence - then the Verifier is able to create Attestation Results that enable Relying Parties to establish a level of confidence in the trustworthiness of the Attester.
The Asserter role and the format for Known-Good-Values and Endorsements are not subject to standardization at this time. The current verticals already include provisions for encoding and/or distributing these objects.
Two distinct flows have been identified for passage of Evidence and production of Attestation Results. It is possible that there are additional situations which are not captured by these two flows.
In the Passport Model message flow the Attester provides it’s Evidence directly to the Verifier. The Verifier will evaluate the Evidence and then sign an Attestation Result. This Attestation Result is returned to the Attester, and it is up to the Attester to communicate the Attestation Result (potentially including the Evidence, if disclosable) to the Relying Party.
************
* Asserter *
************
|Known-Good-Values
|Endorsements
|
v
.---------------.
| Verifier |
| |
| |
'------------|--'
^ |
| |Attestation Results
Evidence | |(Claims)
| |
| |
| v
.---|-----------. .---------------.
| Attester | | Relying Party |
| ----------------------> |
| | Attestation Results | |
'---------------' (Claims) '---------------'
Figure 2: RATS Passport Flow
This flow is named in this way because of the resemblance of how Nations issue Passports to their citizens. The nature of the Evidence that an individual needs to provide to it’s local authority is specific to the country involved. The citizen retains control of the resulting document and presents it to other entities when it needs to assert a citizenship or identity claim.
In the Background-Check message flow the Attester provides it’s Evidence to the Relying Party. The Relying Party sends this evidence to a Verifier of its choice. The Verifier will evaluate the Evidence and then sign an Attestation Result. This Attestation Result is returned to the Relying Party, which processes it directly.
************
* Asserter *
************
|Known-Good-Values
|Endorsements
|
v
.---------------.
| Verifier |
| |
| |
'--^---------|--'
| |
| |Attestation Results
Evidence | |(Claims)
| |
| v
.---------------. .--|------------.
| Attester | Evidence | Relying Party |
| ----------------------> |
| | | |
'---------------' '---------------'
Figure 3: RATS Background Check Flow
This flow is named in this way because of the resemblance of how employers and volunteer organizations perform background checks. When a prospective employee provides claims about education or previous experience, the employer will contact the respective institutions or former employers to validate the claim. Volunteer organizations often perform police background checks on volunteers in order to determine the volunteer’s trustworthiness.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
This section provides an overview of a number of distinct use cases that benefit from a standardized claim format. In addition to outlining the user, the specific message flow is identified from among the flows detailed in Section 1.6.
This is a large category of claims that includes a number of subcategories, not detailed here.
This is a general description for which there are many specific use cases, including [I-D.fedorkow-rats-network-device-attestation] section 1.2, “Software Inventory”
Cryptographic Attestion includes subcategories such as Device Type Attestation (the FIDO use case), and Key storage Attestation (the Android Keystore use case), and End-User Authorization.
The device chain of custody from the original device manufacturer to the new owner may also be verified as part of device provenance attestation. The chain of custody history may be collected by a cloud service or similar capability that the supply chain and owner agree to use.
[I-D.fedorkow-rats-network-device-attestation] section 1.2 refers to this as “Provable Device Identity”, and section 2.3 details the parties.
In network protocol exchanges, it is often the case that one entity (a Relying Party) requires an assessment of the trustworthiness of a remote entity (an Attester or specific system components [RFC4949] thereof). Remote ATtestation procedureS (RATS) enable Relying Parties to establish a level of confidence in the trustworthiness of Attesters through the
of attestation Evidence.
The architecture provides a framework for anticipating when a relevant change with respect to a trustworthiness attribute occurs, what exactly changed and how relevant it is. The architecture also creates a context for enabling an appropriate response by applications, system software and protocol endpoints when changes to trustworthiness attributes do occur.
Detailed protocol specifications for message flows are defined in separate documents.
An Attester produces Evidence about its own integrity, which means “it measures itself”. To disambiguate this recursive or circular looking relationships, two types of Environments inside an Attester are distinguished:
The attest-ED Environments and the attest-ING Environments.
Attested Environments are measured. They provide the raw values and the information to be represented in Claims and ultimately expressed as Evidence.
Attesting Environments conduct the measuring. They collect the Claims, format them appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.
Attesting Environments use system components that have to be trusted. As a result, Evidence includes Claims about the Attested and the Attesting Environments. Claims about the Attested Environments are appraised using Reference Values and Claims about the Attesting Environments are appraised using Endorsements. It is not mandated that both Environments have to be separate, but it is highly encouraged. Examples of separated Environments that can be used as Attesting Environments include: Trusted Execution Environments (TEE), embedded Secure Elements (eSE), or Hardware Security Modules (HSM).
In summary, the majority of the creation of evidence can take place in an Attested Environments. Exemplary duties include the collection and formatting of Claim values, or the trigger for creating Evidence. A trusted sub-set of the creation of evidence can take place in an Attesting Environment, that provide special protection with respect to key material, identity documents, or primitive functions to create the Evidence itself.
One or more Environments that are part of an Attester must be able to conduct the following duties in order to create Evidence:
The trustworthiness of an Attester and therefore the believability of the Evidence it creates relies on the protection methods in place to shield and restrict the use of key material and the duties conducted by the Attesting Environment. In order to assess trustworthiness effectively, it is mandatory to understand the trustworthiness properties of the environments of an Attester. The corresponding appraisal of Evidence that leads to such an assessment of trustworthiness is the duty of a Verifier.
Trusting the assessment of a Verifier might com frome trusting the Verifier’s key material (direct trust), or trusting an Entity that the Verifier is associated with via a certification path (indirect trust).
The trustworthiness of corresponding Attestation Results also relies on trust towards manufacturers and those manufacturer’s hardware in order to assess the integrity and resilience of that manufacturer’s devices.
A stronger level of security comes when information can be vouched for by hardware or by (unchangeable) firmware, especially if such hardware is physically resistant to hardware tampering. The component that is implicitly trusted is often referred to as a Root of Trust.
The basic function of RATS is creation, conveyance and appraisal of attestation Evidence. An Attester creates attestation Evidence that are conveyed to a Verifier for appraisal. The appraisals compare Evidence with expected Known-Good-Values obtained from Asserters (e.g. Principals that are Supply Chain Entities). There can be multiple forms of appraisal (e.g., software integrity verification, device composition and configuration verification, device identity and provenance verification). Attestation Results are the output of appraisals. Attestation Results are signed and conveyed to Relying Parties. Attestation Results provide the basis by which the Relying Party may determine a level of confidence to place in the application data or operations that follow.
The architecture defines attestation Roles: Attester, Verifier, Asserter and Relying Party. Roles exchange messages, but their structure is not defined in this document. The detailed definition of the messages is in an appropriate document, such as [I-D.ietf-rats-eat] or other protocols to be defined. Roles can be combined in various ways into Principals, depending upon the needs of the use case. Information Model representations are realized as data structure and conveyance protocol specifications.
The RATS architecture anticipates use of information modeling techniques that describe computing structures – their components/computational elements and corresponding capabilities – so that verification operations may rely on the information model as an interoperable way to navigate the structural complexity.
RATS architecture has the following goals:
Specifications developed by the RATS working group apply the following principles:
Attestation workflow helps a Relying Party make better decisions by providing insight about the trustworthiness of endpoints participating in a distributed system. The workflow consists primarily of four roles; Relying Party, Verifier, Attester and Asserter. Attestation messages contain information useful for appraising the trustworthiness of an Attester endpoint and informing the Relying Party of the appraisal result.
This section details the primary roles of an attestation workflow and the messages they exchange.
An endpoint system (a.k.a., Entity) may implement one or more attestation Roles to accommodate a variety of possible message flows. Exemplary message flows are described in Section 1.6.1 and Section 1.6.2. Role messages are secured by the Entity that generated it. Entities possess credentials (e.g., cryptographic keys) that authenticate, integrity protect and optionally confidentiality protect attestation messages.
The Attester consists of both an Attesting Environment and an Attested Environment. In some implementations these environments may be combined. Other implementations may have multiples of Attesting and Attested environments. Although endpoint environments can be complex, and that complexity is security relevant, the basic function of an Attester is to create Evidence that captures operational conditions affecting trustworthiness.
The Asserter role is out of scope. The mechanism by which an Asserter communicates Known-Good-Values to a Verifier is also not subject to standardization. Users of the RATS architecture are assumed to have pre-existing mechanisms.
The Verifier workflow function accepts Evidence from an Attester and accepts Reference Values from one or more Asserters. Reference values may be supplied a priori, cached or used to created policies. The Verifier performs an appraisal by matching Claims found in Evidence with Claims found in Reference Values and policies. If an attested Claim value differs from an expected Claim value, the Verifier flags this as a change possibly impacting trust level.
Endorsements may not have corresponding Claims in Evidence (because of their intrinsic nature). Consequently, the Verifier need only authenticate the endpoint and verify the Endorsements match the endpoint identity.
The result of appraisals and Endorsements, informed by owner policies, produces a new set of Claims that a Relying Party is suited to consume.
A Role in an attestation workflow that accepts Attestation Results from a Verifier that may be used by the Relying Party to inform application specific decision making. How Attestation Results are used to inform decision making is out-of-scope for this architecture.
Claims that are formatted and protected by an Attester.
Evidence SHOULD satisfy Verifier expectations for freshness, identity, context, provenance, validity, and veracity.
Reference-values are Claims that a manufacturer, vendor or other supply chain entity makes that affects the trustworthiness of an Attester endpoint.
Claims may be persistent properties of the endpoint due to the physical nature of how it was manufactured or may reflect the processes that were followed as part of moving the endpoint through a supply-chain; e.g., validation or compliance testing. This class of Reference-values is known as Endorsements.
Another class of Reference-values identifies the firmware and software that could be installed in the endpoint after its manufacture. A digest of the the firmware or software can be an effective identifier for keeping track of the images produced by vendors and installed on an endpoint. This class of Reference-value is referred to as Known-Good-Value (KGV).
Statements about the output of an appraisal of Evidence that are created, formatted and protected by a Verifier.
Attestation Results provide the basis for a Relying Party to establish a level of confidence in the trustworthiness of an Attester. Attestation Results SHOULD satisfy Relying Party expectations for freshness, identity, context, provenance, validity, relevance and veracity.
[The authors are unhappy with the term Principal, and have been looking for something else. JOSE/JWT uses the term Principal]
Principals are Containers for the Roles.
Principals are users, organizations, devices and computing environments (e.g., devices, platforms, services, peripherals).
Principals may implement one or more Roles. Massage flows occurring within the same Principal are out-of-scope.
The methods whereby Principals may be identified, discovered, authenticated, connected and trusted, though important, are out-of-scope.
Principal operations that apply resiliency, scaling, load balancing or replication are generally believed to be out-of-scope.
+------------------+ +------------------+ | Principal 1 | | Principal 2 | | +------------+ | | +------------+ | | | | | | | | | | | Role A |<-|---|->| Role D | | | | | | | | | | | +------------+ | | +------------+ | | | | | | +-----+------+ | | +-----+------+ | | | | | | | | | | | Role B |<-|---|->| Role E | | | | | | | | | | | +------------+ | | +------------+ | | | | | +------------------+ +------------------+
Figure 4: Principals-Role Composition
Principals have the following properties:
The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a device. In many cases the whole point of the Attestation process is to provided reliable evidence about the type of the device and the firmware that the device is running. This information is particularly interesting to many attackers: knowing that a device is running a weak version of a the firmware provides a way to aim attacks better.
Just knowing the existence of a device is itself a disclosure.
Conveyance protocols must detail what kinds of information is disclosed, and to whom it is exposed.
Evidence, Verifiable Assertions and Attestation Results SHOULD use formats that support end-to-end integrity protection and MAY support end-to-end confidentiality protection.
Replay attacks are a concern that protocol implementations MUST deal with. This is typically done via a Nonce Claim, but the details belong to the protocol.
All other attacks involving RATS structures are not explicitly addressed by the architecture.
Additional security protections MAY be required of conveyance mechanisms. For example, additional means of authentication, confidentiality, integrity, replay, denial of service and privacy protection of RATS payloads and Principals may be needed.
Dave Thaler created the concepts of “Passport” and “Background Check”.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
| [ABLP] | Abadi, M., Burrows, M., Lampson, B. and G. Plotkin, "A Calculus for Access Control in Distributed Systems", Springer Annual International Cryptology Conference, page 1-23, DOI 10.1.1.36.691, 1991. |
| [DOLEV-YAO] | Dolev, D. and A. Yao, "On the security of public key protocols", IEEE Transactions on Information Theory Vol. 29, pp. 198-208, DOI 10.1109/tit.1983.1056650, March 1983. |
| [fido] | FIDO Alliance, ., "FIDO Specification Overview", 2019. |
| [I-D.birkholz-rats-tuda] | Fuchs, A., Birkholz, H., McDonald, I. and C. Bormann, "Time-Based Uni-Directional Attestation", Internet-Draft draft-birkholz-rats-tuda-01, September 2019. |
| [I-D.fedorkow-rats-network-device-attestation] | Fedorkow, G. and J. Fitzgerald-McKay, "Network Device Attestation Workflow", Internet-Draft draft-fedorkow-rats-network-device-attestation-00, July 2019. |
| [I-D.ietf-rats-eat] | Mandyam, G., Lundblade, L., Ballesteros, M. and J. O'Donoghue, "The Entity Attestation Token (EAT)", Internet-Draft draft-ietf-rats-eat-01, July 2019. |
| [I-D.ietf-teep-architecture] | Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A. and D. Liu, "Trusted Execution Environment Provisioning (TEEP) Architecture", Internet-Draft draft-ietf-teep-architecture-03, July 2019. |
| [I-D.richardson-rats-usecases] | Richardson, M., Wallace, C. and W. Pan, "Use cases for Remote Attestation common encodings", Internet-Draft draft-richardson-rats-usecases-05, October 2019. |
| [iothreats] | GDN, ., "The Internet of Things or the Internet of threats?", 2016. |
| [keystore] | Google, ., "Android Keystore System", 2019. |
| [Lampson2007] | Lampson, B., "Practical Principles for Computer Security", IOSPress Proceedings of Software System Reliability and Security, page 151-195, DOI 10.1.1.63.5360, 2007. |
| [RFC3552] | Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003. |
| [RFC4949] | Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007. |
| [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. |