draft-ietf-rats-architecture-12.txt   draft-ietf-rats-architecture-13.txt 
RATS Working Group H. Birkholz RATS Working Group H. Birkholz
Internet-Draft Fraunhofer SIT Internet-Draft Fraunhofer SIT
Intended status: Informational D. Thaler Intended status: Informational D. Thaler
Expires: 25 October 2021 Microsoft Expires: 12 May 2022 Microsoft
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
N. Smith N. Smith
Intel Intel
W. Pan W. Pan
Huawei Technologies Huawei Technologies
23 April 2021 8 November 2021
Remote Attestation Procedures Architecture Remote Attestation Procedures Architecture
draft-ietf-rats-architecture-12 draft-ietf-rats-architecture-13
Abstract Abstract
In network protocol exchanges it is often useful for one end of a In network protocol exchanges it is often useful for one end of a
communication to know whether the other end is in an intended communication to know whether the other end is in an intended
operating state. This document provides an architectural overview of operating state. This document provides an architectural overview of
the entities involved that make such tests possible through the the entities involved that make such tests possible through the
process of generating, conveying, and evaluating evidentiary claims. process of generating, conveying, and evaluating evidentiary claims.
An attempt is made to provide for a model that is neutral toward An attempt is made to provide for a model that is neutral toward
processor architectures, the content of claims, and protocols. processor architectures, the content of claims, and protocols.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 38 skipping to change at page 2, line 38
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Reference Use Cases . . . . . . . . . . . . . . . . . . . . . 5 2. Reference Use Cases . . . . . . . . . . . . . . . . . . . . . 5
2.1. Network Endpoint Assessment . . . . . . . . . . . . . . . 5 2.1. Network Endpoint Assessment . . . . . . . . . . . . . . . 5
2.2. Confidential Machine Learning Model Protection . . . . . 5 2.2. Confidential Machine Learning Model Protection . . . . . 5
2.3. Confidential Data Protection . . . . . . . . . . . . . . 6 2.3. Confidential Data Protection . . . . . . . . . . . . . . 6
2.4. Critical Infrastructure Control . . . . . . . . . . . . . 6 2.4. Critical Infrastructure Control . . . . . . . . . . . . . 6
2.5. Trusted Execution Environment Provisioning . . . . . . . 7 2.5. Trusted Execution Environment Provisioning . . . . . . . 7
2.6. Hardware Watchdog . . . . . . . . . . . . . . . . . . . . 7 2.6. Hardware Watchdog . . . . . . . . . . . . . . . . . . . . 7
2.7. FIDO Biometric Authentication . . . . . . . . . . . . . . 7 2.7. FIDO Biometric Authentication . . . . . . . . . . . . . . 7
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 8 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 8
3.1. Layered Attestation Environments . . . . . . . . . . . . 12 3.1. Two Types of Environments of an Attester . . . . . . . . 10
3.2. Composite Device . . . . . . . . . . . . . . . . . . . . 14 3.2. Layered Attestation Environments . . . . . . . . . . . . 12
3.3. Implementation Considerations . . . . . . . . . . . . . . 16 3.3. Composite Device . . . . . . . . . . . . . . . . . . . . 14
3.4. Implementation Considerations . . . . . . . . . . . . . . 16
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Topological Patterns . . . . . . . . . . . . . . . . . . . . 19 5. Topological Patterns . . . . . . . . . . . . . . . . . . . . 19
5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 20 5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 20
5.2. Background-Check Model . . . . . . . . . . . . . . . . . 21 5.2. Background-Check Model . . . . . . . . . . . . . . . . . 21
5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 22 5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 22
6. Roles and Entities . . . . . . . . . . . . . . . . . . . . . 23 6. Roles and Entities . . . . . . . . . . . . . . . . . . . . . 23
7. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Relying Party . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Relying Party . . . . . . . . . . . . . . . . . . . . . . 24
skipping to change at page 10, line 17 skipping to change at page 10, line 17
authorization decisions. This procedure is called the appraisal of authorization decisions. This procedure is called the appraisal of
Attestation Results. Attestation Results.
The Appraisal Policy for Attestation Results might be obtained from The Appraisal Policy for Attestation Results might be obtained from
the Relying Party Owner via some protocol mechanism, or might be the Relying Party Owner via some protocol mechanism, or might be
configured into the Relying Party by the Relying Party Owner, or configured into the Relying Party by the Relying Party Owner, or
might be programmed into the Relying Party, or might be obtained via might be programmed into the Relying Party, or might be obtained via
some other mechanism. some other mechanism.
See Section 8 for further discussion of the conceptual messages shown 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 As shown in Figure 2, an Attester consists of at least one Attesting
Environment and at least one Target Environment. In some Environment and at least one Target Environment. In some
implementations, the Attesting and Target Environments might be implementations, the Attesting and Target Environments might be
combined. Other implementations might have multiple Attesting and combined. Other implementations might have multiple Attesting and
Target Environments, such as in the examples described in more detail 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 compositions of Attesting and Target Environments discussed in this
architecture can be combined into more complex implementations. architecture can be combined into more complex implementations.
.--------------------------------. .--------------------------------.
| | | |
| Verifier | | Verifier |
| | | |
'--------------------------------' '--------------------------------'
^ ^
| |
skipping to change at page 12, line 9 skipping to change at page 12, line 9
An arbitrary execution environment may not, by default, be capable of An arbitrary execution environment may not, by default, be capable of
Claims collection for a given Target Environment. Execution Claims collection for a given Target Environment. Execution
environments that are designed specifically to be capable of Claims environments that are designed specifically to be capable of Claims
collection are referred to in this document as Attesting collection are referred to in this document as Attesting
Environments. For example, a TPM doesn't actively collect Claims Environments. For example, a TPM doesn't actively collect Claims
itself, it instead requires another component to feed various values itself, it instead requires another component to feed various values
to the TPM. Thus, an Attesting Environment in such a case would be to the TPM. Thus, an Attesting Environment in such a case would be
the combination of the TPM together with whatever component is the combination of the TPM together with whatever component is
feeding it the measurements. feeding it the measurements.
3.1. Layered Attestation Environments 3.2. Layered Attestation Environments
By definition, the Attester role generates Evidence. An Attester may By definition, the Attester role generates Evidence. An Attester may
consist of one or more nested environments (layers). The root layer consist of one or more nested environments (layers). The root layer
of an Attester includes at least one root of trust. In order to of an Attester includes at least one root of trust. In order to
appraise Evidence generated by an Attester, the Verifier needs 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 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. trust can be established in various ways as discussed in Section 7.4.
In layered attestation, a root of trust is the initial Attesting In layered attestation, a root of trust is the initial Attesting
Environment. Claims can be collected from or about each layer. The Environment. Claims can be collected from or about each layer. The
skipping to change at page 14, line 44 skipping to change at page 14, line 44
Evidence pertaining to that application. Evidence pertaining to that application.
The essence of this example is a cascade of staged environments. The essence of this example is a cascade of staged environments.
Each environment has the responsibility of measuring the next Each environment has the responsibility of measuring the next
environment before the next environment is started. In general, the environment before the next environment is started. In general, the
number of layers may vary by device or implementation, and an number of layers may vary by device or implementation, and an
Attesting Environment might even have multiple Target Environments Attesting Environment might even have multiple Target Environments
that it measures, rather than only one as shown by example in that it measures, rather than only one as shown by example in
Figure 3. Figure 3.
3.2. Composite Device 3.3. Composite Device
A composite device is an entity composed of multiple sub-entities A composite device is an entity composed of multiple sub-entities
such that its trustworthiness has to be determined by the appraisal such that its trustworthiness has to be determined by the appraisal
of all these sub-entities. of all these sub-entities.
Each sub-entity has at least one Attesting Environment collecting the Each sub-entity has at least one Attesting Environment collecting the
Claims from at least one Target Environment, then this sub-entity Claims from at least one Target Environment, then this sub-entity
generates Evidence about its trustworthiness. Therefore, each sub- generates Evidence about its trustworthiness. Therefore, each sub-
entity can be called an Attester. Among all the Attesters, there may entity can be called an Attester. Among all the Attesters, there may
be only some which have the ability to communicate with the Verifier be only some which have the ability to communicate with the Verifier
skipping to change at page 16, line 45 skipping to change at page 16, line 45
Attesters and conveys it to a Verifier. Collection of Evidence from Attesters and conveys it to a Verifier. Collection of Evidence from
sub-entities may itself be a form of Claims collection that results sub-entities may itself be a form of Claims collection that results
in Evidence asserted by the lead Attester. The lead Attester in Evidence asserted by the lead Attester. The lead Attester
generates Evidence about the layout of the whole composite device, generates Evidence about the layout of the whole composite device,
while sub-Attesters generate Evidence about their respective while sub-Attesters generate Evidence about their respective
(sub-)modules. (sub-)modules.
In this scenario, the trust model described in Section 7 can also be In this scenario, the trust model described in Section 7 can also be
applied to an inside Verifier. 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, An entity can take on multiple RATS roles (e.g., Attester, Verifier,
Relying Party, etc.) at the same time. Multiple entities can Relying Party, etc.) at the same time. Multiple entities can
cooperate to implement a single RATS role as well. In essence, the cooperate to implement a single RATS role as well. In essence, the
combination of roles and entities can be arbitrary. For example, in combination of roles and entities can be arbitrary. For example, in
the composite device scenario, the entity inside the lead Attester the composite device scenario, the entity inside the lead Attester
can also take on the role of a Verifier, and the outer entity of 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 Verifier can take on the role of a Relying Party. After collecting
the Evidence of other Attesters, this inside Verifier uses the Evidence of other Attesters, this inside Verifier uses
Endorsements and appraisal policies (obtained the same way as by any Endorsements and appraisal policies (obtained the same way as by any
skipping to change at page 35, line 52 skipping to change at page 35, line 52
In some cases, an attacker may be able to make inferences about the In some cases, an attacker may be able to make inferences about the
contents of Evidence from the resulting effects or timing of the contents of Evidence from the resulting effects or timing of the
processing. For example, an attacker might be able to infer the processing. For example, an attacker might be able to infer the
value of specific Claims if it knew that only certain values were value of specific Claims if it knew that only certain values were
accepted by the Relying Party. accepted by the Relying Party.
Evidence and Attestation Results are expected to be integrity Evidence and Attestation Results are expected to be integrity
protected (i.e., either via signing or a secure channel) and protected (i.e., either via signing or a secure channel) and
optionally might be confidentiality protected via encryption. If optionally might be confidentiality protected via encryption. If
confidentiality protection via signing the conceptual messages is confidentiality protection of the conceptual messages is omitted or
omitted or unavailable, the protecting protocols that convey Evidence unavailable, the protecting protocols that convey Evidence or
or Attestation Results are responsible for detailing what kinds of Attestation Results are responsible for detailing what kinds of
information are disclosed, and to whom they are exposed. information are disclosed, and to whom they are exposed.
As Evidence might contain sensitive or confidential information, As Evidence might contain sensitive or confidential information,
Attesters are responsible for only sending such Evidence to trusted Attesters are responsible for only sending such Evidence to trusted
Verifiers. Some Attesters might want a stronger level of assurance Verifiers. Some Attesters might want a stronger level of assurance
of the trustworthiness of a Verifier before sending Evidence to it. 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 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 for the Verifier's own Attestation Result, and appraising it just as
a Relying Party would appraise an Attestation Result for any other a Relying Party would appraise an Attestation Result for any other
purpose. purpose.
skipping to change at page 43, line 39 skipping to change at page 43, line 39
| {time(RG_v),time(RX_v)} | | | {time(RG_v),time(RX_v)} | |
~ ~ ~ ~
| | | |
|----Attestation Result{time(RG_v),time(RX_v)}-->time(RA_r) |----Attestation Result{time(RG_v),time(RX_v)}-->time(RA_r)
| | | |
~ ~ ~ ~
| | | |
| time(OP_r) | time(OP_r)
The Verifier can check whether the Evidence is fresh when appraising 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 where the Verifier's threshold is large enough to account for the
maximum permitted clock skew between the Verifier and the Attester. maximum permitted clock skew between the Verifier and the Attester.
If time(VG_a) 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 value generated at that time, and the Verifier decides that it can
trust the time(VG_a) value, the Verifier can also determine whether 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) < the Claim value is recent by checking time(RG_v) - time(VG_a) <
Threshold". The threshold is decided by the Appraisal Policy for Threshold. The threshold is decided by the Appraisal Policy for
Evidence, and again needs to take into account the maximum permitted Evidence, and again needs to take into account the maximum permitted
clock skew between the Verifier and the Attester. clock skew between the Verifier and the Attester.
The Relying Party can check whether the Attestation Result is fresh 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) 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 < Threshold, where the Relying Party's threshold is large enough to
account for the maximum permitted clock skew between the Relying account for the maximum permitted clock skew between the Relying
Party and the Verifier. The result might then be used for some time Party and the Verifier. The result might then be used for some time
(e.g., throughout the lifetime of a connection established at (e.g., throughout the lifetime of a connection established at
time(RA_r)). The Relying Party must be careful, however, to not time(RA_r)). The Relying Party must be careful, however, to not
allow continued use beyond the period for which it deems the allow continued use beyond the period for which it deems the
Attestation Result to remain fresh enough. Thus, it might allow use 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) 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 16.2. Example 2: Nonce-based Passport Model Example
The following example illustrates a hypothetical Passport Model The following example illustrates a hypothetical Passport Model
solution that uses nonces instead of timestamps. Compared to the solution that uses nonces instead of timestamps. Compared to the
timestamp-based example, it requires an extra round trip to retrieve timestamp-based example, it requires an extra round trip to retrieve
a nonce, and requires that the Verifier and Relying Party track state a nonce, and requires that the Verifier and Relying Party track state
to remember the nonce for some period of time. to remember the nonce for some period of time.
The advantage is that it does not require that any clocks are The advantage is that it does not require that any clocks are
skipping to change at page 45, line 30 skipping to change at page 45, line 30
| | | |
|<--Nonce2-------------------------------------time(NS_r) |<--Nonce2-------------------------------------time(NS_r)
time(RR_a) | time(RR_a) |
|--[Attestation Result{time(RX_v)-time(RG_v)}, -->|time(RA_r) |--[Attestation Result{time(RX_v)-time(RG_v)}, -->|time(RA_r)
| Nonce2, time(RR_a)-time(EG_a)] | | Nonce2, time(RR_a)-time(EG_a)] |
~ ~ ~ ~
| | | |
| time(OP_r) | time(OP_r)
In this example solution, the Verifier can check whether the Evidence 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) < is fresh at time(RG_v) by verifying that time(RG_v)-time(NS_v) <
Threshold". Threshold.
The Verifier cannot, however, simply rely on a Nonce to determine The Verifier cannot, however, simply rely on a Nonce to determine
whether the value of a Claim is recent, since the Claim value might 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. have been generated long before the nonce was sent by the Verifier.
However, if the Verifier decides that the Attester can be trusted to 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 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)- determine recency by checking time(RG_v)-time(NS_v) + time(EG_a)-
time(VG_a) < Threshold". time(VG_a) < Threshold.
Similarly if, based on an Attestation Result from a Verifier it Similarly if, based on an Attestation Result from a Verifier it
trusts, the Relying Party decides that the Attester can be trusted to trusts, the Relying Party decides that the Attester can be trusted to
correctly provide time deltas, then it can determine whether the correctly provide time deltas, then it can determine whether the
Attestation Result is fresh by checking "time(OP_r)-time(NS_r) + 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) < Threshold. Although the Nonce2 and
"time(RR_a)-time(EG_a)" values cannot be inside the Attestation time(RR_a)-time(EG_a) values cannot be inside the Attestation Result,
Result, they might be signed by the Attester such that the they might be signed by the Attester such that the Attestation Result
Attestation Result vouches for the Attester's signing capability. vouches for the Attester's signing capability.
The Relying Party must still be careful, however, to not allow The Relying Party must still be careful, however, to not allow
continued use beyond the period for which it deems the Attestation continued use beyond the period for which it deems the Attestation
Result to remain valid. Thus, if the Attestation Result sends a Result to remain valid. Thus, if the Attestation Result sends a
validity lifetime in terms of "time(RX_v)-time(RG_v)", then the validity lifetime in terms of time(RX_v)-time(RG_v), then the Relying
Relying Party can check "time(OP_r)-time(NS_r) < time(RX_v)- Party can check time(OP_r)-time(NS_r) < time(RX_v)-time(RG_v).
time(RG_v)".
16.3. Example 3: Epoch ID-based Passport Model Example 16.3. Example 3: Epoch ID-based Passport Model Example
The example in Figure 10 illustrates a hypothetical Passport Model The example in Figure 10 illustrates a hypothetical Passport Model
solution that uses epoch IDs instead of nonces or timestamps. solution that uses epoch IDs instead of nonces or timestamps.
The Epoch ID Distributor broadcasts epoch ID "I" which starts a new The Epoch ID Distributor broadcasts epoch ID I which starts a new
epoch "E" for a protocol participant upon reception at "time(IR)". epoch E for a protocol participant upon reception at time(IR).
The Attester generates Evidence incorporating epoch ID "I" and The Attester generates Evidence incorporating epoch ID I and conveys
conveys it to the Verifier. 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 according to the definition provided in Section 10.3 whereby retries
are required in the case of mismatching epoch IDs, and generates an are required in the case of mismatching epoch IDs, and generates an
Attestation Result. The Attestation Result is conveyed to the Attestation Result. The Attestation Result is conveyed to the
Attester. Attester.
After the transmission of epoch ID "I'" a new epoch "E'" is After the transmission of epoch ID I' a new epoch E' is established
established when "I'" is received by each protocol participant. The when I' is received by each protocol participant. The Attester
Attester relays the Attestation Result obtained during epoch "E" relays the Attestation Result obtained during epoch E (associated
(associated with epoch ID "I") to the Relying Party using the epoch with epoch ID I) to the Relying Party using the epoch ID for the
ID for the current epoch "I'". If the Relying Party had not yet current epoch I'. If the Relying Party had not yet received I', then
received "I'", then the Attestation Result would be rejected, but in the Attestation Result would be rejected, but in this example, it is
this example, it is received. received.
In the illustrated scenario, the epoch ID for relaying an Attestation In the illustrated scenario, the epoch ID for relaying an Attestation
Result to the Relying Party is current, while a previous epoch ID was Result to the Relying Party is current, while a previous epoch ID was
used to generate Verifier evaluated evidence. This indicates that at used to generate Verifier evaluated evidence. This indicates that at
least one epoch transition has occurred, and the Attestation Results least one epoch transition has occurred, and the Attestation Results
may only be as fresh as the previous epoch. If the Relying Party may only be as fresh as the previous epoch. If the Relying Party
remembers the previous epoch ID "I" during an epoch window as remembers the previous epoch ID I during an epoch window as discussed
discussed in Section 10.3, and the message is received during that in Section 10.3, and the message is received during that window, the
window, the Attestation Result is accepted as fresh, and otherwise it Attestation Result is accepted as fresh, and otherwise it is rejected
is rejected as stale. as stale.
.-------------. .-------------.
.----------. | Epoch ID | .----------. .---------------. .----------. | Epoch ID | .----------. .---------------.
| Attester | | Distributor | | Verifier | | Relying Party | | Attester | | Distributor | | Verifier | | Relying Party |
'----------' '-------------' '----------' '---------------' '----------' '-------------' '----------' '---------------'
time(VG_a) | | | time(VG_a) | | |
| | | | | | | |
~ ~ ~ ~ ~ ~ ~ ~
| | | | | | | |
time(IR_a)<------I--+--I--------time(IR_v)----->time(IR_r) time(IR_a)<------I--+--I--------time(IR_v)----->time(IR_r)
skipping to change at page 49, line 10 skipping to change at page 49, line 10
| | {time(RX_v)-time(RG_v)} | | | {time(RX_v)-time(RG_v)} |
~ ~ ~ ~ ~ ~
| | | | | |
| time(OP_r) | | time(OP_r) |
The Verifier can check whether the Evidence is fresh, and whether a The Verifier can check whether the Evidence is fresh, and whether a
Claim value is recent, the same as in Example 2 above. Claim value is recent, the same as in Example 2 above.
However, unlike in Example 2, the Relying Party can use the Nonce to However, unlike in Example 2, the Relying Party can use the Nonce to
determine whether the Attestation Result is fresh, by verifying that 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 The Relying Party must still be careful, however, to not allow
continued use beyond the period for which it deems the Attestation continued use beyond the period for which it deems the Attestation
Result to remain valid. Thus, if the Attestation Result sends a Result to remain valid. Thus, if the Attestation Result sends a
validity lifetime in terms of "time(RX_v)-time(RG_v)", then the validity lifetime in terms of time(RX_v)-time(RG_v), then the Relying
Relying Party can check "time(OP_r)-time(ER_r) < time(RX_v)- Party can check time(OP_r)-time(ER_r) < time(RX_v)-time(RG_v).
time(RG_v)".
17. References 17. References
17.1. Normative References 17.1. Normative References
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/rfc/rfc8392>. May 2018, <https://www.rfc-editor.org/info/rfc8392>.
17.2. Informative References 17.2. Informative References
[CCC-DeepDive] [CCC-DeepDive]
Confidential Computing Consortium, "Confidential Computing Confidential Computing Consortium, "Confidential Computing
Deep Dive", n.d., Deep Dive", n.d.,
<https://confidentialcomputing.io/whitepaper-02-latest>. <https://confidentialcomputing.io/whitepaper-02-latest>.
[CTAP] FIDO Alliance, "Client to Authenticator Protocol", n.d., [CTAP] FIDO Alliance, "Client to Authenticator Protocol", n.d.,
<https://fidoalliance.org/specs/fido-v2.0-id-20180227/ <https://fidoalliance.org/specs/fido-v2.0-id-20180227/
fido-client-to-authenticator-protocol-v2.0-id- fido-client-to-authenticator-protocol-v2.0-id-
20180227.html>. 20180227.html>.
[I-D.birkholz-rats-tuda] [I-D.birkholz-rats-tuda]
Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann, Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann,
"Time-Based Uni-Directional Attestation", Work in "Time-Based Uni-Directional Attestation", Work in
Progress, Internet-Draft, draft-birkholz-rats-tuda-04, 13 Progress, Internet-Draft, draft-birkholz-rats-tuda-05, 12
January 2021, July 2021, <https://www.ietf.org/archive/id/draft-
<https://tools.ietf.org/html/draft-birkholz-rats-tuda-04>. birkholz-rats-tuda-05.txt>.
[I-D.birkholz-rats-uccs] [I-D.birkholz-rats-uccs]
Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C. Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C.
Bormann, "A CBOR Tag for Unprotected CWT Claims Sets", Bormann, "A CBOR Tag for Unprotected CWT Claims Sets",
Work in Progress, Internet-Draft, draft-birkholz-rats- Work in Progress, Internet-Draft, draft-birkholz-rats-
uccs-03, 8 March 2021, uccs-03, 8 March 2021, <https://www.ietf.org/archive/id/
<https://tools.ietf.org/html/draft-birkholz-rats-uccs-03>. draft-birkholz-rats-uccs-03.txt>.
[I-D.ietf-teep-architecture] [I-D.ietf-teep-architecture]
Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
"Trusted Execution Environment Provisioning (TEEP) "Trusted Execution Environment Provisioning (TEEP)
Architecture", Work in Progress, Internet-Draft, draft- Architecture", Work in Progress, Internet-Draft, draft-
ietf-teep-architecture-14, 22 February 2021, ietf-teep-architecture-15, 12 July 2021,
<https://tools.ietf.org/html/draft-ietf-teep-architecture- <https://www.ietf.org/archive/id/draft-ietf-teep-
14>. architecture-15.txt>.
[I-D.tschofenig-tls-cwt] [I-D.tschofenig-tls-cwt]
Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens
(CWTs) in Transport Layer Security (TLS) and Datagram (CWTs) in Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS)", Work in Progress, Transport Layer Security (DTLS)", Work in Progress,
Internet-Draft, draft-tschofenig-tls-cwt-02, 13 July 2020, Internet-Draft, draft-tschofenig-tls-cwt-02, 13 July 2020,
<https://tools.ietf.org/html/draft-tschofenig-tls-cwt-02>. <https://www.ietf.org/archive/id/draft-tschofenig-tls-cwt-
02.txt>.
[OPCUA] OPC Foundation, "OPC Unified Architecture Specification, [OPCUA] OPC Foundation, "OPC Unified Architecture Specification,
Part 2: Security Model, Release 1.03", OPC 10000-2 , 25 Part 2: Security Model, Release 1.03", OPC 10000-2 , 25
November 2015, <https://opcfoundation.org/developer-tools/ November 2015, <https://opcfoundation.org/developer-tools/
specifications-unified-architecture/part-2-security- specifications-unified-architecture/part-2-security-
model/>. model/>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/rfc/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
<https://www.rfc-editor.org/rfc/rfc5209>. <https://www.rfc-editor.org/info/rfc5209>.
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
Requirements", RFC 6024, DOI 10.17487/RFC6024, October Requirements", RFC 6024, DOI 10.17487/RFC6024, October
2010, <https://www.rfc-editor.org/rfc/rfc6024>. 2010, <https://www.rfc-editor.org/info/rfc6024>.
[RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource- [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource-
Oriented Lightweight Information Exchange (ROLIE)", Oriented Lightweight Information Exchange (ROLIE)",
RFC 8322, DOI 10.17487/RFC8322, February 2018, RFC 8322, DOI 10.17487/RFC8322, February 2018,
<https://www.rfc-editor.org/rfc/rfc8322>. <https://www.rfc-editor.org/info/rfc8322>.
[strengthoffunction] [strengthoffunction]
NISC, "Strength of Function", n.d., NISC, "Strength of Function", n.d.,
<https://csrc.nist.gov/glossary/term/ <https://csrc.nist.gov/glossary/term/
strength_of_function>. strength_of_function>.
[TCG-DICE] Trusted Computing Group, "DICE Certificate Profiles", [TCG-DICE] Trusted Computing Group, "DICE Certificate Profiles",
n.d., <https://trustedcomputinggroup.org/wp- n.d., <https://trustedcomputinggroup.org/wp-
content/uploads/DICE-Certificate-Profiles- content/uploads/DICE-Certificate-Profiles-
r01_3june2020-1.pdf>. r01_3june2020-1.pdf>.
 End of changes. 38 change blocks. 
71 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/