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", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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, . [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, . 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", . [TCGGLOSS] TCG, "TCG Glossary Version 1.1 Revision 1.00", May 2017, . 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]