Internet DRAFT - draft-birkholz-rats-endorsement-eat
draft-birkholz-rats-endorsement-eat
RATS Working Group H. Birkholz
Internet-Draft M. Eckel
Intended status: Standards Track Fraunhofer SIT
Expires: September 11, 2020 March 10, 2020
A CWT Claims Set Definition for RATS Endorsement Tokens
draft-birkholz-rats-endorsement-eat-00
Abstract
An Endorsement is defined by the RATS Architecture as a "secure
statement that some entity (typically a manufacturer) vouches for the
integrity of an Attester's signing capability". This documents
defines Claims to be used in CBOR Web Tokens in the same fashion
attestation Evidence can be represented via Entity Attestation Tokens
(EAT). The defined Claims can be included in Endorsement Tokens.
Endorsement Tokens can be provided by a manufacturer or a third party
authority to vouch for the capabilities and characteristics of a
hardware component a RATS Attester is not capable to create Evidence
about.
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 September 11, 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
Birkholz & Eckel Expires September 11, 2020 [Page 1]
Internet-Draft Endorsement EAT March 2020
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Endorsement Claims Definition . . . . . . . . . . . . . . . . 3
2.1. Component Manufacturer Claim . . . . . . . . . . . . . . 3
2.2. Component Version Claim . . . . . . . . . . . . . . . . . 3
2.3. Component Model Claim . . . . . . . . . . . . . . . . . . 4
2.4. Field Upgradable Claim . . . . . . . . . . . . . . . . . 4
2.5. Shielded Secret Origination Claim . . . . . . . . . . . . 4
2.6. Common Criteria Claim . . . . . . . . . . . . . . . . . . 4
3. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Remote ATtestation procedureS (RATS) can be used to establish trust
in the trustworthiness of a remote peer (the Attester). As a Relying
Party typically cannot evaluate every kind of Attester by itself, the
RATS architecture [I-D.ietf-rats-architecture] defines the Verifier
role, to off-load the burden of appraisal to another entity than the
Relying Party itself. The duty of a Verifier is to produce
Attestation Results that are then easier to digest by a Relying Party
in comparison to Evidence that can potentially be both large and/or
esoteric for a generic Relying Party. Evidence are believable Claims
about the Attester. Next to Evidence, a Verifier requires
Endorsements. Endorsements are signed documents that include Claims
about components of an Attester that an Attester cannot create
Evidence about. Very prominent examples are Roots of Trust, such as
a Static Code Root of Trust for Measurement as defined in the Trusted
Computing Group (TCG) Glossary [TCGGLOSS]. These Endorsements of
components of a composite device are typically provided by their
manufacturer, a corresponding supply chain entity that assembles a
composite device, or a certification authority.
This documents defines CBOR Web Token (CWT, [RFC8392]) Claims that
can be assembled into a CWT Claims Set to compose Endorsement Tokens.
Birkholz & Eckel Expires September 11, 2020 [Page 2]
Internet-Draft Endorsement EAT March 2020
This is done in the same fashion as Claims are assembled into Entity
Attestation Tokens [I-D.ietf-rats-eat] that can represent, for
example, attestation Evidence for RATS.
1.1. Terminology
This document uses the terms Claims, Claims Set, and CBOR Web Token
Claims set as defined in [RFC8392].
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. Endorsement Claims Definition
This section uses the same definition style for Claims as introduced
in [I-D.ietf-rats-eat]. New Claims to be used in Endorsement Tokens
are specified below. A JSON Web Token Claims (JWT, [RFC7519])
definition is out-of-scope of this document. Corresponding Claims
are (to be) registered in the 'CWT Claims' subregistry of [IANA.cwt].
Each Claim definition is accompanied by a value definition using the
Concise Data Definition Language (CDDL, [RFC8610]). An Endorsement
Token that is using Claims that are defined in this document MUST
include Claim values as specified in this document.
2.1. Component Manufacturer Claim
As a fall-back alternative to the more specific oemid Claim defined
in [I-D.ietf-rats-eat], this Claim allows for byte strings
representing entity identifiers that are not based on IEEE MA-L, MA-
M, MA-S or an IEEE CID [IEEE.RA].
manufacturer-endorsement-claim = (
manufacturer-endorsement => bytes,
)
2.2. Component Version Claim
A byte string representing a firmware version of a hardware
component. Potentially, the value is derived from multiple version
numbers, such as major and minor version number. The version
represents the hardware component at the time the Endorsement Token
was created, typically during manufacturing.
Birkholz & Eckel Expires September 11, 2020 [Page 3]
Internet-Draft Endorsement EAT March 2020
Note to the reader: in this -00 I-D there are only five exemplary
Claims included yet. This list is far from complete or polished.
version-endorsement-claim = (
version-endorsement => bytes,
)
2.3. Component Model Claim
A manufacturer-specific byte string that represents the part number
or a similar model identifier as defined by the manufacturer.
model-endorsement-claim = (
model-endorsement => bytes,
)
2.4. Field Upgradable Claim
A Claim that indicates if the firmware of a hardware component is
mutable and therefore can be updated after manufacturing or not.
field-upgradable-claim = (
field-upgradable => bool,
)
2.5. Shielded Secret Origination Claim
An indicator that shows if a securely stored secret key in the
hardware component was generated by a function internal to the
hardware component or if the secret key was enrolled in a secure and
controlled environment by the manufacturer.
secret-origination-claim = (
secret-origination => internal / external
)
internal = 0
external = 1
2.6. Common Criteria Claim
A reference to the specification document that includes evaluation
results and parameters as defined by Common Criteria. This Claim
value is a composite of an URI pointing to the specification document
as well as a hash value specification document to ensure its
authenticity. The hash entry is a composite of an algorithm ID as
defined by the IANA "Named Information Hash Algorithm Registry" and
the hash value as a byte string.
Birkholz & Eckel Expires September 11, 2020 [Page 4]
Internet-Draft Endorsement EAT March 2020
common-criteria-claim =(
common-criteria => [ any-uri,
hash,
]
)
any-uri = text
hash = [ hash-alg-id: int,
hash-value: bytes,
]
3. Privacy Considerations
Potentially
4. Security Considerations
Most likely a sub-set of the trust relationships corresponding to the
RATS architecture
5. IANA Considerations
In this section the Claim registration in [IANA.cwt] for the
corresponding Claim definition above will be elaborated on.
6. References
6.1. Normative References
[IANA.cwt]
IANA, "CBOR Web Token (CWT) Claims",
<http://www.iana.org/assignments/cwt>.
[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>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[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 & Eckel Expires September 11, 2020 [Page 5]
Internet-Draft Endorsement EAT March 2020
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[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>.
6.2. Informative References
[I-D.ietf-rats-architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture",
draft-ietf-rats-architecture-02 (work in progress), March
2020.
[I-D.ietf-rats-eat]
Mandyam, G., Lundblade, L., Ballesteros, M., and J.
O'Donoghue, "The Entity Attestation Token (EAT)", draft-
ietf-rats-eat-03 (work in progress), February 2020.
[IEEE.RA] "IEEE Registration Authority",
<https://standards.ieee.org/products-services/regauth/
index.html>.
[TCGGLOSS]
TCG, "TCG Glossary Version 1.1 Revision 1.00", May 2017,
<https://trustedcomputinggroup.org/wp-content/uploads/TCG-
Glossary-V1.1-Rev-1.0.pdf>.
Authors' Addresses
Henk Birkholz
Fraunhofer SIT
Rheinstrasse 75
Darmstadt 64295
Email: henk.birkholz@sit.fraunhofer.de
Birkholz & Eckel Expires September 11, 2020 [Page 6]
Internet-Draft Endorsement EAT March 2020
Michael Eckel
Fraunhofer SIT
Rheinstrasse 75
Darmstadt 64295
Germany
Email: michael.eckel@sit.fraunhofer.de
Birkholz & Eckel Expires September 11, 2020 [Page 7]
