--- 1/draft-ietf-rats-architecture-05.txt 2020-09-01 16:13:11.266255763 -0700 +++ 2/draft-ietf-rats-architecture-06.txt 2020-09-01 16:13:11.354257994 -0700 @@ -1,25 +1,25 @@ RATS Working Group H. Birkholz Internet-Draft Fraunhofer SIT Intended status: Informational D. Thaler -Expires: 11 January 2021 Microsoft +Expires: 5 March 2021 Microsoft M. Richardson Sandelman Software Works N. Smith Intel W. Pan Huawei Technologies - 10 July 2020 + 1 September 2020 Remote Attestation Procedures Architecture - draft-ietf-rats-architecture-05 + draft-ietf-rats-architecture-06 Abstract In network protocol exchanges, it is often the case that one entity (a Relying Party) requires evidence about a remote peer to assess the peer's trustworthiness, and a way to appraise such evidence. The evidence is typically a set of claims about its software and hardware platform. This document describes an architecture for such remote attestation procedures (RATS). @@ -42,21 +42,21 @@ 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 11 January 2021. + This Internet-Draft will expire on 5 March 2021. Copyright Notice Copyright (c) 2020 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 @@ -66,61 +66,66 @@ provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Reference Use Cases . . . . . . . . . . . . . . . . . . . . . 5 3.1. Network Endpoint Assessment . . . . . . . . . . . . . . . 5 3.2. Confidential Machine Learning (ML) Model Protection . . . 6 3.3. Confidential Data Retrieval . . . . . . . . . . . . . . . 6 - 3.4. Critical Infrastructure Control . . . . . . . . . . . . . 6 + 3.4. Critical Infrastructure Control . . . . . . . . . . . . . 7 3.5. Trusted Execution Environment (TEE) Provisioning . . . . 7 3.6. Hardware Watchdog . . . . . . . . . . . . . . . . . . . . 7 + 3.7. FIDO Biometric Authentication . . . . . . . . . . . . . . 8 4. Architectural Overview . . . . . . . . . . . . . . . . . . . 8 - 4.1. Appraisal Policies . . . . . . . . . . . . . . . . . . . 9 - 4.2. Two Types of Environments of an Attester . . . . . . . . 9 - 4.3. Layered Attestation Environments . . . . . . . . . . . . 10 - 4.4. Composite Device . . . . . . . . . . . . . . . . . . . . 12 - 5. Topological Models . . . . . . . . . . . . . . . . . . . . . 15 - 5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 15 - 5.2. Background-Check Model . . . . . . . . . . . . . . . . . 16 - 5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 17 - 6. Roles and Entities . . . . . . . . . . . . . . . . . . . . . 18 - 7. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 7.1. Relying Party . . . . . . . . . . . . . . . . . . . . . . 19 - 7.2. Attester . . . . . . . . . . . . . . . . . . . . . . . . 20 - 7.3. Relying Party Owner . . . . . . . . . . . . . . . . . . . 20 - 7.4. Verifier . . . . . . . . . . . . . . . . . . . . . . . . 20 - 7.5. Endorser and Verifier Owner . . . . . . . . . . . . . . . 21 - - 8. Conceptual Messages . . . . . . . . . . . . . . . . . . . . . 21 - 8.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 21 - 8.2. Endorsements . . . . . . . . . . . . . . . . . . . . . . 21 - 8.3. Attestation Results . . . . . . . . . . . . . . . . . . . 22 - 9. Claims Encoding Formats . . . . . . . . . . . . . . . . . . . 23 - 10. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 - 12. Security Considerations . . . . . . . . . . . . . . . . . . . 27 - 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 - 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 - 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 - 16. Appendix A: Time Considerations . . . . . . . . . . . . . . . 29 - 16.1. Example 1: Timestamp-based Passport Model Example . . . 30 - 16.2. Example 2: Nonce-based Passport Model Example . . . . . 32 - 16.3. Example 3: Timestamp-based Background-Check Model - Example . . . . . . . . . . . . . . . . . . . . . . . . 33 - 16.4. Example 4: Nonce-based Background-Check Model Example . 33 - 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 17.1. Normative References . . . . . . . . . . . . . . . . . . 34 - 17.2. Informative References . . . . . . . . . . . . . . . . . 34 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 + 4.1. Appraisal Policies . . . . . . . . . . . . . . . . . . . 10 + 4.2. Two Types of Environments of an Attester . . . . . . . . 10 + 4.3. Layered Attestation Environments . . . . . . . . . . . . 11 + 4.4. Composite Device . . . . . . . . . . . . . . . . . . . . 13 + 5. Topological Models . . . . . . . . . . . . . . . . . . . . . 16 + 5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 16 + 5.2. Background-Check Model . . . . . . . . . . . . . . . . . 17 + 5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 18 + 6. Roles and Entities . . . . . . . . . . . . . . . . . . . . . 19 + 7. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 7.1. Relying Party . . . . . . . . . . . . . . . . . . . . . . 20 + 7.2. Attester . . . . . . . . . . . . . . . . . . . . . . . . 21 + 7.3. Relying Party Owner . . . . . . . . . . . . . . . . . . . 21 + 7.4. Verifier . . . . . . . . . . . . . . . . . . . . . . . . 21 + 7.5. Endorser and Verifier Owner . . . . . . . . . . . . . . . 22 + 8. Conceptual Messages . . . . . . . . . . . . . . . . . . . . . 22 + 8.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 22 + 8.2. Endorsements . . . . . . . . . . . . . . . . . . . . . . 22 + 8.3. Attestation Results . . . . . . . . . . . . . . . . . . . 23 + 9. Claims Encoding Formats . . . . . . . . . . . . . . . . . . . 24 + 10. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 + 12.1. Attester and Attestation Key Protection . . . . . . . . 29 + 12.1.1. On-Device Attester and Key Protection . . . . . . . 29 + 12.1.2. Attestation Key Provisioning Processes . . . . . . . 30 + 12.2. Integrity Protection . . . . . . . . . . . . . . . . . . 30 + 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 + 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 + 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 + 16. Appendix A: Time Considerations . . . . . . . . . . . . . . . 32 + 16.1. Example 1: Timestamp-based Passport Model Example . . . 33 + 16.2. Example 2: Nonce-based Passport Model Example . . . . . 35 + 16.3. Example 3: Handle-based Passport Model Example . . . . . 36 + 16.4. Example 4: Timestamp-based Background-Check Model + Example . . . . . . . . . . . . . . . . . . . . . . . . 38 + 16.5. Example 5: Nonce-based Background-Check Model Example . 38 + 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 + 17.1. Normative References . . . . . . . . . . . . . . . . . . 39 + 17.2. Informative References . . . . . . . . . . . . . . . . . 39 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 1. Introduction In Remote Attestation Procedures (RATS), one peer (the "Attester") produces believable information about itself - Evidence - to enable a remote peer (the "Relying Party") to decide whether to consider that Attester a trustworthy peer or not. RATS are facilitated by an additional vital party, the Verifier. The Verifier appraises Evidence via Appraisal Policies and creates @@ -326,20 +331,47 @@ If the watchdog does not receive regular, and fresh, Attestation Results as to the systems' health, then it forces a reboot. 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 +3.7. FIDO Biometric Authentication + + In the Fast IDentity Online (FIDO) protocol [WebAuthN], [CTAP], the + device in the user's hand authenticates the human user, whether by + biometrics (such as fingerprints), or by PIN and password. FIDO + authentication puts a large amount of trust in the device compared to + typical password authentication because it is the device that + verifies the biometric, PIN and password inputs from the user, not + 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 attestation + in one form or another. + + Attester: Every FIDO Authenticator contains an Attester. + + Relying Party: Any web site, mobile application back end or service + that does biometric authentication. + 4. Architectural Overview Figure 1 depicts the data that flows between different roles, independent of protocol or use case. ************ ************ **************** * Endorser * * Verifier * * Relying Party* ************ * Owner * * Owner * | ************ **************** | | | @@ -362,32 +394,32 @@ | v v .----------. .-----------------. | Attester | | Relying Party | '----------' '-----------------' Figure 1: Conceptual Data Flow An Attester creates Evidence that is conveyed to a Verifier. The Verifier uses the Evidence, and any Endorsements from Endorsers, - by applying an Evidence Appraisal Policy to assess the + by applying an Appraisal Policy for Evidence to assess the trustworthiness of the Attester, and generates Attestation Results for use by Relying Parties. The Appraisal Policy for Evidence might - be obtained from an Endorser along with the Endorsements, or might be - obtained via some other mechanism such as being configured in the - Verifier by an administrator. + be obtained from an Endorser along with the Endorsements, and/or + might be obtained via some other mechanism such as being configured + in the Verifier by the Verifier Owner. The Relying Party uses Attestation Results by applying its own Appraisal Policy to make application-specific decisions such as authorization decisions. The Appraisal Policy for Attestation - Results might, for example, be configured in the Relying Party by an - administrator. + Results is configured in the Relying Party by the Relying Party + Owner, and/or is programmed into the Relying Party. 4.1. Appraisal Policies The Verifier, when appraising Evidence, or the Relying Party, when appraising Attestation Results, checks the values of some claims against constraints specified in its Appraisal Policy. Such constraints might involve a comparison for equality against a reference value, or a check for being in a range bounded by reference values, or membership in a set of reference values, or a check against values in other claims, or any other test. @@ -405,32 +437,34 @@ An Attester consists of at least one Attesting Environment and at least one Target Environment. In some implementations, the Attesting and Target Environments might be combined. Other implementations might have multiple Attesting and Target Environments, such as in the examples described in more detail in Section 4.3 and Section 4.4. Other examples may exist, and the examples discussed could even be combined into even more complex implementations. Claims are collected from Target Environments, as shown in Figure 2. - That is, Attesting Environments collect the raw values and the - information to be represented in claims, such as by doing some - measurement of a Target Environment's code, memory, and/or registers. - Attesting Environments then format the claims appropriately, and - typically use key material and cryptographic functions, such as - signing or cipher algorithms, to create Evidence. Places that - Attesting Environments can exist include Trusted Execution - Environments (TEE), embedded Secure Elements (eSE), and BIOS - firmware. An execution environment may not, by default, be capable - of claims collection for a given Target Environment. Execution - environments that are designed to be capable of claims collection are - referred to in this document as Attesting Environments. + That is, Attesting Environments collect the values and the + information to be represented in Claims, by reading system registers + and variables, calling into subsystems, taking measurements on code + or memory and so on of the Target Environment. Attesting + Environments then format the claims appropriately, and typically use + key material and cryptographic functions, such as signing or cipher + algorithms, to create Evidence. There is no limit to or requirement + on the places that an Attesting Environment can exist, but they + typically are in Trusted Execution Environments (TEE), embedded + Secure Elements (eSE), and BIOS firmware. An execution environment + may not, by default, be capable of claims collection for a given + Target Environment. Execution environments that are designed to be + capable of claims collection are referred to in this document as + Attesting Environments. .--------------------------------. | | | Verifier | | | '--------------------------------' ^ | .-------------------------|----------. | | | @@ -972,27 +1006,34 @@ 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. 8.3. Attestation Results - Attestation Results may indicate compliance or non-compliance with a - Verifier's Appraisal 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. + Attestation Results are the input used by the Relying Party to decide + the extent to which it will trust a particular Attester, and allow it + to access some data or perform some operation. Attestation Results + may be a Boolean simply indicating compliance or non-compliance with + a Verifier's Appraisal Policy, or a rich set of Claims about the + Attester, against which the Relying Party applies its Appraisal + Policy for Attestation Results. + + 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 Appraisal 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 on such information. @@ -1199,29 +1240,116 @@ Furthermore, because Evidence might contain sensitive 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. 12. Security Considerations +12.1. Attester and Attestation Key Protection + + Implementers need to pay close attention to the isolation and + protection of the Attester and the factory processes for provisioning + the Attestation Key Material. When either of these are compromised, + the remote attestation becomes worthless because the attacker can + forge Evidence. + + Remote attestation applies to use cases with a range of security + requirements, so the protections discussed here range from low to + high security where low security may be only application or process + isolation by the device's operating system and high security involves + specialized hardware to defend against physical attacks on a chip. + +12.1.1. On-Device Attester and Key Protection + + It is assumed that the Attester is located in an isolated environment + of a device like a process, a dedicated chip a TEE or such that + collects the Claims, formats them and signs them with an Attestation + Key. The Attester must be protected from unauthorized modification to + ensure it behaves correctly. There must also be confidentiality so + that the signing key is not captured and used elsewhere to forge + evidence. + + In many cases the user or owner of the device must not be able to + modify or exfiltrate keys from the Attesting Environment of the + Attester. For example the owner or user of a mobile phone or FIDO + authenticator is not trusted. The point of remote attestation is for + the Relying Party to be able to trust the Attester even though they + don't trust the user or owner. + + Some of the measures for low level security include process or + application isolation by a high-level operating system, and perhaps + restricting access to root or system privilege. For extremely simple + single-use devices that don't use a protected mode operating system, + like a Bluetooth speaker, the isolation might only be the plastic + housing for the device. + + At medium level security, a special restricted operating environment + like a Trusted Execution Environment (TEE) might be used. In this + case, only security-oriented software has access to the Attester and + key material. + + For high level security, specialized hardware will likely be used + providing 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 that establishes the signing key material on the + device and the verification key material off the device. Sometimes + this is referred to as "personalization". + + One way to provision a key is to first generate it external to the + device and then copy the key onto the device. In this case, + confidentiality of the generator, as well as the path over which the + key is provisioned, is necessary. This can be achieved in a number + of ways. + + Confidentiality can be achieved entirely with physical provisioning + facility security involving no encryption at all. For low-security + use cases, this might be simply locking doors and limiting personnel + that can enter the facility. For high-security use cases, this might + involve a special area of the facility accessible only to select + security-trained personnel. + + Cryptography can also be used to support confidentiality, but keys + that are used to then provision attestation keys must somehow have + been provisioned securely beforehand (a recursive problem). + + In many cases both some physical security and some cryptography will + be necessary and useful to establish confidentiality. + + Another way to provision the key material is to generate it on the + device and export the verification key. If public key cryptography + is being used, then only integrity is necessary. Confidentiality is + not necessary. + + In all cases, the Attestation Key provisioning process must ensure + that only attestation key material that is generated by a valid + Endorser is established in Attesters and then configured correctly. + For many use cases, this will involve physical security at the + facility, to prevent unauthorized devices from being manufactured + that may be counterfeit or incorrectly configured. + +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: * end-to-end encryption, - * denial of service protection, * authentication, * auditing, * fine grained access controls, and * logging. @@ -1270,310 +1398,419 @@ Model. 16. Appendix A: Time Considerations The table below defines a number of relevant events, with an ID that is used in subsequent diagrams. The times of said events might be defined in terms of an absolute clock time such as Coordinated Universal Time, or might be defined relative to some other timestamp or timeticks counter. - +====+==============+===============================================+ + +====+==============+=============================================+ | ID | Event | Explanation of event | - +====+==============+===============================================+ - | VG | Value | A value to appear in a Claim was | - | | generation | created. | - +----+--------------+-----------------------------------------------+ - | AA | Attester | An Attesting Environment starts to | - | | awareness | be aware of a new/changed Claim | - | | | value. | - +----+--------------+-----------------------------------------------+ - | HD | Handle | A centrally generated identifier for | - | | distribution | time-bound recentness across a | - | | | domain of devices is successfully | - | | | distributed to Attesters. | - +----+--------------+-----------------------------------------------+ - | NS | Nonce sent | A nonce not predictable to an | - | | | Attester (recentness & uniqueness) | - | | | is sent to an Attester. | - +----+--------------+-----------------------------------------------+ + +====+==============+=============================================+ + | VG | Value | A value to appear in a Claim was created. | + | | generated | In some cases, a value may have technically | + | | | existed before an Attester became aware of | + | | | it but the Attester might have no idea how | + | | | long it has had that value. In such a | + | | | case, the Value created time is the time at | + | | | which the Claim containing the copy of the | + | | | value was created. | + +----+--------------+---------------------------------------------+ + | HD | Handle | A centrally generated identifier for time- | + | | distribution | bound recentness across a domain of devices | + | | | is successfully distributed to Attesters. | + +----+--------------+---------------------------------------------+ + | NS | Nonce sent | A nonce not predictable to an Attester | + | | | (recentness & uniqueness) is sent to an | + | | | Attester. | + +----+--------------+---------------------------------------------+ | NR | Nonce | A nonce is relayed to an Attester by | | | relayed | another entity. | - +----+--------------+-----------------------------------------------+ - | EG | Evidence | An Attester creates Evidence from | - | | generation | collected Claims. | - +----+--------------+-----------------------------------------------+ + +----+--------------+---------------------------------------------+ + | HR | Handle | A handle distributed by a Handle | + | | received | Distributor was received. | + +----+--------------+---------------------------------------------+ + | EG | Evidence | An Attester creates Evidence from collected | + | | generation | Claims. | + +----+--------------+---------------------------------------------+ | ER | Evidence | A Relying Party relays Evidence to a | | | relayed | Verifier. | - +----+--------------+-----------------------------------------------+ - | RG | Result | A Verifier appraises Evidence and | - | | generation | generates an Attestation Result. | - +----+--------------+-----------------------------------------------+ - | RR | Result | A Relying Party relays an | - | | relayed | Attestation Result to a Relying | - | | | Party. | - +----+--------------+-----------------------------------------------+ - | RA | Result | The Relying Party appraises | - | | appraised | Attestation Results. | - +----+--------------+-----------------------------------------------+ - | OP | Operation | The Relying Party performs some | - | | performed | operation requested by the Attester. | - | | | For example, acting upon some | - | | | message just received across a | - | | | session created earlier at time(RA). | - +----+--------------+-----------------------------------------------+ - | RX | Result | An Attestation Result should no | - | | expiry | longer be accepted, according to the | - | | | Verifier that generated it. | - +----+--------------+-----------------------------------------------+ + +----+--------------+---------------------------------------------+ + | RG | Result | A Verifier appraises Evidence and generates | + | | generation | an Attestation Result. | + +----+--------------+---------------------------------------------+ + | RR | Result | A Relying Party relays an Attestation | + | | relayed | Result to a Relying Party. | + +----+--------------+---------------------------------------------+ + | RA | Result | The Relying Party appraises Attestation | + | | appraised | Results. | + +----+--------------+---------------------------------------------+ + | OP | Operation | The Relying Party performs some operation | + | | performed | requested by the Attester. For example, | + | | | acting upon some message just received | + | | | across a session created earlier at | + | | | time(RA). | + +----+--------------+---------------------------------------------+ + | RX | Result | An Attestation Result should no longer be | + | | expiry | accepted, according to the Verifier that | + | | | generated it. | + +----+--------------+---------------------------------------------+ Table 1 Using the table above, a number of hypothetical examples of how a solution might be built are illustrated below. a solution might be built. This list is not intended to be complete, but is just representative enough to highlight various timing considerations. + All times are relative to the local clocks, indicated by an "a" + (Attester), "v" (Verifier), or "r" (Relying Party) suffix. + + How and if clocks are synchronized depends upon the model. + 16.1. Example 1: Timestamp-based Passport Model Example The following example illustrates a hypothetical Passport Model solution that uses timestamps and requires roughly synchronized clocks between the Attester, Verifier, and Relying Party, which - depends on using a secure clock synchronization mechanism. + depends on using a secure clock synchronization mechanism. As a + result, the receiver of a conceptual message containing a timestamp + can directly compare it to its own clock and timestamps. .----------. .----------. .---------------. | Attester | | Verifier | | Relying Party | '----------' '----------' '---------------' - time(VG) | | + time(VG_a) | | | | | ~ ~ ~ | | | - time(EG) | | - |------Evidence{time(EG)}-------->| | - | time(RG) | + time(EG_a) | | + |------Evidence{time(EG_a)}------>| | + | time(RG_v) | |<-----Attestation Result---------| | - | {time(RG),time(RX)} | | + | {time(RG_v),time(RX_v)} | | ~ ~ | | - |------Attestation Result{time(RG),time(RX)}-->time(RA) + |----Attestation Result{time(RG_v),time(RX_v)}-->time(RA_r) | | ~ ~ | | - | time(OP) + | time(OP_r) | | The Verifier can check whether the Evidence is fresh when appraising - it at time(RG) by checking "time(RG) - time(EG) < Threshold", where - the Verifier's threshold is large enough to account for the maximum - permitted clock skew between the Verifier and the Attester. + it at time(RG_v) by checking "time(RG_v) - time(EG_a) < Threshold", + where the Verifier's threshold is large enough to account for the + maximum permitted clock skew between the Verifier and the Attester. - If time(VG) is also included in the Evidence along with the claim + If time(VG_a) is also included in the Evidence along with the claim value generated at that time, and the Verifier decides that it can - trust the time(VG) value, the Verifier can also determine whether the - claim value is recent by checking "time(RG) - time(VG) < Threshold", - again where the threshold is large enough to account for the maximum - permitted clock skew between the Verifier and the Attester. + trust the time(VG_a) value, the Verifier can also determine whether + the claim value is recent by checking "time(RG_v) - time(VG_a) < + Threshold", again where the threshold is large enough to account for + the maximum permitted clock skew between the Verifier and the + Attester. The Relying Party can check whether the Attestation Result is fresh - when appraising it at time(RA) by checking "time(RA) - time(RG) < - Threshold", where the Relying Party's threshold is large enough to + when appraising it at time(RA_r) by checking "time(RA_r) - time(RG_v) + < Threshold", where the Relying Party's threshold is large enough to account for the maximum permitted clock skew between the Relying Party and the Verifier. The result might then be used for some time (e.g., throughout the lifetime of a connection established at - time(RA)). The Relying Party must be careful, however, to not allow - continued use beyond the period for which it deems the Attestation - Result to remain fresh enough. Thus, it might allow use (at - time(OP)) as long as "time(OP) - time(RG) < Threshold". However, if - the Attestation Result contains an expiry time time(RX) then it could - explicitly check "time(OP) < time(RX)". + time(RA_r)). The Relying Party must be careful, however, to not + allow continued use beyond the period for which it deems the + Attestation Result to remain fresh enough. Thus, it might allow use + (at time(OP_r)) as long as "time(OP_r) - time(RG_v) < Threshold". + However, if the Attestation Result contains an expiry time time(RX_v) + then it could explicitly check "time(OP_r) < time(RX_v)". 16.2. Example 2: Nonce-based Passport Model Example The following example illustrates a hypothetical Passport Model solution that uses nonces and thus does not require that any clocks are synchronized. + As a result, the receiver of a conceptual message containing a + timestamp cannot directly compare it to its own clock or timestamps. + Thus we use a suffix ("a" for Attester, "v" for Verifier, and "r" for + Relying Party) on the IDs below indicating which clock generated + them, since times from different clocks cannot be compared. Only the + delta between two events from the sender can be used by the receiver. + .----------. .----------. .---------------. | Attester | | Verifier | | Relying Party | '----------' '----------' '---------------' - time(VG) | | + time(VG_a) | | | | | ~ ~ ~ | | | - |<---Nonce1--------------------time(NS) | - time(EG) | | - |----Evidence-------------------->| | - | {Nonce1, time(EG)-time(VG)} | | - | time(RG) | - |<---Attestation Result-----------| | - | {time(RX)-time(RG)} | | + |<--Nonce1---------------------time(NS_v) | + time(EG_a) | | + |---Evidence--------------------->| | + | {Nonce1, time(EG_a)-time(VG_a)} | | + | time(RG_v) | + |<--Attestation Result------------| | + | {time(RX_v)-time(RG_v)} | | ~ ~ | | - |<---Nonce2------------------------------------time(NS') - time(RR) - |----Attestation Result{time(RX)-time(RG)}---->time(RA) - | Nonce2, time(RR)-time(EG) | + |<--Nonce2-------------------------------------time(NS_r) + time(RRa) + |---Attestation Result{time(RX_v)-time(RG_v)}->time(RA_r) + | Nonce2, time(RR_a)-time(EG_a) | ~ ~ | | - | time(OP) + | time(OP_r) In this example solution, the Verifier can check whether the Evidence - is fresh at time(RG) by verifying that "time(RG) - time(NS) < + is fresh at "time(RG_v)" by verifying that "time(RG_v)-time(NS_v) < Threshold". The Verifier cannot, however, simply rely on a Nonce to determine whether the value of a claim is recent, since the claim value might have been generated long before the nonce was sent by the Verifier. However, if the Verifier decides that the Attester can be trusted to - correctly provide the delta time(EG)-time(VG), then it can determine - recency by checking "time(RG)-time(NS) + time(EG)-time(VG) < - Threshold". + correctly provide the delta "time(EG_a)-time(VG_a)", then it can + determine recency by checking "time(RG_v)-time(NS_v) + time(EG_a)- + time(VG_a) < Threshold". Similarly if, based on an Attestation Result from a Verifier it trusts, the Relying Party decides that the Attester can be trusted to correctly provide time deltas, then it can determine whether the - Attestation Result is fresh by checking "time(OP) - time(NS') + - time(RR)-time(EG) < Threshold". Although the Nonce2 and time(RR)- - time(EG) values cannot be inside the Attestation Result, they might - be signed by the Attester such that the Attestation Result vouches - for the Attester's signing capability. + Attestation Result is fresh by checking "time(OP_r)-time(NS_r) + + time(RR_a)-time(EG_a) < Threshold". Although the Nonce2 and + "time(RR_a)-time(EG_a)" values cannot be inside the Attestation + Result, they might be signed by the Attester such that the + Attestation Result vouches for the Attester's signing capability. The Relying Party must still be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain valid. Thus, if the Attestation Result sends a - validity lifetime in terms of time(RX)-time(RG), then the Relying - Party can check "time(OP) - time(NS') < time(RX)-time(RG)". + validity lifetime in terms of "time(RX_v)-time(RG_v)", then the + Relying Party can check "time(OP_r)-time(NS_r) < time(RX_v)- + time(RG_v)". -16.3. Example 3: Timestamp-based Background-Check Model Example +16.3. Example 3: Handle-based Passport Model Example + + Handles are a third option to establish time-keeping next to nonces + or timestamps. Handles are opaque data intended to be available to + all RATS roles that interact with each other, such as the Attester or + Verifier, in specified intervals. To enable this availability, + handles are distributed centrally by the Handle Distributor role over + the network. As any other role, the Handle Distributor role can be + taken on by a dedicated entity or collapsed with other roles, such as + a Verifier. The use of handles can compensate for a lack of clocks + or other sources of time on entities taking on RATS roles. The only + entity that requires access to a source of time is the entity taking + on the role of Handle Distributor. + + Handles are different from nonces as they can be used more than once + and can be used by more than one entity at the same time. Handles + are different from timestamps as they do not have to convey + information about a point in time, but their reception creates that + information. The reception of a handle is similar to the event that + increments a relative tickcounter. Receipt of a new handle + invalidates a previously received handle. + + In this example, Evidence generation based on received handles always + uses the current (most recent) handle. As handles are distributed + over the network, all involved entities receive a fresh handle at + roughly the same time. Due to distribution over the network, there + is some jitter with respect to the time the Handle is received, + time(HR), for each involved entity. To compensate for this jitter, + there is a small period of overlap (a specified offset) in which both + a current handle and corresponding former handle are valid in + Evidence appraisal: "validity-duration = time(HR'_v) + offset - + time(HR_v)". The offset is typically based on a network's round trip + time. Analogously, the generation of valid Evidence is only + possible, if the age of the handle used is lower than the validity- + duration: "time(HR_v) - time(EG_a) < validity-duration". + + From the point of view of a Verifier, the generation of valid + Evidence is only possible, if the age of the handle used in the + Evidence generation is younger than the duration of the distribution + interval - "(time(HR'_v)-time(HR_v)) - (time(HR_a)-time(EG_a)) < + validity-duration". + + Due to the validity-duration of handles, multiple different pieces of + Evidence can be generated based on the same handle. The resulting + granularity (time resolution) of Evidence freshness is typically + lower than the resolution of clock-based tickcounters. + + The following example illustrates a hypothetical Background-Check + Model solution that uses handles and requires a trustworthy time + source available to the Handle Distributor role. + + .-------------. + .----------. | Handle | .----------. .---------------. + | Attester | | Distributor | | Verifier | | Relying Party | + '----------' '-------------' '----------' '---------------' + time(VG_a) | | | + | | | | + ~ ~ ~ ~ + | | | | + time(HR_a)<---------+-------------time(HR_v)------>time(HR_r) + | | | | + time(EG_a) | | | + |----Evidence{time(EG_a)}-------->| | + | {Handle1,time(EG_a)-time(VG_a)}| | + | | time(RG_v) | + |<-----Attestation Result---------| | + | {time(RG_v),time(RX_v)} | | + | | | + ~ ~ ~ + | | | + time(HR_a')<--------'---------------------------->time(HR_r') + | | + time(RR_a) / + |--Attestation Result{time(RX_v)-time(RG_v)}-->time(RA_r) + | {Handle2, time(RR_a)-time(EG_a)} | + ~ ~ + | | + | time(OP_r) + | | + +16.4. Example 4: Timestamp-based Background-Check Model Example The following example illustrates a hypothetical Background-Check Model solution that uses timestamps and requires roughly synchronized clocks between the Attester, Verifier, and Relying Party. .----------. .---------------. .----------. | Attester | | Relying Party | | Verifier | '----------' '---------------' '----------' - time(VG) | | + time(VG_a) | | | | | ~ ~ ~ | | | - time(EG) | | + time(EG_a) | | |----Evidence------->| | - | {time(EG)} time(ER)--Evidence{time(EG)}-->| - | | time(RG) - | time(RA)<-Attestation Result---| - | | {time(RX)} | + | {time(EG_a)} time(ER_r)--Evidence{time(EG_a)}->| + | | time(RG_v) + | time(RA_r)<-Attestation Result---| + | | {time(RX_v)} | ~ ~ ~ | | | - | time(OP) | + | time(OP_r) | The time considerations in this example are equivalent to those discussed under Example 1 above. -16.4. Example 4: Nonce-based Background-Check Model Example +16.5. Example 5: Nonce-based Background-Check Model Example The following example illustrates a hypothetical Background-Check Model solution that uses nonces and thus does not require that any clocks are synchronized. In this example solution, a nonce is generated by a Verifier at the request of a Relying Party, when the Relying Party needs to send one to an Attester. .----------. .---------------. .----------. | Attester | | Relying Party | | Verifier | '----------' '---------------' '----------' - time(VG) | | + time(VG_a) | | | | | ~ ~ ~ | | | - | |<-----Nonce-------------time(NS) - |<---Nonce-----------time(NR) | - time(EG) | | + | |<-------Nonce-----------time(NS_v) + |<---Nonce-----------time(NR_r) | + time(EG_a) | | |----Evidence{Nonce}--->| | - | time(ER)--Evidence{Nonce}----->| - | | time(RG) - | time(RA)<-Attestation Result---| - | | {time(RX)-time(RG)} | + | time(ER_r)--Evidence{Nonce}--->| + | | time(RG_v) + | time(RA_r)<-Attestation Result-| + | | {time(RX_v)-time(RG_v)} | ~ ~ ~ | | | - | time(OP) | + | time(OP_r) | The Verifier can check whether the Evidence is fresh, and whether a claim value is recent, the same as in Example 2 above. However, unlike in Example 2, the Relying Party can use the Nonce to determine whether the Attestation Result is fresh, by verifying that - "time(OP) - time(NR) < Threshold". + "time(OP_r)-time(NR_r) < Threshold". The Relying Party must still be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain valid. Thus, if the Attestation Result sends a - validity lifetime in terms of time(RX)-time(RG), then the Relying - Party can check "time(OP) - time(ER) < time(RX)-time(RG)". + validity lifetime in terms of "time(RX_v)-time(RG_v)", then the + Relying Party can check "time(OP_r)-time(ER_r) < time(RX_v)- + time(RG_v)". 17. References 17.1. Normative References [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, . 17.2. Informative References - [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", - FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, - . - - [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource- - Oriented Lightweight Information Exchange (ROLIE)", - RFC 8322, DOI 10.17487/RFC8322, February 2018, - . - - [OPCUA] OPC Foundation, "OPC Unified Architecture Specification, - Part 2: Security Model, Release 1.03", OPC 10000-2 , 25 - November 2015, . + [CTAP] FIDO Alliance, "Client to Authenticator Protocol", n.d., + . [I-D.birkholz-rats-tuda] Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, "Time-Based Uni-Directional Attestation", Work in - Progress, Internet-Draft, draft-birkholz-rats-tuda-02, 9 - March 2020, . + Progress, Internet-Draft, draft-birkholz-rats-tuda-03, 13 + July 2020, . [I-D.ietf-teep-architecture] Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, "Trusted Execution Environment Provisioning (TEEP) Architecture", Work in Progress, Internet-Draft, draft- - ietf-teep-architecture-11, 2 July 2020, + ietf-teep-architecture-12, 13 July 2020, . + architecture-12.txt>. + + [OPCUA] OPC Foundation, "OPC Unified Architecture Specification, + Part 2: Security Model, Release 1.03", OPC 10000-2 , 25 + November 2015, . + + [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", + FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, + . + + [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource- + Oriented Lightweight Information Exchange (ROLIE)", + RFC 8322, DOI 10.17487/RFC8322, February 2018, + . [TCGarch] Trusted Computing Group, "Trusted Platform Module Library - - Part 1: Architecture", 7 July 2020, + - Part 1: Architecture", n.d., . + [WebAuthN] W3C, "Web Authentication: An API for accessing Public Key + Credentials", n.d., . + Authors' Addresses Henk Birkholz Fraunhofer SIT Rheinstrasse 75 64295 Darmstadt Germany Email: henk.birkholz@sit.fraunhofer.de + Dave Thaler Microsoft United States of America Email: dthaler@microsoft.com Michael Richardson Sandelman Software Works Canada