An Information Model for Assertions used in RATS
draft-birkholz-rats-information-model-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Authors | Henk Birkholz , Michael Eckel | ||
Last updated | 2019-07-08 | ||
RFC stream | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-birkholz-rats-information-model-00
RATS Working Group H. Birkholz Internet-Draft M. Eckel Intended status: Standards Track Fraunhofer SIT Expires: January 9, 2020 July 08, 2019 An Information Model for Assertions used in RATS draft-birkholz-rats-information-model-00 Abstract This document defines a standardized information model (IM) for assertions that can be used in remote attestation procedures (RATS). The information elements defined include attestation assertions 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 January 9, 2020. Copyright Notice Copyright (c) 2019 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 Birkholz & Eckel Expires January 9, 2020 [Page 1] Internet-Draft IMARA July 2019 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Document Structure . . . . . . . . . . . . . . . . . . . 3 2. RATS Information Elements . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 5. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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.birkholz-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 assertions that are accompanied by a proof of their validity). In general, RATS convey information elements that: o enable the functionality of remote attestation protocols, o are able to express assertions about an attester's composition, configuration, or operational state, o represent the provenance of assertions, including entities that provide assertions on behalf of the attester, o compose a type of proof of validity with respect to other assertions, and that o are either verifiable (via comparison with trusted reference values) or non-verifiable. Birkholz & Eckel Expires January 9, 2020 [Page 2] Internet-Draft IMARA July 2019 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_". Birkholz & Eckel Expires January 9, 2020 [Page 3] Internet-Draft IMARA July 2019 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 an assertion value (e.g. by asserters such as a 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] Assertion Selection: [P] A filter expression that enables the conveyance of a subset of all attestation assertions 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 Assertion. 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] Birkholz & Eckel Expires January 9, 2020 [Page 4] Internet-Draft IMARA July 2019 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 computing contexts (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 Birkholz & Eckel Expires January 9, 2020 [Page 5] Internet-Draft IMARA July 2019 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 computing context. 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 Assertions 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 computing context (see [I-D.birkholz-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] Birkholz & Eckel Expires January 9, 2020 [Page 6] Internet-Draft IMARA July 2019 An IE representing the number of seconds since the first computing context 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] Birkholz & Eckel Expires January 9, 2020 [Page 7] Internet-Draft IMARA July 2019 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 6. Contributors TBD 7. References 7.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. [I-D.birkholz-rats-basic-yang-module] Birkholz, H., Eckel, M., Bhandari, S., Sulzen, B., Voit, E., and G. Fedorkow, "YANG Module for Basic Challenge- Response-based Remote Attestation Procedures", draft- birkholz-rats-basic-yang-module-00 (work in progress), March 2019. [I-D.birkholz-rats-tuda] Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, "Time-Based Uni-Directional Attestation", draft-birkholz- rats-tuda-00 (work in progress), March 2019. [I-D.ietf-rats-eat] Mandyam, G., Lundblade, L., Ballesteros, M., and J. O'Donoghue, "The Entity Attestation Token (EAT)", draft- ietf-rats-eat-01 (work in progress), July 2019. Birkholz & Eckel Expires January 9, 2020 [Page 8] Internet-Draft IMARA July 2019 [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", draft-tschofenig-rats-psa-token-02 (work in progress), July 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [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, <https://www.rfc-editor.org/info/rfc8342>. 7.2. Informative References [I-D.birkholz-rats-reference-interaction-model] Birkholz, H. and M. Eckel, "Reference Interaction Model for Challenge-Response-based Remote Attestation", draft- birkholz-rats-reference-interaction-model-00 (work in progress), March 2019. [I-D.ietf-sacm-terminology] Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and A. Montville, "Security Automation and Continuous Monitoring (SACM) Terminology", draft-ietf-sacm- terminology-16 (work in progress), December 2018. [I-D.richardson-rats-usecases] Richardson, M., Wallace, C., and W. Pan, "Use cases for Remote Attestation common encodings", draft-richardson- rats-usecases-03 (work in progress), July 2019. Authors' Addresses Henk Birkholz Fraunhofer SIT Rheinstrasse 75 Darmstadt 64295 Germany Email: henk.birkholz@sit.fraunhofer.de Birkholz & Eckel Expires January 9, 2020 [Page 9] Internet-Draft IMARA July 2019 Michael Eckel Fraunhofer SIT Rheinstrasse 75 Darmstadt 64295 Germany Email: michael.eckel@sit.fraunhofer.de Birkholz & Eckel Expires January 9, 2020 [Page 10]