RATS Working Group H. Birkholz
Internet-Draft M. Eckel
Intended status: Standards Track Fraunhofer SIT
Expires: July 12, 2020 January 09, 2020

An Information Model for Claims used in RATS
draft-birkholz-rats-information-model-01

Abstract

This document defines a standardized information model (IM) for Claims that can be used in remote attestation procedures (RATS). The information elements defined include attestation Claims which provide information about system components characteristics, as well as commonly used attributes and attribute structures that are required by protocols facilitating remote attestation.

Status of This Memo

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

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

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

This Internet-Draft will expire on July 12, 2020.

Copyright Notice

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.

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


Table of Contents

1. Introduction

Remote attestation procedures (RATS) are used to increase the trust in the trustworthiness of an Attester. This is typically accomplished by conveying Attestation Evidence from an Attester to a Verifier that is able to appraise the Evidence. The exact definitions of RATS roles, such as an Attester or a Verifier, are specified in the RATS architecture [I-D.ietf-rats-architecture]. This document defines the common information elements (IE) that are able to express the characteristics of an Attester. Ultimately, these IE can be used to compose Attestation Evidence (attestation Claims that are accompanied by a proof of their validity).

In general, RATS convey information elements that:

1.1. Document Structure

Every information element listed is annotated with one or more of these attributes:

Protocol (P):
This IE is used on a remote attestation protocol layer, typically on the control plane or as protocol-specific data plane content.
Hardware (H):
This IE expresses characteristics about an Attester’s hardware components or the composition of its hardware components.
Software (S):
This IE expresses characteristics about an Attester’s software components or their semantic relationship. The term software component – in the scope of this document – subsumes firmware, bootloader, BIOS/(U)EFI, and microcode.
Operational State (O):
This IE is used to convey information about the combination of applied configuration and system state as defined in [RFC8342].
Verifiable (V):
This IE requires reference integrity measurements (RIM), compliance-policy, certification-path, or another type of trust-chain in order to be appraised appropriately by a Verifier.

Additionally, every IE definition includes a reference to the source of its definition, if it is not specified in this document for the first time (which is the most likely case). If a source of a definition is not a specification or (proposed) standard, but a draft, a web resource, or source that cannot be attribute with a DOI or ISSN, the following attribute is associated.

Unstable (U):
The source of the definition of this IE may change in the future and is not considered to be stable at the time of publication of this document.

Information elements might reference other information elements or have to be associated in a set (with or without a specific order) in order to convey the intended meaning to a Verifier. Reference to other IE inside this documents simply use their name as reference. In consequence, an IE can be a superstructure composed of other IE with its own name (and potentially additional definition text that defines its purpose and or usage).

The RATS Information Model allows for expressing a hierarchical taxonomy. If an IE is a specialisation of another IE, the last sentence in the definition includes a “This IE is a specialization of IE NAME”.

The ordering of IE is in descending alphabetical order; independent of source or semantic relationship to other IE, or other types of hierarchy.

2. RATS Information Elements

Age:
The latency between the creation of a Claim value (e.g. by asserters such as hardware sensors or the Linux Integrity Measurement Architecture) including its composition into Attestation Evidence and its following conveyance to another RATS Actor/Role in RATS. The Age IE does not require a threshold at which point another information element is considered “old” and an age information element has to be included.
Reference: [I-D.ietf-rats-eat]
Claim Selection:
[P]
A filter expression that enables the conveyance of a subset of all attestation Claims available to the Attester, if requested by a Verifier.
Attestation Evidence:
[H, S, O, V]
A composite IE that must include at least an Authentication-Secret Identifier, an Attester Identity, and at least one Attestation Claim. Attestation Evidence is always signed via the Authentication Secret and thereby binds the listed information elements cryptographically. Attestation Evidence can only be trusted by a Verifier if it is associated with a trust anchor the Verifier also trusts.
Attester Identifier:
[P, O, V]
A value associated or bound to a distinguishable Attester that is intended to uniquely identify it, but is not directly associated with a trust anchor. Additional Endorsement Documents can increase the level of confidence in an Attester Identifier.
Attester Identity:
[P, S, V]
A document about a distinguishable Attester issued and signed by a third party. If not cryptographically associated with a trust anchor directly or indirectly, this IE is a specialization of Attester Identifier.
Attestation Result:
[P]
A set of one or more values that are created by an appraisal action of a Verifier. Attestation Result is the most generic definition of the output of RATS and are typically consumed by relying parties.
Authentication-Secret Identifier:
[O, V]
An identifier that is associated with an authentication secret used to sign Attestation Evidence.
Authorization Challenge:
[P]
The input to an challenge-response protocol hand-shake. This IE can be Nonce, but also the output of a local attestation procedure.
Reference [I-D.tschofenig-rats-psa-token]
Endorsement Document:
[P, H, S, V]
A document about the capabilities and functionality of one or more sub-components of a distinguishable Attester issued and signed by a third party. Endorsement Documents are intended to render Attestation Evidence trustworthy. If not cryptographically associated with a trust anchor directly or indirectly, this IE is a specialization of System Component Identifier.
Location:
A global standardized set of coordinates and related attributes representing the geographic position of a device based on a geodetic system, such as Navstar GPS. The coordinate values can have different meaning with respect to the geographic position of a device depending on the geodetic system used. The default is WGS-84.
The basic location attributes include: latitude, longitude, altitude, accuracy, altitude accuracy, heading, and velocity.
Reference [I-D.ietf-rats-eat]
Measured Boot Characteristics:
[H, S, V]
If every piece of software is measured by a root-of-trust for measuring during boot time and across staged execution environments (e.g. UEFI, Bootloader, Kernel, Rich OS), associated information about how and in which operational states these measurements are conducted is vital to RATS. This IE represents several states of a (composite) device with respect to measured boot (previously often called secure boot) including: “Secure Boot Enabled”, “Debug Disabled”, “Debug Disabled Since Boot”, “Debug Permanent Disable”, “Debug Full Permanent Disable”.
Nonce:
[P]
An information element with two major uses: the prevention of replay-attacks and as an IE that can be used in a challenge-response interaction model. It is created by the requester to provide Evidence about the freshness of the corresponding response. It is important to highlight that a nonce by itself does not protect from relay-attacks.
OEM Identifier:
[H, S, V]
A organizationally unique identifier (OUI) assigned by the IEEE Registration Authority (IEEE RA). This IE is associated with a device or a distinguishable sub-component of a composite device with its own execution environment. It intended to identify a device(component) during its life-cycle. This is a specialization of System Component Identifier.
Reference [I-D.ietf-rats-eat]
Origination:
[P, S, V]]
An IE representing attestation provenance. Attestation Claims or Attestation Evidence are produced by a specific source of information that is intended to be uniquely identifiable. The source of information is a distinguishable type of execution environment (see [I-D.ietf-rats-architecture]) of a device or the sub-components of a composite device.
Reference [I-D.ietf-rats-eat]
Universal Entity ID:
[P, H, V]
A unique identifier permanently associated with an individual manufactured entity / device, such as a mobile phone, a water meter, a Bluetooth speaker or a networked security camera. This IE is intended to either identify an device or a submodule or subsystem of a device. It does not identify types, models or classes of devices. It is akin to a serial number, though it does not have to be sequential. This IE is a specialization of System Component Identifier.
Reference [I-D.ietf-rats-eat]
Uptime:
[H, S]
An IE representing the number of seconds since the first execution environment of a (composite) device is able to measure it.
Reference [I-D.ietf-rats-eat]
Security Level:
[H, S, V]
A level of confidence with respect to the resilience against attacks intended to compromise Attestation Evidence. A Security Level can be associated with an Origination. This IE is context specific and requires a scope-specific definition of values as part of a security framework. The [I-D.ietf-rats-eat] document, for example, provides an enumeration of security levels that is similar to the Metadata Service defined by the Fast Identity Online (FIDO) Alliance.
Reference [I-D.ietf-rats-eat]
Software Component Identifier:
[S, V]
An IE representing one or more distinguishable Software Components [I-D.ietf-sacm-terminology] that were loaded and measured by an appropriate root-of-trust. The use of this IE typically requires the use of Measured Boot.
Reference [I-D.tschofenig-rats-psa-token]
System Component Identifier:
[H, S, V]
An identifier intended to uniquely identify a distinguishable system component. System components can be hardware components or software components (e.g. a virtual machine). The system component can be an “atomic” device (i.e. a composite device with only one hardware component) or a part of a composite device.
Timestamp:
[P, S]
A generic information element that represents a certain point of time in the past. The level of confidence in the value of a timestamp is based on the trustworthiness of the source of time, which can be local or remote, a composite of multiple time sources to represent the state synchronization, as well as the precision and the accuracy of the source of time itself.
Timestamps can be time-zone specific and therefore change their meaning if the definition of time zones changes.
Verification Service Indicator:
[P, S, V]
This IE provides a hint (typically consumed by a Relying Party) that enables the discovery of an appropriate Verification Service or Remote Attestation Service, e.g. a URL.
Reference [I-D.tschofenig-rats-psa-token]

3. Security Considerations

Probably none

4. Acknowledgments

TBD

5. Change Log

Initial version -00

Refresh to version -01 for visibility

6. Contributors

TBD

7. References

7.1. Normative References

[I-D.birkholz-rats-tuda] Fuchs, A., Birkholz, H., McDonald, I. and C. Bormann, "Time-Based Uni-Directional Attestation", Internet-Draft draft-birkholz-rats-tuda-01, September 2019.
[I-D.ietf-rats-architecture] Birkholz, H., Thaler, D., Richardson, M. and N. Smith, "Remote Attestation Procedures Architecture", Internet-Draft draft-ietf-rats-architecture-00, December 2019.
[I-D.ietf-rats-eat] Mandyam, G., Lundblade, L., Ballesteros, M. and J. O'Donoghue, "The Entity Attestation Token (EAT)", Internet-Draft draft-ietf-rats-eat-01, July 2019.
[I-D.ietf-rats-yang-tpm-charra] Birkholz, H., Eckel, M., Bhandari, S., Sulzen, B., Voit, E., Xia, L., Laffey, T. and G. Fedorkow, "A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs", Internet-Draft draft-ietf-rats-yang-tpm-charra-00, January 2020.
[I-D.tschofenig-rats-psa-token] Tschofenig, H., Frost, S., Brossard, M., Shaw, A. and T. Fossati, "Arm's Platform Security Architecture (PSA) Attestation Token", Internet-Draft draft-tschofenig-rats-psa-token-04, November 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K. and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018.

7.2. Informative References

[I-D.birkholz-rats-reference-interaction-model] Birkholz, H. and M. Eckel, "Reference Interaction Models for Remote Attestation Procedures", Internet-Draft draft-birkholz-rats-reference-interaction-model-02, January 2020.
[I-D.ietf-sacm-terminology] Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N. and A. Montville, "Security Automation and Continuous Monitoring (SACM) Terminology", Internet-Draft draft-ietf-sacm-terminology-16, December 2018.
[I-D.richardson-rats-usecases] Richardson, M., Wallace, C. and W. Pan, "Use cases for Remote Attestation common encodings", Internet-Draft draft-richardson-rats-usecases-06, November 2019.

Authors' Addresses

Henk Birkholz Fraunhofer SIT Rheinstrasse 75 Darmstadt, 64295 Germany EMail: henk.birkholz@sit.fraunhofer.de
Michael Eckel Fraunhofer SIT Rheinstrasse 75 Darmstadt, 64295 Germany EMail: michael.eckel@sit.fraunhofer.de