draft-ietf-rats-reference-interaction-models-00.txt   draft-ietf-rats-reference-interaction-models-01.txt 
RATS Working Group H. Birkholz RATS Working Group H. Birkholz
Internet-Draft M. Eckel Internet-Draft M. Eckel
Intended status: Informational Fraunhofer SIT Intended status: Informational Fraunhofer SIT
Expires: March 13, 2021 C. Newton Expires: April 26, 2021 C. Newton
L. Chen L. Chen
University of Surrey University of Surrey
September 09, 2020 October 23, 2020
Reference Interaction Models for Remote Attestation Procedures Reference Interaction Models for Remote Attestation Procedures
draft-ietf-rats-reference-interaction-models-00 draft-ietf-rats-reference-interaction-models-01
Abstract Abstract
This document describes interaction models for remote attestation This document describes interaction models for remote attestation
procedures (RATS). Three conveying mechanisms - Challenge/Response, procedures (RATS). Three conveying mechanisms - Challenge/Response,
Uni-Directional, and Streaming Remote Attestation - are illustrated Uni-Directional, and Streaming Remote Attestation - are illustrated
and defined. Analogously, a general overview about the information and defined. Analogously, a general overview about the information
elements typically used by corresponding conveyance protocols are elements typically used by corresponding conveyance protocols are
highlighted. Privacy preserving conveyance of Evidence via Direct highlighted. Privacy preserving conveyance of Evidence via Direct
Anonymous Attestation is elaborated on for each interaction model, Anonymous Attestation is elaborated on in the context of the
individually. Attester, Endorser, and Verifier role.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 13, 2021. This Internet-Draft will expire on April 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Disambiguation . . . . . . . . . . . . . . . . . . . . . . . 4 3. Disambiguation . . . . . . . . . . . . . . . . . . . . . . . 4
4. Scope and Intent . . . . . . . . . . . . . . . . . . . . . . 4 4. Scope and Intent . . . . . . . . . . . . . . . . . . . . . . 4
5. Direct Anonymous Attestation . . . . . . . . . . . . . . . . 5 5. Direct Anonymous Attestation . . . . . . . . . . . . . . . . 5
5.1. Endorsers . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Endorsers . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Endorsers for Direct Anonymous Attestation . . . . . . . 6 5.2. Endorsers for Direct Anonymous Attestation . . . . . . . 6
6. Normative Prerequisites . . . . . . . . . . . . . . . . . . . 6 6. Normative Prerequisites . . . . . . . . . . . . . . . . . . . 6
7. Generic Information Elements . . . . . . . . . . . . . . . . 7 7. Generic Information Elements . . . . . . . . . . . . . . . . 7
8. Interaction Models . . . . . . . . . . . . . . . . . . . . . 9 8. Interaction Models . . . . . . . . . . . . . . . . . . . . . 9
8.1. Challenge/Response Remote Attestation . . . . . . . . . . 10 8.1. Challenge/Response Remote Attestation . . . . . . . . . . 10
8.2. Uni-Directional Remote Attestation . . . . . . . . . . . 11 8.2. Uni-Directional Remote Attestation . . . . . . . . . . . 12
8.3. Streaming Remote Attestation . . . . . . . . . . . . . . 13 8.3. Streaming Remote Attestation . . . . . . . . . . . . . . 13
9. Additional Application-Specific Requirements . . . . . . . . 15 9. Additional Application-Specific Requirements . . . . . . . . 15
9.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 15 9.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 15
9.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 15 9.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 15
9.3. Hardware-Enforcement/Support . . . . . . . . . . . . . . 15 9.3. Hardware-Enforcement/Support . . . . . . . . . . . . . . 15
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
10.1. Implementer . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Implementer . . . . . . . . . . . . . . . . . . . . . . 16
10.2. Implementation Name . . . . . . . . . . . . . . . . . . 16 10.2. Implementation Name . . . . . . . . . . . . . . . . . . 16
10.3. Implementation URL . . . . . . . . . . . . . . . . . . . 16 10.3. Implementation URL . . . . . . . . . . . . . . . . . . . 16
10.4. Maturity . . . . . . . . . . . . . . . . . . . . . . . . 16 10.4. Maturity . . . . . . . . . . . . . . . . . . . . . . . . 16
skipping to change at page 2, line 46 skipping to change at page 2, line 46
10.6. License . . . . . . . . . . . . . . . . . . . . . . . . 16 10.6. License . . . . . . . . . . . . . . . . . . . . . . . . 16
10.7. Implementation Dependencies . . . . . . . . . . . . . . 16 10.7. Implementation Dependencies . . . . . . . . . . . . . . 16
10.8. Contact . . . . . . . . . . . . . . . . . . . . . . . . 17 10.8. Contact . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Security and Privacy Considerations . . . . . . . . . . . . . 17 11. Security and Privacy Considerations . . . . . . . . . . . . . 17
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
14.1. Normative References . . . . . . . . . . . . . . . . . . 19 14.1. Normative References . . . . . . . . . . . . . . . . . . 19
14.2. Informative References . . . . . . . . . . . . . . . . . 20 14.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. CDDL Specification for a simple CoAP Appendix A. CDDL Specification for a simple CoAP
Challenge/Response Interaction . . . . . . . . . . . 20 Challenge/Response Interaction . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Remote ATtestation procedureS (RATS, [I-D.ietf-rats-architecture]) Remote ATtestation procedureS (RATS, [I-D.ietf-rats-architecture])
are workflows composed of roles and interactions, in which Verifiers are workflows composed of roles and interactions, in which Verifiers
create Attestation Results about the trustworthiness of an Attester's create Attestation Results about the trustworthiness of an Attester's
system component characteristics. The Verifier's assessment in the system component characteristics. The Verifier's assessment in the
form of Attestation Results is created based on Attestation Policies form of Attestation Results is created based on Attestation Policies
and Evidence - trustable and tamper-evident Claims Sets about an and Evidence - trustable and tamper-evident Claims Sets about an
Attester's system component characteristics - created by an Attester. Attester's system component characteristics - generated by an
The roles _Attester_ and _Verifier_, as well as the Conceptual Attester. The roles _Attester_ and _Verifier_, as well as the
Messages _Evidence_ and _Attestation Results_ are terms defined by Conceptual Messages _Evidence_ and _Attestation Results_ are concepts
the RATS Architecture [I-D.ietf-rats-architecture]. This documents defined by the RATS Architecture [I-D.ietf-rats-architecture]. This
captures interaction models that can be used in specific RATS-related document defines interaction models that can be used in specific
solution documents. The primary focus of this document is the RATS-related solution documents. The primary focus of this document
conveyance of attestation Evidence. Specific goals of this document is the conveyance of attestation Evidence. The reference models
are to: defined can also be applied to the conveyance of other Conceptual
Messages in RATS. Specific goals of this document are to:
o prevent inconsistencies in descriptions of these interaction o prevent inconsistencies in descriptions of interaction models in
models in other documents (due to text cloning over time), other documents (due to text cloning and evolution over time),
o enable to highlight an exact delta/divergence between the core set o enable to highlight an exact delta/divergence between the core set
of characteristics captured here in this document and variants of of characteristics captured here in this document and variants of
these interaction models used in other specifications or these interaction models used in other specifications or
solutions, and to solutions, and to
o illustrate the application of Direct Anonymous Attestation (DAA) o illustrate the application of Direct Anonymous Attestation (DAA)
for each of the interaction models described. for the defined set of reference models.
In summary, this document enables the specification and design of In summary, this document enables the specification and design of
trustworthy and privacy preserving conveyance methods for attestation trustworthy and privacy preserving conveyance methods for attestation
Evidence from an Attester to a Verifier. While the conveyance of Evidence from an Attester to a Verifier. While the conveyance of
other Conceptual Messages is out-of-scope the methods described can other Conceptual Messages is out-of-scope the methods described can
also be applied to the conveyance of Endorsements or Attestation also be applied to the conveyance of, for example, Endorsements or
Results. Attestation Results.
2. Terminology 2. Terminology
This document uses the terms, roles, and concepts defined in This document uses the following set of terms, roles, and concepts as
[I-D.ietf-rats-architecture]: defined in [I-D.ietf-rats-architecture]:
Attester, Verifier, Relying Party, Conceptual Message, Evidence, Attester, Verifier, Relying Party, Conceptual Message, Evidence,
Endorsement, Attestation Result, Appraisal Policy, Attesting Endorsement, Attestation Result, Appraisal Policy, Attesting
Environment, Target Environment Environment, Target Environment
A PKIX Certificate is an X.509v3 format certificate as specified by A PKIX Certificate is an X.509v3 format certificate as specified by
[RFC5280]. [RFC5280].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
skipping to change at page 4, line 19 skipping to change at page 4, line 19
capitals, as shown here. capitals, as shown here.
3. Disambiguation 3. Disambiguation
The term "Remote Attestation" is a common expression and often The term "Remote Attestation" is a common expression and often
associated or connoted with certain properties. The term "Remote" in associated or connoted with certain properties. The term "Remote" in
this context does not necessarily refer to a remote entity in the this context does not necessarily refer to a remote entity in the
scope of network topologies or the Internet. It rather refers to a scope of network topologies or the Internet. It rather refers to a
decoupled system or entities that exchange the payload of the decoupled system or entities that exchange the payload of the
Conceptual Message type called Evidence [I-D.ietf-rats-architecture]. Conceptual Message type called Evidence [I-D.ietf-rats-architecture].
This conveyance can also be "local", if the Verifier is part of the This conveyance can also be "Local", if the Verifier role is part of
same entity as the Attester, e.g., separate system components of a the same entity as the Attester role, e.g., separate system
Composite Device (a single RATS Entity). Examples of these types of components of the same Composite Device (a single RATS entity).
co-located environments include: a Trusted Execution Environment Examples of these types of co-located environments include: a Trusted
(TEE), Baseboard Management Controllers (BMCs), as well as other Execution Environment (TEE), Baseboard Management Controllers (BMCs),
physical or logical protected/isolated/shielded Computing as well as other physical or logical protected/isolated/shielded
Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Computing Environments (e.g. embedded Secure Elements (eSE) or
Modules (TPM)). Trusted Platform Modules (TPM)). Readers of this document should be
familiar with the concept of Layered Attestation as described in
Section 4.3 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].
4. Scope and Intent 4. Scope and Intent
This document focuses on generic interaction models between Attesters This document focuses on generic interaction models between Attesters
and Verifiers in order to convey Evidence. Complementary procedures, and Verifiers in order to convey Evidence. Complementary procedures,
functions, or services that are required for a complete semantic functions, or services that are required for a complete semantic
binding of the concepts defined in [I-D.ietf-rats-architecture] are binding of the concepts defined in [I-D.ietf-rats-architecture] are
out-of-scope of this document. Examples include: identity out-of-scope of this document. Examples include: identity
establishment, key distribution and enrollment, time synchronization, establishment, key distribution and enrollment, time synchronization,
as well as certificate revocation. as well as certificate revocation.
skipping to change at page 5, line 15 skipping to change at page 5, line 19
5. Direct Anonymous Attestation 5. Direct Anonymous Attestation
DAA [DAA] is a signature scheme used in RATS that allows preservation DAA [DAA] is a signature scheme used in RATS that allows preservation
of the privacy of users that are associated with an Attester (e.g. of the privacy of users that are associated with an Attester (e.g.
its owner). Essentially, DAA can be seen as a group signature scheme its owner). Essentially, DAA can be seen as a group signature scheme
with the feature that given a DAA signature no-one can find out who with the feature that given a DAA signature no-one can find out who
the signer is, i.e., the anonymity is not revocable. To be able to 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 sign anonymously an Attester has to obtain a credential from a DAA
Issuer. The DAA Issuer uses a private/public key pair to generate a Issuer. 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 credential for an Attester and makes the public key (in the form of a
public key certificate) available to the verifier to enable them to public key certificate) available to the verifier in order to enable
validate the DAA signature obtained as part of the Evidence. them to validate the DAA signature obtained as part of the Evidence.
In order to support these DAA signatures, the DAA Issuer MUST In order to support these DAA signatures, the DAA Issuer MUST
associate a single key pair with each group of Attesters and use the 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 same key pair when creating the credentials for all of the Attesters
in this group. The DAA Issuer's public key certificate for the group in this group. The DAA Issuer's public key certificate used by a
replaces the Attester Identity documents in the verification of the group of Attesters replaces the individual Attester Identity
Evidence (instead of unique Attester Identity documents). This is in documents during authenticity validation as a part of the appraisal
contrast to intuition that there has to be a unique Attester Identity of Evidence conducted by a Verifier. This is in contrast to
per device. intuition that there has to be a unique Attester Identity per device.
This document extends the duties of the Endorser role as defined by This document extends the duties of the Endorser role as defined by
the RATS architecture with respect to the provision of these Attester the RATS architecture with respect to the provision of these Attester
Identity documents to Attesters. The existing duties of the Endorser Identity documents to Attesters. The existing duties of the Endorser
role and the duties of a DAA Issuer are quite similar as illustrated role and the duties of a DAA Issuer are quite similar as illustrated
in the following subsections. in the following subsections.
5.1. Endorsers 5.1. Endorsers
Via its Attesting Environments, an Attester can only create Evidence Via its Attesting Environments, an Attester only generates Evidence
about its Target Environments. After being appraised to be about its Target Environments. After being appraised to be
trustworthy, a Target Environment may become a new Attesting trustworthy, a Target Environment may become a new Attesting
Environment in charge of creating Evidence for further Target Environment in charge of generating Evidence for further Target
Environments. [I-D.ietf-rats-architecture] explains this as Layered Environments. [I-D.ietf-rats-architecture] explains this as Layered
Attestation. Layered Attestation has to start with an initial Attestation. Layered Attestation has to start with an initial
Attesting Environment (i.e., there cannot be turtles all the way down Attesting Environment. In essence, there cannot be turtles all the
[turtles]). At this rock bottom of Layered Attestation, the way down [turtles]. At this rock bottom of Layered Attestation, the
Attesting Environments are called Roots of Trust (RoT). An Attester Attesting Environments are always called Roots of Trust (RoT). An
cannot create Evidence about its own RoTs by design. As a Attester cannot generate Evidence about its own RoTs by design. As a
consequence, a Verifier requires trustable statements about this consequence, a Verifier requires trustable statements about this
subset of Attesting Environments from a different source than the subset of Attesting Environments from a different source than the
Attester itself. The corresponding trustable statements are called Attester itself. The corresponding trustable statements are called
Endorsements and originate from external, trustable entities that Endorsements and originate from external, trustable entities that
take on the role of an Endorser (e.g., supply chain entities). take on the role of an Endorser (e.g., supply chain entities).
5.2. Endorsers for Direct Anonymous Attestation 5.2. Endorsers for Direct Anonymous Attestation
In order to enable DAA to be used, an Endorser role takes on the 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. duties of a DAA Issuer in addition to its already defined duties.
DAA Issuers offer zero-knowledge proofs based on public key DAA Issuers offer zero-knowledge proofs based on public key
certificates used for a group of Attesters [DAA]. Effectively, these certificates used for a group of Attesters [DAA]. Effectively, these
certificates share the semantics of Endorsements. The differences certificates share the semantics of Endorsements, with the following
are: exceptions:
o The associated private keys are used by the DAA Issuer to provide 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 an Attester with a credential that it can use to convince the
Verifier that its Evidence is valid. To keep their anonymity the Verifier that its Evidence is valid. To keep their anonymity the
Attester randomises this credential each time that it is used. Attester randomizes this credential each time that it is used.
o The Verifier can use the DAA Issuer's public key certificate, o The Verifier can use the DAA Issuer's public key certificate,
together with the randomised credential from the Attester, to together with the randomized credential from the Attester, to
confirm that the Evidence comes from a valid Attester. confirm that the Evidence comes from a valid Attester.
o A credential is conveyed from an Endorser to an Attester together o A credential is conveyed from an Endorser to an Attester in
with the transfer of the public key certificates from Endorser to combination with the conveyance of the public key certificates
Verifier. from Endorser to Verifier.
The zero-knowledge proofs required cannot be created by an Attester The zero-knowledge proofs required cannot be created by an Attester
alone - like the Endorsements of RoTs - and have to be created by a alone - like the Endorsements of RoTs - and have to be created by a
trustable third entity - like an Endorser. Due to that vast semantic trustable third entity - like an Endorser. Due to that semantic
overlap (XXX-mcr:explain), an Endorser in this document can convey overlap, the Endorser role is augmented via the definition of DAA
trustable third party statements both to a Verifier and an Attester. duties as defined below. This augmentation enables the Endorser to
convey trustable third party statements both to Verifier roles and
Attester roles.
6. Normative Prerequisites 6. Normative Prerequisites
In order to ensure an appropriate conveyance of Evidence, the In order to ensure an appropriate conveyance of Evidence via
following set of prerequisites MUST be in place to support the interaction models in general, the following set of prerequisites
implementation of interaction models: MUST be in place to support the implementation of interaction models:
Attester Identity: The provenance of Evidence with respect to a Attester Identity: The provenance of Evidence with respect to a
distinguishable Attesting Environment MUST be correct and distinguishable Attesting Environment MUST be correct and
unambiguous. unambiguous.
An Attester Identity MAY be a unique identity, it MAY be included 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 in a zero-knowledge proof (ZKP), or it MAY be part of a group
signature, or it MAY be a randomised DAA credential. signature, or it MAY be a randomised DAA credential.
Attestation Evidence Authenticity: Attestation Evidence MUST be Attestation Evidence Authenticity: Attestation Evidence MUST be
skipping to change at page 7, line 16 skipping to change at page 7, line 23
Authentication Secret: An Authentication Secret MUST be available Authentication Secret: An Authentication Secret MUST be available
exclusively to an Attester's Attesting Environment. exclusively to an Attester's Attesting Environment.
The Attester MUST protect Claims with that Authentication Secret, The Attester MUST protect Claims with that Authentication Secret,
thereby proving the authenticity of the Claims included in thereby proving the authenticity of the Claims included in
Evidence. The Authentication Secret MUST be established before Evidence. The Authentication Secret MUST be established before
RATS can take place. RATS can take place.
Evidence Freshness: Evidence MUST include an indicator about its Evidence Freshness: Evidence MUST include an indicator about its
Freshness that can be understood by a Verifier. Analogously, freshness that can be understood by a Verifier. Analogously,
interaction models MUST support the conveyance of proofs of interaction models MUST support the conveyance of proofs of
freshness in a way that is useful to Verifiers and their appraisal freshness in a way that is useful to Verifiers and their appraisal
procedures. procedures.
Evidence Protection: Evidence MUST be a set of well-formatted and Evidence Protection: Evidence MUST be a set of well-formatted and
well-protected Claims that an Attester can create and convey to a well-protected Claims that an Attester can create and convey to a
Verifier in a tamper-evident manner. Verifier in a tamper-evident manner.
7. Generic Information Elements 7. Generic Information Elements
This section defines the information elements that are vital to all This section defines the information elements that are vital to all
kinds interaction models. Varying from solution to solution, generic kinds interaction models. Varying from solution to solution, generic
information elements can be either included in the scope of protocol information elements can be either included in the scope of protocol
messages or can be included in their payload. Ultimately, the messages (instantiating Conceptual Messages) or can be included in
following information elements are required by any kind of scalable additional protocol parameters or payload. Ultimately, the following
remote attestation procedure using one or more of the interaction information elements are required by any kind of scalable remote
models provided. attestation procedure using one or more of the interaction models
provided.
Attester Identity ('attesterIdentity'): _mandatory_ Attester Identity ('attesterIdentity'): _mandatory_
A statement about a distinguishable Attester made by an Endorser A statement about a distinguishable Attester made by an Endorser
without accompanying evidence about its validity - used as proof without accompanying evidence about its validity - used as proof
of identity. of identity.
In DAA the Attester's identity is not revealed to the verifier. In DAA, the Attester's identity is not revealed to the verifier.
The Attester is issued with a credential by the Endorser that is The Attester is issued with a credential by the Endorser that is
randomised and then used to anonymously confirm the validity of randomised and then used to anonymously confirm the validity of
their evidence. The evidence is verified using the Endorser's their evidence. The evidence is verified using the Endorser's
public key. public key.
Authentication Secret IDs ('authSecID'): _mandatory_ Authentication Secret IDs ('authSecID'): _mandatory_
A statement representing an identifier list that MUST be A statement representing an identifier list that MUST be
associated with corresponding Authentication Secrets used to associated with corresponding Authentication Secrets used to
protect Evidence. In DAA, Authentication Secret IDs are protect Evidence.
represented by the Endorser (DAA issuer)'s public key that MUST be
used to create DAA credentials for the corresponding In DAA, Authentication Secret IDs are represented by the Endorser
Authentication Secrets used to protect Evidence. (DAA issuer)'s public key that MUST be used to create DAA
credentials for the corresponding Authentication Secrets used to
protect Evidence.
Each Authentication Secret is uniquely associated with a Each Authentication Secret is uniquely associated with a
distinguishable Attesting Environment. Consequently, an distinguishable Attesting Environment. Consequently, an
Authentication Secret ID also identifies an Attesting Environment. Authentication Secret ID also identifies an Attesting Environment.
In DAA an Authentication Secret ID does not identify a unique
In DAA, an Authentication Secret ID does not identify a unique
Attesting Environment but associated with a group of Attesting Attesting Environment but associated with a group of Attesting
Environments. This is because an Attesting Environment should not Environments. This is because an Attesting Environment should not
be distinguishable and the DAA credential which represents the be distinguishable and the DAA credential which represents the
Attesting Environment is randomised each time it used. Attesting Environment is randomised each time it used.
Handle ('handle'): _mandatory_ Handle ('handle'): _mandatory_
A statement that is intended to uniquely distinguish received A statement that is intended to uniquely distinguish received
Evidence and/or determine the Freshness of Evidence. Evidence and/or determine the freshness of Evidence.
A Verifier can also use a Handle as an indicator for authenticity A Verifier can also use a Handle as an indicator for authenticity
or attestation provenance, as only Attesters and Verifiers that or attestation provenance, as only Attesters and Verifiers that
are intended to exchange Evidence should have knowledge of the are intended to exchange Evidence should have knowledge of the
corresponding Handles. Examples include Nonces or signed corresponding Handles. Examples include Nonces or signed
timestamps. timestamps.
Claims ('claims'): _mandatory_ Claims ('claims'): _mandatory_
Claims are assertions that represent characteristics of an Claims are assertions that represent characteristics of an
Attester's Target Environment. Attester's Target Environment.
Claims are part Conceptual Message and are, for example, used to Claims are part Conceptual Message and are, for example, used to
appraise the integrity of Attesters via a Verifiers. The other appraise the integrity of Attesters via a Verifiers. The other
information elements in this section can be expressed as Claims in information elements in this section can be expressed as Claims in
any type of Conceptional Messages. any type of Conceptional Messages.
Reference Claims ('refClaims') _mandatory_ Reference Claims ('refClaims') _mandatory_
Reference Claims are components of Reference Values as defined in
Reference Claims are a specific subset of Appraisal Policies as [I-D.ietf-rats-architecture]. [Editor's Note: Definition might
defined in [I-D.ietf-rats-architecture]. become obsolete, if replaced by Reference Values. Is there a
difference between Claims and Values here? Analogously, why is
not named Reference Claims in the RATS arch?]
Reference Claims are used to appraise the Claims received from an Reference Claims are used to appraise the Claims received from an
Attester via appraisal by direct comparison. For example, Attester via appraisal by direct comparison. For example,
Reference Claims MAY be Reference Integrity Measurements (RIM) or Reference Claims MAY be Reference Integrity Measurements (RIM) or
assertions that are implicitly trusted because they are signed by assertions that are implicitly trusted because they are signed by
a trusted authority (see Endorsements in a trusted authority (see Endorsements in
[I-D.ietf-rats-architecture]). Reference Claims typically [I-D.ietf-rats-architecture]). Reference Claims typically
represent (trusted) Claim sets about an Attester's intended represent (trusted) Claim sets about an Attester's intended
platform operational state. platform operational state.
skipping to change at page 9, line 21 skipping to change at page 9, line 35
of Claims to be included in Evidence. An Attester MAY decide of Claims to be included in Evidence. An Attester MAY decide
whether or not to provide all Claims as requested via a Claim whether or not to provide all Claims as requested via a Claim
Selection. Selection.
Evidence ('signedAttestationEvidence'): _mandatory_ Evidence ('signedAttestationEvidence'): _mandatory_
A set of Claims that consists of a list of Authentication Secret A set of Claims that consists of a list of Authentication Secret
IDs that each identifies an Authentication Secret in a single IDs that each identifies an Authentication Secret in a single
Attesting Environment, the Attester Identity, Claims, and a Attesting Environment, the Attester Identity, Claims, and a
Handle. Attestation Evidence MUST cryptographically bind all of Handle. Attestation Evidence MUST cryptographically bind all of
these information elements. The Evidence MUST be protected via these information elements. Evidence MUST be protected via an
the Authentication Secret. The Authentication Secret MUST be Authentication Secret. The Authentication Secret MUST be trusted
trusted by the Verifier as authoritative. by the Verifier as authoritative.
Attestation Result ('attestationResult'): _mandatory_ Attestation Result ('attestationResult'): _mandatory_
An Attestation Result is produced by the Verifier as the output of An Attestation Result is produced by the Verifier as the output of
the appraisal of Evidence. Attestation Results include condensed the appraisal of Evidence. Attestation Results include condensed
assertions about integrity or other characteristics of the assertions about integrity or other characteristics of the
corresponding Attester. corresponding Attester that are digestable by Relying Parties.
8. Interaction Models 8. Interaction Models
The following subsections introduce and illustrate the interaction The following subsections introduce and illustrate the interaction
models: models:
1. Challenge/Response Remote Attestation 1. Challenge/Response Remote Attestation
2. Uni-Directional Remote Attestation 2. Uni-Directional Remote Attestation
3. Streaming Remote Attestation 3. Streaming Remote Attestation
Each section starts with a sequence diagram illustrating the Each section starts with a sequence diagram illustrating the
interactions between Attester and Verifier. The other roles RATS interactions between Attester and Verifier. While the interaction
roles - mainly Relying Parties and Endorsers - are not relevant for models presented focus on the conveyance of Evidence, the intention
this interaction model. While the interaction models presented focus of this document is in support of future work that applies the
on the conveyance of Evidence, future work could apply this to the presented models to the conveyance of other Conceptual Messages,
conveyance of other Conceptual Messages, namely Attestation Results, namely Attestation Results, Endorsements, Reference Values, or
Endorsements, or Appraisal Policies. Appraisal Policies.
All interaction model have a strong focus on the use of a handle to All interaction models have a strong focus on the use of a handle to
incorporate a proof of freshness. The ways these handles are incorporate a type of proof of freshness. The ways these handles are
processed is the most prominent difference between the three processed is the most prominent difference between the three
interaction models. interaction models.
8.1. Challenge/Response Remote Attestation 8.1. Challenge/Response Remote Attestation
.----------. .----------. .----------. .----------.
| Attester | | Verifier | | Attester | | Verifier |
'----------' '----------' '----------' '----------'
| | | |
| | | |
skipping to change at page 12, line 24 skipping to change at page 12, line 27
| | | handle----------> | | | | handle----------> |
| '--------------------' | | '--------------------' |
| | | |
evidenceGeneration(handle, authSecIDs, collectedClaims) | evidenceGeneration(handle, authSecIDs, collectedClaims) |
| => evidence | | => evidence |
| | | |
| pushEventLog---------------------------------------------> | | pushEventLog---------------------------------------------> |
| pushEvidence---------------------------------------------> | | pushEvidence---------------------------------------------> |
| | | |
| appraiseEvidence(evidence, eventLog, refClaims) | appraiseEvidence(evidence, eventLog, refClaims)
| evidenceAppraisal(evidence, refClaims)
| attestationResult <= | | attestationResult <= |
~ ~ ~ ~
| | | |
valueGeneration(targetEnvironment) | valueGeneration(targetEnvironment) |
| => claimsDelta | | => claimsDelta |
| | | |
evidenceGeneration(handle, authSecIDs, collectedClaims) | evidenceGeneration(handle, authSecIDs, collectedClaims) |
| => evidence | | => evidence |
| | | |
| pushEventLogDelta----------------------------------------> | | pushEventLogDelta----------------------------------------> |
| pushEvidence---------------------------------------------> | | pushEvidence---------------------------------------------> |
| | | |
| appraiseEvidence(evidence, eventLogDelta, refClaims) | appraiseEvidence(evidence, eventLogDelta, refClaims)
| evidenceAppraisal(evidence, refClaims)
| attestationResult <= | | attestationResult <= |
| | | |
Uni-Directional Remote Attestation procedures can be initiated both Uni-Directional Remote Attestation procedures can be initiated both
by the Attester and by the Verifier. Initiation by the Attester can by the Attester and by the Verifier. Initiation by the Attester can
result in unsolicited pushes of Evidence to the Verifier. Initiation result in unsolicited pushes of Evidence to the Verifier. Initiation
by the Verifier always results in solicited pushes to the Verifier. by the Verifier always results in solicited pushes to the Verifier.
The Uni-Directional model uses the same information elements as the The Uni-Directional model uses the same information elements as the
Challenge/Response model. In the sequence diagram above, the Challenge/Response model. In the sequence diagram above, the
Attester initiates the conveyance of Evidence (comparable with a Attester initiates the conveyance of Evidence (comparable with a
skipping to change at page 16, line 35 skipping to change at page 16, line 35
The open-source implementation project resource can be located via: The open-source implementation project resource can be located via:
https://github.com/Fraunhofer-SIT/charra https://github.com/Fraunhofer-SIT/charra
10.4. Maturity 10.4. Maturity
The code's level of maturity is considered to be "prototype". The code's level of maturity is considered to be "prototype".
10.5. Coverage and Version Compatibility 10.5. Coverage and Version Compatibility
The current version (commit '847bcde') is aligned with the exemplary The current version ('1bcb469') implements a challenge/response
specification of the CoAP FETCH bodies defined in section Appendix A interaction model and is aligned with the exemplary specification of
of this document. the CoAP FETCH bodies defined in Section Appendix A of this document.
10.6. License 10.6. License
The CHARRA project and all corresponding code and data maintained on The CHARRA project and all corresponding code and data maintained on
github are provided under the BSD 3-Clause "New" or "Revised" github are provided under the BSD 3-Clause "New" or "Revised"
license. license.
10.7. Implementation Dependencies 10.7. Implementation Dependencies
The implementation requires the use of the official Trusted Computing The implementation requires the use of the official Trusted Computing
skipping to change at page 20, line 35 skipping to change at page 20, line 35
page 132-145, 2004. page 132-145, 2004.
[I-D.birkholz-rats-tuda] [I-D.birkholz-rats-tuda]
Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,
"Time-Based Uni-Directional Attestation", draft-birkholz- "Time-Based Uni-Directional Attestation", draft-birkholz-
rats-tuda-03 (work in progress), July 2020. rats-tuda-03 (work in progress), July 2020.
[I-D.ietf-rats-architecture] [I-D.ietf-rats-architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture", W. Pan, "Remote Attestation Procedures Architecture",
draft-ietf-rats-architecture-06 (work in progress), draft-ietf-rats-architecture-07 (work in progress),
September 2020. October 2020.
[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
in progress), September 2020.
[turtles] Rudnicki, R., "Turtles All the Way Down: Foundation, [turtles] Rudnicki, R., "Turtles All the Way Down: Foundation,
Edifice, and Ruin in Faulkner and McCarthy", The Faulkner Edifice, and Ruin in Faulkner and McCarthy", The Faulkner
Journal 25.2, DOI 10.1353/fau.2010.0002, 2010. Journal 25.2, DOI 10.1353/fau.2010.0002, 2010.
Appendix A. CDDL Specification for a simple CoAP Challenge/Response Appendix A. CDDL Specification for a simple CoAP Challenge/Response
Interaction Interaction
The following CDDL specification is an exemplary proof-of-concept to The following CDDL specification is an exemplary proof-of-concept to
illustrate a potential implementation of the Challenge/Response illustrate a potential implementation of the Challenge/Response
 End of changes. 41 change blocks. 
94 lines changed or deleted 110 lines changed or added

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