RATS Working Group H. Birkholz
Internet-Draft Fraunhofer SIT
Intended status: Standards Track P. Uiterwijk
Expires: January 14, 2021 Red Hat
N. Smith
Intel
J. Fitzgerald-McKay
Department of Defense
D. Waltermire
NIST
S. Bhandari
Cisco
July 13, 2020

Reference Integrity Measurement Extension for Concise Software Identities
draft-birkholz-rats-coswid-rim-01

Abstract

Concise Software Identification (CoSWID) tags identify and describe individual software components, patches, and installation bundles. CoSWID is based on ISO/IEC 19770-2:2015 2:2015 that provides a complementary XML schema definition (XSD) for Software Identification (SWID) tags. CoSWID supports the same features as the corresponding XML SWID tags. The CoSWID specification also includes more structured extensibility features and reduces a few of ambiguities that are not explicitly resolved in the ISO XSD. In this document, these extensibility features (extension points) are used to add attributes to the CoSWID specification. The new attributes allow for the use of CoSWID as Reference Integrity Measurements (RIM). There are four sets of RIM features defined in this specification. 1.) attributes that support RIM manifests for Measured Boot, 2.) attributes that support package manager managed structures, 3.) attributes that allow for OID to be used in the description of Reference Integrity Measurements, and 4.) attributes for object trees in support of Target Environments that are chained via Layered 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 14, 2021.

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

Reference Integrity Measurements describe the intended state of (composite) software components installed on a (composite) device. A measurement of all installed software components of a devices allows for assertions about the trustworthiness of the given device. In combination with a root of trust (RoT) for reporting (RTR), these measurements can be refined into evidence and enable IETF Remote ATtestation procedureS (RATS). RATS support the decision process of whether to put trust in the trustworthiness of a device – or not.

The RATS architecture [I-D.ietf-rats-architecture] defines the roles Verifiers, Attesters, Endorsers, and Relying Parties. The RATS architecture also specifies that Attestation Evidence is created by Attesters and consumed by Verifiers. Ultimately, the goal is to enable a Relying Party to put trust in the trustworthiness of a remote peer (the Attester). Attestation Evidence is composed of believable assertions about an Attester’s trustworthiness characteristics. In RATS, these assertions are called Claims. The Verifier conducts a set of appraisal procedures in order to assess the compliance of an Attester’s trustworthiness characteristics.

A prominent appraisal procedure in RATS is the comparison of Claim values included in Attestation Evidence with Reference Claim values provided by Endorsers (e.g. supply chain entities). The comparison of Claim values via Reference Claim values is vital for the assessment of compliance metrics with respect to software components installed on an Attester. A typical objective here is the remediation of already vulnerabilities discovered in certain versions of software components.

The Integrity Measurement Architecture (IMA) of the Linux Security Modules (LSM) provides a detailed Event Log (sometimes also referred to as a Measurement Log) that retains a sequence of hash measurements of every software sub-component (e.g. a firmware, an ELF executable, or a configuration file) that is created and appended to the sequence of measurements that composes the event log before the software component in question is started or read.

In essence, to enable this appraisal procedure conducted by Verfiers an Attester’s IMA provides Event Logs that include the hash values of every started software component and therefore are part of the Attestation Evidence an Attester creates. The complementary well-known-values that Verifiers require are included in the Reference Integrity Measurements (RIM). RIMs can be provided via Software Identification tags created by Endorsers, such as the software creators, manufacturers, vendors, or other trusted third parties (e.g. supply chain or certification entities).

This document provides an extension to the CoSWID specification defined in [I-D.ietf-sacm-coswid]. The extension adds attributes to CoSWID tags that enable them to express RIMs. One prominent subset of these attributes are illustrated in the TCG Reference Integrity Manifest Information Model [ref] specification. These attributes are added to the existing CoSWID specification via the most general extension point the CoSWID specification provides: $$coswid-extensions. An additional map definition named “reference-measurements” is added and is defined in section [ref] of this document. Another prominent subset is the addition of an object tree next to the file system tree as defined by [I-D.ietf-sacm-coswid]. The object tree enables the representation of multiple layered execution environments as described by the Layered Attestation concept in the RATS architecture [I-D.ietf-rats-architecture].

Furthermore, a usage profile for signed CoSWID tags is defined in this specification in support of the software-component structure of systems managed by package managers. Signed CoSWID tags that are aligned with that software model can be used to describe the contents of one or multiple of the packages that make up the contents of a system. In this case, it may be that multiple CoSWID tags are provided as Reference Claim values for a attestation by a single Attester. In order to minimize the impact on the sizes of packages, it is likely that any CoSWID tags delivered as part of packages as part of a package manager managed system will not contain actual reference values, but instead a link-entry to a CoSWID tag published by the vendor in a repository.

Reference Integrity Measurements are a subset of the Conceptual Messages defined as Endorsements. RIMs provide a vital resource to be consumed by Verifiers in conjunction with Appraisal Policies and Evidence. While RIMs represent nominal values, Appraisal Policies represent imperative guidance how to use nominal values in an appraisal procedure. Evidence represents assertions about the trustworthiness of a device’s Target Environments created by its own Attesting Environment. As Evidence can be rather complex and its appraisal therefore a burden for Relying Parties that are interested in trustworthiness evaluations, Verifies take on this duty and create easier to digest Attestation Results for Relying Parties. In consequence, Verifiers are the entities that have to put trust in the provenance and integrity of RIMs – and Endorsements in general – relying on proof of integrity and authenticity.

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

2. CoSWID Attribute Extensions

This specification defines four types of attribute sets that can be added to the CoSWID specification via its defined extension points.

  1. Attributes that support RIM manifests for Measured Boot (often referred to as Secure Boot),
  2. Attributes that support the RPM package manager structure,
  3. Attributes that allow to represent composite devices including several Target Environments, and
  4. Attributes that allow for OID to be used in the description of Reference Integrity Measurements.

2.1. RIM requirements on existing CoSWID attributes

As defined by NIST IR 8060 [ref], there are required “Meta Attributes” for XML SWID tags that have to be included in a SWID tag in order to compose a valid SWID RIM. In this section, these attributes are mapped to CoSWID attributes and corresponding requirements on attributes defined in the CoSWID specification to compose valid NIST IR 8060 signed Payload content in the Concise Software Identity Reference Integrity Measurement (CoSWID RIM) representation.

The ‘software-meta-entry’ type defined in the CoSWID specification includes the optional members ‘product’, ‘colloquial-version’, ‘revision’, and ‘edition’. These four members MUST be included in a CoSWID RIM in order to compose a valid Reference Integrity Measurement in alignment with NIST IR 8060. Furthermore, the semantics of the text (tstr) typed values MUST convey content that allows for semantic interoperability in a given scope (e.g., an administrative domain). The software-meta-entries provide vital support for steering decisions made by the RATS verifier role in order to enable discovery and matching of related or additional CoSWID RIM available to or discoverable by the verifier.

2.2. RIM Extensions for Measured Boot

The following attributes are derived from the TCG Reference Integrity Manifest Information Model [ref] specification. These attributes support the creation of very small CoSWID RIM tags that enable the Remote Integrity Verification (RIV [I-D.fedorkow-rats-network-device-attestation]) of small things, i.e., constrained devices in constrained network environments. In consequence, the majority of the attributes listed in this section represent metadata about firmware and supply chain entities that provide firmware for a device (platform). Analogously to the mandated software-meta-entries illustrated above, the attributes defined in the table below provide more context and enable steering decisions for the appraisal procedures of a Verifier. Consecutively, RIM have to be managed and curated in a consistent manner so that there is no significant threshold for a Verifier to make use of them during an appraisal procedure.

The design of the additional RIM attributes in this section is motivated by the vast variety of identifier types used in production today, e.g. endorsement documents [I-D.ietf-rats-architecture] that are enrolled or on-boarded on the Attester itself. It is vital to highlight that this variety can render semantic self-descriptiveness more difficult. Most importantly though: interoperability beats self-descriptiveness. A convergence towards a common identification scheme with respect to software components and its subset that is firmware is highly encouraged - alas not achieved at the time of creating this proposed standard. The following table defines the semantics of the set of new members that are added via the reference-measurement-entry map. The reference-measurement-entry map is added using the $$coswid-extension CDDL extension point.

Attribute Name Quantity Description
payload-type 0-1 The value of this attribute MUST be one equivalent of the following three choices. ‘direct’: the representation used in this RIM (and referred RIMs) is using the CoSWID encoding as its representation. ‘indirect’: the representation used in referred RIMs (‘Support RIMs) is using a different representation than CoSWID as it’s encoding. Analogously, a reference to the corresponding specification MUST be provided if the value is set to an equivalent of ‘indirect’ (see binding-spec-name and binding-spec-version). ‘hybrid’: the representation used in the referred RIMs (‘Support RIMs’) is a mix of CoSWID representations and other representations. In this case, a reference to the representation used MUST be included - even if it is the CoSWID representation - for every Support RIM (see ‘binding-spec-name’ and ‘binding-spec-version’ definition in this table).
platform-configuration-uri-global 0-1 A byte-comparable reference to a Platform Configuration URI as defined by the TCG Platform Certificate Profile [ref TCG Platform Certificate Profile, Version 1.1] for X.509v3 certificates that MUST be identical to the URI included in a TCG Platform Certificate pointing to a resource providing a copy of the CoSWID RIM this attribute is included in.
platform-configuration-uri-local 0-1 A byte-comparable reference to a Platform Configuration URI defined by the TCG Platform Certificate Profile [ref TCG Platform Certificate Profile, Version 1.1] that MUST represent the resource at which a copy of this CoSWID RIM can be found within the (composite) device/platform itself.
binding-spec-name 1 If the value of ‘payload-type’ is an equivalent to the enumeration ‘indirect’, the value of this attribute MUST contain a global unique text (tstr) identifier referring to the specification that defines the representation of the referred RIM in order to enable its decoding.
binding-spec-version 1 If the value of ‘payload-type’ is an equivalent to the enumeration ‘indirect’, the value of this attribute MUST contain a unique version number with respect to the specification represented in the value of ‘binding-spec-name’.
platform-manufacturer-id 0-1 An identifier based on the IANA Private Enterprise Number registry that is assigned to firmware manufacturer. This identifier MUST be included unless the firmware manufacturer and the platform manufacturer are represented by the same text (tstr) value. Analogously, if the firmware manufacturer and the platform manufacturer are represented via the same text (tstr) value, this attribute MAY be omitted.
platform-manufacturer-name 0-1 An identifier number (uint) value that uniquely represents the firmware manufacturer. This identifier MUST be included unless the firmware manufacturer and the platform manufacturer are represented via the same number (unit) value, this attribute MAY be omitted.
platform-model-name 1 An identifier text (tstr) value enabling the identification of a certain device model/type composite. The reliability of this identifier is not absolute. In consequence this identifier MUST NOT be omitted. In an case, the use of this identifier requires foresight and preparation as it’s purpose supports semantic interoperability. Arbitrary, conflicting, or unresolvable values SHOULD be avoided.
platform-version 0-1 A byte-comparable reference to a Platform Certificate’s ‘Manufacturer-Specific Identifier’ extension value [ref TCG Platform Certificate Profile, Version 1.1].
firmware-manufacturer-id 0-1 An IANA defined unique value that is a Private Enterprise Number (Platform manufacturer unique identifier) that SHOULD be included in a CoSWID RIM that covers firmware.
firmware-manufacturer-name 0-1 An identifier that is represented as the name of a platform manufacturer via a text (tstr) value that SHOULD be included in a CoSWID RIM that covers firmware.
firmware-model-name 0-1 An identifier that represents the target platform model via a text (tstr) value that SHOULD be included in a CoSWID RIM.
firmware-version 0-1 An identifier that is represented as the version number of a specific firmware version corresponding to a given set of platform identifiers and SHOULD be included in a CoSWID RIM.
boot-events 0-1 A reference to the platform measured boot event logs that can be compared to individual events from the platform measured boot events collected at platform runtime.

2.3. RIM Extensions for Software Package Management

To enable very small CoSWID tags that basically are signed references to full Base RIMs for each software package that ultimately include all the hash values required by the appraisal procedure of a Verifier, the member rim-reference is added using the $$payload-extension CDDL extension point.

Attribute Name Quantity Description
rim-reference 0-1 A URI pointing to the CoSWID Base RIM that will list the payload reference measurements (hashes) in case of a minimal CoSWID tag.

2.4. RIM Extensions for Composite Device

Attesters that are composite devices can include several Target Environments. Some of these Target Environments can take on the duties of Attesting Environments during a boot sequence as described in section 4.3. of the RATS architecture [I-D.ietf-rats-architecture]. The corresponding procedure is called Layered Attestation and requires a dedicated RIM for each Target Environment of the Attester. The addition of object tree attributes to CoSWID using the $$resource-collection-extension extension point addresses the resulting requirements.

Each Target Environment involved in Layered Attestation can be considered its own Trusted Computing Base (TCB) [ref]. TCB metadata can be used to identify or locate RIMs. The addition of TCB information to the new object tree structure is in support of these identifiers for RIM discovery.

Additionally, software components started in these Target Environments might not be referenceable via a filesystem (e.g., in the case of firmware). To enable RIMs to represent firmware items that are not associated with a filesystem, attributes for object trees are added to the existing filesystem items tree.

2.4.1. The tcb-info Group

Every object in the object tree can be represented with a set of metadata items pertaining a specific TCB. The following items can be associated with a dedicate object-entry:

Attribute Name Quantity Description
tcb-info.id 1 A hash of the tcb-info.key-elements value including the map structure
tcb-info.key-elements 1 A collection of attributes that disambiguates the various TCB objects in a composite device scope
tcb-info.vendor 1 The entity that named the measurement of the Target Environment TCB referenced by an object-entry
tcb-info.model 0-1 The product name associated with the object-entry in a measurement
tcb-info.layer 0-1 The layer in the composite devive (and therefore object tree) of the TCB associated with the object-entry in a measurement
tcb-info.index 0-1 An index that enumerates TCB/object-entries in a CoSWID RIM tag
tcb-info.type 1 A machine-readable description of the measurement
tcb-info.version 0-1 A revision string associated with the measurement and a reference value
tcb-info.SVN 0-1 The security version number associated with the measurement and a reference value
tcb-info.flags 0-1 Operational states associated with a TCB or composite device that affects the object being measured. If omitted, the TCB or omposite device is not capable of entering this state. Valid states are: not-configured, not-secure, recovery, debug.
tcb-info.fwids 0-1 A list of digests resulting from applying the hash algorithm over the object being measured
tcb-info.vendorinfo 0-1 Actual values or state that is associated with a TVB element
tcb-info.vendormask 0-1 A mask that allows a Verifier to ignore a subset of collected tcb-info.vendorinfo values that the Endorser asserts are not security relevant

2.4.2. CoSWID Version Scheme for RPM

To enable encoding version information into a CoSWID of RPM packages, the SWID version scheme value index TBD1 has been registered. RPM versions are defined as epoch:version-release-architecture, where the “epoch:” component is optional. Epoch is a numerical value, which should be considered zero if the epoch component is missing. Version and Release can be any string as long as they do not contain a hyphen (-). Architecture is an alphanumerical string.

Sorting of RPM versions is a multi-step process: - The epoch, version and release components are compared in that order, as soon as a difference is found, that is the overall difference. - The epoch component is compared as integers. A higher number means a higher version. - The version and release components are compared alphabetically, until a digit is encountered in both strings, at which point as many digits are consumed from both to form an integer, which is then compared. If the integers are identical, the comparison continues alphabetically. - The architecture component is never sorted. If they are different between two versions, the versions are inequal, not higher or lower.

2.5. Additional Measurement Attributes for CoSWID

[I-D.ietf-sacm-coswid] specifies a well-defined file hash structure for integrity measurements of individual files in a file-system. This documents extends this feature to all additional members of the resource-collection group: ‘directory’, ‘resource’, and ‘process’. These new well-defined measurement options extend the scope of RIM to (sub-)trees of files, software running in memory (e.g. available from Trusted Execution Environments, such as SGX enclaves), and even external resources, such as remote services of collections of RIM bundles.

2.6. CoSWID RIM CDDL

The following CDDL specification uses the existing CDDL extension points as defined in [I-D.ietf-sacm-coswid]:

<CODE BEGINS>
$$coswid-extension //= (reference-measurement => reference-measurement-entry)

reference-measurement-entry = {
  ? payload-type => direct / indirect / hybrid,
  ? platform-configuration-uri-global => any-uri,
  ? platform-configuration-uri-local => any-uri,
  binding-spec-name => text,
  binding-spec-version => text,
  platform-manufacturer-id => uint,
  platform-manufacturer-name => text,
  platform-model-name => text,
  ? platform-version => uint,
  ? firmware-manufacturer-id => uint,
  ? firmware-manufacturer-name => text,
  ? firmware-model-name => text,
  ? firmware-version => uint,
  ? boot-events => [ * boot-event-entry ],
  rim-link-hash => bytes,
}

boot-event-entry = {
   boot-event-number => uint,
   boot-event-type => uint,
   boot-digest-list => [ 1* hash-entry ],
   boot-event-data => bytes
}

$$payload-extension //= ( ? support-rim-type-kramdown => direct / indirect )
$$payload-extension //= ( ? support-rim-format => text )
$$payload-extension //= ( ? support-rim-uri-global => any-uri )
$$payload-extension //= ( ? rim-reference => any-uri )

reference-measurement = 58
payload-type = 59
payload-rim = 60
platform-configuration-uri-global = 61
platform-configuration-uri-local = 62
binding-spec-name = 63
binding-spec-version = 64
platform-manufacturer-id = 65
platform-manufacturer-name = 66
platform-model-name = 67
platform-version = 68
firmware-manufacturer-id = 69
firmware-manufacturer-name = 70
firmware-model-name = 71
firmware-version = 72
rim-link-hash = 73
support-rim-type-kramdown = 74
support-rim-format = 75
support-rim-uri-global = 76
rim-reference = 77
boot-events = 78
boot-event-number = 79
boot-event-type = 80
boot-digest-list = 81
boot-event-data = 82

direct = 0
indirect = 1
hybrid = 2

$$directory-extension //= ( ? hash => hash-entry )

$$resource-extension //= ( ? hash => hash-entry )

$$process-extension //= ( ? hash => hash-entry )

$$link-extension //= ( ? thumbprint => hash-entry )

$$resource-collection-extension //= (
  ? object => object-entry / [ 2* object-entry ]
)

object-entry = { 
  resource-collection,
  tcb-info,
  $$object-extension,
}

tcb-info = (
  tcb-info.id => hash-entry, 
  tcb-info.key-elements => {
    tcb-info.vendor => text,
    ? tcb-info.model => text,
    ? tcb-info.layer => int,
    ? tcb-info.index => int,
    tcb-info.type => tagged-bytes / uuid-bytes,
  },
  ? tcb-info.version => text,
  ? tcb-info.SVN => int,
  ? tcb-info.flags => uint .bits tcb-info.operational-flags,
  ? tcb-info.fwids,
  ? tcb-info.vendorinfo => bytes .size 8,
  ? tcb-info.vendormask => bytes,
)

uuid-bytes = bytes .size 8

tcb-info.operational-flags = &(
  not-configured: 0,
  not-secure: 1,
  recovery: 2,
  debug: 3,
)

tcb-info.fwids = [
  + [ hash-alg: [ * int ] / text,
      digest: bytes,
    ]
]

object = 83
tcb-info.id = 84
tcb-info.key-elements = 85
tcb-info.vendor = 86
tcb-info.model = 87
tcb-info.layer = 88
tcb-info.index = 89
tcb-info.type = 90
tcb-info.version = 91
tcb-info.SVN = 92
tcb-info.flags = 93
tcb-info.fwids = 94
tcb-info.vendorinfo = 95
tcb-info.vendormask = 96
<CODE ENDS>

3. Privacy Considerations

TBD

4. Security Considerations

To be elaborated on

5. IANA Considerations

This document has added the following entries to the SWID/CoSWID Version Scheme Values registry at https://www.iana.org/assignments/swid:

Index: TBD1
Version Scheme Name: rpm
Specification: See {{rpm-version-scheme}}

6. References

6.1. Normative References

[I-D.ietf-sacm-coswid] Birkholz, H., Fitzgerald-McKay, J., Schmidt, C. and D. Waltermire, "Concise Software Identification Tags", Internet-Draft draft-ietf-sacm-coswid-15, May 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

6.2. Informative References

[I-D.fedorkow-rats-network-device-attestation] Fedorkow, G., Voit, E. and J. Fitzgerald-McKay, "TPM-based Network Device Remote Integrity Verification", Internet-Draft draft-fedorkow-rats-network-device-attestation-05, April 2020.
[I-D.ietf-rats-architecture] Birkholz, H., Thaler, D., Richardson, M., Smith, N. and W. Pan, "Remote Attestation Procedures Architecture", Internet-Draft draft-ietf-rats-architecture-05, July 2020.

Authors' Addresses

Henk Birkholz Fraunhofer SIT Rheinstrasse 75 Darmstadt, 64295 Germany EMail: henk.birkholz@sit.fraunhofer.de
Patrick Uiterwijk Red Hat 100 E Davie Street Raleigh, 27601 Netherlands EMail: puiterwijk@redhat.com
Ned Smith Intel Corporation USA EMail: ned.smith@intel.com
Jessica Fitzgerald-McKay Department of Defense 9800 Savage Road Ft. Meade, Maryland USA EMail: jmfitz2@nsa.gov
David Waltermire National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, Maryland 20877 USA EMail: david.waltermire@nist.gov
Shwetha Bhandari Cisco Systems, Inc. Cessna Business Park, Sarjapura Marathalli Outer Ring Road Bangalore, KARNATAKA 560087 India EMail: shwethab@cisco.com