wdiff draft-ietf-rats-reference-interaction-models-01.txt draft-ietf-rats-reference-interaction-models-02.txt

RATS Working Group H. Birkholz
Internet-Draft M. Eckel
Intended status: Informational Fraunhofer SIT
Expires: 28 October 2021 W. Pan
Huawei Technologies
E. Voit
Cisco
26 April 26, 2021 C. Newton
L. Chen
University of Surrey
October 23, 2020

Reference Interaction Models for Remote Attestation Procedures
draft-ietf-rats-reference-interaction-models-01
draft-ietf-rats-reference-interaction-models-02

Abstract

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. Privacy preserving conveyance of Evidence via Direct
Anonymous Attestation is elaborated on in the context of the
Attester, Endorser, and Verifier role.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 26, 28 October 2021.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.
2.1. Disambiguation . . . . . . . . . . . . . . . . . . . . . . . 4
4.
3. Scope and Intent . . . . . . . . . . . . . . . . . . . . . . 4
5. Direct Anonymous Attestation . . . . . . . . . . .
4. Essential Requirements . . . . . 5
5.1. Endorsers . . . . . . . . . . . . . . 5
4.1. Endorsement of Attesting Environments . . . . . . . . . . 5
5.2. Endorsers for Direct Anonymous Attestation . . . . . . . 6
6.
5. Normative Prerequisites . . . . . . . . . . . . . . . . . . . 6
7.
6. Generic Information Elements . . . . . . . . . . . . . . . . 7
8.
7. Interaction Models . . . . . . . . . . . . . . . . . . . . . 9
8.1.
7.1. Challenge/Response Remote Attestation . . . . . . . . . . 10
8.2. 9
7.2. Uni-Directional Remote Attestation . . . . . . . . . . . 12
8.3. 11
7.3. Streaming Remote Attestation . . . . . . . . . . . . . . 13
9.
8. Additional Application-Specific Requirements . . . . . . . . 15
9.1.
8.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 15
9.2.
8.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 15
9.3.
8.3. Hardware-Enforcement/Support . . . . . . . . . . . . . . 15
10.
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
10.1.
9.1. Implementer . . . . . . . . . . . . . . . . . . . . . . . 16
10.2.
9.2. Implementation Name . . . . . . . . . . . . . . . . . . . 16
10.3.
9.3. Implementation URL . . . . . . . . . . . . . . . . . . . 16
10.4.
9.4. Maturity . . . . . . . . . . . . . . . . . . . . . . . . 16
10.5.
9.5. Coverage and Version Compatibility . . . . . . . . . . . 16
10.6.
9.6. License . . . . . . . . . . . . . . . . . . . . . . . . 16
10.7. . 17
9.7. Implementation Dependencies . . . . . . . . . . . . . . 16
10.8. . 17
9.8. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.
10. Security and Privacy Considerations . . . . . . . . . . . . . 17
12.
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
14.1. 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 19
14.2. 17
12.2. Informative References . . . . . . . . . . . . . . . . . 20 18
Appendix A. CDDL Specification for a simple CoAP
Challenge/Response Challenge/
Response Interaction . . . . . . . . . . . 21 . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 20

1. Introduction

Remote ATtestation procedureS (RATS, [I-D.ietf-rats-architecture])
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 created based on 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 [I-D.ietf-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. Specific goals of this document are to:

1.) prevent inconsistencies in descriptions of interaction models in
other documents (due to text cloning and evolution over time),

o and to
2.) enable to highlight an exact delta/divergence between the core
set of characteristics captured here in this document and variants of
these interaction models used in other specifications or
solutions, and to

o illustrate the application of Direct Anonymous Attestation (DAA)
for the defined set of reference models. 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 methods described can
also be applied to the conveyance of, for example, Endorsements or
Attestation Results.

2. Terminology

This document uses the following set of terms, roles, and concepts as
defined in [I-D.ietf-rats-architecture]: Attester, Verifier, Relying
Party, Conceptual Message, Evidence, Endorsement, Attestation Result,
Appraisal Policy, Attesting Environment, Target Environment

A PKIX Certificate is an X.509v3 format certificate as specified by
[RFC5280].

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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

2.1. Disambiguation

The term "Remote Attestation" is a common expression and often
associated or connoted with certain properties. The term "Remote" in
this context does not necessarily refer to a remote entity in the
scope of network topologies or the Internet. It rather refers to a
decoupled system systems or entities that exchange the payload of the
Conceptual Message type called Evidence [I-D.ietf-rats-architecture].
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).
Examples Even
if an entity takes on two or more different roles, the functions they
provide typically reside in isolated environments that are components
of these types the same entity. Examples of co-located 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)). Readers of
this document should be familiar with the concept of Layered
Attestation as described in Section 4.3 3.1 Two Types of Environments of
an Attester in [I-D.ietf-rats-architecture] and the definition of
Attestation as described in
[I-D.ietf-rats-tpm-based-network-device-attest].

3. Scope and Intent

This document focuses on generic interaction models between Attesters
and Verifiers in order to convey Evidence. Complementary procedures,
functions, or services that are required for a complete semantic
binding of the concepts defined in [I-D.ietf-rats-architecture] are
out-of-scope of this document. Examples include: identity
establishment, key distribution and enrollment, time synchronization,
as well as certificate revocation.

Furthermore, any processes and duties that go beyond carrying out
remote attestation procedures are out-of-scope.

For instance, using the results of a remote attestation procedure
that are created by the Verifier, e.g., how to triggering remediation
actions or recovery processes, as well as such remediation actions
and recovery processes themselves, are also out-of-scope.

The interaction models illustrated in this document are intended to
provide a stable basis and reference for other solutions documents
inside or outside the IETF. Solution documents of any kind can
reference the interaction models in order to avoid text clones and to
avoid the danger of subtle discrepancies. Analogously, deviations
from the generic model descriptions in this document can be
illustrated in solutions documents to highlight distinct
contributions.

5. Direct Anonymous Attestation

DAA [DAA] is a signature scheme used in RATS that allows preservation
of the privacy

4. Essential Requirements

In order to ensure appropriate conveyance of users that are associated with Evidence, there exist
essential requirements which MUST be fulfilled:

Integrity: Information provided by an Attester (e.g.
its owner). Essentially, DAA can MUST be seen as a group signature scheme
with the feature that given integral.
This may be achieved by means of a DAA digital signature no-one can find out who
the signer is, i.e., the anonymity is not revocable. To be able to
sign anonymously an Attester has to obtain a credential from a DAA
Issuer. over
Attestation Evidence. The DAA Issuer uses a private/public key pair to generate a
credential for an Attester and makes the public key (in the form of a
public key certificate) available to the verifier in order to enable
them to validate the DAA signature obtained may be symmetric, such as part of the Evidence.

In order to support these DAA signatures, the DAA Issuer MUST
associate a single key pair with each group of Attesters and use the
same key pair when creating the credentials for all of the Attesters
in this group. an
HMAC, or asymmetric, such as ECDSA.

Authentication: The DAA Issuer's public key certificate used information provided by a
group of Attesters replaces the individual Attester Identity
documents during authenticity validation as a part of MUST be
authentic. For that purpose, the Attester should authenticate
itself to the appraisal
of Evidence conducted by a Verifier. This is in contrast to
intuition that there has to may be a unique Attester Identity per device.

This document extends the duties an implicit authentication by
means of a digital signature over the Endorser role as defined Attestation Evidence, which
does not require additional protocol steps, or may be achieved by
the RATS architecture with respect to the provision of these Attester
Identity documents to Attesters. The existing duties
using a confidential channel by means of the Endorser
role and the duties encryption.

4.1. Endorsement of a DAA Issuer are quite similar as illustrated
in the following subsections.

5.1. Endorsers Attesting Environments

Via its Attesting Environments, an Attester only generates Evidence
about its Target Environments. After being appraised to be
trustworthy, a Target Environment may become a new Attesting
Environment in charge of generating Evidence for further Target
Environments. [I-D.ietf-rats-architecture] explains this as Layered
Attestation. Layered Attestation has to start with an initial
Attesting Environment. In essence, there cannot be turtles all the
way down [turtles]. At this rock bottom of Layered Attestation, the
Attesting Environments are always called Roots of Trust (RoT). An
Attester cannot generate Evidence about its own RoTs by design. As a
consequence, a Verifier requires trustable statements about this
subset of Attesting Environments from a different source than the
Attester itself. The corresponding trustable statements are called
Endorsements and originate from external, trustable entities that
take on the role of an Endorser (e.g., supply chain entities).

5.2. Endorsers for Direct Anonymous Attestation

In order to enable the use of DAA, an Endorser role takes on the
duties of a DAA Issuer in addition to its already defined duties.
DAA Issuers offer zero-knowledge proofs based on public key
certificates used for a group of Attesters [DAA]. Effectively, these
certificates share the semantics of Endorsements, with the following
exceptions:

o The associated private keys are used by the DAA Issuer to provide
an Attester with a credential that it can use to convince the
Verifier that its Evidence is valid. To keep their anonymity the
Attester randomizes this credential each time that it is used.

o The Verifier can use the DAA Issuer's public key certificate,
together with the randomized credential from the Attester, to
confirm that the Evidence comes from a valid Attester.

o A credential is conveyed from an Endorser to an Attester in
combination with the conveyance of the public key certificates
from Endorser to Verifier.

The zero-knowledge proofs required cannot be created by an Attester
alone - like statements about this
subset of Attesting Environments from a different source than the
Attester itself. The corresponding trustable statements are called
Endorsements of RoTs - and have to be created by a originate from external, trustable third entity - like an Endorser. Due to entities that semantic
overlap,
take on the Endorser role is augmented via the definition of DAA
duties as defined below. This augmentation enables the an Endorser to
convey trustable third party statements both to Verifier roles and
Attester roles.

6. (e.g., supply chain entities).

5. Normative Prerequisites

In order to ensure an appropriate conveyance of Evidence via
interaction models in general, the following set of prerequisites
MUST be in place to support the implementation of interaction models:

Attester Identity: A statement about a distinguishable Attester made
by an Endorser without accompanying evidence about its validity,
used as proof of identity.

The provenance of Evidence with respect to a distinguishable
Attesting Environment MUST be correct and unambiguous.

An Attester Identity MAY be a unique identity, it MAY be included in
a zero-knowledge proof (ZKP), or it MAY be part of a group signature, or
it MAY be a randomised randomized DAA credential. credential [DAA].

Attestation Evidence Authenticity: Attestation Evidence MUST be
correct and
authentic.

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

Authentication Secret: An Authentication Secret MUST be available
exclusively to an Attester's Attesting Environment.

The Attester MUST protect Claims with that Authentication Secret,
thereby proving the authenticity of the Claims included in
Evidence. The Authentication Secret MUST be established before
RATS can take place.

Evidence Freshness: Evidence MUST include an indicator about its
freshness that can be understood by a Verifier. Analogously,
interaction models MUST 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.

6. Generic Information Elements

This section defines the information elements that are vital to all
kinds interaction models. Varying from solution to solution, generic
information elements can be either included in the scope of protocol
messages (instantiating Conceptual Messages) or can be included in
additional protocol parameters or payload. Ultimately, the following
information elements are required by any kind of scalable remote
attestation procedure using one or more of the interaction models
provided.

Attester Identity ('attesterIdentity'): _mandatory_

A statement about a distinguishable Attester made by an Endorser
without accompanying evidence about its validity - used as proof
of identity.

In DAA, the Attester's identity is not revealed to the verifier.
The Attester is issued with a credential by the Endorser that is
randomised and then used to anonymously confirm the validity of
their evidence. The evidence is verified using the Endorser's
public key.

Authentication Secret IDs ('authSecID'): ('authSecIDs'): _mandatory_

A statement representing an identifier list that MUST be
associated with corresponding Authentication Secrets used to
protect Evidence.

In DAA, Authentication Secret IDs are represented by the Endorser
(DAA issuer)'s public key that MUST be used to create DAA
credentials for the corresponding Authentication Secrets used to
protect Claims included in Evidence.

Each Authentication Secret is uniquely associated with a
distinguishable Attesting Environment. Consequently, an
Authentication Secret ID also identifies an Attesting Environment.

In DAA, an Authentication Secret ID does not identify a unique
Attesting Environment but associated with a group of Attesting
Environments. This is because an Attesting Environment should not
be distinguishable and the DAA credential which represents the
Attesting Environment is randomised each time it used.

Handle ('handle'): _mandatory_

A statement that is intended to uniquely distinguish received
Evidence and/or determine the freshness of Evidence.

A Verifier can also use a Handle as an indicator for authenticity
or attestation provenance, as only Attesters and Verifiers that
are intended to exchange Evidence should have knowledge of the
corresponding Handles. Examples include Nonces or signed
timestamps.

Claims ('claims'): _mandatory_

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

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

Reference Claims ('refClaims') _mandatory_
Reference

Event Logs ('eventLogs'): _optional_

Event Logs accompany Claims are components by providing event trails of Reference Values as defined security-
critical events in
[I-D.ietf-rats-architecture]. [Editor's Note: Definition might
become obsolete, if replaced by Reference Values. Is there a
difference between system. The primary purpose of Event Logs is
to support Claim reproducibility by providing information on how
Claims and originated.

Reference Values here? Analogously, why is
not named ('refValues') _mandatory_

Reference Claims Values as defined in the RATS arch?]

Reference [I-D.ietf-rats-architecture]. This
specific type of Claims are is used to appraise the Claims received from an
Attester via appraisal by direct comparison. incorporated in
Evidence. For example, Reference Claims Values MAY be Reference
Integrity Measurements (RIM) or assertions that are implicitly
trusted because they are signed by a trusted authority (see
Endorsements in [I-D.ietf-rats-architecture]). Reference Claims Values
typically represent (trusted) Claim sets about an Attester's
intended platform operational state.

Claim Selection ('claimSelection'): _optional_

A statement that represents a (sub-)set of Claims that which can be created by an Attester.

Claim Selections can act as filters that can to specify the exact set of Claims
to be included in Evidence. In a remote attestation process, a
Verifier sends a Claim Selection, among other elements, to an
Attester. An Attester MAY decide whether or not to provide all Claims as
requested via Claims from a Claim Selection 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 Claims selected in the
Claim Selection. If a Verifier does not provide a Claim
Selection, then all available Claims on the Attester are part of
the Collected Claims.

Evidence ('signedAttestationEvidence'): ('evidence'): _mandatory_

A set of Claims that consists of a list of Authentication Secret
IDs that each identifies an Authentication Secret in a single
Attesting Environment, the Attester Identity, Claims, and 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 authoritative.

Attestation Result ('attestationResult'): _mandatory_

An Attestation Result is produced by the Verifier as the output of
the appraisal of Evidence. Attestation Results include condensed
assertions about integrity or other characteristics of the
corresponding Attester that are digestable processible by Relying Parties.

7. Interaction Models

The following subsections introduce and illustrate the interaction
models:

1. Challenge/Response Remote Attestation

2. Uni-Directional Remote Attestation

3. Streaming Remote Attestation

Each section starts with a sequence diagram illustrating the
interactions between Attester and Verifier. While the presented
interaction models presented focus on the conveyance of Evidence, the intention
of this document is in support of future work that applies the
presented models to the conveyance of other Conceptual Messages,
namely Attestation Results, Endorsements, Reference Values, or
Appraisal Policies.

All interaction models have a strong focus on the use of a handle to
incorporate a type of proof of freshness. freshness and to prevent replay
attacks. The ways way these handles are processed is the most prominent
difference between the three interaction models.

8.1.

7.1. Challenge/Response Remote Attestation
.----------. .----------.
| Attester | | Verifier |
'----------' '----------'
| |
| |
valueGeneration(targetEnvironment)
generateClaims(attestingEnvironment) |
| => claims claims, eventLogs |
| |
| <------requestEvidence(handle, <-- requestAttestation(handle, authSecIDs, claimSelection) |
| |
claimsCollection(claimSelection)
collectClaims(claims, claimSelection) |
| => collectedClaims |
| |
evidenceGeneration(handle,
generateEvidence(handle, authSecIDs, collectedClaims) |
| => evidence |
| |
| returnEvidence-------------------------------------------> | evidence, eventLogs -------------------------------------> | returnEventLog------------------------------------------->
| |
|
| evidenceAppraisal(evidence, eventLog, refClaims) appraiseEvidence(evidence, eventLogs, refValues)
| attestationResult <= |
| |

This

The Attester boots up and thereby produces claims about its boot
state and its operational state. Event Logs accompany the produced
claims by providing an event trail of security-critical events in a
system. Claims are produced by all attesting Environments of an
Attester system.

The Challenge/Response Remote Attestation remote attestation procedure is initiated by
the Verifier, Verifier by sending a remote attestation request to the Attester.
A request includes a Handle, a list of Authentication Secret IDs, and
a 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 strongly randomly generated,
and therefore unpredictable, nonce. strong random number. The Verifier-generated
nonce is intended to guarantee Evidence freshness. freshness and to prevent
replay attacks.

The list of Authentication Secret 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 Authentication
Secret ID identifies a single Attesting Environment.

Analogously,
Correspondingly, a particular set of Evidence originating from a
particular Attesting Environments Environment in a composite device can be
requested via multiple Authentication Secret IDs. Methods to acquire
Authentication Secret IDs or mappings between Attesting Environments
to Authentication Secret IDs are out-of-scope of this document.

The Attester collects Claims based on the Claim Selection. With the
Claim Selection narrows down the Verifier defines the set of Claims it requires.
Correspondingly, collected and used
to create Evidence to those that Claims can be a subset of the Verifier requires. produced
Claims. This could be all available Claims, depending on the Claim
Selection. If the Claim Selection is omitted, then by default all
Claims that are known and available on the Attester MUST be used to
create corresponding Evidence. For example example, when performing a boot
integrity evaluation, a Verifier may only be requesting a particular
subset of claims about the Attester, such as Evidence about BIOS BIOS/UEFI
and firmware that the Attester booted up, and not include information
about all currently running
software. currently running software.

With the Handle, the Authentication Secret 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 Authentication Secret ID. This is done once per
Attesting Environment which is identified by the particular
Authentication Secret ID. The Attester communicates the signed
Evidence as well as all accompanying Event Logs back to the Verifier.

While it is crucial that Claims, the Handle, as well as and the Attester
Identity information MUST be cryptographically bound to the signature
of Evidence, they may be presented in an encrypted form.

Cryptographic blinding MAY be used at this point. presented obfuscated, encrypted, or
cryptographically blinded. For further reference see section
Section 11. 10.

As soon as the Verifier receives the signed Evidence, Evidence and Event Logs,
it appraises the Evidence. For this purpose, it validates the
signature, the Attester Identity, as well as and the Nonce, Handle, and then appraises
the Claims. Appraisal procedures are application-specific and can be
conducted via comparison of the Claims with corresponding Reference
Claims,
Values, such as Reference Integrity Measurements. The final output
of the Verifier are Attestation Results. Attestation Results
constitute new Claims Claim Sets about an Attester's the properties and characteristics that of
an Attester, which enables Relying Parties, for example, to assess an
Attester's trustworthiness.

8.2.

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 Evidence from the Verifier would result in a sequence diagram more
similar to the Challenge/Response model (comparable with a RESTful
GET operation), the operation). The specific manner how handles Handles are created and used
always remains as the distinguishing quality of this model.

In the Uni-Directional model, handles are composed of trustable
cryptographically signed trusted timestamps as shown in
[I-D.birkholz-rats-tuda], potentially including other qualifying
data. The handles Handles are created by an external 3rd entity - -- the
Handle Distributor - that -- which includes a trustworthy source of time time,
and takes on the role of a Time Stamping Authority (TSA, as initially
defined in [RFC3161]). Timstamps 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 every evidence created. all produced Evidence. Correspondingly, evidence created for conveyance via 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 Logs entries since the
previous conveyance. This updates reflecting the differences are
called "delta" in the sequence diagram above.

Effectively, this the Uni-Directional model allows for a series of evidence
Evidence to be pushed to multiple Verifiers, simultaniously. Verifiers simultaneously. Methods
to detect excessive time drift that would mandate a fresh Handle to
be received by the Handle
Distributor, Distributor as well as timing of handle Handle
distribution are out-of-
scope out-of-scope of this document.

8.3.

Streaming Remote Attestation procedures require the setup of
subscription state. Setting up subscription state between a Verifier
and an Attester is conducted via a subscribe operation. This The
subscribe operation is used to convey the handles required Handles for
Evidence generation. producing
Evidence. Effectively, this allows for a series of evidence Evidence to be
pushed to a Verifier Verifier, similar to the Uni-Directional model. While a
Handle Distributor is not required in this model, it is also limited
to bi-lateral subscription relationships, relationships in which each Verifier has
to create and provide its individual handle. Handle. Handles provided by a
specific subscribing Verifier MUST be used in Evidence generation for
that specific Verifier. The Streaming model uses the same
information elements as the Challenge/Response and the Uni-
Directional model. Methods to detect excessive time drift that would
mandate a refreshed Handle to be conveyed via another subscribe
operation are out-of-scope of this document.

8. Additional Application-Specific Requirements

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

9.1.

8.1. 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 uses used as a suitable communication protocol that
preserves confidentiality.
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.

9.2.

8.2. Mutual Authentication

In particular use cases 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.

9.3.

8.3. 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).

10.

9. Implementation Status

Note to RFC Editor: Please remove this section as well as references
to [BCP205] 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 [BCP205].
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 [BCP205], "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".

10.1.

9.1. Implementer

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

10.2.

9.2. Implementation Name

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

10.3.

9.3. Implementation URL

The open-source implementation project resource can be located via:
https://github.com/Fraunhofer-SIT/charra

10.4.

9.4. Maturity

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

10.5.

9.5. Coverage and Version Compatibility

The current version ('1bcb469') implements a challenge/response
interaction model and is aligned with the exemplary specification of
the CoAP FETCH bodies defined in Section Appendix A of this document.

10.6.

9.6. License

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

10.7.

9.7. Implementation Dependencies

The implementation requires the use of the official Trusted Computing
Group (TCG) open-source Trusted Software Stack (TSS) for the Trusted
Platform Module (TPM) 2.0. The corresponding code and data is also
maintained on github GitHub and the project resources can be located via:
https://github.com/tpm2-software/tpm2-tss/

The implementation uses the Constrained Application Protocol
[RFC7252] (http://coap.technology/) and the Concise Binary Object
Representation [RFC7049] (https://cbor.io/).

10.8.

9.8. Contact

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

11.

10. 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.

12.

11. Acknowledgments

Olaf Bergmann, Michael Richardson, and Ned Smith

13. Change Log

o Initial draft -00

o Changes from version 00 to version 01:

* Added details to the flow diagram

* Integrated comments from Ned Smith (Intel)

* Reorganized sections and

* Updated interaction model

* Replaced "claims" with "assertions"

* Added proof-of-concept CDDL for CBOR via CoAP based on a TPM
2.0 quote operation

o Changes from version 01 to version 02:

* Revised the relabeling of "claims" with "assertion" in
alignment with the RATS Architecture I-D.

* Added Implementation Status section

* Updated interaction model

* Text revisions based on changes in [I-D.ietf-rats-architecture]
and comments provided on rats@ietf.org.

o Changes from version 02 to version 00 RATS related document

* update of the challenge/response diagram

* minor rephrasing of Prerequisites section

* rephrasing to information elements and interaction model
section

o Changes from version 00 to version 01

* added Attestation Authenticity, updated Identity and Secret

* relabeled Secret ID to Authentication Secret ID + rephrasing

* relabeled Claim Selection to Assertion Selection + rephrasing

* relabeled Evidence to (Signed) Attestation Evidence

* Added Attestation Result and Reference Assertions

* update of the challenge/response diagram and expositional text

* added CDDL spec for CoAP FETCH operation proof-of-concept

o Changes from version 01 to version 02

* prepared the inclusion of additional reference models

* update to Introduction and Scope section

* major update to (Normative) Prerequisites

* relabeled Attestation Authenticity to Att. Evidence
Authenticity

* relabeled Assertion term back to Claim terms
* added BCP205 Implementation Status section related to
Appendix CDDL

o Changes from version 02 to version 03

* major refactoring to now accommodate three interaction models

* updated existing and added two new diagrams for models

* major refactoring of existing and adding of new diagram
description

* incorporated content about Direct Anonymous Attestation

* integrated comments from Michael Richardson

* updated roster

14.

12. References

14.1.

12.1. Normative References

[BCP205] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August
2001, <https://www.rfc-editor.org/info/rfc3161>.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.

[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.

[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.

14.2.

12.2. Informative References

[DAA] Brickell, E., Camenisch, J., and L. Chen, "Direct
Anonymous Attestation", page 132-145, ACM Proceedings of
the 11rd ACM conference on Computer and Communications Security ,
page 132-145,
Security, 2004.

[I-D.birkholz-rats-tuda]
Fuchs, A., Birkholz, H., McDonald, I., I. E., and C. Bormann,
"Time-Based Uni-Directional Attestation", draft-birkholz-
rats-tuda-03 (work Work in progress), July 2020.
Progress, Internet-Draft, draft-birkholz-rats-tuda-04, 13
January 2021, <https://www.ietf.org/archive/id/draft-
birkholz-rats-tuda-04.txt>.

[I-D.ietf-rats-architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture",
draft-ietf-rats-architecture-07 (work Work
in progress),
October 2020. Progress, Internet-Draft, draft-ietf-rats-architecture-
12, 23 April 2021, <https://www.ietf.org/archive/id/draft-
ietf-rats-architecture-12.txt>.

[I-D.ietf-rats-tpm-based-network-device-attest]
Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM-
based Network Device Remote Integrity Verification",
draft-ietf-rats-tpm-based-network-device-attest-04 (work Work
in progress), September 2020. Progress, Internet-Draft, draft-ietf-rats-tpm-based-
network-device-attest-06, 7 December 2020,
<https://www.ietf.org/archive/id/draft-ietf-rats-tpm-
based-network-device-attest-06.txt>.

[turtles] Rudnicki, R., "Turtles All the Way Down: Foundation,
Edifice, and Ruin in Faulkner and McCarthy",
DOI 10.1353/fau.2010.0002, The Faulkner Journal 25.2, DOI 10.1353/fau.2010.0002, 2010.
2010, <https://doi.org/10.1353/fau.2010.0002>.

Appendix A. 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 transfer protocol used is CoAP using the
FETCH operation. The actual resource operated on can be empty. Both
the Challenge 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.

RAIM-Bodies = CoAP-FETCH-Body / CoAP-FETCH-Response-Body

CoAP-FETCH-Body = [ hello: bool, ; if true, the AK-Cert is conveyed
nonce: bytes,
pcr-selection: [ + [ tcg-hash-alg-id: uint .size 2, ; TPM2_ALG_ID
[ + pcr: uint .size 1 ],
]
],
]

CoAP-FETCH-Response-Body = [ attestation-evidence: TPMS_ATTEST-quote,
tpm-native-signature: bytes,
? ak-cert: bytes, ; attestation key certificate
]

TPMS_ATTEST-quote = [ qualifiediSigner: uint .size 2, ;TPM2B_NAME
TPMS_CLOCK_INFO,
firmwareVersion: uint .size 8
quote-responses: [ * [ pcr: uint .size 1,
+ [ pcr-value: bytes,
? hash-alg-id: uint .size 2,
],
],
? pcr-digest: bytes,
],
]

TPMS_CLOCK_INFO = [ clock: uint .size 8,
resetCounter: uint .size 4,
restartCounter: uint .size 4,
save: bool,
]

Authors' Addresses

Henk Birkholz
Fraunhofer SIT
Rheinstrasse 75
Darmstadt
64295 Darmstadt
Germany

Email: henk.birkholz@sit.fraunhofer.de
Michael Eckel
Fraunhofer SIT
Rheinstrasse 75
Darmstadt
64295 Darmstadt
Germany

Email: michael.eckel@sit.fraunhofer.de

Christopher Newton
University of Surrey

Wei Pan
Huawei Technologies

Email: cn0016@surrey.ac.uk

Liqun Chen
University of Surrey william.panwei@huawei.com

Eric Voit
Cisco Systems

Email: liqun.chen@surrey.ac.uk evoit@cisco.com