Network Working Group D. Thaler Internet-Draft Microsoft Intended status: Informational November 04, 2019 Expires: May 7, 2020 Remote Attestation Architecture draft-thaler-rats-architecture-01 Abstract In network protocol exchanges, it is often the case that one entity (a relying party) requires evidence about the remote peer (and system components [RFC4949] thereof), in order to assess the trustworthiness of the peer. This document describes an architecture for such remote attestation procedures (RATS), which enable relying parties to decide whether to consider a remote system component trustworthy or not. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://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 Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Thaler Expires May 7, 2020 [Page 1] Internet-Draft Remote Attestation Architecture November 2019 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Network Endpoint Assessment . . . . . . . . . . . . . . . 4 3.2. Confidential Machine Learning (ML) Model Protection . . . 5 3.3. Confidential Data Retrieval . . . . . . . . . . . . . . . 5 3.4. Critical Infrastructure Control . . . . . . . . . . . . . 5 3.5. Trusted Execution Environment (TEE) Provisioning . . . . 6 3.6. Hardware Watchdog . . . . . . . . . . . . . . . . . . . . 6 4. Serialization Formats . . . . . . . . . . . . . . . . . . . . 7 5. Architectural Models . . . . . . . . . . . . . . . . . . . . 8 5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 8 5.2. Background-Check Model . . . . . . . . . . . . . . . . . 9 5.2.1. Variation: Verifying Relying Party . . . . . . . . . 10 5.2.2. Variation: Out-of-Band Evidence Conveyance . . . . . 10 5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 11 6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Conceptual Messages . . . . . . . . . . . . . . . . . . . . . 12 7.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Endorsements . . . . . . . . . . . . . . . . . . . . . . 13 7.3. Attestation Results . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 11. Informative References . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction In network protocol exchanges, it is often the case that one entity (a relying party) requires evidence about the remote peer (and system components [RFC4949] thereof), in order to assess the trustworthiness of the peer. Remote attestation procedures (RATS) enable relying parties to establish a level of confidence in the trustworthiness of remote system components through the creation of attestation evidence by remote system components and a processing chain towards the relying party. A relying party can then decide whether to consider a remote system component trustworthy or not. To improve the confidence in a system component's trustworthiness, a relying party may require evidence about: - system component identity, Thaler Expires May 7, 2020 [Page 2] Internet-Draft Remote Attestation Architecture November 2019 - composition of system components, including nested components, - roots of trust, - assertion/claim origination or provenance, - manufacturing origin, - system component integrity, - system component configuration, - operational state and measurements of steps which led to the operational state, or - other factors that could influence trust decisions. This document discusses an architecture for describing solutions for this problem. 2. Terminology This document uses the following terms: - Attestation: A process by which one entity (the "Attester") provides evidence about its identity and health to another entity, which then assesses its trustworthiness. - Attestation Result: The evaluation results generated by a Verifier, typically including information about an Attester, where the Verifier vouches for the validity of the results. - Attester: An entity whose attributes must be evaluated in order to determine whether the entity is considered healthy or authorized to access a resource. - Endorsement: A secure statement that some entity (typically a manufacturer) vouches for the integrity of an Attester's signing capability. (Note: in some discussions the entity providing an Endorsement has been called an Asserter, but some believe that term is confusing and the term Endorser would be more correct. For now, this document avoids using a specific term until consensus is reached.) - Evidence: A set of information about an Attester that is to be evaluated by a Verifier. Thaler Expires May 7, 2020 [Page 3] Internet-Draft Remote Attestation Architecture November 2019 - Relying Party: An entity that depends on the validity of information about another entity, typically for purposes of authorization. Compare /relying party/ in [RFC4949]. - Security policy: A set of rules that direct how a system evaluates the validity of information about another entity. For example, the security policy might involve an equality comparison against known-good values (called Reference Integrity Measurements in some contexts), or might involve more complex logic. Compare /security policy/ in [RFC4949]. - Verifier: An entity that evaluates the validity of information about an Attester. 3. Use Cases This section covers a number of representative use cases for attestation, independent of solution. The purpose is to provide motivation for various aspects of the architecture presented in this draft. Many other use cases exist, and this document does not intend to have a complete list, only to have a set of use cases that collectively cover all the functionality required in the architecture. The use cases are covered prior to discussion of architectural models in Section 5, since each use case might be addressed via different solutions that have different architectural models. Each use case includes a description, and a summary of what an Attester and a Relying Party refer to in the use case. (Since solutions to a use case may greatly vary in architectural model, the role of a Verifier is considered part of a specific solution, not a solution-independent property of a use case, and so is not covered in this section.) 3.1. Network Endpoint Assessment Network operators want a trustworthy report of identity and version of information of the hardware and software on the machines attached to their network, for purposes such as inventory, auditing, and/or logging. The network operator may also want a policy by which full access is only granted to devices that meet some definition of health, and so wants to get claims about such information and verify their validity. Attestation is desired to prevent vulnerable or compromised devices from getting access to the network and potentially harming others. Typically, solutions start with some component (called a "Root of Trust") that provides device identity and protected storage for Thaler Expires May 7, 2020 [Page 4] Internet-Draft Remote Attestation Architecture November 2019 measurements. They then perform a series of measurements, and express this with Evidence as to the hardware and firmware/software that is running. - Attester: A device desiring access to a network - Relying Party: A network infrastructure device such as a router, switch, or access point. 3.2. Confidential Machine Learning (ML) Model Protection 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 typically works by having some protected environment in the device attest to some manufacturer service. If attestation succeeds. then the manufacturer service releases either the model, or a key to decrypt a model the Attester already has in encrypted form, to the requester. - Attester: A device desiring to run an ML model to do inferencing - Relying Party: A server or service holding ML models it desires to protect 3.3. Confidential Data Retrieval This is a generalization of the ML model use case above, where the data can be any highly confidential data, such as health data about customers, payroll data about employees, future business plans, etc. Attestation is desired to prevent leaking data to compromised devices. - Attester: An entity desiring to retrieve confidential data - Relying Party: An entity that holds confidential data for retrieval by other entities 3.4. Critical Infrastructure Control In this use case, potentially dangerous physical equipment (e.g., power grid, traffic control, hazardous chemical processing, etc.) is connected to a network. The organization managing such infrastructure needs to ensure that only authorized code and users can control such processes, and they are protected from malware or Thaler Expires May 7, 2020 [Page 5] Internet-Draft Remote Attestation Architecture November 2019 other adversaries. When a protocol operation can affect some critical system, the device attached to the critical equipment thus 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. - Attester: A device or application wishing to control physical equipment. - Relying Party: A device or application connected to potentially dangerous physical equipment (hazardous chemical processing, traffic control, power grid, etc. 3.5. Trusted Execution Environment (TEE) Provisioning A "Trusted Application Manager (TAM)" server is responsible for managing the applications running in the TEE of a client device. To do this, the TAM wants to verify the state of a TEE, or of applications in the TEE, of a client device. The TEE attests to the TAM, which can then decide whether the TEE is already in compliance with the TAM's latest policy, or if the TAM needs to uninstall, update, or install approved applications in the TEE to bring it back into compliance with the TAM's policy. - Attester: A device with a trusted execution environment capable of running trusted applications that can be updated. - Relying Party: A Trusted Application Manager. 3.6. Hardware Watchdog 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. A hardware watchdog can be implemented by forcing a reboot unless attestation to a remote server succeeds within a periodic interval, and having the reboot do remediation by bringing a device into compliance, including installation of patches as needed. - Attester: The device that is desired to keep from being held hostage for a long period of time. - Relying Party: A remote server that will securely grant the Attester permission to continue operating (i.e., not reboot) for a period of time. Thaler Expires May 7, 2020 [Page 6] Internet-Draft Remote Attestation Architecture November 2019 4. Serialization Formats The following diagram illustrates a relationship to which attestation is desired to be added: +-------------+ +-------------+ | |-------------->| | | Attester | Access some | Relying | Evaluate request | | resource | Party | against security policy +-------------+ +-------------+ Figure 1: Typical Resource Access In this diagram, the protocol between Attester and a Relying Party can be any new or existing protocol (e.g., HTTP(S), COAP(S), 802.1x, OPC UA, etc.), depending on the use case. Such protocols typically already have mechanisms for passing security information for purposes of authentication and authorization. Common formats include JWTs [RFC7519], CWTs [RFC8392], and X.509 certificates. In many cases, it is desirable to add attestation to existing protocols, enabling a higher level of assurance against malware for example. To enable such integration, it is important that information needed for evaluating the Attester be usable with existing protocols that have constraints around what formats they can transport. For example, OPC UA [OPCUA] (probably the most common protocol in industrial IoT environments) is defined to carry X.509 certificates and so security information must be embedded into an X.509 certificate to be passed in the protocol. Thus, attestation- related information could be natively encoded in X.509 certificate extensions, or could be natively encoded in some other format (e.g., a CWT) which in turn is then encoded in an X.509 certificate extension. Especially for constrained nodes, however, there is a desire to minimize the amount of parsing code needed in a Relying Party, in order to both minimize footprint and to minimize the attack surface area. So while it would be possible to embed a CWT inside a JWT, or a JWT inside an X.509 extension, etc., there is a desire to encode the information natively in the format that is natural for the Relying Party. This motivates having a common "information model" that describes the set of attestation related information in an encoding-agnostic way, and allowing multiple serialization formats (CWT, JWT, X.509, etc.) that encode the same information into the format needed by the Relying Party. Thaler Expires May 7, 2020 [Page 7] Internet-Draft Remote Attestation Architecture November 2019 5. Architectural Models There are multiple possible models for communication between an Attester, a Verifier, and a Relying Party. 5.1. Passport Model In this model, an Attester sends Evidence to a Verifier, which compares the Evidence against its security policy. The Verifier then gives back an Attestation Result. If the Attestation Result was a successful one, the Attester can then present the Attestation Result to a Relying Party, which then compares the Attestation Result against its own security policy. Since the resource access protocol between the Attester and Relying Party includes an Attestation Result, in this model the details of that protocol constrain the serialization format of the Attestation Result. The format of the Evidence on the other hand is only constrained by the Attester-Verifier attestation protocol. +-------------+ | | Compare Evidence | Verifier | against security policy | | +-------------+ ^ | Evidence| |Attestation | | Result | v +-------------+ +-------------+ | |-------------->| | Compare Attestation | Attester | Attestation | Relying | Result against | | Result | Party | security policy +-------------+ +-------------+ Figure 2: Passport Model The passport model is so named because it resembles the process typically used for passports and drivers licenses, where a person applies and gets a passport or license that is issued by a government and shows information such as the person's name and birthdate. The passport or license can then be supplied to other entities to gain entrance to an airport boarding area, or age-restricted section of a bar, where the passport or license is considered sufficient because it vouches for that piece of information and is issued by a trusted authority. Thus, in this analogy, the passport issuing agency is a Verifier, the passport is an Attestation Result, and the airport security is a Relying Party. Thaler Expires May 7, 2020 [Page 8] Internet-Draft Remote Attestation Architecture November 2019 5.2. Background-Check Model In this model, an Attester sends Evidence to a Relying Party, which simply passes it on to a Verifier. The Verifier then compares the Evidence against its security policy, and returns an Attestation Result to the Relying Party. The Relying Party then compares the Attestation Result against its own security policy. The resource access protocol between the Attester and Relying Party includes Evidence rather than an Attestation Result, but that Evidence is not processed by the Relying Party. Since the Evidence is merely forwarded on to a trusted Verifier, any serialization format can be used for Evidence because the Relying Party does not need a parser for it. The only requirement is that the Evidence can be _encapsulated in_ the format required by the resource access protocol between the Attester and Relying Party. However, like in the Passport model, an Attestation Result is still consumed by the Relying Party and so the serialization format of the Attestation Result is still important. If the Relying Party is a constrained node whose purpose is to serve a given type resource using a standard resource access protocol, it already needs the parser(s) required by that existing protocol. Hence, the ability to let the Relying Party obtain an Attestation Result in the same serialization format allows minimizing the code footprint and attack surface area of the Relying Party, especially if the Relying Party is a constrained node. +-------------+ | | Compare Evidence | Verifier | against security policy | | +-------------+ ^ | Evidence| |Attestation | | Result | v +-------------+ +-------------+ | |-------------->| | Compare Attestation | Attester | Evidence | Relying | Result against | | | Party | security policy +-------------+ +-------------+ Figure 3: Background-Check Model The background-check model is so named because it resembles the process typically used for job and loan applications, where a person fills out an application to get a job or a loan from a company, and Thaler Expires May 7, 2020 [Page 9] Internet-Draft Remote Attestation Architecture November 2019 the company then does a background check with some other agency that checks credit history, arrest records, etc. and gives back a report on the application that is then used to help determine whether to actually offer the job or loan. Thus, in this analogy, a person asking for a loan is an Attester, the bank is the Relying Party, and a credit report agency is a Verifier. 5.2.1. Variation: Verifying Relying Party One variation of the background-check model is a "Verifying Relying party", where the Relying Party and the Verifier on the same machine, and so there is no need for a protocol between the two. 5.2.2. Variation: Out-of-Band Evidence Conveyance Another variation of the background-check model is shown in Figure 4, where the Verifier is still chosen by (and trusted by) the Relying Party, but the Evidence must be passed out-of-band. For example, in step 1, the Attester communicates with the Relying Party, which refers the matter to a Verifier chosen by the Relying Party in step 2. Evidence is then passed to that Verifier in step 3, e.g., either by the Relying Party providing the Attester with information about the Verifier to send Evidence to, or by the Verifier querying the Attester directly, although the latter has the problem that it only works if devices allow unsolicited inbound queries, which may be a security problem in some contexts. +-------------+ | | Compare Evidence +----->| Verifier | against security policy | | | Evidence| +-------------+ | ^ | | | |Attestation |3 2| | Result | | v +-------------+ | +-------------+ | |--------+ | | Compare Attestation | Attester |-------------->| Relying | Result against | | 1 | Party | security policy +-------------+ +-------------+ Figure 4: Out-of-Band Evidence Conveyance Thaler Expires May 7, 2020 [Page 10] Internet-Draft Remote Attestation Architecture November 2019 5.3. Combinations The choice of model is generally up to the Relying Party, and the same device may need to attest to different relying parties for different use cases (e.g., a network infrastructure device to gain access to the network, and then a server holding confidential data to get access to that data). As such, both models may simultaneously be in use by the same device. Figure 5 shows an example of a combination where Relying Party 1 uses the passport model, whereas Relying Party 2 uses an extension of the background-check model. Specifically, in addition to the basic functionality shown in Figure 3, Relying Party 2 actually provides the Attestation Result back to the Attester, allowing the Attester to use it with other Relying Parties. This is the model that the Trusted Application Manager plans to support in the TEEP architecture [I-D.ietf-teep-architecture]. +-------------+ | | Compare Evidence | Verifier | against security policy | | +-------------+ ^ | Evidence| |Attestation | | Result | v +-------------+ | | Compare | Relying | Attestation Result | Party 2 | against security policy +-------------+ ^ | Evidence| |Attestation | | Result | v +-------------+ +-------------+ | |-------------->| | Compare Attestation | Attester | Attestation | Relying | Result against | | Result | Party 1 | security policy +-------------+ +-------------+ Figure 5: Example Combination Thaler Expires May 7, 2020 [Page 11] Internet-Draft Remote Attestation Architecture November 2019 6. Trust Model The scope of this document is scenarios for which a Relying Party trusts a Verifier that can evaluate the trustworthiness of information about an Attester. Such trust might come by the Relying Party trusting the Verifier (or its public key) directly, or might come by trusting an entity (e.g., a Certificate Authority) that the Verifier has a certificate that chains up to. The Relying Party might implicitly trust a Verifier (such as in the Verifying Relying Party combination). Or, for a stronger level of security, the Relying Party might require that the Verifier itself provide information about itself that the Relying Party can use to evaluate the health of the Verifier before accepting its Attestation Results. In solutions following the background-check model, the Attester is assumed to trust the Verifier (again, whether directly or indirectly via a Certificate Authority that it trusts), since the Attester relies on an Attestation Result it obtains from the Verifier, in order to access resources. The Verifier trusts (or more specifically, the Verifier's security policy is written in a way that configures the Verifier to trust) a manufacturer, or the manufacturer's hardware, so as to be able to evaluate the health of that manufacturer's devices. In solutions with weaker security, a Verifier might be configured to implicitly trust firmware or even software (e.g., a hypervisor). That is, it might evaluate the health of an application component, or operating system component or service, under the assumption that information provided about it by the lower-layer hypervisor or firmware is true. A stronger level of security comes when information can be vouched for by hardware or by ROM code, 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. 7. Conceptual Messages 7.1. Evidence Today, Evidence tends to be highly device-specific, since the information in the evidence often includes vendor-specific information that is necessary to fully describe the manufacturer and model of the device including its security properties, the health of the device, and the level of confidence in the correctness of the information. Evidence is typically signed by the device (whether by hardware, firmware, or software on the device), and evaluating it in isolation would require security policy to be based on device- specific details (e.g., a device public key). Thaler Expires May 7, 2020 [Page 12] Internet-Draft Remote Attestation Architecture November 2019 7.2. Endorsements An Endorsement is a secure statement that some entity (typically a manufacturer) vouches for the integrity of the device's signing capability. For example, if the signing capability is in hardware, then an Endorsement might be a manufacturer certificate that signs a public key whose corresponding private key is only known inside the device's hardware. Thus, when Evidence and such an Endorsement are used together, evaluating them can be done against security policy that may not be specific to the device instance, but merely specific to the manufacturer providing the Endorsement. For example, a security policy might simply check that devices from a given manufacturer have information matching a set of known-good reference values, or a security policy might have a set of more complex logic on how to evaluate the validity of information. However, while a security policy that treats all devices from a given manufacturer the same may be appropriate for some use cases, it would be inappropriate to use such a security policy as the sole means of authorization for use cases that wish to constrain _which_ compliant devices are considered authorized for some purpose. For example, an enterprise using attestation for Network Endpoint Assessment may not wish to let every healthy laptop from the same manufacturer onto the network, but instead only want to let devices that it legally owns onto the network. Thus, an Endorsement may be helpful information in authenticating information about a device, but is not necessarily sufficient to authorize access to resources which may need device- specific information such as a public key for the device or component or user on the device. 7.3. Attestation Results Attestation Results may indicate compliance or non-compliance with a Verifier's security policy. A result that indicates non-compliance can be used by an Attester (in the passport model) or a Relying Party (in the background-check model) to indicate that the Attester should not be treated as authorized and may be in need of remediation. In some cases, it may even indicate that the Evidence itself cannot be authenticated as being correct. An Attestation Result that indicates compliance can be used by a Relying Party to make authorization decisions based on the Relying Party's security policy. The simplest such policy might be to simply authorize any party supplying a compliant Attestation Result signed by a trusted Verifier. A more complex policy might also entail comparing information provided in the result against known-good reference values, or applying more complex logic using such information. Thaler Expires May 7, 2020 [Page 13] Internet-Draft Remote Attestation Architecture November 2019 Thus, Attestation Results often need to include detailed information about the Attester, for use by Relying Parties, much like physical passports and drivers licenses include personal information such as name and date of birth. Unlike Evidence, which is often very device- and vendor-specific, Attestation Results can be vendor-neutral if the Verifier has a way to generate vendor-agnostic information based on evaluating vendor-specific information in Evidence. This allows a Relying Party's security policy to be simpler, potentially based on standard ways of expressing the information, while still allowing interoperability with heterogeneous devices. Finally, whereas Evidence is signed by the device (or indirectly by a manufacturer, if Endorsements are used), Attestation Results are signed by a Verifier, allowing a Relying Party to only need a trust relationship with one entity, rather than a larger set of entities, for purposes of its security policy. 8. Security Considerations To evaluate the security provided by a particular security policy, it is important to understand the strength of the Root of Trust, e.g., whether it is mutable software, or firmware that is read-only after boot, or immutable hardware/ROM. It is also important that the security policy was itself obtained securely. As such, if security policy in a Relying Party or Verifier can be configured via a network protocol, the ability to attest to the health of the client providing the security policy needs to be considered. 9. IANA Considerations This document does not require any actions by IANA. 10. Acknowledgements Some content in this document came from drafts by Michael Richardson, Henk Birkholz, and Ned Smith, and from the IETF RATS Working Group Charter. 11. Informative References [I-D.ietf-teep-architecture] Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D. Liu, "Trusted Execution Environment Provisioning (TEEP) Architecture", draft-ietf-teep-architecture-03 (work in progress), July 2019. Thaler Expires May 7, 2020 [Page 14] Internet-Draft Remote Attestation Architecture November 2019 [OPCUA] OPC Foundation, "OPC Unified Architecture Specification, Part 2: Security Model, Release 1.03", Global Platform GPD_SPE_009, November 2015, . [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . Author's Address Dave Thaler Microsoft EMail: dthaler@microsoft.com Thaler Expires May 7, 2020 [Page 15]