--- 1/draft-ietf-rats-architecture-12.txt 2021-11-08 07:14:09.216292322 -0800 +++ 2/draft-ietf-rats-architecture-13.txt 2021-11-08 07:14:09.320294932 -0800 @@ -1,25 +1,25 @@ RATS Working Group H. Birkholz Internet-Draft Fraunhofer SIT Intended status: Informational D. Thaler -Expires: 25 October 2021 Microsoft +Expires: 12 May 2022 Microsoft M. Richardson Sandelman Software Works N. Smith Intel W. Pan Huawei Technologies - 23 April 2021 + 8 November 2021 Remote Attestation Procedures Architecture - draft-ietf-rats-architecture-12 + draft-ietf-rats-architecture-13 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,21 +43,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 25 October 2021. + This Internet-Draft will expire on 12 May 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 @@ -71,23 +71,24 @@ 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. Layered Attestation Environments . . . . . . . . . . . . 12 - 3.2. Composite Device . . . . . . . . . . . . . . . . . . . . 14 - 3.3. Implementation Considerations . . . . . . . . . . . . . . 16 + 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 @@ -402,28 +403,30 @@ authorization decisions. This procedure is called the appraisal of Attestation Results. The Appraisal Policy for Attestation Results might be obtained from the Relying Party Owner via some protocol mechanism, or might be configured into the Relying Party by the Relying Party Owner, or might be programmed into the Relying Party, or might be obtained via some other mechanism. See Section 8 for further discussion of the conceptual messages shown - in Figure 1. ## Two Types of Environments of an Attester + in Figure 1. + +3.1. Two Types of Environments of an Attester As shown in Figure 2, 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 3.1 and Section 3.2. Other examples may exist. All + in Section 3.2 and Section 3.3. Other examples may exist. All compositions of Attesting and Target Environments discussed in this architecture can be combined into more complex implementations. .--------------------------------. | | | Verifier | | | '--------------------------------' ^ | @@ -466,21 +469,21 @@ An arbitrary execution environment may not, by default, be capable of Claims collection for a given Target Environment. Execution environments that are designed specifically to be capable of Claims collection are referred to in this document as Attesting Environments. For example, a TPM doesn't actively collect Claims itself, it instead requires another component to feed various values to the TPM. Thus, an Attesting Environment in such a case would be the combination of the TPM together with whatever component is feeding it the measurements. -3.1. Layered Attestation Environments +3.2. Layered Attestation Environments By definition, the Attester role generates Evidence. An Attester may consist of one or more nested environments (layers). The root layer of an Attester includes at least one root of trust. In order to appraise Evidence generated by an Attester, the Verifier needs to trust the Attester's root of trust. Trust in the Attester's root of trust can be established in various ways as discussed in Section 7.4. In layered attestation, a root of trust is the initial Attesting Environment. Claims can be collected from or about each layer. The @@ -568,21 +571,21 @@ Evidence pertaining to that application. The essence of this example is a cascade of staged environments. Each environment has the responsibility of measuring the next environment before the next environment is started. In general, the number of layers may vary by device or implementation, and an Attesting Environment might even have multiple Target Environments that it measures, rather than only one as shown by example in Figure 3. -3.2. Composite Device +3.3. Composite Device A composite device is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by the appraisal of all these sub-entities. Each sub-entity has at least one Attesting Environment collecting the Claims from at least one Target Environment, then this sub-entity generates Evidence about its trustworthiness. Therefore, each sub- entity can be called an Attester. Among all the Attesters, there may be only some which have the ability to communicate with the Verifier @@ -650,21 +653,21 @@ Attesters and conveys it to a Verifier. Collection of Evidence from sub-entities may itself be a form of Claims collection that results in Evidence asserted by the lead Attester. The lead Attester generates Evidence about the layout of the whole composite device, while sub-Attesters generate Evidence about their respective (sub-)modules. In this scenario, the trust model described in Section 7 can also be applied to an inside Verifier. -3.3. Implementation Considerations +3.4. Implementation Considerations An entity can take on multiple RATS roles (e.g., Attester, Verifier, Relying Party, etc.) at the same time. Multiple entities can cooperate to implement a single RATS role as well. In essence, the combination of roles and entities can be arbitrary. For example, in the composite device scenario, the entity inside the lead Attester can also take on the role of a Verifier, and the outer entity of Verifier can take on the role of a Relying Party. After collecting the Evidence of other Attesters, this inside Verifier uses Endorsements and appraisal policies (obtained the same way as by any @@ -1534,23 +1537,23 @@ 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 via signing the conceptual messages is - omitted or unavailable, the protecting protocols that convey Evidence - or Attestation Results are responsible for detailing what kinds of + 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. 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. @@ -1891,44 +1894,44 @@ | {time(RG_v),time(RX_v)} | | ~ ~ | | |----Attestation Result{time(RG_v),time(RX_v)}-->time(RA_r) | | ~ ~ | | | time(OP_r) The Verifier can check whether the Evidence is fresh when appraising - it at time(RG_v) by checking "time(RG_v) - time(EG_a) < Threshold", + 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_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_a) value, the Verifier can also determine whether - the Claim value is recent by checking "time(RG_v) - time(VG_a) < - Threshold". The threshold is decided by the Appraisal Policy for + the Claim value is recent by checking time(RG_v) - time(VG_a) < + Threshold. The threshold is decided by the Appraisal Policy for Evidence, and again needs to take into account 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_r) by checking "time(RA_r) - time(RG_v) - < 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_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". + (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)". + 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 instead of timestamps. Compared to the timestamp-based example, it requires an extra round trip to retrieve a nonce, and requires that the Verifier and Relying Party track state to remember the nonce for some period of time. The advantage is that it does not require that any clocks are @@ -1958,81 +1961,80 @@ | | |<--Nonce2-------------------------------------time(NS_r) time(RR_a) | |--[Attestation Result{time(RX_v)-time(RG_v)}, -->|time(RA_r) | Nonce2, time(RR_a)-time(EG_a)] | ~ ~ | | | time(OP_r) In this example solution, the Verifier can check whether the Evidence - is fresh at "time(RG_v)" by verifying that "time(RG_v)-time(NS_v) < - Threshold". + 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_a)-time(VG_a)", then it can - determine recency by checking "time(RG_v)-time(NS_v) + time(EG_a)- - time(VG_a) < 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_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. + 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_v)-time(RG_v)", then the - Relying Party can check "time(OP_r)-time(NS_r) < time(RX_v)- - time(RG_v)". + 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: Epoch ID-based Passport Model Example The example in Figure 10 illustrates a hypothetical Passport Model solution that uses epoch IDs instead of nonces or timestamps. - The Epoch ID Distributor broadcasts epoch ID "I" which starts a new - epoch "E" for a protocol participant upon reception at "time(IR)". + The Epoch ID Distributor broadcasts epoch ID I which starts a new + epoch E for a protocol participant upon reception at time(IR). - The Attester generates Evidence incorporating epoch ID "I" and - conveys it to the Verifier. + The Attester generates Evidence incorporating epoch ID I and conveys + it to the Verifier. - The Verifier appraises that the received epoch ID "I" is "fresh" + The Verifier appraises that the received epoch ID I is "fresh" according to the definition provided in Section 10.3 whereby retries are required in the case of mismatching epoch IDs, and generates an Attestation Result. The Attestation Result is conveyed to the Attester. - After the transmission of epoch ID "I'" a new epoch "E'" is - established when "I'" is received by each protocol participant. The - Attester relays the Attestation Result obtained during epoch "E" - (associated with epoch ID "I") to the Relying Party using the epoch - ID for the current epoch "I'". If the Relying Party had not yet - received "I'", then the Attestation Result would be rejected, but in - this example, it is received. + After the transmission of epoch ID I' a new epoch E' is established + when I' is received by each protocol participant. The Attester + relays the Attestation Result obtained during epoch E (associated + with epoch ID I) to the Relying Party using the epoch ID for the + current epoch I'. If the Relying Party had not yet received I', then + the Attestation Result would be rejected, but in this example, it is + received. In the illustrated scenario, the epoch ID for relaying an Attestation Result to the Relying Party is current, while a previous epoch ID was used to generate Verifier evaluated evidence. This indicates that at least one epoch transition has occurred, and the Attestation Results may only be as fresh as the previous epoch. If the Relying Party - remembers the previous epoch ID "I" during an epoch window as - discussed in Section 10.3, and the message is received during that - window, the Attestation Result is accepted as fresh, and otherwise it - is rejected as stale. + remembers the previous epoch ID I during an epoch window as discussed + in Section 10.3, and the message is received during that window, the + Attestation Result is accepted as fresh, and otherwise it is rejected + as stale. .-------------. .----------. | Epoch ID | .----------. .---------------. | Attester | | Distributor | | Verifier | | Relying Party | '----------' '-------------' '----------' '---------------' time(VG_a) | | | | | | | ~ ~ ~ ~ | | | | time(IR_a)<------I--+--I--------time(IR_v)----->time(IR_r) @@ -2107,111 +2109,111 @@ | | {time(RX_v)-time(RG_v)} | ~ ~ ~ | | | | 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_r)-time(NR_r) < 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_v)-time(RG_v)", then the - Relying Party can check "time(OP_r)-time(ER_r) < time(RX_v)- - time(RG_v)". + 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 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, - . + . [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, . + May 2018, . 17.2. Informative References [CCC-DeepDive] Confidential Computing Consortium, "Confidential Computing Deep Dive", n.d., . [CTAP] FIDO Alliance, "Client to Authenticator Protocol", n.d., . [I-D.birkholz-rats-tuda] Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann, "Time-Based Uni-Directional Attestation", Work in - Progress, Internet-Draft, draft-birkholz-rats-tuda-04, 13 - January 2021, - . + Progress, Internet-Draft, draft-birkholz-rats-tuda-05, 12 + July 2021, . [I-D.birkholz-rats-uccs] Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C. Bormann, "A CBOR Tag for Unprotected CWT Claims Sets", Work in Progress, Internet-Draft, draft-birkholz-rats- - uccs-03, 8 March 2021, - . + uccs-03, 8 March 2021, . [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-14, 22 February 2021, - . + ietf-teep-architecture-15, 12 July 2021, + . [I-D.tschofenig-tls-cwt] Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens (CWTs) in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Work in Progress, 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, . [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 Requirements", RFC 6024, DOI 10.17487/RFC6024, October - 2010, . + 2010, . [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource- Oriented Lightweight Information Exchange (ROLIE)", RFC 8322, DOI 10.17487/RFC8322, February 2018, - . + . [strengthoffunction] NISC, "Strength of Function", n.d., . [TCG-DICE] Trusted Computing Group, "DICE Certificate Profiles", n.d., .