--- 1/draft-ietf-rats-architecture-13.txt 2021-12-09 11:13:17.012705490 -0800 +++ 2/draft-ietf-rats-architecture-14.txt 2021-12-09 11:13:17.116708078 -0800 @@ -1,25 +1,25 @@ RATS Working Group H. Birkholz Internet-Draft Fraunhofer SIT Intended status: Informational D. Thaler -Expires: 12 May 2022 Microsoft +Expires: 12 June 2022 Microsoft M. Richardson Sandelman Software Works N. Smith Intel W. Pan Huawei Technologies - 8 November 2021 + 9 December 2021 Remote Attestation Procedures Architecture - draft-ietf-rats-architecture-13 + draft-ietf-rats-architecture-14 Abstract In network protocol exchanges it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary claims. An attempt is made to provide for a model that is neutral toward processor architectures, the content of claims, and protocols. @@ -43,113 +43,113 @@ 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 12 May 2022. + This Internet-Draft will expire on 12 June 2022. Copyright Notice Copyright (c) 2021 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. + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Reference Use Cases . . . . . . . . . . . . . . . . . . . . . 5 2.1. Network Endpoint Assessment . . . . . . . . . . . . . . . 5 2.2. Confidential Machine Learning Model Protection . . . . . 5 2.3. Confidential Data Protection . . . . . . . . . . . . . . 6 2.4. Critical Infrastructure Control . . . . . . . . . . . . . 6 2.5. Trusted Execution Environment Provisioning . . . . . . . 7 2.6. Hardware Watchdog . . . . . . . . . . . . . . . . . . . . 7 2.7. FIDO Biometric Authentication . . . . . . . . . . . . . . 7 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 8 - 3.1. Two Types of Environments of an Attester . . . . . . . . 10 - 3.2. Layered Attestation Environments . . . . . . . . . . . . 12 - 3.3. Composite Device . . . . . . . . . . . . . . . . . . . . 14 - 3.4. Implementation Considerations . . . . . . . . . . . . . . 16 - 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 4.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 4.2. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . 18 - 5. Topological Patterns . . . . . . . . . . . . . . . . . . . . 19 - 5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 20 - 5.2. Background-Check Model . . . . . . . . . . . . . . . . . 21 - 5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 22 - 6. Roles and Entities . . . . . . . . . . . . . . . . . . . . . 23 - 7. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 7.1. Relying Party . . . . . . . . . . . . . . . . . . . . . . 24 - 7.2. Attester . . . . . . . . . . . . . . . . . . . . . . . . 25 - 7.3. Relying Party Owner . . . . . . . . . . . . . . . . . . . 25 + 3.1. Two Types of Environments of an Attester . . . . . . . . 9 + 3.2. Layered Attestation Environments . . . . . . . . . . . . 11 + 3.3. Composite Device . . . . . . . . . . . . . . . . . . . . 13 + 3.4. Implementation Considerations . . . . . . . . . . . . . . 15 + 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.2. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . 17 + 5. Topological Patterns . . . . . . . . . . . . . . . . . . . . 18 + 5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 18 + 5.2. Background-Check Model . . . . . . . . . . . . . . . . . 20 + 5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 21 + 6. Roles and Entities . . . . . . . . . . . . . . . . . . . . . 22 + 7. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 7.1. Relying Party . . . . . . . . . . . . . . . . . . . . . . 23 + 7.2. Attester . . . . . . . . . . . . . . . . . . . . . . . . 24 + 7.3. Relying Party Owner . . . . . . . . . . . . . . . . . . . 24 7.4. Verifier . . . . . . . . . . . . . . . . . . . . . . . . 25 7.5. Endorser, Reference Value Provider, and Verifier Owner . 27 - 8. Conceptual Messages . . . . . . . . . . . . . . . . . . . . . 28 - 8.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 28 + 8. Conceptual Messages . . . . . . . . . . . . . . . . . . . . . 27 + 8.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 27 8.2. Endorsements . . . . . . . . . . . . . . . . . . . . . . 28 - 8.3. Reference Values . . . . . . . . . . . . . . . . . . . . 29 - 8.4. Attestation Results . . . . . . . . . . . . . . . . . . . 29 + 8.3. Reference Values . . . . . . . . . . . . . . . . . . . . 28 + 8.4. Attestation Results . . . . . . . . . . . . . . . . . . . 28 8.5. Appraisal Policies . . . . . . . . . . . . . . . . . . . 30 - 9. Claims Encoding Formats . . . . . . . . . . . . . . . . . . . 31 + 9. Claims Encoding Formats . . . . . . . . . . . . . . . . . . . 30 10. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 10.1. Explicit Timekeeping using Synchronized Clocks . . . . . 33 + 10.1. Explicit Timekeeping using Synchronized Clocks . . . . . 32 10.2. Implicit Timekeeping using Nonces . . . . . . . . . . . 33 10.3. Implicit Timekeeping using Epoch IDs . . . . . . . . . . 33 - 10.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 35 + 10.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 34 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35 12. Security Considerations . . . . . . . . . . . . . . . . . . . 36 12.1. Attester and Attestation Key Protection . . . . . . . . 36 - 12.1.1. On-Device Attester and Key Protection . . . . . . . 37 + 12.1.1. On-Device Attester and Key Protection . . . . . . . 36 12.1.2. Attestation Key Provisioning Processes . . . . . . . 37 - 12.2. Integrity Protection . . . . . . . . . . . . . . . . . . 39 + 12.2. Integrity Protection . . . . . . . . . . . . . . . . . . 38 12.3. Epoch ID-based Attestation . . . . . . . . . . . . . . . 39 12.4. Trust Anchor Protection . . . . . . . . . . . . . . . . 40 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 - 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 - 15. Notable Contributions . . . . . . . . . . . . . . . . . . . . 41 + 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 + 15. Notable Contributions . . . . . . . . . . . . . . . . . . . . 40 16. Appendix A: Time Considerations . . . . . . . . . . . . . . . 41 - 16.1. Example 1: Timestamp-based Passport Model Example . . . 43 + 16.1. Example 1: Timestamp-based Passport Model Example . . . 42 16.2. Example 2: Nonce-based Passport Model Example . . . . . 44 - 16.3. Example 3: Epoch ID-based Passport Model Example . . . . 46 + 16.3. Example 3: Epoch ID-based Passport Model Example . . . . 45 16.4. Example 4: Timestamp-based Background-Check Model - Example . . . . . . . . . . . . . . . . . . . . . . . . 47 - 16.5. Example 5: Nonce-based Background-Check Model Example . 48 - 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 - 17.1. Normative References . . . . . . . . . . . . . . . . . . 49 - 17.2. Informative References . . . . . . . . . . . . . . . . . 49 - Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 51 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 + Example . . . . . . . . . . . . . . . . . . . . . . . . 46 + 16.5. Example 5: Nonce-based Background-Check Model Example . 47 + 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 + 17.1. Normative References . . . . . . . . . . . . . . . . . . 48 + 17.2. Informative References . . . . . . . . . . . . . . . . . 48 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 50 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 1. Introduction The question of how one system can know that another system can be trusted has found new interest and relevance in a world where trusted computing elements are maturing in processor architectures. Systems that have been attested and verified to be in a good state (for some value of "good") can improve overall system posture. Conversely, systems that cannot be attested and verified to be in a - good state can be taken out of service, or otherwise flagged for - repair. + good state can be given reduced access or privileges, taken out of + service, or otherwise flagged for repair. For example: * A bank back-end system might refuse to transact with another system that is not known to be in a good state. * A healthcare system might refuse to transmit electronic healthcare records to a system that is not known to be in a good state. In Remote Attestation Procedures (RATS), one peer (the "Attester") @@ -194,30 +194,31 @@ and this document does not intend to have a complete list, only to illustrate a set of use cases that collectively cover all the functionality required in the architecture. Each use case includes a description followed by an additional summary of the Attester and Relying Party roles derived from the use case. 2.1. Network Endpoint Assessment - Network operators want a trustworthy report that includes identity - and version information about the hardware and software on the - machines attached to their network, for purposes such as inventory, - audit, anomaly detection, record maintenance and/or trending reports - (logging). The network operator may also want a policy by which full - access is only granted to devices that meet some definition of - hygiene, and so wants to get Claims about such information and verify - its validity. Remote attestation is desired to prevent vulnerable or - compromised devices from getting access to the network and - potentially harming others. + Network operators want trustworthy reports that include identity and + version information about the hardware and software on the machines + attached to their network. Examples of reports include purposes, + such as inventory summaries, audit results, anomaly notifications, + typically including the maintenance of log records or trend reports. + The network operator may also want a policy by which full access is + only granted to devices that meet some definition of hygiene, and so + wants to get Claims about such information and verify its validity. + Remote attestation is desired to prevent vulnerable or compromised + devices from getting access to the network and potentially harming + others. Typically, solutions start with a specific component (called a root of trust) that is intended to provide trustworthy device identity and protected storage for measurements. The system components perform a series of measurements that may be signed via functions provided by a root of trust, considered as Evidence about present system components, such as hardware, firmware, BIOS, software, etc. Attester: A device desiring access to a network. @@ -331,25 +332,21 @@ the server. For the Relying Party to know that the authentication is trustworthy, the Relying Party needs to know that the Authenticator part of the device is trustworthy. The FIDO protocol employs remote attestation for this. The FIDO protocol supports several remote attestation protocols and a mechanism by which new ones can be registered and added. Remote attestation defined by RATS is thus a candidate for use in the FIDO protocol. - Other biometric authentication protocols such as the Chinese IFAA - standard and WeChat Pay as well as Google Pay make use of remote - attestation in one form or another. - - Attester: Every FIDO Authenticator contains an Attester. + Attester: FIDO Authenticator. Relying Party: Any web site, mobile application back-end, or service that relies on authentication data based on biometric information. 3. Architectural Overview Figure 1 depicts the data that flows between different roles, independent of protocol or use case. ************ ************* ************ ***************** @@ -607,21 +604,21 @@ Another example is a multi-chassis router composed of multiple single carrier-grade routers. Multi-chassis router setups create redundancy groups that provide higher throughput by interconnecting multiple routers in these groups, which can be treated as one logical router for simpler management. A multi-chassis router setup provides a management point that connects to the Verifier. Typically one router in the group is designated as the main router. Other routers in the multi-chassis setup are connected to the main router only via physical network links and are therefore managed and appraised via - the main router's help. In consequence, a multi-chassis router setup + the main router's help. Consequently, a multi-chassis router setup is a composite device, each router is an Attester, and the main router is the lead Attester. Figure 4 depicts the conceptual data flow for a composite device. .-----------------------------. | Verifier | '-----------------------------' ^ | @@ -688,21 +685,22 @@ the Attester is considered trustworthy, such as when deciding whether it is authorized to perform some operation. Produces: Evidence Relying Party: A role performed by an entity that depends on the validity of information about an Attester, for purposes of reliably applying application specific actions. Compare /relying party/ in [RFC4949]. - Consumes: Attestation Results + Consumes: Attestation Results, Appraisal Policy for Attestation + Results Verifier: A role performed by an entity that appraises the validity of Evidence about an Attester and produces Attestation Results to be used by a Relying Party. Consumes: Evidence, Reference Values, Endorsements, Appraisal Policy for Evidence Produces: Attestation Results @@ -712,22 +710,22 @@ Produces: Appraisal Policy for Attestation Results Verifier Owner: A role performed by an entity (typically an administrator), that is authorized to configure Appraisal Policy for Evidence in a Verifier. Produces: Appraisal Policy for Evidence Endorser: A role performed by an entity (typically a manufacturer) - whose Endorsements help Verifiers appraise the authenticity of - Evidence. + whose Endorsements may help Verifiers appraise the authenticity of + Evidence and infer further capabilities of the Attester. Produces: Endorsements Reference Value Provider: A role performed by an entity (typically a manufacturer) whose Reference Values help Verifiers appraise Evidence to determine if acceptable known Claims have been recorded by the Attester. Produces: Reference Values @@ -805,49 +803,54 @@ The passport model is so named because of its resemblance to how nations issue passports to their citizens. The nature of the Evidence that an individual needs to provide to its local authority is specific to the country involved. The citizen retains control of the resulting passport document and presents it to other entities when it needs to assert a citizenship or identity Claim, such as an airport immigration desk. The passport is considered sufficient because it vouches for the citizenship and identity Claims, and it is issued by a trusted authority. Thus, in this immigration desk - analogy, the passport issuing agency is a Verifier, the passport is - an Attestation Result, and the immigration desk is a Relying Party. + analogy, the citizen is the Attester, the passport issuing agency is + a Verifier, the passport application and identifying information + (e.g., birth certificate) is the the Evidence, the passport is an + Attestation Result, and the immigration desk is a Relying Party. In this model, an Attester conveys Evidence to a Verifier, which compares the Evidence against its appraisal policy. The Verifier - then gives back an Attestation Result. If the Attestation Result was - a successful one, the Attester can then present the Attestation + then gives back an Attestation Result which the Attester treats as + opaque data. The Attester does not consume the Attestation Result, + but might cache it. The Attester can then present the Attestation Result (and possibly additional Claims) to a Relying Party, which then compares this information against its own appraisal policy. Three ways in which the process may fail include: * First, the Verifier may not issue a positive Attestation Result due to the Evidence not passing the Appraisal Policy for Evidence. * The second way in which the process may fail is when the Attestation Result is examined by the Relying Party, and based upon the Appraisal Policy for Attestation Results, the result does not pass the policy. * The third way is when the Verifier is unreachable or unavailable. - 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 remote attestation protocol. - This implies that interoperability and standardization is more - relevant for Attestation Results than it is for Evidence. + As with any other information needed by the Relying Party to make an + authorization decision, an Attestation Result can be carried in a + resource access protocol between the Attester and Relying Party. In + this model the details of the resource access 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 remote attestation protocol. This implies that + interoperability and standardization is more relevant for Attestation + Results than it is for Evidence. +------------+ | | Compare Evidence | Verifier | against appraisal policy | | +------------+ ^ | Evidence | | Attestation | | Result | v @@ -866,24 +868,25 @@ 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. Thus, in this analogy, a prospective volunteer is an Attester, the organization is the Relying Party, and the organization that issues a report is a Verifier. In this model, an Attester conveys Evidence to a Relying Party, which - simply passes it on to a Verifier. The Verifier then compares the - Evidence against its appraisal policy, and returns an Attestation - Result to the Relying Party. The Relying Party then compares the - Attestation Result against its own appraisal policy. + treats it as opaque and simply forwards it on to a Verifier. The + Verifier compares the Evidence against its appraisal policy, and + returns an Attestation Result to the Relying Party. The Relying + Party then compares the Attestation Result against its own appraisal + 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. @@ -994,61 +997,65 @@ In essence, an entity that combines more than one role creates and consumes the corresponding conceptual messages as defined in this document. 7. Trust Model 7.1. Relying Party This document covers scenarios for which a Relying Party trusts a Verifier that can appraise 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 is in the Verifier's - certificate path. Such trust is expressed by storing one or more - "trust anchors" in a secure location known as a trust anchor store. + an Attester. Such trust is expressed by storing one or more "trust + anchors" in a secure location known as a trust anchor store. As defined in [RFC6024], "A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative." The trust anchor may be a certificate or it may be a raw public key along with additional data if necessary such as its public key algorithm and parameters. - The Relying Party might implicitly trust a Verifier, such as in a - Verifier/Relying Party combination where the Verifier and Relying - Party roles are combined. Or, for a stronger level of security, the - Relying Party might require that the Verifier first provide - information about itself that the Relying Party can use to assess the - trustworthiness of the Verifier before accepting its Attestation - Results. + Thus, trusting a Verifier might be expressed by having the Relying + Party store the Verifier's public key or certificate in its trust + anchor store, or might be expressed by storing the public key or + certificate of an entity (e.g., a Certificate Authority) that is in + the Verifier's certificate path. For example, the Relying Party can + verify that the Verifier is an expected one by out of band + establishment of key material, combined with a protocol like TLS to + communicate. There is an assumption that between the establishment + of the trusted key material and the creation of the Evidence, that + the Verifier has not been compromised. - For example, one explicit way for a Relying Party "A" to establish - such trust in a Verifier "B", would be for B to first act as an - Attester where A acts as a combined Verifier/Relying Party. If A - then accepts B as trustworthy, it can choose to accept B as a - Verifier for other Attesters. + For a stronger level of security, the Relying Party might require + that the Verifier first provide information about itself that the + Relying Party can use to assess the trustworthiness of the Verifier + before accepting its Attestation Results. Such process would provide + a stronger level of confidence in the correctness of the information + provided, such as a belief that the authentic Verifier has not been + compromised by malware. - As another example, the Relying Party can establish trust in the - Verifier by out of band establishment of key material, combined with - a protocol like TLS to communicate. There is an assumption that - between the establishment of the trusted key material and the - creation of the Evidence, that the Verifier has not been compromised. + For example, one explicit way for a Relying Party "A" to establish + such confidence in the correctness of a Verifier "B", would be for B + to first act as an Attester where A acts as a combined Verifier/ + Relying Party. If A then accepts B as trustworthy, it can choose to + accept B as a Verifier for other Attesters. Similarly, the Relying Party also needs to trust the Relying Party Owner for providing its Appraisal Policy for Attestation Results, and in some scenarios the Relying Party might even require that the Relying Party Owner go through a remote attestation procedure with it before the Relying Party will accept an updated policy. This can be done similarly to how a Relying Party could establish trust in a - Verifier as discussed above. + Verifier as discussed above, i.e., verifying credentials against a + trust anchor store and optionally requiring Attestation Results from + the Relying Party Owner. 7.2. Attester In some scenarios, Evidence might contain sensitive information such as Personally Identifiable Information (PII) or system identifiable information. Thus, an Attester must trust entities to which it conveys Evidence, to not reveal sensitive data to unauthorized parties. The Verifier might share this information with other authorized parties, according to a governing policy that address the handling of sensitive information (potentially included in Appraisal @@ -1077,23 +1084,26 @@ 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 appraise the trustworthiness of that manufacturer's devices. Such trust is expressed by storing one or more trust anchors in the Verifier's trust anchor store. In a typical solution, a Verifier comes to trust an Attester indirectly by having an Endorser (such as a manufacturer) vouch for - the Attester's ability to securely generate Evidence, in which case - the Endorser's key material is stored in the Verifier's trust anchor - store. + the Attester's ability to securely generate Evidence through + Endorsements (see Section 8.2). Endorsements might describe the ways + in which the Attester resists attack, protects secrets and measures + Target Environments. Consequently, the Endorser's key material is + stored in the Verifier's trust anchor store so that Endorsements can + be authenticated and used in the Verifier's appraisal process. In some solutions, a Verifier might be configured to directly trust an Attester by having the Verifier have the Attester's key material (rather than the Endorser's) in its trust anchor store. Such direct trust must first be established at the time of trust anchor store configuration either by checking with an Endorser at that time, or by conducting a security analysis of the specific device. Having the Attester directly in the trust anchor store narrows the Verifier's trust to only specific devices rather than all @@ -1188,45 +1198,48 @@ implementation considerations. It is the responsibility of protocol specifications to define the actual data format and semantics of any relevant conceptual messages. 8.1. Evidence Evidence is a set of Claims about the target environment that reveal operational status, health, configuration or construction that have security relevance. Evidence is appraised by a Verifier to establish its relevance, compliance, and timeliness. Claims need to be - collected in a manner that is reliable. Evidence needs to be - securely associated with the target environment so that the Verifier - cannot be tricked into accepting Claims originating from a different - environment (that may be more trustworthy). Evidence also must be - protected from man-in-the-middle attackers who may observe, change or - misdirect Evidence as it travels from Attester to Verifier. The - timeliness of Evidence can be captured using Claims that pinpoint the - time or interval when changes in operational status, health, and so - forth occur. + collected in a manner that is reliable such that a Target Environment + cannot lie to the Attesting Environment about its trustworthiness + properties. Evidence needs to be securely associated with the target + environment so that the Verifier cannot be tricked into accepting + Claims originating from a different environment (that may be more + trustworthy). Evidence also must be protected from man-in-the-middle + attackers who may observe, change or misdirect Evidence as it travels + from Attester to Verifier. The timeliness of Evidence can be + captured using Claims that pinpoint the time or interval when changes + in operational status, health, and so forth occur. 8.2. Endorsements An Endorsement is a secure statement that some entity (e.g., 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, an appraisal procedure can be conducted based on - appraisal policies that may not be specific to the device instance, - but merely specific to the manufacturer providing the Endorsement. - For example, an appraisal policy might simply check that devices from - a given manufacturer have information matching a set of Reference - Values, or an appraisal policy might have a set of more complex logic - on how to appraise the validity of information. + manufacturer) vouches for the integrity of the device's various + capabilities such as claims collection, signing, launching code, + transitioning to other environments, storing secrets, and more. For + example, if the device's 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, an appraisal procedure can be conducted based on appraisal + policies that may not be specific to the device instance, but merely + specific to the manufacturer providing the Endorsement. For example, + an appraisal policy might simply check that devices from a given + manufacturer have information matching a set of Reference Values, or + an appraisal policy might have a set of more complex logic on how to + appraise the validity of information. However, while an appraisal 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 an appraisal 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 remote attestation for Network Endpoint Assessment [RFC5209] 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 @@ -1270,30 +1283,30 @@ compliant. Upon receipt of an authentic Attestation Result and given the Appraisal Policy for Attestation Results is satisfied, the Attester is allowed to perform the prescribed actions or access. The simplest such appraisal policy might authorize granting the Attester full access or control over the resources guarded by the Relying Party. A more complex appraisal policy might involve using the information provided in the Attestation Result to compare against expected values, or to apply complex analysis of other information contained in the Attestation Result. - 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 the appraisal of vendor-specific information in Evidence. This - allows a Relying Party's appraisal policy to be simpler, potentially - based on standard ways of expressing the information, while still - allowing interoperability with heterogeneous devices. + Thus, Attestation Results can contain detailed information about an + Attester, which can include privacy sensitive information as + discussed in section Section 11. 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 the appraisal of vendor-specific information in + Evidence. This allows a Relying Party's appraisal 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 appraisal policy. 8.5. Appraisal Policies The Verifier, when appraising Evidence, or the Relying Party, when @@ -1388,20 +1401,33 @@ 10. Freshness A Verifier or Relying Party might need to learn the point in time (i.e., the "epoch") an Evidence or Attestation Result has been produced. This is essential in deciding whether the included Claims and their values can be considered fresh, meaning they still reflect the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence. + This section provides a number of details. It does not however + define any protocol formats, the interactions shown are abstract. + This section is intended for those creating protocols and solutions + to understand the options available to ensure freshness. The way in + which freshness is provisioned in a protocol is an architectural + decision. Provisioning of freshness has an impact on the number of + needed round trips in a protocol, and therefore must be made very + early in the design. Different decisions will have significant + impacts on resulting interoperability, which is why this section goes + into sufficient detail such that choices in freshness will be + compatible across interacting protocols, such as depicted in + Figure 9. + Freshness is assessed based on the Appraisal Policy for Evidence or Attestation Results that compares the estimated epoch against an "expiry" threshold defined locally to that policy. There is, however, always a race condition possible in that the state of the Attester, and the appraisal policies might change immediately after the Evidence or Attestation Result was generated. The goal is merely to narrow their recentness to something the Verifier (for Evidence) or Relying Party (for Attestation Result) is willing to accept. Some flexibility on the freshness requirement is a key component for enabling caching and reuse of both Evidence and Attestation Results, @@ -1513,73 +1539,85 @@ established to the remote Verifier and a nonce is obtained. A more detailed discussion with examples appears in Section 16. For a discussion on the security of epoch IDs see Section 12.3. 11. Privacy Considerations The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a - device as well as potentially any users of the device. In many - cases, the whole point of attestation procedures is to provide - reliable information about the type of the device and the firmware/ - software that the device is running. This information might be - particularly interesting to many attackers. For example, knowing - that a device is running a weak version of firmware provides a way to - aim attacks better. + device as well as potentially any users of the device. - Many Claims in Evidence and Attestation Results are potentially - Personally Identifying Information (PII) depending on the end-to-end - use case of the remote attestation procedure. Remote attestation - that goes up to include containers and applications, e.g., a blood - pressure monitor, may further reveal details about specific systems - or users. + In many cases, the whole point of attestation procedures is to + provide reliable information about the type of the device and the + firmware/software that the device is running. + + This information might be particularly interesting to many attackers. + For example, knowing that a device is running a weak version of + firmware provides a way to aim attacks better. + + In some circumstances, if an attacker can become aware of + Endorsements, Reference Values, or appraisal policies, it could + potentially provide an attacker with insight into defensive + mitigations. It is recommended that attention be paid to + confidentiality of such information. + + Additionally, many Claims in Evidence, many Claims in Attestation + Results, and appraisal policies potentially contain Personally + Identifying Information (PII) depending on the end-to-end use case of + the remote attestation procedure. Remote attestation that includes + containers and applications, e.g., a blood pressure monitor, may + further reveal details about specific systems or users. In some cases, an attacker may be able to make inferences about the contents of Evidence from the resulting effects or timing of the processing. For example, an attacker might be able to infer the value of specific Claims if it knew that only certain values were accepted by the Relying Party. - Evidence and Attestation Results are expected to be integrity - protected (i.e., either via signing or a secure channel) and - optionally might be confidentiality protected via encryption. If - confidentiality protection of the conceptual messages is omitted or - unavailable, the protecting protocols that convey Evidence or - Attestation Results are responsible for detailing what kinds of - information are disclosed, and to whom they are exposed. + Conceptual messages (see Section 8) carrying sensitive or + confidential information are expected to be integrity protected + (i.e., either via signing or a secure channel) and optionally might + be confidentiality protected via encryption. If there isn't + confidentiality protection of conceptual messages themselves, the + underlying conveyance protocol should provide these protections. As Evidence might contain sensitive or confidential information, Attesters are responsible for only sending such Evidence to trusted Verifiers. Some Attesters might want a stronger level of assurance of the trustworthiness of a Verifier before sending Evidence to it. In such cases, an Attester can first act as a Relying Party and ask for the Verifier's own Attestation Result, and appraising it just as a Relying Party would appraise an Attestation Result for any other purpose. Another approach to deal with Evidence is to remove PII from the Evidence while still being able to verify that the Attester is one of a large set. This approach is often called "Direct Anonymous Attestation". See [CCC-DeepDive] section 6.2 for more discussion. 12. Security Considerations This document provides an architecture for doing remote attestation. No specific wire protocol is documented here. Without a specific proposal to compare against, it is impossible to know if the security - threats listed below have been mitigated well. The security - considerations below should be read as being essentially requirements - against realizations of the RATS Architecture. Some threats apply to - protocols, some are against implementations (code), and some threats - are against physical infrastructure (such as factories). + threats listed below have been mitigated well. + + The security considerations below should be read as being essentially + requirements against realizations of the RATS Architecture. Some + threats apply to protocols, some are against implementations (code), + and some threats are against physical infrastructure (such as + factories). + + The fundamental purpose of the RATS architecture is to allow a + Relying Party to establish a basis for trusting the Attester. 12.1. Attester and Attestation Key Protection Implementers need to pay close attention to the protection of the Attester and the manufacturing processes for provisioning attestation key material. If either of these are compromised, intended levels of assurance for RATS are compromised because attackers can forge Evidence or manipulate the Attesting Environment. For example, a Target Environment should not be able to tamper with the Attesting Environment that measures it, by isolating the two environments from @@ -1602,23 +1640,21 @@ chip, a TEE, a virtual machine, or another secure mode of operation. The Attesting Environment must be protected from unauthorized modification to ensure it behaves correctly. Confidentiality protection of the Attesting Environment's signing key is vital so it cannot be misused to forge Evidence. In many cases the user or owner of a device that includes the role of Attester must not be able to modify or extract keys from the Attesting Environments, to prevent creating forged Evidence. Some common examples include the user of a mobile phone or FIDO - authenticator. An essential value-add provided by RATS is for the - Relying Party to be able to trust the Attester even if the user or - owner is not trusted. + authenticator. Measures for a minimally protected system might include process or application isolation provided by a high-level operating system, and restricted access to root or system privileges. In contrast, For really simple single-use devices that don't use a protected mode operating system, like a Bluetooth speaker, the only factual isolation might be the sturdy housing of the device. Measures for a moderately protected system could include a special restricted operating environment, such as a TEE. In this case, only @@ -1627,36 +1663,40 @@ Measures for a highly protected system could include specialized hardware that is used to provide protection against chip decapping attacks, power supply and clock glitching, faulting injection and RF and power side channel attacks. 12.1.2. Attestation Key Provisioning Processes Attestation key provisioning is the process that occurs in the factory or elsewhere to establish signing key material on the device - and the validation key material off the device. Sometimes this is + and the validation key material off the device. Sometimes this procedure is referred to as personalization or customization. + The keys generated in the factory, whether generated in the device or + off-device by the factory SHOULD be generated by a Cryptographically + Strong Sequence ([RFC4086], Section 6.2). + 12.1.2.1. Off-Device Key Generation One way to provision key material is to first generate it external to the device and then copy the key onto the device. In this case, confidentiality protection of the generator, as well as for the path over which the key is provisioned, is necessary. The manufacturer needs to take care to protect corresponding key material with measures appropriate for its value. The degree of protection afforded to this key material can vary by - device, based upon considerations as to a cost/benefit evaluation of - the intended function of the device. The confidentiality protection - is fundamentally based upon some amount of physical protection: while + the intended function of the device and the specific practices of the + device manufacturer or integrator. The confidentiality protection is + fundamentally based upon some amount of physical protection: while encryption is often used to provide confidentiality when a key is conveyed across a factory, where the attestation key is created or applied, it must be available in an unencrypted form. The physical protection can therefore vary from situations where the key is unencrypted only within carefully controlled secure enclaves within silicon, to situations where an entire facility is considered secure, by the simple means of locked doors and limited access. The cryptography that is used to enable confidentiality protection of the attestation key comes with its own requirements to be secured. @@ -1676,32 +1716,30 @@ key cryptography, it is, by definition, not necessary to maintain confidentiality of the public key: however integrity of the chain of custody of the public key is necessary in order to avoid attacks where an attacker is able get a key they control endorsed. To summarize: attestation key provisioning must ensure that only valid attestation key material is established in Attesters. 12.2. Integrity Protection - Any solution that conveys information used for security purposes, - whether such information is in the form of Evidence, Attestation - Results, Endorsements, or appraisal policy must support end-to-end - integrity protection and replay attack prevention, and often also - needs to support additional security properties, including: + Any solution that conveys information in any conceptual message (see + Section 8) must support end-to-end integrity protection and replay + attack prevention, and often also needs to support additional + security properties, including: * end-to-end encryption, * denial of service protection, * authentication, - * auditing, * fine grained access controls, and * logging. Section 10 discusses ways in which freshness can be used in this architecture to protect against replay attacks. To assess the security provided by a particular appraisal policy, it @@ -1703,32 +1741,32 @@ Section 10 discusses ways in which freshness can be used in this architecture to protect against replay attacks. To assess the security provided by a particular appraisal 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 appraisal policy was itself obtained - securely. If an attacker can configure appraisal policies for a - Relying Party or for a Verifier, then integrity of the process is - compromised. + securely. If an attacker can configure or modify appraisal policies, + Endorsements or Reference Values for a Relying Party or for a + Verifier, then integrity of the process is compromised. Security protections in RATS may be applied at different layers, whether by a conveyance protocol, or an information encoding format. - This architecture expects conceptual messages (see Section 8) to be - end-to-end protected based on the role interaction context. For - example, if an Attester produces Evidence that is relayed through - some other entity that doesn't implement the Attester or the intended - Verifier roles, then the relaying entity should not expect to have - access to the Evidence. + This architecture expects conceptual messages to be end-to-end + protected based on the role interaction context. For example, if an + Attester produces Evidence that is relayed through some other entity + that doesn't implement the Attester or the intended Verifier roles, + then the relaying entity should not expect to have access to the + Evidence. 12.3. Epoch ID-based Attestation Epoch IDs, described in Section 10.3, can be tampered with, replayed, dropped, delayed, and reordered by an attacker. An attacker could be either external or belong to the distribution group, for example, if one of the Attester entities have been compromised. @@ -1753,22 +1791,23 @@ from a past epoch as fresh, while in the meantime the Attester has been compromised. Reordering and dropping attacks are mitigated if the transport provides the ability to detect reordering and drop. However, the delay attack described above can't be thwarted in this manner. 12.4. Trust Anchor Protection As noted in Section 7, Verifiers and Relying Parties have trust - anchor stores that must be secured. Specifically, a trust anchor - store must resist modification against unauthorized insertion, + anchor stores that must be secured. [RFC6024] contains more + discussion of trust anchor store requirements. Specifically, a trust + anchor store must resist modification against unauthorized insertion, deletion, and modification. If certificates are used as trust anchors, Verifiers and Relying Parties are also responsible for validating the entire certificate path up to the trust anchor, which includes checking for certificate revocation. See Section 6 of [RFC5280] for details. 13. IANA Considerations This document does not require any actions by IANA. @@ -2183,20 +2223,25 @@ Internet-Draft, draft-tschofenig-tls-cwt-02, 13 July 2020, . [OPCUA] OPC Foundation, "OPC Unified Architecture Specification, Part 2: Security Model, Release 1.03", OPC 10000-2 , 25 November 2015, . + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + DOI 10.17487/RFC4086, June 2005, + . + [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, . [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management