< draft-birkholz-rats-tuda-00.txt   draft-birkholz-rats-tuda-01.txt >
Network Working Group A. Fuchs RATS Working Group A. Fuchs
Internet-Draft H. Birkholz Internet-Draft H. Birkholz
Intended status: Informational Fraunhofer SIT Intended status: Standards Track Fraunhofer SIT
Expires: September 13, 2019 I. McDonald Expires: March 15, 2020 I. McDonald
High North Inc High North Inc
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
March 12, 2019 September 12, 2019
Time-Based Uni-Directional Attestation Time-Based Uni-Directional Attestation
draft-birkholz-rats-tuda-00 draft-birkholz-rats-tuda-01
Abstract Abstract
This memo documents the method and bindings used to conduct time- This documents defines the method and bindings used to conduct Time-
based uni-directional attestation between distinguishable endpoints based Uni-Directional Attestation (TUDA) between two RATS (Remote
over the network. ATtestation procedureS) Principals over the Internet. 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. Conversely, TUDA enables the creation of Secure Audit Logs
that can constitute Evidence about current and past operational
states of an Attester. As a prerequisite for TUDA, every RATS
Principal requires access to a trusted and synchronized time-source.
Per default, in TUDA this is a Time Stamp Authority (TSA) issuing
signed Time Stamp Tokens (TST).
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 September 13, 2019. This Internet-Draft will expire on March 15, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Remote Attestation . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.2. Evidence Creation . . . . . . . . . . . . . . . . . . . . 5 1.2. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Evidence Appraisal . . . . . . . . . . . . . . . . . . . 5 1.3. Creating Evidence about Software Component Integrity . . 5
1.4. Activities and Actions . . . . . . . . . . . . . . . . . 5 1.3.1. Data Items . . . . . . . . . . . . . . . . . . . . . 5
1.5. Attestation and Verification . . . . . . . . . . . . . . 6 1.3.2. System Components . . . . . . . . . . . . . . . . . . 5
1.6. Information Elements and Conveyance . . . . . . . . . . . 6 1.3.3. Operations . . . . . . . . . . . . . . . . . . . . . 6
1.7. TUDA Objectives . . . . . . . . . . . . . . . . . . . . . 7 1.4. Remote Attestation Principles . . . . . . . . . . . . . . 6
1.8. Hardware Dependencies . . . . . . . . . . . . . . . . . . 7 1.5. System Component Requirements . . . . . . . . . . . . . . 7
1.9. Requirements Notation . . . . . . . . . . . . . . . . . . 7 1.6. Evidence Appraisal . . . . . . . . . . . . . . . . . . . 7
2. TUDA Core Concept . . . . . . . . . . . . . . . . . . . . . . 8 1.7. Activities and Actions . . . . . . . . . . . . . . . . . 8
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.8. Attestation and Verification . . . . . . . . . . . . . . 8
3.1. Universal Terms . . . . . . . . . . . . . . . . . . . . . 9 1.9. Information Elements and Conveyance . . . . . . . . . . . 8
3.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.10. TUDA Objectives . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. General Types . . . . . . . . . . . . . . . . . . . . 11 1.11. Hardware Dependencies . . . . . . . . . . . . . . . . . . 10
3.2.2. RoT specific terms . . . . . . . . . . . . . . . . . 11 2. TUDA Core Concept . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 11 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Time-Based Uni-Directional Attestation . . . . . . . . . . . 11 3.1. Universal Terms . . . . . . . . . . . . . . . . . . . . . 11
4.1. TUDA Information Elements Update Cycles . . . . . . . . . 13 3.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Sync Base Protocol . . . . . . . . . . . . . . . . . . . . . 15 3.2.1. General Types . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 3.2.2. RoT specific terms . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 3.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 13
8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Time-Based Uni-Directional Attestation . . . . . . . . . . . 13
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. TUDA Information Elements Update Cycles . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Sync Base Protocol . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
Appendix A. REST Realization . . . . . . . . . . . . . . . . . . 21 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix B. SNMP Realization . . . . . . . . . . . . . . . . . . 21 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
B.1. Structure of TUDA MIB . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
B.1.1. Cycle Index . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
B.1.2. Instance Index . . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 20
B.1.3. Fragment Index . . . . . . . . . . . . . . . . . . . 22 Appendix A. REST Realization . . . . . . . . . . . . . . . . . . 24
B.2. Relationship to Host Resources MIB . . . . . . . . . . . 23 Appendix B. SNMP Realization . . . . . . . . . . . . . . . . . . 24
B.3. Relationship to Entity MIB . . . . . . . . . . . . . . . 23 B.1. Structure of TUDA MIB . . . . . . . . . . . . . . . . . . 25
B.4. Relationship to Other MIBs . . . . . . . . . . . . . . . 23 B.1.1. Cycle Index . . . . . . . . . . . . . . . . . . . . . 25
B.5. Definition of TUDA MIB . . . . . . . . . . . . . . . . . 23 B.1.2. Instance Index . . . . . . . . . . . . . . . . . . . 25
Appendix C. YANG Realization . . . . . . . . . . . . . . . . . . 39 B.1.3. Fragment Index . . . . . . . . . . . . . . . . . . . 25
Appendix D. Realization with TPM functions . . . . . . . . . . . 54 B.2. Relationship to Host Resources MIB . . . . . . . . . . . 26
D.1. TPM Functions . . . . . . . . . . . . . . . . . . . . . . 54 B.3. Relationship to Entity MIB . . . . . . . . . . . . . . . 26
D.1.1. Tick-Session and Tick-Stamp . . . . . . . . . . . . . 54 B.4. Relationship to Other MIBs . . . . . . . . . . . . . . . 26
D.1.2. Platform Configuration Registers (PCRs) . . . . . . . 55 B.5. Definition of TUDA MIB . . . . . . . . . . . . . . . . . 26
D.1.3. PCR restricted Keys . . . . . . . . . . . . . . . . . 55 Appendix C. YANG Realization . . . . . . . . . . . . . . . . . . 42
D.1.4. CertifyInfo . . . . . . . . . . . . . . . . . . . . . 56 Appendix D. Realization with TPM functions . . . . . . . . . . . 57
D.2. IE Generation Procedures for TPM 1.2 . . . . . . . . . . 56 D.1. TPM Functions . . . . . . . . . . . . . . . . . . . . . . 57
D.2.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 56 D.1.1. Tick-Session and Tick-Stamp . . . . . . . . . . . . . 57
D.2.2. Synchronization Token . . . . . . . . . . . . . . . . 57 D.1.2. Platform Configuration Registers (PCRs) . . . . . . . 58
D.2.3. RestrictionInfo . . . . . . . . . . . . . . . . . . . 59 D.1.3. PCR restricted Keys . . . . . . . . . . . . . . . . . 58
D.2.4. Measurement Log . . . . . . . . . . . . . . . . . . . 61 D.1.4. CertifyInfo . . . . . . . . . . . . . . . . . . . . . 59
D.2.5. Implicit Attestation . . . . . . . . . . . . . . . . 62 D.2. IE Generation Procedures for TPM 1.2 . . . . . . . . . . 59
D.2.6. Attestation Verification Approach . . . . . . . . . . 63 D.2.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 59
D.3. IE Generation Procedures for TPM 2.0 . . . . . . . . . . 65 D.2.2. Synchronization Token . . . . . . . . . . . . . . . . 60
D.3.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 65 D.2.3. RestrictionInfo . . . . . . . . . . . . . . . . . . . 62
D.3.2. Synchronization Token . . . . . . . . . . . . . . . . 66 D.2.4. Measurement Log . . . . . . . . . . . . . . . . . . . 64
D.3.3. Measurement Log . . . . . . . . . . . . . . . . . . . 66 D.2.5. Implicit Attestation . . . . . . . . . . . . . . . . 65
D.3.4. Explicit time-based Attestation . . . . . . . . . . . 67 D.2.6. Attestation Verification Approach . . . . . . . . . . 66
D.3.5. Sync Proof . . . . . . . . . . . . . . . . . . . . . 67 D.3. IE Generation Procedures for TPM 2.0 . . . . . . . . . . 68
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 68 D.3.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 D.3.2. Synchronization Token . . . . . . . . . . . . . . . . 69
D.3.3. Measurement Log . . . . . . . . . . . . . . . . . . . 69
D.3.4. Explicit time-based Attestation . . . . . . . . . . . 70
D.3.5. Sync Proof . . . . . . . . . . . . . . . . . . . . . 70
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71
1. Introduction 1. Introduction
Remote attestation (RA) describes the attempt to determine and Remote ATtestation procedureS (RATS) describe the attempt to
appraise properties, such as integrity and trustworthiness, of an determine and appraise properties, such as integrity and
endpoint -- the Attestor -- over a network to another endpoint -- the trustworthiness, of a communication partner - the Attester - over the
Verifier -- without direct access. Typically, this kind of appraisal Internet to another communication parter - the Verifier - without
is based on integrity measurements of software components right direct access. TUDA uses the architectural constituents of the RATS
before they are loaded as software instances on the Attestor. In Architecture [I-D.birkholz-rats-architecture] that defines the Roles
general, attestation procedures are utilizing a hardware root of Attester and Verifier in detail. The RATS Architecture also defines
trust (RoT). The TUDA protocol family uses hash values of all Role Messages. TUDA creates and conveys a specific type of Role
started software components that are stored (extended into) a Trust- Message called Evidence, a composition of trustwrthiness Claims
Anchor (the RoT) implemented as a Hardware Security Module (e.g. a provided by an Attester and consumed by a Verifier (potentially
Trusted Platform Module or similar) and are reported via a signature relayed by another RATS Role that is a Relying Party). TUDA - in
over those measurements. contrast to traditional bi-directional challenge-response protocols
This draft introduces the concept of including the exchange of [I-D.birkholz-rats-reference-interaction-model] - enables a uni-
evidence -- created via a hardware RoT containing a shielded secret directional conveyance of attestation Evidence that allows for
that is inaccessible to the user -- in order to increase the providing attestation information without solicitation (e.g. as
confidence in a communication peer that is supposed to be a Trusted beacons or push data via YANG Push [RFC8641], [RFC8640], [RFC8639]).
System [RFC4949]. In consequence, this document introduces the term
forward authenticity. As a result, this document introduces the term Forward Authenticity.
Forward Authenticity (FA): A property of secure communication Forward Authenticity (FA): A property of secure communication
protocols, in which later compromise of the long-term keys of a protocols, in which later compromise of the long-term keys of a
data origin does not compromise past authentication of data from data origin does not compromise past authentication of data from
that origin. FA is achieved by timely recording of assessments of that origin. FA is achieved by timely recording of assessments of
the authenticity from entities (via "audit logs" during "audit the authenticity from system components (via "audit logs" during
sessions") that are authorized for this purpose, in a time frame "audit sessions") that are authorized for this purpose and
trustworthy (e.g via endorsed roots of trust), in a time frame
much shorter than that expected for the compromise of the long- much shorter than that expected for the compromise of the long-
term keys. term keys.
Forward Authenticity enables new level of guarantee and can be Forward Authenticity enables new levels of assurance and can be
included in the basically every protocol, such as ssh, router included in basically every protocol, such as ssh, YANG Push,
advertisements, link layer neighbor discover, or even ICMP echo. router advertisements, link layer neighbor discovery, or even ICMP
echo.
1.1. Remote Attestation 1.1. Requirements Notation
In essence, remote attestation (RA) is composed of three activities. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
The following definitions are derived from the definitions presented "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
in [PRIRA] and [TCGGLOSS]. "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.
1.2. Evidence
Remote attestation Evidence is basically a set of trustworthiness
claims (assertions about the Attester and its system characteristics
including security posture and protection characteristics) that are
accompanied by a proof of their veracity - typically a signature
based on shielded, private and potentially restricted key material.
As key material alone is typically not self-descriptive with respect
to its intended use (its semantics), the remote attestation Evidence
created via TUDA is accompanied by two kinds of certificates that are
cryptographically associated with a Trust Anchor (TA) [RFC4949] via a
certification path:
o an Attestation Key (AK) Certificate (AK-Cert) that represents the
attestation provenance of the created Evidence, and
o an Endorsement Key (EK) Certificate (EK-Cert) that represents the
protection characteristics of the system components the AK is
stored in.
If a Verifier decides to trust both the TA of an AK-Cert and an EK-
Cert presented by an Attester - and the included assertions about the
system characteristics describing the Attester, the attestation
Evidence created via TUDA by the Attester is considered believable.
Ultimately, believable Evidence is appraised by a Verifier in order
to assess the trustworthiness of the corresponding Attester.
1.3. Creating Evidence about Software Component Integrity
The TUDA protocol mechanism uses hash values of all started software
components as a basis to provide and create Evidence about the
integrity of the software components of an Attester. This section
defines the processed data items, the required system components, and
corresponding operations to enable the creation of Evidence about
software component integrity for TUDA.
1.3.1. Data Items
The hash value of a software component created before it is executed
is referred to as a "measurement" in the remainder of this document.
Measurements are chained using a rolling hash function. Each
measurement added to the sequence of all measurements results in a
new current hash value that is referred to as a "digest" in the
remainder of this document.
1.3.2. System Components
The function to store these measurements via a rolling hash function
is provided by a root of trust for storage - a system component that
MUST be a component of the attester.
With respect to the boot sequence of an Attester, the very first
measurements of software components (e.g. the BIOS, or a sometimes a
bootloader) have to be conducted by a root of trust for measurement
that is implemented in hardware and MUST be a system component of the
Attester.
All measurements retained in the root of trust for measurements are
handed over to the root of trust for storage when it becomes
available during the boot procedure of the Attester. During that
hand-over the sequence of measurements retained in the root of trust
for measurement are processed by the rolling hash function of the
root of trust for storage.
The function of retrieving the current output value of the rolling
hash function, including a signature to provide a proof of veracity,
is provided by a root of trust for reporting and MUST be a system
component of the Attester.
Typically, a root of trust for storage and a root of trust for
reporting are tightly coupled. Analogously, a root of trust for
measurement is typically independent from the root of trust for
storage, but has to be able to interact with root of trust for
storage at some point of the boot sequence of the Attester to hand
over the retained measurements.
1.3.3. Operations
The operation of processing a measurement and adding it to the
sequence of measurements via the rolling hash function is called
"extend" and is provided by the root of trust for storage.
The operation of retrieving the current available hash value that is
the result of the rolling hash function including a signature based
on an Attestation Key is called "quote" and is provided by the
corresponding root of trust for reporting.
1.4. Remote Attestation Principles
In essence, RATS are composed of three base activities. The
following definitions are derived from the definitions presented in
[PRIRA] and [TCGGLOSS], and are a simplified summary of the RATS
Architecture relevant for TUDA. The complete RATS Architecture and
every corresponding constituent, message and interaction is defined
in [I-D.birkholz-rats-architecture].
Attestation: The creation of one ore more claims about the Attestation: The creation of one ore more claims about the
properties of an Attestor, such that the claims can be used as trustworthiness properties of an Attester, such that the claims
evidence. can be used as Evidence.
Conveyance: The transfer of evidence from the Attestor to the Conveyance: The transfer of Evidence from the Attester to the
Verifier via an interconnect. Verifier via an interconnect.
Verification: The appraisal of evidence by evaluating it against Verification: The appraisal of Evidence by evaluating it against
declarative guidance. known-good-values (a type of declarative guidance).
With TUDA, the claims that compose the evidence are signatures over With TUDA, the claims that compose the evidence are signatures over
trustworthy integrity measurements created by leveraging a hardware trustworthy integrity measurements created by leveraging roots of
RoT. The evidence is appraised via corresponding signatures over trust. The evidence is appraised via corresponding signatures over
reference integrity measurements (RIM, represented, for example via reference integrity measurements (RIM, represented, for example via
[I-D.ietf-sacm-coswid]). [I-D.ietf-sacm-coswid]).
Protocols that facilitate Trust-Anchor based signatures in order to Protocols that facilitate Trust-Anchor based signatures in order to
provide RATS are usually bi-directional challenge/response protocols, provide RATS are usually bi-directional challenge/response protocols,
such as the Platform Trust Service protocol [PTS] or CAVES [PRIRA], such as the Platform Trust Service protocol [PTS] or CAVES [PRIRA],
where one entity sends a challenge that is included inside the where one entity sends a challenge that is included inside the
response to prove the recentness -- the freshness (see fresh in response to prove the recentness - the freshness (see fresh in
[RFC4949]) -- of the attestation information. The corresponding [RFC4949]) - of the attestation information. The corresponding
interaction model tightly couples the three activities of creating, interaction model tightly couples the three activities of creating,
transferring and appraising evidence. transferring and appraising evidence.
The Time-Based Uni-directional Attestation family of protocols -- The Time-Based Uni-directional Attestation family of protocols - TUDA
TUDA -- described in this document can decouple the three activities - described in this document can decouple the three activities RATS
RATS are composed of. As a result, TUDA provides additional are composed of. As a result, TUDA provides additional capabilities,
capabilities, such as: such as:
o remote attestation for Attestors that might not always be able to o remote attestation for Attesters that might not always be able to
reach the Internet by enabling the verification of past states, reach the Internet by enabling the verification of past states,
o secure audit logs by combining the evidence created via TUDA with o secure audit logs by combining the evidence created via TUDA with
integrity measurement logs that represent a detailed record of integrity measurement logs that represent a detailed record of
corresponding past states, corresponding past states,
o an uni-directional interaction model that can traverse "diode- o an uni-directional interaction model that can traverse "diode-
like" network security functions (NSF) or can be leveraged in like" network security functions (NSF) or can be leveraged in
RESTful architectures (e.g. CoAP [RFC7252]), analogously. RESTful architectures (e.g. CoAP [RFC7252]), analogously.
1.2. Evidence Creation 1.5. System Component Requirements
TUDA is a family of protocols that bundles results from specific TUDA is a family of protocols that bundles results from specific
attestation activities. The attestation activities of TUDA are based attestation activities. The attestation activities of TUDA are based
on a hardware Root of Trust that provides the following capabilities: on a hardware roots of trust that provides the following
capabilities:
o Platform Configuration Registers (PCR) that store measurements o Platform Configuration Registers (PCR) that can extend
consecutively (corresponding terminology: "to extend a PCR") and measurements consecutively and represent the sequence of
represent the chain of measurements as a single measurement value measurements as a single digest,
("PCR value"),
o Restricted Signing Keys (RSK) that can only be accessed, if a o Restricted Signing Keys (RSK) that can only be accessed, if a
specific signature about measurements can be provided as specific signature about a set of measurements can be provided as
authentication, and authentication, and
o a dedicated source of (relative) time, e.g. a tick counter. o a dedicated source of (relative) time, e.g. a tick counter (a tick
being a specific time interval, for example 10 ms).
1.3. Evidence Appraisal 1.6. Evidence Appraisal
To appraise the evidence created by an Attestor, the Verifier To appraise the evidence created by an Attester, the Verifier
requires corresponding Reference Integrity Measurements (RIM). requires corresponding Reference Integrity Measurements (RIM).
Typically, a set of RIM are bundled in a RIM-Manifest (RIMM). The Typical set of RIMs are required to assess the integrity of an
scope of a manifest encompasses, e.g., a platform, a device, a Attester. These sets are called RIM Bundles. The scope of a RIM
computing context, or a virtualised function. In order to be Bundle encompasses, e.g., a platform, a device, a computing context,
comparable, the hashing algorithms used by the Attestor to create the or a virtualised function. In order to be comparable, the hashing
integrity measurements have to match the hashing algorithms used to algorithms used by the Attester to create the integrity measurements
create the corresponding RIM that are used by the Verifier to have to match the hashing algorithms used to create the corresponding
appraise the integrity evidence. RIM that are used by the Verifier to appraise the attestation
Evidence about software component integrity.
1.4. Activities and Actions 1.7. Activities and Actions
Depending on the platform (i.e. one or more computing contexts Depending on the platform (i.e. one or more computing contexts
including a dedicated hardware RoT), a generic RA activity results in including a dedicated hardware RoT), a generic RA activity results in
platform-specific actions that have to be conducted. In consequence, platform-specific actions that have to be conducted. In consequence,
there are multiple specific operations and data models (defining the there are multiple specific operations and data models (defining the
input and output of operations). Hence, specific actions are are not input and output of operations). Hence, specific actions are are not
covered by this document. Instead, the requirements on operations covered by this document. Instead, the requirements on operations
and the information elements that are the input and output to these and the information elements that are the input and output to these
operations are illustrated using pseudo code in Appendix C and D. operations are illustrated using pseudo code in Appendix C and D.
1.5. Attestation and Verification 1.8. Attestation and Verification
Both the attestation and the verification activity of TUDA also Both the attestation and the verification activity of TUDA also
require a trusted Time Stamp Authority (TSA) as an additional third require a trusted Time Stamp Authority (TSA) as an additional third
party next to the Attestor and the Verifier. The protocol uses a party next to the Attester and the Verifier. The protocol uses a
Time Stamp Authority based on [RFC3161]. The combination of the Time Stamp Authority based on [RFC3161]. The combination of the
local source of time provided by the hardware RoT (located on the local source of time provided by the hardware RoT (located on the
Attestor) and the Time Stamp Tokens provided by the TSA (to both the Attester) and the Time Stamp Tokens provided by the TSA (to both the
Attestor and the Verifier) enable the attestation and verification of Attester and the Verifier) enable the attestation and verification of
an appropriate freshness of the evidence conveyed by the Attestor -- an appropriate freshness of the evidence conveyed by the Attester --
without requiring a challenge/response interaction model that uses a without requiring a challenge/response interaction model that uses a
nonce to ensure the freshness. nonce to ensure the freshness.
Typically, the verification activity requires declarative guidance Typically, the verification activity requires declarative guidance
(representing desired or compliant endpoint characteristics in the (representing desired or compliant endpoint characteristics in the
form of RIM, see above) to appraise the individual integrity form of RIM, see above) to appraise the individual integrity
measurements the conveyed evidence is composed on. The acquisition measurements the conveyed evidence is composed on. The acquisition
or representation (data models) of declarative guidance as well as or representation (data models) of declarative guidance as well as
the corresponding evaluation methods are out of the scope of this the corresponding evaluation methods are out of the scope of this
document. document.
1.6. Information Elements and Conveyance 1.9. Information Elements and Conveyance
TUDA defines a set of information elements (IE) that are created and TUDA defines a set of information elements (IE) that are created and
stored on the Attestor and are intended to be transferred to the stored on the Attester and are intended to be transferred to the
Verifier in order to enable appraisal. Each TUDA IE: Verifier in order to enable appraisal. Each TUDA IE:
o is encoded in the Concise Binary Object Representation (CBOR o is encoded in the Concise Binary Object Representation (CBOR
[RFC7049]) to minimize the volume of data in motion. In this [RFC7049]) to minimize the volume of data in motion. In this
document, the composition of the CBOR data items that represent IE document, the composition of the CBOR data items that represent IE
is described using the Concise Data Definition Language, CDDL is described using the Concise Data Definition Language, CDDL
[I-D.ietf-cbor-cddl] [RFC8610]
o that requires a certain freshness is only created/updated when o that requires a certain freshness is only created/updated when
out-dated, which reduces the overall resources required from the out-dated, which reduces the overall resources required from the
Attestor, including the utilization of the hardware root of trust. Attester, including the utilization of the hardware root of trust.
The IE that have to be created are determined by their age or by The IE that have to be created are determined by their age or by
specific state changes on the Attestor (e.g. state changes due to specific state changes on the Attester (e.g. state changes due to
a reboot-cycle) a reboot-cycle)
o is only transferred when required, which reduces the amount of o is only transferred when required, which reduces the amount of
data in motion necessary to conduct remote attestation data in motion necessary to conduct remote attestation
significantly. Only IE that have changed since their last significantly. Only IE that have changed since their last
conveyance have to be transferred conveyance have to be transferred
o that requires a certain freshness can be reused for multiple o that requires a certain freshness can be reused for multiple
remote attestation procedures in the limits of its corresponding remote attestation procedures in the limits of its corresponding
freshness-window, further reducing the load imposed on the freshness-window, further reducing the load imposed on the
Attestor and its corresponding hardware RoT. Attester and its corresponding hardware RoT.
1.7. TUDA Objectives 1.10. TUDA Objectives
The Time-Based Uni-directional Attestation family of protocols is The Time-Based Uni-directional Attestation family of protocols is
designed to: designed to:
o increase the confidence in authentication and authorization o increase the confidence in authentication and authorization
procedures, procedures,
o address the requirements of constrained-node networks, o address the requirements of constrained-node networks,
o support interaction models that do not maintain connection-state o support interaction models that do not maintain connection-state
skipping to change at page 7, line 30 skipping to change at page 10, line 5
o be able to leverage existing management interfaces, such as SNMP o be able to leverage existing management interfaces, such as SNMP
[RFC3411]. RESTCONF [RFC8040] or CoMI [I-D.ietf-core-comi] -- and [RFC3411]. RESTCONF [RFC8040] or CoMI [I-D.ietf-core-comi] -- and
corresponding bindings, corresponding bindings,
o support broadcast and multicast schemes (e.g. [IEEE1609]), o support broadcast and multicast schemes (e.g. [IEEE1609]),
o be able to cope with temporary loss of connectivity, and to o be able to cope with temporary loss of connectivity, and to
o provide trustworthy audit logs of past endpoint states. o provide trustworthy audit logs of past endpoint states.
1.8. Hardware Dependencies 1.11. Hardware Dependencies
The binding of the attestation scheme used by TUDA to generate the The binding of the attestation scheme used by TUDA to generate the
TUDA IE is specific to the methods provided by the hardware RoT used TUDA IE is specific to the methods provided by the hardware RoT used
(see above). In this document,expositional text and pseudo-code that (see above). In this document,expositional text and pseudo-code that
is provided as a reference to instantiate the TUDA IE is based on TPM is provided as a reference to instantiate the TUDA IE is based on TPM
1.2 and TPM 2.0 operations. The corresponding TPM commands are 1.2 and TPM 2.0 operations. The corresponding TPM commands are
specified in [TPM12] and [TPM2]. The references to TPM commands and specified in [TPM12] and [TPM2]. The references to TPM commands and
corresponding pseudo-code only serve as guidance to enable a better corresponding pseudo-code only serve as guidance to enable a better
understanding of the attestation scheme and is intended to encourage understanding of the attestation scheme and is intended to encourage
the use of any appropriate hardware RoT or equivalent set of the use of any appropriate hardware RoT or equivalent set of
functions available to a CPU or Trusted Execution Environment [TEE]. functions available to a CPU or Trusted Execution Environment [TEE].
1.9. Requirements Notation
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 RFC
2119, BCP 14 [RFC2119].
2. TUDA Core Concept 2. TUDA Core Concept
There are significant differences between conventional bi-directional There are significant differences between conventional bi-directional
attestation and TUDA regarding both the information elements conveyed attestation and TUDA regarding both the information elements conveyed
between Attestor and Verifier and the time-frame, in which an between Attester and Verifier and the time-frame, in which an
attestation can be considered to be fresh (and therefore attestation can be considered to be fresh (and therefore
trustworthy). trustworthy).
In general, remote attestation using a bi-directional communication In general, remote attestation using a bi-directional communication
scheme includes sending a nonce-challenge within a signed attestation scheme includes sending a nonce-challenge within a signed attestation
token. Using the TPM 1.2 as an example, a corresponding nonce- token. Using the TPM 1.2 as an example, a corresponding nonce-
challenge would be included within the signature created by the challenge would be included within the signature created by the
TPM_Quote command in order to prove the freshness of the attestation TPM_Quote command in order to prove the freshness of the attestation
response, see e.g. [PTS]. response, see e.g. [PTS].
skipping to change at page 8, line 47 skipping to change at page 11, line 11
o the time of transmission of the nonce, and o the time of transmission of the nonce, and
o the reception of the corresponding response. o the reception of the corresponding response.
Given the time-based attestation scheme, the freshness property of Given the time-based attestation scheme, the freshness property of
TUDA is equivalent to that of bi-directional challenge response TUDA is equivalent to that of bi-directional challenge response
attestation, if the point-in-time of attestation lies between: attestation, if the point-in-time of attestation lies between:
o the transmission of a TUDA time-synchronization token, and o the transmission of a TUDA time-synchronization token, and
o the typical round-trip time between the Verifier and the Attestor. o the typical round-trip time between the Verifier and the Attester.
The accuracy of this time-frame is defined by two factors: The accuracy of this time-frame is defined by two factors:
o the time-synchronization between the Attestor and the TSA. The o the time-synchronization between the Attester and the TSA. The
time between the two tickstamps acquired via the hardware RoT time between the two tickstamps acquired via the hardware RoT
define the scope of the maximum drift ("left" and "right" in define the scope of the maximum drift ("left" and "right" in
respect to the timeline) to the TSA timestamp, and respect to the timeline) to the TSA timestamp, and
o the drift of clocks included in the hardware RoT. o the drift of clocks included in the hardware RoT.
Since the conveyance of TUDA evidence does not rely upon a Verifier Since the conveyance of TUDA evidence does not rely upon a Verifier
provided value (i.e. the nonce), the security guarantees of the provided value (i.e. the nonce), the security guarantees of the
protocol only incorporate the TSA and the hardware RoT. In protocol only incorporate the TSA and the hardware RoT. In
consequence, TUDA evidence can even serve as proof of integrity in consequence, TUDA evidence can even serve as proof of integrity in
skipping to change at page 10, line 5 skipping to change at page 12, line 17
the entity. the entity.
Claim: A piece of information asserted about a subject [RFC4949]. A Claim: A piece of information asserted about a subject [RFC4949]. A
claim is represented as a name/value pair consisting of a Claim claim is represented as a name/value pair consisting of a Claim
Name and a Claim Value [RFC7519]. Name and a Claim Value [RFC7519].
In the context of SACM, a claim is also specialized as an In the context of SACM, a claim is also specialized as an
attribute/value pair that is intended to be related to a statement attribute/value pair that is intended to be related to a statement
[I-D.ietf-sacm-terminology]. [I-D.ietf-sacm-terminology].
Endpoint Attestation: the creation of evidence on the Attestor that Endpoint Attestation: the creation of evidence on the Attester that
provides proof of a set of the endpoints's integrity measurements. provides proof of a set of the endpoints's integrity measurements.
This is done by digitally signing a set of PCRs using an AIK This is done by digitally signing a set of PCRs using an AIK
shielded by the hardware RoT. shielded by the hardware RoT.
Endpoint Characteristics: the context, composition, configuration, Endpoint Characteristics: the context, composition, configuration,
state, and behavior of an endpoint. state, and behavior of an endpoint.
Evidence: a trustworthy set of claims about an endpoint's Evidence: a trustworthy set of claims about an endpoint's
characteristics. characteristics.
skipping to change at page 10, line 46 skipping to change at page 13, line 10
Trustworthy Endpoint: an endpoint that guarantees trustworthy Trustworthy Endpoint: an endpoint that guarantees trustworthy
behavior and/or composition (with respect to certain declarative behavior and/or composition (with respect to certain declarative
guidance and a scope of confidence). guidance and a scope of confidence).
Trustworthy Statement: evidence that is trustworthy conveyed by an Trustworthy Statement: evidence that is trustworthy conveyed by an
endpoint that is not necessarily trustworthy. endpoint that is not necessarily trustworthy.
3.2. Roles 3.2. Roles
Attestor: the endpoint that is the subject of the attestation to Attester: the endpoint that is the subject of the attestation to
another endpoint. another endpoint.
Verifier: the endpoint that consumes the attestation of another Verifier: the endpoint that consumes the attestation of another
endpoint to conduct a verification. endpoint to conduct a verification.
TSA: a Time Stamp Authority [RFC3161] TSA: a Time Stamp Authority [RFC3161]
3.2.1. General Types 3.2.1. General Types
Byte: the now customary synonym for octet Byte: the now customary synonym for octet
skipping to change at page 11, line 38 skipping to change at page 13, line 51
platform credential for this protocol. It is a placeholder for a platform credential for this protocol. It is a placeholder for a
specific CA and AIK-Cert is a placeholder for the corresponding specific CA and AIK-Cert is a placeholder for the corresponding
certificate, depending on what protocol was used. The specific certificate, depending on what protocol was used. The specific
protocols are out of scope for this document, see also protocols are out of scope for this document, see also
[AIK-Enrollment] and [IEEE802.1AR]. [AIK-Enrollment] and [IEEE802.1AR].
4. Time-Based Uni-Directional Attestation 4. Time-Based Uni-Directional Attestation
A Time-Based Uni-Directional Attestation (TUDA) consists of the A Time-Based Uni-Directional Attestation (TUDA) consists of the
following seven information elements. They are used to gain following seven information elements. They are used to gain
assurance of the Attestor's platform configuration at a certain point assurance of the Attester's platform configuration at a certain point
in time: in time:
TSA Certificate: The certificate of the Time Stamp Authority that is TSA Certificate: The certificate of the Time Stamp Authority that is
used in a subsequent synchronization protocol token. This used in a subsequent synchronization protocol token. This
certificate is signed by the TSA-CA. certificate is signed by the TSA-CA.
AIK Certificate: A certificate about the Attestation Identity Key AIK Certificate: A certificate about the Attestation Identity Key
(AIK) used. This may or may not also be an [IEEE802.1AR] IDevID (AIK) used. This may or may not also be an [IEEE802.1AR] IDevID
or LDevID, depending on their setting of the corresponding or LDevID, depending on their setting of the corresponding
identity property. ([AIK-Credential], [AIK-Enrollment]; see identity property. ([AIK-Credential], [AIK-Enrollment]; see
Appendix D.2.1.) Appendix D.2.1.)
Synchronization Token: The reference for attestations are the Synchronization Token: The reference for attestations are the
relative timestanps provided by the hardware RoT. In order to put relative timestanps provided by the hardware RoT. In order to put
attestations into relation with a Real Time Clock (RTC), it is attestations into relation with a Real Time Clock (RTC), it is
necessary to provide a cryptographic synchronization between these necessary to provide a cryptographic synchronization between these
trusted relative timestamps and the regular RTC that is a hardware trusted relative timestamps and the regular RTC that is a hardware
component of the Attestor. To do so, a synchronization protocol component of the Attester. To do so, a synchronization protocol
is run with a Time Stamp Authority (TSA). is run with a Time Stamp Authority (TSA).
Restriction Info: The attestation relies on the capability of the Restriction Info: The attestation relies on the capability of the
hardware RoT to operate on restricted keys. Whenever the PCR hardware RoT to operate on restricted keys. Whenever the PCR
values for the machine to be attested change, a new restricted key values for the machine to be attested change, a new restricted key
is created that can only be operated as long as the PCRs remain in is created that can only be operated as long as the PCRs remain in
their current state. their current state.
In order to prove to the Verifier that this restricted temporary In order to prove to the Verifier that this restricted temporary
key actually has these properties and also to provide the PCR key actually has these properties and also to provide the PCR
skipping to change at page 12, line 41 skipping to change at page 15, line 6
signed timestamp provided by the hardware RoT using the restricted signed timestamp provided by the hardware RoT using the restricted
temporary key that was certified in the steps above. The signed temporary key that was certified in the steps above. The signed
timestamp provides evidence that at this point in time (with timestamp provides evidence that at this point in time (with
respect to the relative time of the hardware RoT) a certain respect to the relative time of the hardware RoT) a certain
configuration existed (namely the PCR values associated with the configuration existed (namely the PCR values associated with the
restricted key). Together with the synchronization token this restricted key). Together with the synchronization token this
timestamp represented in relative time can then be related to the timestamp represented in relative time can then be related to the
real-time clock. real-time clock.
Concise SWID tags: As an option to better assess the trustworthiness Concise SWID tags: As an option to better assess the trustworthiness
of an Attestor, a Verifier can request the reference hashes (RIM, of an Attester, a Verifier can request the reference hashes (RIM,
which are often referred to as golden measurements) of all started which are often referred to as golden measurements) of all started
software components to compare them with the entries in the software components to compare them with the entries in the
measurement log. References hashes regarding installed (and measurement log. References hashes regarding installed (and
therefore running) software can be provided by the manufacturer therefore running) software can be provided by the manufacturer
via SWID tags. SWID tags are provided by the Attestor using the via SWID tags. SWID tags are provided by the Attester using the
Concise SWID representation [I-D.ietf-sacm-coswid] and bundled Concise SWID representation [I-D.ietf-sacm-coswid] and bundled
into a CBOR array (a RIM Manifest). Ideally, the reference hashes into a CBOR array (a RIM Manifest). Ideally, the reference hashes
include a signature created by the manufacturer of the software to include a signature created by the manufacturer of the software to
prove their integrity. prove their integrity.
These information elements could be sent en bloc, but it is These information elements could be sent en bloc, but it is
recommended to retrieve them separately to save bandwidth, since recommended to retrieve them separately to save bandwidth, since
these elements have different update cycles. In most cases, these elements have different update cycles. In most cases,
retransmitting all seven information elements would result in retransmitting all seven information elements would result in
unnecessary redundancy. unnecessary redundancy.
Furthermore, in some scenarios it might be feasible not to store all Furthermore, in some scenarios it might be feasible not to store all
elements on the Attestor endpoint, but instead they could be elements on the Attester endpoint, but instead they could be
retrieved from another location or be pre-deployed to the Verifier. retrieved from another location or be pre-deployed to the Verifier.
It is also feasible to only store public keys on the Verifier and It is also feasible to only store public keys on the Verifier and
skip the whole certificate provisioning completely in order to save skip the whole certificate provisioning completely in order to save
bandwidth and computation time for certificate verification. bandwidth and computation time for certificate verification.
4.1. TUDA Information Elements Update Cycles 4.1. TUDA Information Elements Update Cycles
An endpoint can be in various states and have various information An endpoint can be in various states and have various information
associated with it during its life cycle. For TUDA, a subset of the associated with it during its life cycle. For TUDA, a subset of the
states (which can include associated information) that an endpoint states (which can include associated information) that an endpoint
skipping to change at page 13, line 44 skipping to change at page 16, line 8
reset after an endpoint is powered off. reset after an endpoint is powered off.
o very volatile, because they change during an uptime cycle (the o very volatile, because they change during an uptime cycle (the
period of time an endpoint is powered on, starting with its boot). period of time an endpoint is powered on, starting with its boot).
This includes the content of PCRs of a hardware RoT and thereby This includes the content of PCRs of a hardware RoT and thereby
also the PCR-restricted signing keys used for attestation. also the PCR-restricted signing keys used for attestation.
Depending on this "lifetime of state", data has to be transported Depending on this "lifetime of state", data has to be transported
over the wire, or not. E.g. information that does not change due to over the wire, or not. E.g. information that does not change due to
a reboot typically has to be transported only once between the a reboot typically has to be transported only once between the
Attestor and the Verifier. Attester and the Verifier.
There are three kinds of events that require a renewed attestation: There are three kinds of events that require a renewed attestation:
o The Attestor completes a boot-cycle o The Attester completes a boot-cycle
o A relevant PCR changes o A relevant PCR changes
o Too much time has passed since the last attestation statement o Too much time has passed since the last attestation statement
The third event listed above is variable per application use case and The third event listed above is variable per application use case and
also depends on the precision of the clock included in the hardware also depends on the precision of the clock included in the hardware
RoT. For usage scenarios, in which the device would periodically RoT. For usage scenarios, in which the device would periodically
push information to be used in an audit-log, a time-frame of push information to be used in an audit-log, a time-frame of
approximately one update per minute should be sufficient in most approximately one update per minute should be sufficient in most
cases. For those usage scenarios, where Verifiers request (pull) a cases. For those usage scenarios, where Verifiers request (pull) a
fresh attestation statement, an implementation could use the hardware fresh attestation statement, an implementation could use the hardware
RoT continuously to always present the most freshly created results. RoT continuously to always present the most freshly created results.
To save some utilization of the hardware RoT for other purposes, To save some utilization of the hardware RoT for other purposes,
however, a time-frame of once per ten seconds is recommended, which however, a time-frame of once per ten seconds is recommended, which
would typically leave about 80% of utilization for other would typically leave about 80% of utilization for other
applications. applications.
Attestor Verifier Attester Verifier
| | | |
Boot | Boot |
| | | |
Create Sync-Token | Create Sync-Token |
| | | |
Create Restricted Key | Create Restricted Key |
Certify Restricted Key | Certify Restricted Key |
| | | |
| AIK-Cert ---------------------------------------------> | | AIK-Cert ---------------------------------------------> |
| Sync-Token -------------------------------------------> | | Sync-Token -------------------------------------------> |
skipping to change at page 17, line 30 skipping to change at page 19, line 42
compared with the measurement logs. compared with the measurement logs.
9. Contributors 9. Contributors
TBD TBD
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.birkholz-rats-architecture]
Birkholz, H., Wiseman, M., Tschofenig, H., and N. Smith,
"Architecture and Reference Terminology for Remote
Attestation Procedures", draft-birkholz-rats-
architecture-01 (work in progress), March 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Subscription to YANG Notifications",
RFC 8639, DOI 10.17487/RFC8639, September 2019,
<https://www.rfc-editor.org/info/rfc8639>.
[RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Dynamic Subscription to YANG Events
and Datastores over NETCONF", RFC 8640,
DOI 10.17487/RFC8640, September 2019,
<https://www.rfc-editor.org/info/rfc8640>.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
September 2019, <https://www.rfc-editor.org/info/rfc8641>.
10.2. Informative References 10.2. Informative References
[AIK-Credential] [AIK-Credential]
TCG Infrastructure Working Group, "TCG Credential TCG Infrastructure Working Group, "TCG Credential
Profile", 2007, <https://www.trustedcomputinggroup.org/wp- Profile", 2007, <https://www.trustedcomputinggroup.org/wp-
content/uploads/IWG-Credential_Profiles_V1_R1_14.pdf>. content/uploads/IWG-Credential_Profiles_V1_R1_14.pdf>.
[AIK-Enrollment] [AIK-Enrollment]
TCG Infrastructure Working Group, "A CMC Profile for AIK TCG Infrastructure Working Group, "A CMC Profile for AIK
Certificate Enrollment", 2011, Certificate Enrollment", 2011,
<https://www.trustedcomputinggroup.org/wp-content/uploads/ <https://www.trustedcomputinggroup.org/wp-content/uploads/
IWG_CMC_Profile_Cert_Enrollment_v1_r7.pdf>. IWG_CMC_Profile_Cert_Enrollment_v1_r7.pdf>.
[I-D.ietf-cbor-cddl] [I-D.birkholz-rats-reference-interaction-model]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H. and M. Eckel, "Reference Interaction Model
definition language (CDDL): a notational convention to for Challenge-Response-based Remote Attestation", draft-
express CBOR and JSON data structures", draft-ietf-cbor- birkholz-rats-reference-interaction-model-01 (work in
cddl-07 (work in progress), February 2019. progress), July 2019.
[I-D.ietf-core-comi] [I-D.ietf-core-comi]
Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP Veillette, M., Stok, P., Pelov, A., Bierman, A., and I.
Management Interface", draft-ietf-core-comi-04 (work in Petrov, "CoAP Management Interface", draft-ietf-core-
progress), November 2018. comi-07 (work in progress), July 2019.
[I-D.ietf-sacm-coswid] [I-D.ietf-sacm-coswid]
Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
Waltermire, "Concise Software Identifiers", draft-ietf- Waltermire, "Concise Software Identification Tags", draft-
sacm-coswid-08 (work in progress), November 2018. ietf-sacm-coswid-12 (work in progress), July 2019.
[I-D.ietf-sacm-terminology] [I-D.ietf-sacm-terminology]
Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and
A. Montville, "Security Automation and Continuous A. Montville, "Security Automation and Continuous
Monitoring (SACM) Terminology", draft-ietf-sacm- Monitoring (SACM) Terminology", draft-ietf-sacm-
terminology-16 (work in progress), December 2018. terminology-16 (work in progress), December 2018.
[IEEE1609] [IEEE1609]
IEEE Computer Society, "1609.4-2016 - IEEE Standard for IEEE Computer Society, "1609.4-2016 - IEEE Standard for
Wireless Access in Vehicular Environments (WAVE) -- Multi- Wireless Access in Vehicular Environments (WAVE) -- Multi-
skipping to change at page 20, line 22 skipping to change at page 23, line 14
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[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>.
[SCALE] Fuchs, A., "Improving Scalability for Remote Attestation", [SCALE] Fuchs, A., "Improving Scalability for Remote Attestation",
Master Thesis (Diplomarbeit), Technische Universitaet Master Thesis (Diplomarbeit), Technische Universitaet
Darmstadt, Germany, 2008. Darmstadt, Germany, 2008.
[SFKE2008] [SFKE2008]
Stumpf, F., Fuchs, A., Katzenbeisser, S., and C. Eckert, Stumpf, F., Fuchs, A., Katzenbeisser, S., and C. Eckert,
"Improving the scalability of platform attestation", "Improving the scalability of platform attestation",
ACM Proceedings of the 3rd ACM workshop on Scalable ACM Proceedings of the 3rd ACM workshop on Scalable
trusted computing - STC '08 , page 1-10, trusted computing - STC '08 , page 1-10,
DOI 10.1145/1456455.1456457, 2008. DOI 10.1145/1456455.1456457, 2008.
skipping to change at page 21, line 28 skipping to change at page 24, line 28
SNMPv3 [STD62] [RFC3411] is widely available on computers and also SNMPv3 [STD62] [RFC3411] is widely available on computers and also
constrained devices. To transport the TUDA information elements, an constrained devices. To transport the TUDA information elements, an
SNMP MIB is defined below which encodes each of the seven TUDA SNMP MIB is defined below which encodes each of the seven TUDA
information elements into a table. Each row in a table contains a information elements into a table. Each row in a table contains a
single read-only columnar SNMP object of datatype OCTET-STRING. The single read-only columnar SNMP object of datatype OCTET-STRING. The
values of a set of rows in each table can be concatenated to values of a set of rows in each table can be concatenated to
reconstitute a CBOR-encoded TUDA information element. The Verifier reconstitute a CBOR-encoded TUDA information element. The Verifier
can retrieve the values for each CBOR fragment by using SNMP GetNext can retrieve the values for each CBOR fragment by using SNMP GetNext
requests to "walk" each table and can decode each of the CBOR-encoded requests to "walk" each table and can decode each of the CBOR-encoded
data items based on the corresponding CDDL [I-D.ietf-cbor-cddl] data items based on the corresponding CDDL [RFC8610] definition.
definition.
Design Principles: Design Principles:
1. Over time, TUDA attestation values age and should no longer be 1. Over time, TUDA attestation values age and should no longer be
used. Every table in the TUDA MIB has a primary index with the used. Every table in the TUDA MIB has a primary index with the
value of a separate scalar cycle counter object that value of a separate scalar cycle counter object that
disambiguates the transition from one attestation cycle to the disambiguates the transition from one attestation cycle to the
next. next.
2. Over time, the measurement log information (for example) may grow 2. Over time, the measurement log information (for example) may grow
 End of changes. 62 change blocks. 
172 lines changed or deleted 311 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/