Internet DRAFT - draft-birkholz-rats-coswid-rim
draft-birkholz-rats-coswid-rim
RATS Working Group H. Birkholz
Internet-Draft Fraunhofer SIT
Intended status: Standards Track P. Uiterwijk
Expires: July 17, 2021 Red Hat
D. Waltermire
NIST
S. Bhandari
Cisco
J. Fitzgerald-McKay
Department of Defense
January 13, 2021
Reference Integrity Measurement Extension for Concise Software
Identities
draft-birkholz-rats-coswid-rim-02
Abstract
This document specifies the CDDL and usage description for Reference
Integrity Measurements (RIM) in Remote Attestation Procedures (RATS).
The specification is based on Concise Software Identification
(CoSWID) and TCG Reference Integrity Manifest Information Model -
based on Host Integrity at Runtime and Start-up (HIRS). Extension
points defined in CoSWID used to augment CoSWID tags with new
attributes that can express the TCG Reference Integrity Manifest
extensions.
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 17, 2021.
Birkholz, et al. Expires July 17, 2021 [Page 1]
Internet-Draft CoSWID RIM January 2021
Copyright Notice
Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. CoSWID Attribute Extensions for RIM . . . . . . . . . . . . . 4
2.1. RIM requirements on existing CoSWID attributes . . . . . 4
2.2. RIM Extensions for HIRS . . . . . . . . . . . . . . . . . 5
2.3. RIM Extensions for Software Package Management . . . . . 10
2.3.1. CoSWID Version Scheme for RPM . . . . . . . . . . . . 11
2.4. CoSWID RIM CDDL . . . . . . . . . . . . . . . . . . . . . 11
3. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 14
6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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 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
following roles: Verifier, Attester, Endorse, and Relying Party, and
Reference Value Provider. The RATS architecture also specifies that
Birkholz, et al. Expires July 17, 2021 [Page 2]
Internet-Draft CoSWID RIM January 2021
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 Reference Value Providers (RVP, e.g. a supply chain
entity). The comparison of Claim values via Reference Claim Values
(RCV) 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 vulnerabilities discovered in certain
versions of installed 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 - "first measure, than
start".
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 for software components can be
provided via Concise Software Identification (CoSWID) tags created or
maintained by RVPs, such as the software creators, manufacturers,
vendors, or other trusted third parties (e.g. a certification
entity).
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 new map type-definition named "reference-values" is
added and is defined in section [ref] of this document.
Birkholz, et al. Expires July 17, 2021 [Page 3]
Internet-Draft CoSWID RIM January 2021
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 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.
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 for RIM
This specification defines two types of attribute sets that can be
added to the CoSWID specification via the specified defined extension
points:
1. Attributes that support RIM manifests for Measured Boot (often
referred to as Secure Boot) and
2. Attributes that support the RPM package manager structure.
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
Birkholz, et al. Expires July 17, 2021 [Page 4]
Internet-Draft CoSWID RIM January 2021
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 HIRS
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 |
Birkholz, et al. Expires July 17, 2021 [Page 5]
Internet-Draft CoSWID RIM January 2021
| | | 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- | 0-1 | A byte-comparable |
| global | | reference to a |
| | | Platform |
| | | Configuration URI as |
| | | defined by the TCG |
| | | Platform Certificate |
Birkholz, et al. Expires July 17, 2021 [Page 6]
Internet-Draft CoSWID RIM January 2021
| | | 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- | 0-1 | A byte-comparable |
| local | | 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. |
Birkholz, et al. Expires July 17, 2021 [Page 7]
Internet-Draft CoSWID RIM January 2021
| | | |
| 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 |
Birkholz, et al. Expires July 17, 2021 [Page 8]
Internet-Draft CoSWID RIM January 2021
| | | 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. |
| | | |
Birkholz, et al. Expires July 17, 2021 [Page 9]
Internet-Draft CoSWID RIM January 2021
| 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.
Birkholz, et al. Expires July 17, 2021 [Page 10]
Internet-Draft CoSWID RIM January 2021
+---------------+----------+----------------------------------------+
| Attribute | Quantity | Description |
| Name | | |
+---------------+----------+----------------------------------------+
| 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.3.1. CoSWID Version Scheme for RPM
To enable encoding version information into a CoSWID tag for 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.4. CoSWID RIM CDDL
The following CDDL specification uses the existing CDDL extension
points as defined in [I-D.ietf-sacm-coswid]:
o $$coswid-extension
o $$payload-extension
<CODE BEGINS>
$$coswid-extension //= (reference-values => reference-values-entry)
reference-value-entry = {
? payload-type => direct / indirect / hybrid,
? platform-configuration-uri-global => any-uri,
Birkholz, et al. Expires July 17, 2021 [Page 11]
Internet-Draft CoSWID RIM January 2021
? 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
Birkholz, et al. Expires July 17, 2021 [Page 12]
Internet-Draft CoSWID RIM January 2021
boot-event-number = 79
boot-event-type = 80
boot-digest-list = 81
boot-event-data = 82
direct = 0
indirect = 1
hybrid = 2
<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 [1]:
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", draft-
ietf-sacm-coswid-16 (work in progress), November 2020.
[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>.
[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>.
Birkholz, et al. Expires July 17, 2021 [Page 13]
Internet-Draft CoSWID RIM January 2021
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",
draft-fedorkow-rats-network-device-attestation-05 (work in
progress), April 2020.
[I-D.ietf-rats-architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture",
draft-ietf-rats-architecture-08 (work in progress),
December 2020.
6.3. URIs
[1] https://www.iana.org/assignments/swid
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
David Waltermire
National Institute of Standards and Technology
100 Bureau Drive
Gaithersburg, Maryland 20877
USA
Email: david.waltermire@nist.gov
Birkholz, et al. Expires July 17, 2021 [Page 14]
Internet-Draft CoSWID RIM January 2021
Shwetha Bhandari
Cisco Systems, Inc.
Cessna Business Park, Sarjapura Marathalli Outer Ring Road
Bangalore, KARNATAKA 560087
India
Email: shwethab@cisco.com
Jessica Fitzgerald-McKay
Department of Defense
9800 Savage Road
Ft. Meade, Maryland
USA
Email: jmfitz2@nsa.gov
Birkholz, et al. Expires July 17, 2021 [Page 15]
