Fraunhofer SIT

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

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, Attestation 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 defines interaction models that can be used in specific RATS-related solution documents. The primary focus of this document is the conveyance of attestation Evidence. The reference models defined can also be applied to the conveyance of other Conceptual Messages in RATS. 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 conveyance methods for attestation Evidence from an Attester to a Verifier. While the conveyance of other Conceptual Messages is out of scope, the models described in this document may be adapted to the conveyance of 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. 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)). It is useful but not necessary for readers of this document to be familiar with the Concept Data/Message flows as described in and the definition of Attestation in general as described in .

Scope and Intent This document outlines common interaction models between RATS roles. This document illustrates interaction models focusing on conveying Evidence about boot-time integrity from Attesters to Verifiers. This document does not exclude the application of those interaction models to runtime integrity or the conveyance of other RATS Conceptual Messages. This document does not cover every detail about Evidence conveyance. While details regarding Evidence of run-time 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 through a digital signature over Attestation Evidencewhich may be symmetric, like an HMAC, or asymmetric, 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 done through implicit authentication using a digital signature over the Attestation Evidence, which does not require additional protocol steps, or by using a confidential channel with encryption.

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 exclusively available 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. (Note that distinguishability does not imply uniqueness.)

The provenance of Evidence for a distinguishable Attesting Environment MUST be unambiguous.

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.

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.

Evidence Protection:

Evidence MUST be a set of well-formatted and well-protected Claims that an Attester can create and convey to a Verifier in a tamper-evident manner.

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.

Attestation Key IDs (attKeyIDs):

optional

One or more identifiers associated with corresponding attestation keys (Authentication Secrets) used to protect Evidence Claims produced by Attesting Environments of an Attester.

While a Verifier may (and typically does) not know an Attesting Environment's Attestation Key, each distinct Attesting Environment has access to a protected capability that includes an Attestation Key. Therefore, an Attestation Key ID can also identify an Attesting Environment. If no attestation key identifiers are provided, a local default applies based on the Attester. For example, all Attesting Environments will report.

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 Nonces, which protect against replay attacks, and Epoch Markers that 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.

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.

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.

Reference Values (refValues)

mandatory

Reference Values as defined in . This specific type of Claims is used to appraise Claims incorporated in Evidence. For example, Reference Values MAY be Reference Integrity Measurements (RIM) or assertions that are implicitly trusted because they are signed by a trusted authority (see Endorsements in ). Reference Values typically represent (trusted) Claim sets about an Attester's intended platform operational state.

Claim Selection (claimSelection):

optional

A (sub-)set of the Claims that can be created by an Attester.

Claim Selections are optional filters that specify the exact set of Claims to be included in Evidence. For example, a Verifier could send a Claim Selection, along with other elements, to an Attester. An Attester MAY decide whether 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 to the Verifier.

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 consists of: (a) a list of Attestation Key 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

An Attestation Result is produced by the Verifier as the output of the appraisal of Evidence generated by an Attester. Attestation Results include concise assertions about integrity or other characteristics of the appraised Attester that can be processed by Relying Parties.

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 claims, ?eventLogs | | | |<-- requestAttestation(handle, ?attKeyIDs, ?claimSelection) | | | collectClaims(claims, ?claimSelection) | | => collectedClaims | | | generateEvidence(handle, ?attKeyIDs, collectedClaims) | | => evidence | | | | evidence, ?eventLogs ------------------------------------->| | | ==========================[Evidence Appraisal]========================== | | | appraiseEvidence(evidence, ?eventLogs, refValues) | attestationResult <= | | | ]]> The Attester boots up and thereby produces Claims about its boot state and its operational state. 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 initiated by the Verifier by sending a remote attestation request to the Attester. 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. The Verifier-generated nonce is intended to guarantee Evidence freshness and to prevent replay attacks. 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. 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 cryptographically blinded. 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.

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. claims, ?eventLogs | | | | | |<--------------------- requestAttestation(handle, | | ?attKeyIDs, ?claimSelection) | | | | collectClaims(claims, ?claimSelection) | | | => collectedClaims | | | | | generateEvidence(handle, | | ?attKeyIDs, collectedClaims) | | | => evidence | | | | | | {evidence, ?eventLogs} ------------->| | | | | ==========================[Evidence Appraisal]========================== | | | | appraiseEvidence(evidence, | | ?eventLogs, refValues) | | attestationResult <= | | | | | |<------------------ attestationResult | | | | | | {evidence, attestationResult} ------------------------>| | | | ====================[Attestation Result Generation]===================== | | | | | 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. {claims, ?eventLogs} | | | | | collectClaims(claims, | | ?claimSelection) | | | => collectedClaims | | | | | generateEvidence(handle, | | ?attKeyIDs, collectedClaims) | | | => evidence | | | | | | {evidence, ?eventLogs} ---------->| | | | | ==========================[Evidence Appraisal]========================== | | | | | {handle, evidence, | | | ?eventLogs} -------->| | | | | | appraiseEvidence(evidence, | | ?eventLogs, refValues) | | attestationResult <= | | | | | |<---------- {evidence, | | | attestationResult} | | | | ====================[Attestation Result Generation]===================== | | | | appraiseResult(policy, | | attestationResult) | | | | ]]>

Uni-Directional Remote Attestation handle | | | | |<---------------------------- {handle} | {handle} --------->| | | | | x | | | =================[Evidence Generation and Conveyance]=================== | | generateClaims(attestingEnvironment) | | => claims, eventLogs | | | collectClaims(claims, claimSelection) | | => collectedClaims | | | generateEvidence(handle, attKeyIDs, collectedClaims) | | => evidence | | | | {evidence, eventLogs} ------------------------------------>| | | ==========================[Evidence Appraisal]========================== | | | appraiseEvidence(evidence, | eventLogs, | refValues) | attestationResult <= | ~ ~ | | .--------[loop]------------------------------------------------------. | | | | | =============[Delta Evidence Generation and Conveyance]============= | | | | | | generateClaims(attestingEnvironment) | | | | => claimsDelta, eventLogsDelta | | | | | | | collectClaims(claimsDelta, claimSelection) | | | | => collectedClaimsDelta | | | | | | | generateEvidence(handle, attKeyIDs, collectedClaimsDelta) | | | | => evidence | | | | | | | | {evidence, eventLogsDelta} ------------------------------->| | | | | | | =====================[Delta Evidence Appraisal]===================== | | | | | | | appraiseEvidence(evidence, | | | eventLogsDelta, | | | refValues) | | | 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 or the emission of a beacon). 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 created and used always remains as the distinguishing quality of this model. 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 3rd entity -- 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. Correspondingly, conveyed Evidence in this model provides a proof that it was fresh at a certain point in time. While periodically pushing Evidence to the Verifier, the Attester only needs to generate and convey evidence generated from Claim values that have changed and new Event Log entries since the previous conveyance. These updates reflecting the differences are called "delta" in the sequence diagram above. 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 observer pattern () and the publish-subscribe pattern (). It entails establishing subscription states to enable continuous remote attestation. The observer pattern directly connects observers to subjects without a broker, while the publish-subscribe pattern involves a central broker for message distribution. In the following Subsections, streaming remote attestation without a broker (observer pattern) as well as with a broker (publish-subscribe pattern) are illustrated.

Streaming Remote Attestation without a Broker | | | =================[Evidence Generation and Conveyance]=================== | | generateClaims(attestingEnvironment) | | => claims, eventLogs | | | collectClaims(claims, claimSelection) | | => collectedClaims | | | generateEvidence(handle, attKeyIDs, collectedClaims) | | => evidence | | | ==========================[Evidence Appraisal]========================== | | | {handle, evidence, eventLogs} ---------------------------->| | | | appraiseEvidence(evidence, | eventLogs, | refValues) | attestationResult <= | ~ ~ | | .--------[loop]------------------------------------------------------. | | | | | =============[Delta Evidence Generation and Conveyance]============= | | | | | | generateClaims(attestingEnvironment) | | | | => claimsDelta, eventLogsDelta | | | | | | | collectClaims(claimsDelta, claimSelection) | | | | => collectedClaimsDelta | | | | | | | generateEvidence(handle, attKeyIDs, collectedClaimsDelta) | | | | => evidence | | | | | | | =====================[Delta Evidence Appraisal]===================== | | | | | | | {evidence, eventLogsDelta} ------------------------------->| | | | | | | | appraiseEvidence(evidence, | | | eventLogsDelta, | | | refValues) | | | attestationResult <= | | | | | | '--------------------------------------------------------------------' | | ]]> The observer pattern is employed in scenarios where message delivery does not involve a central broker. Instead, an observer directly subscribes to observed resources via a dedicated mechanism. Consequently, these dedicated mechanisms contain information about the observer and are responsible for maintaining subscription state. 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. While a Handle Distributor is not mandatory in this model, the model is also limited to bi-lateral subscription relationships, in which each Verifier has to create and provide Handles individually. 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.

Streaming Remote Attestation with a Broker The publish-subscribe messaging pattern is widely used for communication in different areas. Unlike the Streaming Remote Attestation without a Broker interaction model, Attesters do not (need 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 the particular publish-subscribe model and implementation, clients can be either publishers or subscribers or both. 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 | | | |<------------ 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 provided by a Verifier on a per-request basis. In the sequence diagram above, an Attester subscribes to the "AttReq" (= Attestation Request) topic on the PubSub server. The Verifier publishes a Handle to the "AttReq" topic, which the PubSub server forwards to the Attester by notifying it.

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) ------->| | | | ~ ~ ~ ]]> The Uni-Directional Remote Attestation over Publish-Subscribe model uses the same information elements as the Uni-Directional Remote Attestation model. Accordingly, Handles are created by a 3rd party, the Handle Distributor. 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 claims, eventLogs | | | | | | | | | collectClaims(claims, claimSelection) | | | | | => collectedClaims | | | | | | | | | generateEvidence(handle, attKeyIDs, | | | | | collectedClaims) | | | | | => evidence | | | | | | | | | pub(topic=AttEv, | | | | | evidence, eventLogs) ------------>| | | | | | | | | | notify(topic=AttEv, | | | | | evidence, | | | | | eventLogs) ---------->| | | | | | | | ========================[Evidence Appraisal]======================== | | | | | | | | | appraiseEvidence( | | | | evidence, | | | | eventLogs, | | | | refValues) | | | | attestationResult <= | | | | | | | | ==================[Attestation Result Generation]=================== | | | | | | | | |<--------- pub(topic=AttRes, | | | | 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. Verifiers appraise the Evidence and publish the Attestation Result to topic "AttRes" (= Attestation Result) on the PubSub server.

Attestation Result Generation | | | | | | .--------[loop]------------------------------------------------------. | | | | | | | | | |<--------- pub(topic=AttRes, | | | | | attestationResult) | | | | | | | | | |<----------------- notify(topic=AttRes | | | | | | 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.

Publish/Subscribe Topics Many publish-subscribe models provide hierarchical organization of topics. This way, subscribers can subscribe to either all attestations (topic AttRes), or, for example, to topic AttRes/DbServers/Germany to receive only attestations from database servers in Germany. Further, it may be required to distinguish between uni-directional and challenge-response attestation evidence.

Additional Application-Specific Requirements Depending on the use cases covered, there can be additional requirements. An exemplary subset is illustrated in this section.

Confidentiality Confidentiality of exchanged attestation information may be desirable. This requirement usually is present when communication takes place over insecure channels, such as the public Internet. In such cases, TLS may be used as a suitable communication protocol which provides confidentiality protection. In private networks, such as carrier management networks, it must be evaluated whether or not the transport medium is considered confidential.

Mutual Authentication In particular use cases, mutual authentication may be desirable in such a way that a Verifier also needs to prove its identity to the Attester, instead of only the Attester proving its identity to the Verifier.

Hardware-Enforcement/Support Depending on given usage scenarios, hardware support for secure storage of cryptographic keys, crypto accelerators, as well as protected or isolated execution environments can be mandatory requirements. Well-known technologies in support of these requirements are roots of trusts, such as Hardware Security Modules (HSM), Physically Unclonable Functions (PUFs), Shielded Secrets, or Trusted Executions Environments (TEEs).

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 In a remote attestation procedure the Verifier or the Attester MAY want to cryptographically blind several attributes. For instance, information can be part of the signature after applying a one-way function (e. g., a hash function). There is also a possibility to scramble the Nonce or Attester Identity with other information that is known to both the Verifier and Attester. A prominent example is the IP address of the Attester that usually is known by the Attester itself as well as the Verifier. This extra information can be used to scramble the Nonce in order to counter certain types of relay attacks.

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. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. 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 Arm Limited Huawei Technologies Universität Bremen TZI This document defines Epoch Markers as a way 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, the Epoch Bell. Systems that receive Epoch Markers do not have to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a certain Epoch Marker establishes a new epoch that is shared between all recipients. 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 Juniper Networks, Inc. Cisco Systems National Security Agency This document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules [TPM1.2], [TPM2.0], as defined by the Trusted Computing Group (TCG)), or equivalent hardware implementations that include the protected capabilities, as provided by TPMs. 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.

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. charra-bodies = charra-attestation-request / charra-attestation-response charra-attestation-request = [ hello: bool, ; if true, the TPM 2.0 AK Cert shall be conveyed key-id: bytes, ; the key ID to use for signing nonce: bytes, ; a (random) nonce, providing freshness and/or recentness pcr-selections: [ * pcr-selection ] ] pcr-selection = [ tcg-hash-alg-id: uint .size 2, ; TPM2_ALG_ID pcrs: [ pcr: uint .size 2 ] ] charra-attestation-response = [ attestation-data: bytes, ; TPMS_ATTEST.quoted tpm2-signature: bytes, ? ak-cert: bytes, ; TPM2 attestation key certificate (AK Cert) ]