Cisco Systems

evoit@cisco.com

Fraunhofer SIT

Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@sit.fraunhofer.de

MIT

hardjono@mit.edu

Arm Limited

Thomas.Fossati@arm.com

Intel

vincent.r.scarlata@intel.com

Security RATS Working Group Internet-Draft This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogenous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party.

The Remote ATtestation procedureS (RATS) architecture defines conceptual messages conveyed between architectural subsystems to support trustworthiness appraisal. Within RATS, the Attestation Results conceptual message consists of “output generated by a Verifier, typically including information about an Attester, where the Verifier vouches for the validity of the results”. Generated Attestation Results are ultimately conveyed to one or more Relying Parties. Reception of an Attestation Result enables a Relying Party to determine what action to take with regards to an Attester. Frequently, this action will be to choose whether to allow the Attester to interact with the Relying Party over a connection between the two. When determining whether to allow connectivity-based interactions with an Attester, a Relying Party is challenged with a number of difficult problems which it must be able to handle successfully. These problems include: What types of Attestation Results (AR) might a Relying Party be willing to trust from a specific type of Verifier? What supplemental information must the Verifier need to include within Attestation Results to convince a Relying Party to allow interactions, or to apply policies to any connections, based on these Attestation Results? What are the operating/environmental realities of the Attesting Environment where a Relying Party should only be able to associate a certain confidence regarding Attestation Results out of the Verifier? (In other words, different types of Trusted Execution Environments (TEE) need not be treated as equivalent.) How to make direct comparisons where there is a heterogeneous mix of Attesting Environments and Verifier types. To address these problems, it is important that specific Attestation Result information elements are framed independently of Attesting Environment specific constraints. If they are not, a Relying Party would be forced to adapt to the syntax and semantics of many vendor specific environments. This is not a reasonable ask as there can be many types of Attesters connecting into a Relying Party. The business need therefore is for common Attestation Result information element definitions. With these definitions, consistent connectivity decisions can be made by a Relying Party where there is a heterogenous mix of Attesting Environment types and Verifier types. This document defines information elements for Attestation Results in a way which normalizes the trustworthiness assertions that can be made from a diverse set of Attesters. Of specific focus are TPM, TrustZone, and SGX based Attesting Environments. Extensions to this document can enable additional TEE environments and additional information elements to be supported.

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 when, and only when, they appear in all capitals, as shown here.

The following terms are imported from : Appraisal Policy for Attestation Results, Attester, Attesting Environment, Claims, Evidence, Relying Party, and Verifier. also describes topological patterns that illustrate the need for interoperable conceptual messages. The two patterns called “background-check model” and “passport model” are imported from the RATS architecture and used in this document as a reference to the architectural concepts: Background-Check Model and Passport Model. Newly defined terms for this document: a bundle of Evidence which includes at least the following: Verifier signed Attestation Results. These Attestation Results must include a Trustworthiness Vector describing a Verifier’s most recent appraisal of an Attester, and some Verifier Proof-of-Freshness (PoF). A Relying Party PoF which is bound to the Attestation Results of (1) by the Attester’s Attesting Environment signature. Sufficient information to determine the elapsed interval between the Verifier PoF and Relying Party PoF. Evidence which unambiguously identifies an identity. Identity Evidence could take different forms, such as a certificate, or a signature which can be appraised to have only been generated by a specific private/public key pair. a specific quanta of trustworthiness which can be assigned by a Verifier based on its appraisal policy. a set of zero to many Trustworthiness Claims assigned during a single appraisal procedure by a Verifier using Evidence generated by an Attester. The vector is included within Attestation Results.

When a Relying Party receives Attestation Results, it will receive them as part of a protocol from an endpoint which expects some result from this communication. Upon receipt, the Relying Party will apply an Appraisal Policy for Attestation Results. This policy will consider the Attestation Results as well as additional information about the Attester and Verifier when determining what action to take.

When the action is a communication establishment attempt with an Attester, there is only a limited set of actions which a Relying Party might take. These actions include: Allow or deny information exchange with the Attester (i.e., connectivity). When there is a deny, reasons should be returned to the Attester. Connect the Attester to a specific context within a Relying Party. Apply policies on the connection to or from the Attester (e.g., rate limits). There are three categories of information which must be conveyed to the Relying Party before it determines which of these actions to take. Non-repudiable Identity Evidence – Evidence which undoubtably identifies one or more entities involved with a connection. Trustworthiness Claims – Specifics a Verifier asserts with regards to its trustworthiness findings about an Attester. Claim Freshness – Establishes the time of last update (or refresh) of Trustworthiness Claims. The following sections detail requirements for these three categories.

Identity Evidence must be conveyed during the establishment of any trust-based relationship. Specific use cases will define the minimum types of identities required by a particular Relying Party. At minimum, a Relying Party MUST able to verify the identity of a Verifier it chooses to trust. This Identity Evidence will often consist of a Verifier signature aross the Attestation Results; and this signature could only have come from a key pair maintained by a trusted developer or operator of the Verifier. Also at minimum for connectivity related relationships, each set of Attestation Results must be provably and non-reputably bound to the identity of the specific Attesting Environment. In a subset of use cases, these two pieces of Identity Evidence may be sufficient for a Relying Party to successfully meet the criteria for its Appraisal Policy for Attestation Results. In this case a Relying Party will simply connect to any device successfully appraised and verified by a Verifier. However where the Appraisal Policy for Attestation Results is more nuanced, the Relying Party may need additional information. Some Identity Evidence related questions which the Relying Party may consider include: Does the Relying Party only trust this Verifier to make Trustworthiness Claims on behalf a specific type of hardware rooted Attesting Environment? Might a mix of Verifiers be necessary to cover all mandatory Trustworthiness Claims? Does the Relying Party only accept connections from a verified-authentic software build from a specific software developer? Does the Relying Party only accept connections from specific preconfigured list of Attesters? For any of these more nuanced appraisals, additional Identity Evidence or other policy related information must be conveyed or pre-provisioned during the formation of a trust context between the Relying Party, the Attester, the Attester’s Attesting Environment, and the Verifier.

For the Verifier identity, it is important to review the chain of trust for that Verifier. Additionally, the Relying Party must have confidence that the Trustworthiness Claims being relied upon from the Verifier considered the chain of trust for the Attesting Environment .

For the Attesting Environment identity, there MUST exist a chain of trust ultimately bound to a hardware-based root of trust in the Attesting Environment. It is upon this root of trust that unique, non-repudiable identities may be founded. Example attested identities may include: a type of hardware chip used for the Attesting Environment a specific instance of a running Attesting Environment a software build executing within an Attesting Environment the developer(s) responsible for the code executing within an Attesting Environment This document only defines the domain of the first of these four identities. The reason the first is especially important in this document’s context is that each type of hardware chip might support a different set of Trustworthiness Claims. Consequently, the Relying Party might require Identity Evidence which indicates of the type of hardware chip when it considers its Appraisal Policy for Attestation Results. For more see .

Per Section 3.3, an Attester and a corresponding Attesting Environment might not share common boundaries. In such cases, where connections are being established directly to an Attester but not to the Attesting Environment, the Verifier must include sufficient information in the Attestation Results to enable the Relying Party to have confidence that the Attester’s trustworthiness is represented by Trustworthiness Claims signed by the appropriate Attesting Environment.

Any of the above identities may be needed to be established by the Relying Party during the connectivity establishment process. (text below needs work) The mechanism for communicating the Attesting Environment identity (and if it is different, the Attester identity ) may be either implicit or explicit within an instance of Attestation Results. An example of explicit communication would be to include the following Identity Evidence directly in the Attestation Results: a unique identifier for an Attesting Environment, the name of a key which can be provably associated with that unique identifier, and the set of Attestation Results are signed using that key. An example of implicit communication would be to include the following Identity Evidence: a signature which has been made across the Attestation Results. It would be then up to the Relying Party’s Appraisal Policy for Attestation Results to verify that this signature could only have come from an entity having access to the associated private key. Note that proving identity also requires some element of freshness be embedded within a signed portion of the Attestation Results. This element of freshness significantly reduces the identity spoofing risks from a replay attack.

A Verifier must be able to assert different aspects of Attester trustworthiness. Therefore specific Claims of Verifier appraised trustworthiness have been defined in this section. These are known as Trustworthiness Claims. These Trustworthiness Claims may be either affirming (positive) or detracting (negative). It is these Trustworthiness Claims which are asserted within the Attestation Results produced by a Verifier. It is out of the scope of this document for the Verifier to provide proof or logic on how the assertion was derived. Following are the set of Trustworthiness Claims defined within this document: Trustworthiness Claim Definition +/- hw-authentic A Verifier has appraised an Attester as having authentic hardware and firmware affirming hw-verification-fail A Verifier has appraised that an Attester has failed its hardware or firmware verification detracting hw-instance-recognized A Verifier has verified an Attesting Environment’s unique identity based on some hardware based private key signing affirming hw-instance-unknown A Verifier has attempted and failed to verify an Attesting Environment’s unique hardware protected identity detracting executables-verified A Verifier has appraised that an Attester has installed into runtime memory only a genuine set of approved files during and after boot affirming executables-fail A Verifier has appraised that an Attester has installed into runtime memory files other than approved files detracting file-system-anomaly A Verifier has found a file on an Attester which should not be present detracting config-secure A Verifier has appraised an Attester’s configuration, and has found no security issues affirming config-insecure A Verifier has appraised an Attester’s configuration, and has found security issues which should be addressed detracting runtime-confidential A Verifier has appraised that an Attester is opaque to the device operator. See O.RUNTIME_CONFIDENTIALITY from . affirming isolation A Verifier has appraised an Attester has execution and storage space which is separated from the spaces of any other application or Attester. See O.TA_ISOLATION from . affirming secure-storage A Verifier has appraised that an Attester has a Trusted Execution Environment which encrypts persistent storage using keys unavailable outside protected hardware. Protections must meet the capabilities of Section 5, but need not be hardware tamper resistant. affirming source-data-integrity A Verifier has appraised that the Attester is operating upon data inputs from an external Attester having a Trustworthiness Vector with no less than the current Vector. affirming Each type of Attesting Environment MUST be able to support one or more of the set of affirming Trustworthiness Claims listed above. Additional Trustworthiness Claims may be defined in subsequent documents, but the goal is to minimize these Trustworthiness Claims to just Verifier appaisals which are directly actionable by the Relying Party.

Multiple Trustworthiness Claims may be asserted about an Attesting Environment at single point in time. The set of Trustworthiness Claims inserted into an instance of Attestation Results by a Verifier is known as a Trustworthiness Vector. The order of Claims in the vector is NOT meaningful. A Trustworthiness Vector with no Trustworthiness Claims (i.e., a null Trustworthiness Vector) is a valid construct. In this case, the Verifier is making no affirming or detracting Claims.

Some Trustworthiness Claims are implicit based on the underlying type of Attesting Environment. Where such implicit Trustworthiness Claims exist, they do not have to be explicitly included in the Trustworthiness Vector. However these implicit Trustworthiness Claims SHOULD be considered as being present by the Relying Party. Additionally, there are some Trustworthiness Claims which cannot be adequately supported by an Attesting Environment. For example, it would be difficult for an Attester that includes only a TPM (and no other TEE) from ever having a Verifier appraise support for ‘runtime-confidential’. As such, a Relying Party would be acting properly, if it rejects any non-supportable Trustworthiness Claims asserted from a Verifier. As a result, the need for the ability to carry a specific Trustworthiness Claim will vary by the type of Attesting Environment. Example mappings for SGX, Trustzone, and TPMs can be seen in . (This is work in progress)

(Work needed in this Section. The intent is that all freshness mechanisms of , Section 20 will be supported.) A Relying Party will care about the recentness of specific Trustworthiness Claims. And a Relying Party will often track when there is an Expiry of Verifier Confidence for the Trustworthiness Vector itself. With connectivity related Attestation Results, sometimes reboot will reset various Trustworthiness Claims. In this case you don’t have to worry about seeing the reboot itself as connectivity reestablishment will refresh the recentness timers.

The establishment and maintenance of a connection between an Attester and a Relying Party will follow the Passport Model from Section 5.1 of . describes this flow of information using the time definitions described in . Corresponding messages are passed within an authentication framework, such the EAP protocol over TLS .

| | | time(RG) | |<------Attestation Results-(2) | ~ ~ ~ time(VG')? | | ~ ~ ~ |<------Relying Party PoF-----------------(3)time(NS') | | | time(EG')(4)------AR-augmented Evidence----------------->| | | time(RG',RA')(5) (6) ~ time(RX') ]]>

assumes that some form of time interval tracking is possible between the Verifer PoF and Relying Party PoF. However, there is a simplified case that does not require a Relying Party’s PoF. In that second variant, the Relying Party trusts that the Attester cannot be meaningfully changed from the outside during that interval. Based on that assumption, the Relying Party PoF can be safely omitted. In essence, the AR-augmented Evidence is replaced by the stand-alone Attestation Results. In the first variant illustrated in , a Verifier B is often implemented as a code module within the Relying Party. In these cases, the role Relying Party and the role Verifier are collapsed in one entity. As a result, the entity can appraise both the Attestation Result parts as well as the Evidence parts of AR-augmented Evidence to determine whether an Attester qualifies for connection to the Relying Party’s resources. Appraisal policies define the conditions and prerequisites for when an Attester qualifies for connection. In essence, an Attester has to be able to provide all of the mandatory affirming Trustworthiness Claims and none of the disqualifying detracting Trustworthiness Claims. More details on each interaction step are as follows. The numbers used match to the numbered steps in : An Attester sends Evidence which is provably fresh to Verifier A at time(EG). Freshness from the perspective of Verifer A MAY be established with Verifier PoF such as a nonce. Verifier A appraises (1), then sends the following items back to that Attester within Attestation Results: the verified identity of the Attesting Environment, the Verifier A appraised Trustworthiness Vector of an Attester, a freshness proof associated with the Attestation Results, a Verifier signature across (2.1) though (2.3). At time(EG’) a Relying Party PoF (such as a nonce) known to the Relying Party is sent to the Attester. The Attester generates and sends AR-augmented Evidence to the Relying Party/Verifier B. This AR-augmented Evidence includes: The Attestation Results from (2) Attestation Environment signing of a hash of the Attestation Results plus the proof-of-freshness from (3). This allows the delta of time between (2.3) and (3) to be definitively calculated by the Relying Party. On receipt of (4), the Relying Party applies its Appraisal Policy for Attestation Results. At minimum, this appraisal policy process must include the following: Verify that (4.2) includes the nonce from (3). Use a local certificate to validate the signature (4.1). Verify that the hash from (4.2) matches (4.1) Use the identity of (2.1) to validate the signature of (4.2). Failure of any steps (5.1) through (5.4) means the link does not meet minimum validation criteria, therefore appraise the link as having a null Verifier B Trustworthiness Vector. Jump to step (6.1). When there is large or uncertain time gap between time(EG) and time(EG’), the link should be assigned a null Verifier B Trustworthiness Vector. Jump to step (6.1). Assemble the Verifier B Trustworthiness Vector Copy Verifier A Trustworthiness Vector to Verifier B Trustworthiness Vector Add implicit Trustworthiness Claims inherent to the type of TEE. Prune any unbelieveable Trustworthiness Claims Prune any Trustworthiness Claims the Relying Party doesn’t accept from this Verifier. The Relying Party takes action based on Verifier B’s appraised Trustworthiness Vector: Allow the information exchange from the Attester into a Relying Party context where the Verifier B appraised Trustworthiness Vector includes all the mandatory affirming Trustworthiness Claims, and none of the disqualifying detracting Trustworthiness Claims. Disallow any information exchange into a Relying Party context for which that Verifier B appraised Trustworthiness Vector not qualified. As link layer protocols re-authenticate, steps (1) to (2) and steps (3) to (6) will independently refresh. This allows the Trustworthiness of Attester to be continuously re-appraised. Additionally, it will be common that each device on either side of a connection will want to attest the other. This will be a process known as multual-attestation. To support this, the process listed above may be run independently on each side of the connection.

Privacy Considerations Text

Security Considerations Text

See Body.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. In network protocol exchanges it is often the case that one entity requires believable evidence about the operational state of a remote peer. Such evidence is typically conveyed as claims about the peer's software and hardware platform, and is subsequently appraised in order to assess the peer's trustworthiness. The process of generating and appraising this kind of evidence is known as remote attestation. This document describes an architecture for remote attestation procedures that generate, convey, and appraise evidence about a peer's operational state. This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community. The Extensible Authentication Protocol (EAP), defined in RFC 3748, enables extensible network access authentication. This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by EAP authentication algorithms, known as "methods". It also provides a detailed system-level security analysis, describing the conditions under which the key management guidelines described in RFC 4962 can be satisfied. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.

The following is a table which shows what Claims are supportable by different Attesting Environment types. Note that claims MAY BE implicit to an Attesting Environment type, and therefore do not have to be included in the Trustworthiness Vector to be considered as set by the Relying Party.

Following are Trustworthiness Claims which MAY be set for a TPM based Attester. Trustworthiness Claim TPM hw-authentic If PCR check ok from BIOS checks, through Master Boot Record configuration hw-verification-fail If PCR don’t check ok hw-instance-recognized Optional hw-instance-unknown Optional executables-verified If PCRs check for the static operating system, and for any tracked files subsequently loaded. executables-refuted If PCR checks fail for the static operating system, and for any tracked files subsequently loaded. file-system-anomaly Verifier evaluation of Attester reveals an unexpected file. config-secure Verifier evaluation of Attester reveals no configuration lines which expose the Attester to known security vulnerabilities. config-insecure Optional runtime-confidential TPMs do not provide a sufficient technology base for this claim. isolation This can be set only if no other applications are running on the Attester secure-storage Minimal secure storage space exists and is writeable by external applications. This space would typically just be used to store keys. Setting the Trustworthiness Claims may follow the following logic at the Verifier A within (2) of :

Trustworthiness Claim SGX hw-authentic Implicit in signature hw-verification-fail Implicit if signature not ok hw-instance-recognized Optional hw-instance-unknown Optional executables-verified Optional executables-refuted Optional file-system-anomaly Optional config-secure Optional config-insecure Optional runtime-confidential Implicit in signature isolation Implicit in signature secure-storage Implicit in signature

Trustworthiness Claim TrustZone hw-authentic Implicit in signature hw-verification-fail Implicit if signature not ok hw-instance-recognized ? hw-instance-unknown ? executables-verified Optional executables-refuted Optional file-system-anomaly Optional config-secure Optional config-insecure Optional runtime-confidential (?) isolation Implicit in signature secure-storage Implicit in signature

It is possible for a cluster/hierarchy of Verifiers to have aggregate AR which are perhaps signed/endorsed by a lead Verifier. What should be the Proof-of-Freshness or Verifier associated with any of the aggregate set of Trustworthiness Claims? There will need to be a subsequent document which documents how these objects which will be translated into a protocol on a wire (e.g. EAP on TLS). Some breakpoint between what is in this draft, and what is in specific drafts for wire encoding will need to be determined. Questions like architecting the cluster/hierarchy of Verifiers fall into this breakdown. For Trustworthiness Claims such as “exectables verified”, there could be value in identifying a specific Appraisal Policy for Attestation Results applied. One way this could be done would be a URI which identifies this policy. As the URI also could encode the version of the software, it might also act as a mechanism to signal the Relying Party to refresh/re-evaluate its view of Verifier A. Expand the variant of which requires no Relying Party PoF into its own picture.

Guy Fedorkow Email: gfedorkow@juniper.net