]> Fraunhofer SIT

Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@ietf.contact

Fraunhofer SIT

Rheinstrasse 75 Darmstadt 64295 Germany michael.eckel@sit.fraunhofer.de

Huawei Technologies

william.panwei@huawei.com

Cisco Systems

evoit@cisco.com

Security RATS Working Group Internet-Draft This document describes interaction models for remote attestation procedures (RATS) . Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted.

Introduction Remote ATtestation procedureS (RATS, ) are workflows composed of roles and interactions, in which Verifiers create Attestation Results about the trustworthiness of an Attester's system component characteristics. The Verifier's assessment in the form of Attestation Results is produced based on Endorsements, Reference Values, Appraisal Policies, and Evidence -- trustable and tamper-evident Claims Sets about an Attester's system component characteristics -- generated by an Attester. The roles Attester and Verifier, as well as the Conceptual Messages Evidence and Attestation Results are concepts defined by the RATS Architecture . This document illustrates three main interaction models between various RATS roles, namely Attesters, Verifiers, and Relying Parties that can be used in specific RATS-related specifications. Using Evidence as a prominent example, these three interaction models are:

1. Challenge/Response Remote Attestation: A Verifier actively challenges an Attester and receives time-fresh Evidence in response.
2. Uni-Directional Remote Attestation: An Attester sends Evidence proactively to a Verifier, often using externally generated freshness indicators.
3. Streaming Remote Attestation: A persistent subscription-based model where Evidence is pushed continuously to interested Verifiers, optionally via a broker.

As a basis to describe the interaction models is this document, the example of attestation Evidence conveyance is used to illustrate the usage scenarios. This document aims to:

1. prevent inconsistencies in descriptions of interaction models in other documents, which may occur due to text cloning and evolution over time, and to
2. highlight the exact delta/divergence between the core characteristics captured in this document and variants of these interaction models used in other specifications or solutions.

In summary, this document enables the specification and design of trustworthy and privacy-preserving (see Section ) conveyance methods for RATS Conceptual Messages; specifically attestation Evidence conveyed from an Attester to a Verifier. While the exact details for conveyance of other Conceptual Messages is out of scope, the models described in this document may be adapted to apply to the conveyance of other Conceptual Messages, such as Endorsements or Attestation Results, or supplemental messages, such as Epoch Markers or stand-alone event logs.

Terminology This document uses the following terms defined in : Attester, Verifier, Relying Party, Conceptual Message, Evidence, Endorsement, Attestation Result, Appraisal Policy, Attesting Environment, Target Environment. A PKIX Certificate is an X.509v3 certificate as specified by . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Disambiguation "Remote Attestation" is a common expression often associated or connoted with certain properties. In the context of this document, the term "Remote" does not necessarily refer to a remote entity in the scope of network topologies or the Internet. It rather refers to decoupled systems or entities that exchange the Conceptual Message type called Evidence . This conveyance can also be "Local", if the Verifier role is part of the same entity as the Attester role, e.g., separate system components of the same Composite Device (a single RATS entity), or the Verifier and Relying Party roles are hosted by the same entity, for example in a cryptographic key broker system (see for more details). If an entity takes on two or more different roles, the functions they provide typically reside in isolated environments that are components of the same entity. Examples of such isolated environments include a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g., embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).

Nonce Disambiguation The term "nonce" can be used in different security disciplines with different intended security properties. In order to avoid confusion, this document distinguishes the following contexts:

Attestation nonce (freshness handle):

A nonce used as a Handle in a remote attestation interaction model to provide replay protection and/or evidence freshness. It is conveyed to an Attesting Environment and is cryptographically bound into Evidence. Depending on deployment, an attestation nonce MAY also serve as a claims-collection control signal (e.g., to invalidate cached claims and trigger re-collection of fresh claims), and it may be provisioned before a reboot and then included with Evidence collected after boot.

• TLS nonce:

  Random values used within TLS handshakes and key derivation. These are not Handles and are unrelated to Evidence freshness semantics in this document.

• Signature nonce (e.g., ECDSA nonce):

  Ephemeral randomness used internally by some signature algorithms. These are not protocol-visible Handles and have different security requirements (e.g., uniqueness and secrecy) than attestation nonces.

Unless explicitly stated otherwise, when this document uses the term "nonce" in the context of Handles, it refers to an attestation nonce with the purpose to demonstrate freshness.

Boot Time Integrity Boot time integrity refers to the trustworthiness of the platform during its boot sequence, typically covering firmware, BIOS/UEFI, initial bootloaders, and core operating system components up until a stable runtime environment is reached. This may apply equally to physical devices and virtual machines.

Runtime Integrity Runtime integrity refers to the ongoing trustworthiness of a platform during normal operation, after the boot sequence completes. It encompasses the integrity of dynamic system state, including loaded applications, kernel modules, and active configurations.

Boot-to-Runtime Boundary The exact boundary between boot time and runtime may vary between systems. Generally, it is marked by the handoff from the final bootloader or initial OS kernel to a fully operational environment capable of executing arbitrary applications or services.

Scope and Intent This document:

• outlines common interaction models between RATS roles;
• illustrates interaction models using the conveyance of Evidence about boot-time integrity as an example throughout this document;
• does not exclude the application of those interaction models to runtime integrity or the conveyance of other RATS Conceptual Messages;
• does not cover every detail about Evidence conveyance.

While details regarding Evidence of runtime integrity are not explicitly highlighted, the provided model descriptions serve as a foundation for developing corresponding model extensions. While the interaction models described in this document, including their variants, cover many relevant conveyance models for Conceptual Messages implemented on the Internet, they do not represent an exhaustive list of all possible models. Procedures, functions, and services needed for a complete semantic binding of the concepts defined in are not covered in this document. Examples of such procedures include: identity establishment, key distribution and enrollment, time synchronization, and certificate revocation. Furthermore, any processes and duties beyond conducting remote attestation procedures are out of scope. For example, utilizing the results of a remote attestation procedure generated by the Verifier, such as triggering remediation actions or recovery processes, as well as the remediation actions and recovery processes themselves, are also out of scope. The interaction models described in this document are meant to serve as a solid foundation and reference for other solution documents within or outside the IETF. Solution documents of any kind can refer to these interaction models to prevent duplicating text and to avoid the risk of subtle discrepancies. Similarly, deviations from the generic model described in this document can be illustrated in solution documents to highlight distinct contributions.

Essential Requirements In order to ensure appropriate conveyance of Evidence, the following requirements MUST be fulfilled:

Integrity:

Information provided by an Attester MUST NOT have been altered since it was created. This may be achieved via symmetric cryptography, e.g., using COSE Mac0 as in PSA TF-M profile (), or asymmetric, such as a COSE Sign algorithm like ECDSA.

Authentication:

The information provided by the Attester MUST be authentic. To do this, the Attester should authenticate itself to the Verifier.

This can be achieved by digitally signing the Attestation Evidence (i.e., explicit authentication) and conveying that signed Evidence to the Verifier, without requiring additional authentication handshakes beyond those needed for conveyance.

Alternatively, Evidence can be conveyed over a secure channel that provides authentication (see Sections 3 and 4 of ).

Normative Prerequisites In order to ensure Evidence is appropriately conveyed through the interaction models described in this document, the following prerequisites MUST be in place to support their implementation:

Authentication Secret:

An Authentication Secret MUST be established before any RATS interaction takes place, and it must be made available exclusively to an Attesting Environment of the Attester.

The Attester MUST protect Claims with this Authentication Secret to prove the authenticity of the Claims included in Evidence. The Authentication Secret MUST be established before RATS take place.

Attester Identity:

A statement made by an Endorser about an Attester that affirms the Attester's distinguishability.

In essence, an Attester Identity can either be explicit (e.g., via a Claim in Evidence or Endorsement) or implicit (e.g., via a signature that matches a trust anchor). Note that distinguishability does not imply uniqueness; for example, a group of Attesters can be identified by an Attester Identity.

The provenance of Evidence SHOULD be distinguishable with respect to the Attesting Environment and MUST be unambiguous with respect to the Attester Identity.

An Attester Identity MAY be an Authentication Secret which is available exclusively to one of the Attesting Environments of the Attester. It could be a unique identity, it could be included in a zero-knowledge proof (ZKP), it could be part of a group signature, or it could be a randomized DAA credential .

Attestation Evidence Authenticity:

Attestation Evidence MUST be authentic.

In order to provide a proof of authenticity, Attestation Evidence can be cryptographically associated with an identity document (e.g., a PKIX certificate or trusted key material, or a randomized DAA credential ), or could include a correct, unambiguous, and stable reference to an accessible identity document.

For signature validation and appraisal, the Verifier MUST be able to obtain the corresponding verification key material (e.g., a public key or certificate) and the trust anchor(s) needed to establish trust in that material. This may be achieved via provisioning/enrollment, by conveying the identity document together with Evidence, or by providing a stable reference that enables retrieval of the identity document. The concrete distribution and enrollment mechanisms are out of scope of this document.

Authenticity includes the protection of Evidence in a tamper-evident manner (e.g., either by signatures or by protection mechanisms implemented at both ends of a Secure Channel; see Authentication above).

Evidence Freshness:

Evidence MUST include an indicator about its freshness that can be understood by a Verifier (See also ). This enables interaction models to support the conveyance of proofs of freshness in a way that is useful to Verifiers and their appraisal procedures.

Generic Information Elements This section describes the essential information elements for the interaction models described in . These generic information elements may be Conceptual Messages included in the protocol messages or may be added as protocol parameters, depending on the specific solution. The information elements below are grouped with mandatory elements first, followed by optional elements.

Handle (handle):

mandatory

An information element provided to the Attester from an external source included in Evidence (or other RATS Conceptual Messages) to determine recentness, freshness, or to protect against replay attacks.

The term Handle encompasses various data types that can be utilized to determine recentness, freshness, or provide replay protection. Examples include attestation nonces (see ), which are used to demonstrate freshness (and also protect against replay attacks), and Epoch Markers, which identify distinct periods (Epochs) of freshness . Handles can also indicate authenticity or attestation Evidence provenance, as only specific RATS roles (e.g., an Attester and a Verifier in a challenge-response interaction) are meant to know a certain handle. In contexts where the concrete Handle type matters, this document uses the more specific term (e.g., "attestation nonce" or "Epoch Marker") in addition to the generic term Handle.

Claims (claims):

mandatory

Claims are assertions that represent characteristics of an Attester's Target Environment.

Claims are part of a Conceptual Message and are used, for example, to appraise the integrity of Attesters by Verifiers. The other information elements in this section can be presented as Claims in any type of Conceptual Message.

Collected Claims (collectedClaims):

mandatory

Collected Claims represent a (sub-)set of Claims created by an Attester.

Collected Claims are gathered based on the Claim Selection. If a Verifier does not provide a Claim Selection, all available Claims on the Attester are part of the Collected Claims.

Evidence (evidence):

mandatory

A set of Claims that can include: (a) a list of Attestation Environment IDs, each identifying an Authentication Secret in a single Attesting Environment, (b) the Attester Identity, (c) Claims about the Attester's Target Environment, and (d) a Handle. Attestation Evidence MUST cryptographically bind all of these information elements. Evidence MUST be protected via an Authentication Secret. The Authentication Secret MUST be trusted by the Verifier as authoritatively "speaking for" the Attester.

Attestation Result (attestationResult):

mandatory

Attestation Results are assertions about the integrity or other characteristics of the appraised Attester.

Attestation Results are created by Verifiers based on appraised Evidence and other input information. Attestation Results are typically conveyed to Relying Parties and can be used to inform access control decisions.

Verifier Inputs ('verInputs')

mandatory

Appraisal procedures implemented by Verifiers require certain inputs as defined in : Reference Values, Endorsements, and Appraisal Policy for Evidence. These Conceptual Messages can take various forms. For example, Reference Values that can be expressed via Reference Integrity Measurements (RIM) or Endorsements that can range from trust anchors to assertions cryptographically bound to the public key associated with an Attesting Environment.

Attesting Environment IDs ('attEnvIDs'):

optional

A statement representing one or more identifiers that MUST be associated with a corresponding Attestation Environment's keys used to protect Claims in Evidence produced by an Attester. Exemplary identifiers include attestation key material (e.g., the public key associated with the private key that is used to produce Evidence), key identifiers, environment names, or individual hardware-based immutable identifiers.

A Verifier MAY use such identifiers (or other key identifiers used by a given interaction model) to locate the verification key material and related trust anchors required to validate the Evidence signature.

While a Verifier does not necessarily have knowledge about an Attesting Environment's identifiers, each distinguishable Attesting Environment typically has access to a protected capability that includes an Attesting Environment ID. If no Attesting Environment IDs are provided, a local default applies based on the Attester. For example, all Attesting Environments will provide Evidence.

Event Logs (eventLogs):

optional

Event Logs accompany Claims by providing event trails of security-critical events in a system. The primary purpose of Event Logs is to ensure Claim reproducibility by providing information on how Claims originated.

Claim Selection (claimSelection):

optional

A (sub-)set of Claims that can be collected and incorporated in Evidence by the Attesting Environments of an Attester.

Claim Selections act as optional filters to specify the exact set of Claims to be included in Evidence. For example, a Verifier could send a Claim Selection, among other elements, to an Attester. An Attester MAY decide whether or not to provide all requested Claims from a Claim Selection to the Verifier. If there is no way to convey a Claim Selection in a remote attestation protocol, a default Claim Selection (e.g., "all") MUST be defined by the Attester and SHOULD be known by the Verifier. In order to select Claims, Claims that can be potentially included in Evidence by an Attesting Environment have to be known by the Verifier.

Interaction Models This document describes three interaction models for Remote Attestation:

1. Challenge/Response (),
2. Unidirectional (), and
3. Streaming ().

Each section starts with a sequence diagram illustrating the interactions between the involved roles: Attester, Verifier and, optionally, a Relying Party. The presented interaction models focus on the conveyance of Evidence and Attestation Results. The same interaction models may apply to the conveyance of other Conceptual Messages (Endorsements, Reference Values, or Appraisal Policies) with other roles involved. However, that is out of scope for the present document. All interaction models have a strong focus on the use of a Handle to incorporate a proof of freshness and to prevent replay attacks. The way the Handle is processed is the most prominent difference between the three interaction models.

Challenge/Response Remote Attestation Note: In the following diagrams, a leading ? indicates that an information element is optional.

Challenge/Response Remote Attestation claims, ?eventLogs | | | |<----- requestEvidence(handle, ?attEnvIDs, ?claimSelection) | | | collectClaims(claims, ?claimSelection) | | => collectedClaims | | | generateEvidence(handle, ?attEnvIDs, collectedClaims) | | => evidence | | | | {evidence, ?eventLogs}------------------------------------>| | | ==========================[Evidence Appraisal]========================== | | | appraiseEvidence(evidence, ?eventLogs, verInputs) | attestationResult <= | | | ]]>

The Attester boots up and thereby produces Claims about its boot state and its operational state during runtime (cf. ), e.g., loaded applications, configurations, and environment variables. Event Logs may accompany the produced Claims and provide an event trail of security-critical events in the system. Claims are produced by all Attesting Environments of an Attester system. The Challenge/Response remote attestation procedure is typically initiated by the Verifier by sending a remote attestation request to the Attester. Alternative initiation flows, e.g., via an intermediary or through pre-configured requests (e.g., Call-Home procedures or trusted trigger events from Relying Parties), are out of scope for this document. A request includes a Handle, an optional list of Attestation Key IDs, and an optional Claim Selection. In the Challenge/Response model, the Handle is composed of qualifying data in the form of a practically infeasible-to-guess nonce , such as a cryptographically strong random number. This nonce is typically generated by the Verifier to guarantee Evidence freshness and prevent replay attacks; however, depending on deployment context, it may also be generated by another trusted role, such as a Relying Party. In this interaction model, that nonce is an attestation nonce (freshness handle) as described in . The list of Attestation Key IDs selects the attestation keys with which the Attester is requested to sign the attestation Evidence. Each selected key is uniquely associated with an Attesting Environment of the Attester. As a result, a single Attestation Key ID identifies a single Attesting Environment. Correspondingly, a particular set of Evidence originating from a particular Attesting Environment in a composite device can be requested via multiple Attestation Key IDs. Methods to acquire Attestation Key IDs or mappings between Attesting Environments to Attestation Key IDs are out of scope of this document. Nevertheless, in order to validate the Evidence signature, the Verifier needs access to the verification key material corresponding to the selected Attestation Key ID(s), as well as the trust anchors required to establish trust in that key material. This trust material may be provisioned/enrolled out of band, conveyed alongside Evidence, or retrieved via a stable reference to an identity document. The Attester selects Claims based on the specified Claim Selection, which is defined by the Verifier. The Claim Selection determines the Collected Claims, which may be a subset of all the available Claims. If the Claim Selection is omitted, then all available Claims on the Attester MUST be used to create corresponding Evidence. For example, when performing a boot integrity evaluation, a Verifier may only request specific claims about the Attester, such as Evidence about the BIOS/UEFI and firmware that the Attester booted up, without including information about all currently running software. With the Handle, the Attestation Key IDs, and the Collected Claims, the Attester produces signed Evidence. That is, it digitally signs the Handle and the Collected Claims with a cryptographic secret identified by the Attestation Key ID. This is done once per Attesting Environment which is identified by the particular Attestation Key ID. The Attester communicates the signed Evidence as well as all accompanying Event Logs back to the Verifier. The Claims, the Handle, and the Attester Identity information (i.e., the Authentication Secret) MUST be cryptographically bound to the signature of Evidence. These MAY be presented obfuscated, encrypted, or selectively disclosed (e.g., via hashing) as discussed in Section or, for example, via the use of in . For further reference see, Section . Upon receiving the Evidence and Event Logs, the Verifier validates the signature, Attester Identity, and Handle, and then appraises the Claims. Claim appraisal is driven by Policy and takes Reference Values and Endorsements as input. The Verifier outputs Attestation Results. Attestation Results create new Claim Sets about the properties and characteristics of an Attester, which enable Relying Parties to assess an Attester's trustworthiness. Note: This diagram illustrates the canonical Challenge/Response interaction between Attester and Verifier. Variants that include a Relying Party (e.g., Passport or Background-Check models) are shown in subsequent sections.

Models and Example Sequences of Challenge/Response Remote Attestation According to the RATS Architecture, two reference models for Challenge/Response Attestation have been proposed. This section highlights the information flows between the Attester, Verifier, and Relying Party undergoing Remote Attestation Procedure, using these models.

Passport Model The passport model is so named because of its resemblance to how nations issue passports to their citizens. In this model, the attestation sequence is a two-step procedure. In the first step, an Attester conveys Evidence to a Verifier, which appraises the Evidence according to its Appraisal Policy. The Verifier then gives back an Attestation Result to the Attester, which caches it. In the second step, the Attester presents the Attestation Result (and possibly additional Claims/Evidence) to a Relying Party, which appraises this information according to its own Appraisal Policy to establish the trustworthiness of the Attester. In Challenge/Response interaction models, the Handle (e.g., an attestation nonce) can be generated by different trusted roles depending on deployment context. In the Passport model, the Handle MAY be generated by the Relying Party and conveyed as part of the requestEvidence(...) call; alternatively, it MAY be generated by the Verifier and conveyed to the Attester (e.g., via the Relying Party or other protocol mechanisms).

Passport Model for Challenge/Response Remote Attestation {claims, ?eventLogs} | | | | | |<----------------------------------(----------- requestEvidence( | | handle, | | ?attEnvIDs, | | ?claimSelection) collectClaims(claims, | | ?claimSelection) | | | => collectedClaims | | | | | generateEvidence(handle, | | ?attEnvIDs, collectedClaims) | | | => evidence | | | | | | {evidence, ?eventLogs} -----------)---------------------->| | | | ==========================[Evidence Appraisal]========================== | | | | | appraiseEvidence( | | evidence, | | ?eventLogs, | | verInputs) | | attestationResult <= | | | | =============[Attestation Result Conveyance and Appraisal]============== | | | | <---------------------------------(-- {attestationResult} | | | | | | | | {evidence, attestationResult} --->| | | | | | appraiseResult( | | policy, | | attestationResult) | | | | ]]>

Background-Check Model The background-check model is so named because of the resemblance of how employers and volunteer organizations perform background checks. In this model, the attestation sequence is initiated by a Relying Party. The Attester conveys Evidence to the Relying Party, which does not process its payload, but relays the message and optionally checks its signature against a policed trust anchor store. Upon receiving the Evidence, the Relying Party initiates a session with the Verifier. Once the session is established, it forwards the received Evidence to the Verifier. The Verifier appraises the received Evidence according to its appraisal policy for Evidence and returns a corresponding Attestation Result to the Relying Party. The Relying Party then checks the Attestation Result against its own appraisal policy to conclude attestation. As in the Passport model, the Handle MAY be generated by the Relying Party (as depicted), or it MAY originate from the Verifier and be conveyed to the Attester by protocol-specific means.

Background-Check Model for Challenge/Response Remote Attestation {claims, ?eventLogs} | | | | | |<-------------------------- requestEvidence( | | handle, | | ?attEnvIDs, | | ?claimSelection) | | | | collectClaims(claims, | | ?claimSelection) | | | => collectedClaims | | | | | generateEvidence(handle, | | ?attEnvIDs, collectedClaims) | | | => evidence | | | | | | {evidence, ?eventLogs} ---------->| | | | {handle, evidence, | | | ?eventLogs} -------->| | | | ==========================[Evidence Appraisal]========================== | | | | | appraiseEvidence( | | evidence, | | ?eventLogs, | | verInputs) | | attestationResult <= | | | | =============[Attestation Result Conveyance and Appraisal]============== | | | | |<- {attestationResult} | | | | | appraiseResult(policy, | | attestationResult) | | | | ]]>

Uni-Directional Remote Attestation

Uni-Directional Remote Attestation handle | | | | | | | | |<---------------------------- {handle} | {handle} --------->| | | | | | | | | x | | | | | | | ===============[Evidence Generation and Conveyance]================= | | | | | | generateClaims(attestingEnvironment) | | | | => claims, eventLogs | | | | | | | collectClaims(claims, ?claimSelection) | | | | => collectedClaims | | | | | | | generateEvidence(handle, attEnvIDs, collectedClaims) | | | | => evidence | | | | | | | | {evidence, eventLogs} ------------------------------------>| | | | | | | ========================[Evidence Appraisal]======================== | | | | | | | appraiseEvidence(evidence, | | | eventLogs, | | | verInputs) | | | attestationResult <= | | | ~ ~ | | | | | | .-------[loop]-----------------------------------------------------. | || | | || || ============[Delta Evidence Generation and Conveyance]============ || || | | || || generateClaims(attestingEnvironment) | || || | => claimsDelta, eventLogsDelta | || || | | || || collectClaims(claimsDelta, ?claimSelection) | || || | => collectedClaimsDelta | || || | | || || generateEvidence(handleDelta, attEnvIDs, collectedClaimsDelta) | || || | => evidence | || || | | || || | {evidence, eventLogsDelta} ------------------------------->| || || | | || || ====================[Delta Evidence Appraisal]==================== || || | | || || | appraiseEvidence(evidence, || || | eventLogsDelta, || || | verInputs) || || | attestationResult <= | || || | | || | '------------------------------------------------------------------' | '--------------------------------------------------------------------' | | ]]>

Uni-Directional Remote Attestation procedures can be initiated both by the Attester and by the Verifier. Initiation by the Attester can result in unsolicited pushes of Evidence to the Verifier. Initiation by the Verifier always results in solicited pushes to the Verifier. The Uni-Directional model uses the same information elements as the Challenge/Response model. In the sequence diagram above, the Attester initiates the conveyance of Evidence (comparable with a RESTful POST operation). While a request of Evidence from the Verifier would result in a sequence diagram more similar to the Challenge/Response model (comparable with a RESTful GET operation). The specific manner how Handles are generated is not in scope of this document. One example of a specific handle representation is . In the Uni-Directional model, Evidence may be conveyed as full Evidence or as delta Evidence. Regardless of whether delta Evidence is used, each Evidence conveyance is bound to a current Handle. In the diagrams, handleDelta denotes the Handle associated with the delta Evidence conveyance, which may be the same as the previous Handle or a newly issued Handle (e.g., for a new Epoch or freshness window). The concrete rules for when a Handle is rotated (resulting in a new handleDelta) are deployment- and protocol-specific and are out of scope of this document. Note: If a Verifier does not receive the current Handle (e.g., due to propagation loss or delay), it may be unable to determine Evidence freshness for the corresponding Epoch. In such cases, Evidence appraisal cannot be completed until re-synchronization occurs. Error signaling and re-synchronization mechanisms are protocol-specific and out of scope of this document. In the Uni-Directional model, handles are composed of cryptographically signed trusted timestamps as shown in , potentially including other qualifying data. The Handles are created by an external trusted third party (TTP) -- the Handle Distributor -- which includes a trustworthy source of time, and takes on the role of a Time Stamping Authority (TSA, as initially defined in ). Timestamps created from local clocks (absolute clocks using a global timescale, as well as relative clocks, such as tick-counters) of Attesters and Verifiers MUST be cryptographically bound to fresh Handles received from the Handle Distributor. This binding provides a proof of synchronization that MUST be included in all produced Evidence. This model provides proof that Evidence generation happened after the Handle generation phase. The Verifier can always determine whether the received Evidence includes a fresh Handle, i.e., one corresponding to the current Epoch as identified by an Epoch Marker handle.

Handle Lifecycle and Propagation Delays The term "uni-directional" refers to individual conveyance channels: one from the Handle Distributor to the Attester, and one from the Attester to the Verifier. Together, they establish an attestation loop without requiring request/response exchanges. This model does not assume that Verifiers broadcast Handles, as such a setup would require Verifiers to take on the Handle Distributor role and undermine the separation of duties between these roles. The lifecycle of a handle is a critical aspect of ensuring the freshness and validity of attestation Evidence. When a new handle is generated by the Handle Distributor, it effectively supersedes the previous handle. However, due to network latencies and propagation delays, there may be a period during which both the old and new handles are in circulation. This "grey zone" can potentially lead to situations where Evidence may be associated with an outdated handle yet still appear to be valid. To manage this complexity, it is essential to define a clear policy for handle validity and expiration:

• Handle Expiry: Each handle should have a well-defined expiration time, after which it is considered invalid. This expiry must account for expected propagation delays and be clearly communicated to all entities in the attestation process.
• Synchronization Checks: Implement periodic synchronization checks between the Handle Distributor and both Attesters and Verifiers to ensure that handles are updated consistently across all participants. For example, in TUDA , synchronization checks can be realized by cryptographically binding local timestamps from Attesters and Verifiers to fresh Epoch Handles issued by a trusted Time Stamp Authority (TSA), thereby proving that both entities share a consistent notion of time.
• Grace Periods: Define grace periods during which a newly issued handle starts being accepted, and the old handle stops being valid. This period should be long enough to account for the maximum expected propagation delay across the network.

Implementing these measures will help mitigate the risks associated with the handle lifecycle, particularly in environments where propagation delays are significant. This careful management ensures that the integrity and trustworthiness of the attestation process are maintained. While periodically pushing Evidence to the Verifier, the Attester only needs to generate and convey updates since the previous conveyance. These updates, referred to as "delta" in the sequence diagrams, are not limited to net changes of Claim values. They MUST include all state changes detected since the previous conveyance, even if values later revert to their prior state. For example, if an Attester goes through a sleep or hibernation cycle and a Claim value changes and then reverts, both transitions MUST be reported to the Verifier as soon as possible after resuming operation. Effectively, the Uni-Directional model allows for a series of Evidence to be pushed to multiple Verifiers simultaneously. Methods to detect excessive time drift that would mandate a fresh Handle to be received by the Handle Distributor as well as timing of Handle distribution are out-of-scope of this document.

Streaming Remote Attestation Streaming Remote Attestation serves as the foundational concept for both the publish-subscribe pattern and the observer pattern . It entails establishing subscription state to enable continuous remote attestation. In the publish-subscribe pattern, a central broker is used to distribute messages between publishers and subscribers. The broker receives messages from publishers and forwards them to the appropriate subscribers. In the observer pattern, however, observers are connected directly to target resources, without a broker (oub/sub only).

Streaming Remote Attestation without a Broker

Streaming Remote Attestation without a Broker | | | | | | | ===============[Evidence Generation and Conveyance]================= | | | | | | generateClaims(attestingEnvironment) | | | | => claims, eventLogs | | | | | | | collectClaims(claims, ?claimSelection) | | | | => collectedClaims | | | | | | | generateEvidence(handle, attEnvIDs, collectedClaims) | | | | => evidence | | | | | | | | {handle, evidence, eventLogs} ---------------------------->| | | | | | | ========================[Evidence Appraisal]======================== | | | | | | | appraiseEvidence(evidence, | | | eventLogs, | | | verInputs) | | | attestationResult <= | | | ~ ~ | | | | | | .--------[loop]----------------------------------------------------. | || | | || || ============[Delta Evidence Generation and Conveyance]============ || || | | || || generateClaims(attestingEnvironment) | || || | => claimsDelta, eventLogsDelta | || || | | || || collectClaims(claimsDelta, ?claimSelection) | || || | => collectedClaimsDelta | || || | | || || generateEvidence(handleDelta, attEnvIDs, collectedClaimsDelta) | || || | => evidence | || || | | || || | {evidence, eventLogsDelta} ------------------------------->| || || | | || || ====================[Delta Evidence Appraisal]==================== || || | | || || | appraiseEvidence(evidence, || || | eventLogsDelta, || || | verInputs) || || | attestationResult <= | || || | | || | '------------------------------------------------------------------' | '--------------------------------------------------------------------' | | ]]>

In the observer pattern, an observer establishes a direct connection to the observed resources through a subscription mechanism, which is designed specifically for conveying conceptual messages for remote attestation purposes. This mechanism not only facilitates the initial subscription request but also actively maintains the state of the subscription, ensuring that any changes in the observed resources are consistently communicated to the observer. It handles the complexities of managing these connections, including the maintenance of pertinent information about the observer's preferences and security requirements, ensuring that the transmission of attestation data remains both secure and relevant to the observer’s specific context. Setting up subscription state between a Verifier and an Attester is conducted via a subscribe operation. The subscribe operation is used to convey Handles required for Evidence generation. Effectively, this allows for a series of Evidence to be pushed to a Verifier, similar to the Uni-Directional model. In the observer pattern, the Handle Distributor role is optional. While the model is typically used for direct, bi-lateral subscription relationships where the Verifier generates and provides Handles directly, it is also possible to include the trusted third party that is a Handle Distributor. A Handle Distributor independently manages the generation and distribution of Handles to other RATS roles. As a result, scenarios involving more than bi-lateral interactions are enabled. However, in its basic form, the model assumes direct interaction between an Attester and a Verifier, where the Handle generation is a responsibility taken on by the Verifier roles. Handles provided by a specific subscribing Verifier MUST be used in Evidence generation for that specific Verifier. The streaming model without a Broker uses the same information elements as the Challenge/Response and the Uni-Directional model. Methods to detect excessive time drift that would render Handles stale and mandate a fresh Handles to be conveyed via another subscribe operation are out-of-scope of this document. Delta Evidence is produced with respect to the previous conveyance, but it is still bound to a (potentially updated) current Handle (e.g., handleDelta). If a new Handle is required, it is conveyed by a subsequent subscribe operation. If Evidence or delta Evidence repeatedly fails to verify, a Verifier may terminate the subscription. The detailed mechanisms for unsubscribe and re-subscribe are protocol-specific and out of scope for this document; for example, subscription lifecycle management is defined in .

Streaming Remote Attestation with a Broker This model includes a Broker to facilitate the distribution of messages between RATS roles, such as Attesters and Verifiers. The Broker is a trusted third party and acts as an intermediary that ensures messages are securely and reliably conveyed between involved RATS roles. The publish-subscribe messaging pattern is widely used for communication in different areas. An example for a publish-subscribe model with a Broker is the Message Queuing Telemetry Transport . Unlike the Streaming Remote Attestation without a Broker interaction model, Attesters are not required to be aware of corresponding Verifiers. In scenarios with large numbers of Attesters and Verifiers, the publish-subscribe pattern may reduce interdependencies and improve scalability. With publish-subscribe, clients typically connect to (or register with) a publish-subscribe server (PubSub server or Broker). Clients may publish data in the form of a message under a certain topic. Subscribers to that topic get notified whenever a message arrives under a topic, and the appropriate message is forwarded to them. Depending on particular publish-subscribe models and implementations, involved roles can be publishers, subscribers or both. The Broker and Handle Distributor are considered to be trusted third parties (TTPs) for all other participating roles, including Attesters and Verifiers (see also ). All roles must establish a trust relationship with the Broker and Handle Distributor, as those are responsible for the secure and reliable dissemination of critical protocol information, such as Handles and Attestation Results. Ensuring the security of these trusted third parties is vital, as any compromise could undermine the entire remote attestation procedure. Therefore, the deployment of Brokers and Handle Distributors requires stringent security measures to protect against unauthorized access and to ensure that they operate as trustworthy facilitators within the remote attestation framework. In the following sections, the interaction models Challenge/Response Remote Attestation over Publish-Subscribe and Uni-Directional Remote Attestation over Publish-Subscribe are described. There are different phases that both models go through:

1. Handle Generation
2. Evidence Generation and Conveyance
3. Evidence Appraisal
4. Attestation Result Generation

The models only differ in the handle generation phase. From a remote attestations procedure's point of view Evidence Generation, Conveyance, and Appraisal, as well as Attestation Result Generation are identical in both models.

Handle Generation for Challenge/Response Remote Attestation over Publish-Subscribe

Handle Generation for Challenge/Response Remote Attestation over Publish-Subscribe | | | |<--------- pub(topic=AttReq, | | handle) |<---------------------- notify(topic=AttReq, handle) | | | | ~ ~ ~ ]]>

The Challenge/Response Remote Attestation over Publish-Subscribe interaction model uses the same information elements as the Challenge/Response Remote Attestation interaction model. Handles are generated by the Verifier on a per-request basis. In the sequence diagram above, the Verifier initiates an attestation by generating a new handle and publishing it to the "AttReq" (= Attestation Request) topic on the PubSub server. The PubSub server then forwards this handle to the Attester by notifying it. This mechanism ensures that each handle is uniquely associated with a specific attestation request, thereby enhancing security by preventing replay attacks.

Handle Generation for Uni-Directional Remote Attestation over Publish-Subscribe

Handle Generation for Uni-Directional Remote Attestation over Publish-Subscribe | | | | | | | | |<--------- sub(topic=Handle) | | | | | | | | | generateHandle() | | | | => handle | | | | | | | pub(topic=Handle, | | | | handle) --------->| | | x | | | | | |<--------------------- notify(topic=Handle, handle) | | | | | notify(topic=Handle, handle) ------->| | | | ~ ~ ~ ]]>

Handles are created by a trusted third party, the Handle Distributor (see ). In the sequence diagram above, both an Attester and a Verifier subscribe to the topic "Handle" on the PubSub server. When the Handle Distributor generates and publishes a Handle to the "Handle" topic on the PubSub server, the PubSub server notifies the subscribers, Attester and Verifier, and forwards ("notify") the Handle to them during Handle Generation.

Evidence Generation and Appraisal

Evidence Generation and Appraisal for Remote Attestation over Publish-Subscribe claims, eventLogs | | | | | | | | | collectClaims(claims, ?claimSelection) | | | | | => collectedClaims | | | | | | | | | generateEvidence(handle, attEnvIDs, | | | | | collectedClaims) | | | | | => evidence | | | | | | | | | pub(topic=AttEv, | | | | | evidence, eventLogs) ------------>| | | | | | | | | | notify(topic=AttEv, | | | | | evidence, | | | | | eventLogs) ---------->| | | | | | | | ========================[Evidence Appraisal]======================== | | | | | | | | | appraiseEvidence( | | | | evidence, | | | | eventLogs, | | | | verInputs) | | | | attestationResult <= | | | | | | | '--------------------------------------------------------------------' | | | ~ ~ ~ ]]>

Exactly as in the Challenge/Response and Uni-Directional interaction models, there is an Evidence Generation-Appraisal loop, in which the Attester generates Evidence and the Verifier appraises it. In the Publish-Subscribe model above, the Attester publishes Evidence to the topic "AttEv" (= Attestation Evidence) on the PubSub server, to which a Verifier subscribed before. The PubSub server notifies Verifiers, accordingly, by forwarding the attestation Evidence. Although the above diagram depicts only full attestation Evidence and Event Logs, later attestations may use "deltas' for Evidence and Event Logs. The definition of delta Evidence is provided in . Verifiers appraise the Evidence and publish the Attestation Result to topic "AttRes" (= Attestation Result) on the PubSub server.

Attestation Result Generation

Attestation Result Generation for Remote Attestation over Publish-Subscribe | | | | | | .--------[loop]------------------------------------------------------. | | | | | | | | | |<--------- pub(topic=AttRes, | | | | | {handle, | | | | | attestationResult}) | | | | | | | | | |<----------------- notify(topic=AttRes, {handle, | | | | | | attestationResult}) | | | | | | | | '--------------------------------------------------------------------' | | | | ~ ~ ~ ~ ]]>

Attestation Result Generation is the same for both publish-subscribe models,Challenge/Response Remote Attestation over Publish-Subscribe and Uni-Directional Remote Attestation over Publish-Subscribe. Relying Parties subscribe to topic AttRes (= Attestation Result) on the PubSub server. The PubSub server forwards Attestation Results to the Relying Parties as soon as they are published to topic AttRes. Attestation Results conveyed to Relying Parties MUST be bound to the Handle used for the corresponding Evidence appraisal (to prevent mix-up and replay across Handles/Epochs, and to enable correlation). This binding can be achieved by including the Handle in the Attestation Result itself, or by cryptographically binding the Handle to the published message (e.g., signing a structure that includes both Handle and Attestation Result).

Implementation Status Note to RFC Editor: Please remove this section as well as references to before AUTH48. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

Implementer The open-source implementation was initiated and is maintained by the Fraunhofer Institute for Secure Information Technology SIT.

Implementation Name The open-source implementation is named "CHAllenge-Response based Remote Attestation" or in short: CHARRA.

Implementation URL The open-source implementation project resource can be located via: https://github.com/fraunhofer-sit/charra

Maturity The code's level of maturity is considered to be "prototype".

Coverage and Version Compatibility The current version ('6194b3b') implements a challenge/response interaction model and is aligned with the exemplary specification of the CoAP FETCH bodies defined in Section of this document.

License The CHARRA project and all corresponding code and data maintained on GitHub are provided under the BSD 3-Clause "New" or "Revised" license.

Implementation Dependencies The implementation requires the use of the Trusted Computing Group (TCG) Trusted Software Stack (TSS), and an HSM interoperable with the Trusted Platform Module Library specifications, e.g., a Trusted Platform Module (TPM) 2.0 or equivalent implementation. The corresponding project resources (code and data) for Linux-based operating systems are maintained on GitHub at https://github.com/tpm2-software/tpm2-tss/. The implementation uses the Constrained Application Protocol (http://coap.technology/) and the Concise Binary Object Representation (https://cbor.io/).

Contact Michael Eckel (michael.eckel@sit.fraunhofer.de)

Security and Privacy Considerations This document outlines three interaction models for remote attestation procedures (RATS) . While the subsequent sections address additional security and privacy considerations, the security considerations from must also be adhered to. Additionally, for TPM-based remote attestation, the security considerations outlined in should be taken into account.

Selective Disclosure and Obfuscation This section uses the term "blinding" in the broad sense of privacy-preserving treatment of attributes prior to disclosure (e.g., selective disclosure, obfuscation, or encryption), and not in the more specific cryptographic sense used for blind signatures. In a remote attestation procedure, the Verifier and the Attester may choose to reduce the disclosure of sensitive attributes while still enabling appraisal. For example, an attribute can be conveyed only as a digest that is included in, and protected by, the Evidence signature; or it can be encrypted for an authorized recipient.

Trust Assumptions on the Handle Distributor The handle distributor, as a third party in remote attestation scenarios, holds a critical position similar to that of a Trusted Third Party (TTP). Given its role in generating handles, it has the potential to influence the attestation process significantly. The integrity and reliability of the handles it produces are pivotal for ensuring that the attestation evidence remains trustworthy and that the attestation process is not susceptible to manipulation or interference.

Security Assumptions

• Integrity and Authenticity: It is assumed that the handle distributor operates with high levels of integrity and authenticity. Handles generated by the distributor must be secure, unique, and verifiable. This ensures that they cannot be forged or reused maliciously.
• Isolation and Protection: The handle distributor must be isolated and protected from unauthorized access and attacks. This includes physical security measures for hardware that might house the handle distributor's operations, as well as cybersecurity measures to protect against online threats.
• Auditability: The operations of the handle distributor should be auditable. This allows for the verification of its compliance with security policies and the integrity of its operations. Regular audits help to ensure that the handle distributor is functioning as expected and has not been compromised.
• Transparency: While maintaining security and confidentiality, the processes by which handles are generated and distributed should be as transparent as possible to authorized parties. This helps in building trust and verifying that handles are distributed in a fair and unbiased manner.

Mitigating Risks To mitigate risks associated with the handle distributor being a central point of potential failure or attack, several measures should be implemented:

• Redundancy: Deploying multiple, geographically dispersed handle distributors can ensure continuity of service even if one distributor is compromised or fails.
• Cryptographic Security: Using strong cryptographic techniques to protect the generation and transmission of handles ensures that they cannot be tampered with during distribution.
• Certification and Compliance: The handle distributor should comply with relevant security standards and undergo regular security certifications. This ensures that they meet industry-wide security benchmarks and maintain high levels of trust.

By defining and adhering to these security assumptions, the role of the handle distributor in remote attestation procedures can be securely managed, minimizing risks and enhancing the overall trust in the attestation process.

Security Considerations for Brokers in Remote Attestation The role of the Broker in the "Streaming Remote Attestation with a Broker model" introduces potential security vulnerabilities, including the ability to perform cross-application attacks by manipulating handles and topics. To mitigate these risks, it is essential to implement robust security measures:

• End-to-End Authentication: Establishing end-to-end authenticated channels between Attesters and Verifiers ensures that data integrity and authenticity are preserved across the communication process. This measure prevents the Broker from altering the content of the messages, including Handles and other sensitive data.
• Strong Isolation of Topics: Implementing strong isolation mechanisms for topics can help prevent the Broker from inadvertently or maliciously routing notifications to unauthorized parties. This includes using secure naming conventions and access controls that restrict the Broker's ability to manipulate topic subscriptions.
• Trusted Association Verification: To further safeguard against confusion attacks where the Broker might misroute notifications, mechanisms should be in place to verify the trust association between senders and receivers continuously. This can be facilitated by cryptographic assurances, such as digital signatures and trusted certificates that validate the sender's identity and the integrity of the message content.
• Audit and Monitoring: Regular audits and real-time monitoring of Broker activities can detect and respond to anomalous behavior that might indicate security breaches or manipulation attempts. Logging all actions performed by the Broker provides an audit trail that can be critical for forensic analysis.
• Broker as a Trusted Third Party (TTP): Recognizing the Broker as a TTP necessitates stringent security certifications and compliance with security standards to ensure that they operate under strict governance and security protocols. This includes regular security assessments and certifications that validate the Broker's security practices.

By addressing these vulnerabilities proactively, the integrity and confidentiality of the attestation process can be maintained, reducing the risks associated with Broker-mediated communication in remote attestation scenarios. It is crucial for solution architects to incorporate these security measures during the design and deployment phases to ensure that the attestation process remains secure and trustworthy.

Additional Application-Specific Security Considerations The security and privacy requirements for remote attestation can vary significantly based on the deployment environment, the nature of the attestation mechanisms used, and the specific threats each scenario faces. This section details additional security considerations that are pertinent to the interaction models discussed in this document.

Confidentiality The need for confidentiality in the transmission of attestation information is critical, particularly when exchanges occur over public or untrusted networks, such as the public Internet. For instance, in the Streaming Remote Attestation with a Broker model (cf.), where data might traverse multiple nodes, employing TLS can provide necessary confidentiality protections. Similarly, for scenarios involving sensitive environments like carrier management networks, evaluating the confidentiality of the transport medium is crucial to ensure that attestation data remains secure against interception or eavesdropping.

Mutual Authentication Mutual authentication is particularly relevant in models such as the Challenge/Response Remote Attestation (cf. ) where both the Attester and the Verifier engage in bidirectional exchanges of sensitive information. Ensuring that both parties can authenticate each other prevents impersonation attacks, enhancing the trustworthiness of the attestation results. Practical example mechanisms to achieve mutual authentication include:

Mutual TLS (mTLS):

TLS 1.3 supports mutual authentication via the ertificateRequest message. The client presents its X.509 certificate and proves possession of the private key, establishing bidirectional trust before attestation data is exchanged.

Server-Authenticated TLS with HTTP Authentication:

Server-only TLS authentication can be combined with application-layer client authentication. The server authenticates via its TLS certificate, while the client uses HTTP authentication such as Basic or Digest credentials. This approach suits deployments where client certificates are impractical.

Hardware Enforcement/Support In environments where the integrity and security of attestation evidence are paramount, hardware-based security features play a critical role. Technologies like Hardware Security Modules (HSMs), Physically Unclonable Functions (PUFs), and Trusted Execution Environments (TEEs) provide robust protections against tampering and unauthorized access. These are especially important in high-security settings such as financial services or military applications, where attestation processes must rely on physically secure and tamper-resistant components to meet stringent regulatory and security standards. By addressing these application-specific security requirements within the context of defined interaction models, security strategies can be tailored to fit the unique challenges and operational contexts of different attestation scenarios.

Acknowledgments Olaf Bergmann, Michael Richardson, and Ned Smith

References Normative References This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. 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. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. Fraunhofer SIT Linaro Huawei Technologies Arm Universität Bremen TZI This document defines Epoch Markers as a means to establish a notion of freshness among actors in a distributed system. Epoch Markers are similar to "time ticks" and are produced and distributed by a dedicated system known as the Epoch Bell. Systems receiving Epoch Markers do not need to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a specific Epoch Marker establishes a new epoch that is shared among all recipients. This document defines Epoch Marker types, including CBOR time tags, RFC 3161 TimeStampToken, and nonce-like structures. It also defines a CWT Claim to embed Epoch Markers in RFC 8392 CBOR Web Tokens, which serve as vehicles for signed protocol messages. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Fraunhofer Institute for Secure Information Technology Fraunhofer Institute for Secure Information Technology High North Inc Universität Bremen TZI This document defines the method and bindings used to convey Evidence via Time-based Uni-Directional Attestation (TUDA) in Remote ATtestation procedureS (RATS). TUDA does not require a challenge- response handshake and thereby does not rely on the conveyance of a nonce to prove freshness of remote attestation Evidence. TUDA enables the creation of Secure Audit Logs that can constitute believable Evidence about both current and past operational states of an Attester. In TUDA, RATS entities require access to a Handle Distributor to which a trustable and synchronized time-source is available. The Handle Distributor takes on the role of a Time Stamp Authority (TSA) to distribute Handles incorporating Time Stamp Tokens (TST) to the RATS entities. RATS require an Attesting Environment that generates believable Evidence. While a TPM is used as the corresponding root of trust in this specification, any other type of root of trust can be used with TUDA. This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules (TPMs), as defined by the Trusted Computing Group (TCG), or equivalent hardware implementations that include the protected capabilities, as provided by TPMs. Arm's Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, along with open-source reference implementations, aimed at helping device makers and chip manufacturers integrate best-practice security into their products. Devices that comply with PSA can generate attestation tokens as described in this document, which serve as the foundation for various protocols, including secure provisioning and network access control. This document specifies the structure and semantics of the PSA attestation token. The PSA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes the claims used in an attestation token generated by PSA-compliant systems, how these claims are serialized for transmission, and how they are cryptographically protected. This Informational document is published as an Independent Submission to improve interoperability with Arm's architecture. It is not a standard nor a product of the IETF. This document defines the Unprotected CWT Claims Set (UCCS), a data format for representing a CBOR Web Token (CWT) Claims Set without protecting it by a signature, Message Authentication Code (MAC), or encryption. UCCS enables the use of CWT claims in environments where protection is provided by other means, such as secure communication channels or trusted execution environments. This specification defines a CBOR tag for UCCS and describes the UCCS format, its encoding, and its processing considerations. It also discusses security implications of using unprotected claims sets. Armidale Consulting Fraunhofer SIT Linaro In the IETF Remote Attestation Procedures (RATS) architecture, a Verifier accepts Evidence and uses Appraisal Policy for Evidence, typically with additional input from Endorsements and Reference Values, to generate Attestation Results in formats that are useful for Relying Parties. This document illustrates the purpose and role of Endorsements and discusses some considerations in the choice of message format for Endorsements in the scope of the RATS architecture. This document does not aim to define a conceptual message format for Endorsements and Reference Values. Instead, it extends RFC9334 to provide further details on Reference Values and Endorsements, as these topics were outside the scope of the RATS charter when RFC9334 was developed. Fraunhofer SIT Cisco Systems, Inc. Huawei Technologies This document defines how to subscribe to YANG Event Streams for Remote Attestation Procedures (RATS). Specifically, this document defines a YANG module that augments the YANG module for TPM-based Challenge-Response Remote Attestation (CHARRA), enabling subscription to RATS Conceptual Messages of the Evidence type and auxiliary Event Logs as part of that Evidence. The module defined requires that at least one TPM 1.2 or TPM 2.0 (or equivalent hardware implementation providing the same protected capabilities as a TPM) must be available on the Attester on which the YANG server is running. mesur.io Tradeverifyd Fraunhofer SIT This specification describes a data minimization technique for use with CBOR Web Tokens (CWTs). The approach is inspired by the Selective Disclosure JSON Web Token (SD-JWT), with changes to align with CBOR Object Signing and Encryption (COSE) and CWTs. This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.

CDDL Specification for a simple CoAP Challenge/Response Interaction The following CDDL specification is an exemplary proof-of-concept to illustrate a potential implementation of the Challenge/Response Interaction Model. The communication protocol used is CoAP. Both the request message and the response message are exchanged via the FETCH operation and corresponding FETCH request and FETCH response body. In this example, Evidence is created via the root-of-trust for reporting primitive operation "quote" that is provided by a TPM 2.0.