RATS Working Group H. Birkholz Internet-Draft Fraunhofer SIT Intended status: Standards Track T. Fossati Expires: 27 April 2023 Arm Limited W. Pan Huawei Technologies C. Bormann Universität Bremen TZI 24 October 2022 Epoch Markers draft-birkholz-rats-epoch-markers-02 Abstract This document defines Epoch Markers as a way to establish a notion of freshness among actors in a distributed system. Epoch Markers are similar to "time ticks" and are produced and distributed by a dedicated system, the Epoch Bell. Systems that receive Epoch Markers do not have to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a certain Epoch Marker establishes a new epoch that is shared between all recipients. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-birkholz-rats-epoch-markers/. Discussion of this document takes place on the rats Working Group mailing list (mailto:rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/. Subscribe at https://www.ietf.org/mailman/listinfo/rats/. Source for this draft and an issue tracker can be found at https://github.com/ietf-rats/draft-birkholz-rats-epoch-marker. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Birkholz, et al. Expires 27 April 2023 [Page 1] Internet-Draft Epoch Markers October 2022 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 27 April 2023. Copyright Notice Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 2. Epoch IDs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Interaction Models . . . . . . . . . . . . . . . . . . . . . 4 4. Epoch Marker Structure . . . . . . . . . . . . . . . . . . . 5 4.1. Epoch Marker Payloads . . . . . . . . . . . . . . . . . . 5 4.1.1. CBOR Time Tag (etime) . . . . . . . . . . . . . . . . 5 4.1.2. Classical RFC 3161 TST Info . . . . . . . . . . . . . 6 4.1.3. CBOR-encoded RFC3161 TST Info . . . . . . . . . . . . 6 4.1.4. Multi-Nonce . . . . . . . . . . . . . . . . . . . . . 7 4.1.5. Multi-Nonce-List . . . . . . . . . . . . . . . . . . 8 4.1.6. Strictly Monotonically Increasing Counter . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10 A.1. RFC 3161 TSTInfo . . . . . . . . . . . . . . . . . . . . 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 Birkholz, et al. Expires 27 April 2023 [Page 2] Internet-Draft Epoch Markers October 2022 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Systems that need to interact securely often require a shared understanding of the freshness of conveyed information. This is certainly the case in the domain of remote attestation procedures. In general, securely establishing a shared notion of freshness of the exchanged information among entities in a distributed system is not a simple task. The entire Appendix A of [I-D.ietf-rats-architecture] deals solely with the topic of freshness, which is in itself an indication of how relevant, and complex, it is to establish a trusted and shared understanding of freshness in a RATS system. This document defines Epoch Markers as a way to establish a notion of freshness among actors in a distributed system. Epoch Markers are similar to "time ticks" and are produced and distributed by a dedicated system, the Epoch Bell. Systems that receive Epoch Markers do not have to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a certain Epoch Marker establishes a new epoch that is shared between all recipients. In essence, the emissions and corresponding receptions of Epoch Markers are like the ticks of a clock where the ticks are conveyed by the Internet. In general (barring highly symmetrical topologies), epoch ticking incurs differential latency due to the non-uniform distribution of receivers with respect to the Epoch Bell. This introduces skew that needs to be taken into consideration when Epoch Markers are used. While all Epoch Markers share the same core property of behaving like clock ticks in a shared domain, various "epoch id" types are defined to accommodate different use cases and diverse kinds of Epoch Bells. While Epoch Markers are encoded in CBOR [STD94], and many of the epoch id types are themselves encoded in CBOR, a prominent format in this space is the Time-Stamp Token defined by [RFC3161], a DER- encoded TSTInfo value wrapped in a CMS envelope [RFC5652]. Time- Stamp Tokens (TST) are produced by Time-Stamp Authorities (TSA) and exchanged via the Time-Stamp Protocol (TSP). At the time of writing, TSAs are the most common providers of secure time-stamping services. Therefore, reusing the core TSTInfo structure as an epoch id type for Epoch Markers is instrumental for enabling smooth migration paths and promote interoperability. There are, however, several other ways to represent a signed timestamp, and therefore other kinds of payloads that can be used to implement Epoch Markers. Birkholz, et al. Expires 27 April 2023 [Page 3] Internet-Draft Epoch Markers October 2022 To inform the design, this document discusses a number of interaction models in which Epoch Markers are expected to be exchanged. The top- level structure of Epoch Markers and an initial set of epoch id types are specified using CDDL [RFC8610]. To increase trustworthiness in the Epoch Bell, Epoch Markers also provide the option to include a "veracity proof" in the form of attestation evidence, attestation results, or SCITT receipts [I-D.birkholz-scitt-receipts] associated with the trust status of the Epoch Bell. 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. In this document, CDDL [RFC8610] is used to describe the data formats. The examples in Appendix A use CBOR diagnostic notation as defined in Section 8 of [STD94] and Appendix G of [RFC8610]. 2. Epoch IDs The RATS architecture introduces the concept of Epoch IDs that mark certain events during remote attestation procedures ranging from simple handshakes to rather complex interactions including elaborate freshness proofs. The Epoch Markers defined in this document are a solution that includes the lessons learned from TSAs, the concept of Epoch IDs defined in the RATS architecture, and provides several means to identify a new freshness epoch. Some of these methods are introduced and discussed in Section 10.3 of the RATS architecture [I-D.ietf-rats-architecture]. 3. Interaction Models The interaction models illustrated in this section are derived from the RATS Reference Interaction Models. In general, there are three interaction models: * ad-hoc requests (e.g., via challenge-response requests addressed at Epoch Bells), corresponding to Section 7.1 in [I-D.ietf-rats-reference-interaction-models] * unsolicited distribution (e.g., via uni-directional methods, such as broad- or multicasting from Epoch Bells), corresponding to Section 7.2 in [I-D.ietf-rats-reference-interaction-models] Birkholz, et al. Expires 27 April 2023 [Page 4] Internet-Draft Epoch Markers October 2022 * solicited distribution (e.g., via a subscription to Epoch Bells), corresponding to Section 7.3 in [I-D.ietf-rats-reference-interaction-models] 4. Epoch Marker Structure At the top level, an Epoch Marker is a CBOR array with a header carrying an optional veracity proof about the Epoch Bell and a payload. epoch-marker = [ $tagged-epoch-id ? bell-veracity-proof ] ; veracity of the bell bell-veracity-proof = non-empty<{ ? remote-attestation-evidence ; could be EAT or Concise Evidence ? remote-attestation-result ; hopefully EAT with AR4SI Claims ? scitt-receipt ; SCITT receipt }> remote-attestation-evidence = (1: "PLEASE DEFINE") remote-attestation-result = (2: "PLEASE DEFINE") scitt-receipt = (3: "PLEASE DEFINE") ; epoch-id types independent of interaction model $tagged-epoch-id /= cbor-epoch-id $tagged-epoch-id /= #6.26980(classical-rfc3161-TST-info) $tagged-epoch-id /= #6.26981(TST-info-based-on-CBOR-time-tag) $tagged-epoch-id /= #6.26982(multi-nonce) $tagged-epoch-id /= #6.26983(multi-nonce-list) $tagged-epoch-id /= #6.26984(strictly-monotonic-counter) Figure 1: Epoch Marker definition 4.1. Epoch Marker Payloads This memo comes with a set of predefined payloads. 4.1.1. CBOR Time Tag (etime) CBOR extended time tag (1001) optionally bundled with a nonce. See Section 3 of [I-D.ietf-cbor-time-tag] for the (many) details about the CBOR extended time format. Birkholz, et al. Expires 27 April 2023 [Page 5] Internet-Draft Epoch Markers October 2022 cbor-epoch-id = [ etime ? nonce ] etime = #6.1001({* (int/tstr) => any}) nonce = tstr / bstr / int 4.1.2. Classical RFC 3161 TST Info DER-encoded [X.690] TSTInfo [RFC3161]. See Appendix A.1 for the layout. classical-rfc3161-TST-info = bytes 4.1.3. CBOR-encoded RFC3161 TST Info Semantically equivalent to classical RFC3161 TSTInfo rewritten using the CBOR type system. Birkholz, et al. Expires 27 April 2023 [Page 6] Internet-Draft Epoch Markers October 2022 TST-info-based-on-CBOR-time-tag = { &(version : 0) => int .default 1 ; obsolete? &(policy : 1) => oid &(messageImprint : 2) => MessageImprint &(serialNumber : 3) => int &(eTime : 4) => profiled-etime &(ordering : 5) => bool .default false ? &(nonce : 6) => int ? &(tsa : 7) => GeneralName * $$TSTInfoExtensions } oid = #6.110(bstr) / #6.111(bstr) / #6.112(bstr) ; based on COSE_Hash_Find (draft-ietf-cose-hash-algs) MessageImprint = [ hashAlg : int hashValue : bstr ] ; timeMap profiles etime, see: ; https://datatracker.ietf.org/doc/html/draft-ietf-cbor-time-tag profiled-etime = #6.1001(timeMap) timeMap = { 1 => #6.1(int / float) ; TIME_T -8 => profiled-duration ; guarantee aka RFC 3161 accuracy * int => any } profiled-duration = #6.1002({* int => any}) ; Section 11.8 of I-D.ietf-cose-cbor-encoded-cert GeneralName = [ GeneralNameType : int, GeneralNameValue : any ] 4.1.4. Multi-Nonce Typically, a nonce is a number only used once. In the context of Epoch Markers, one Nonce can be distributed to multiple consumers, each of them using that Nonce only once. Technically, that is not a Nonce anymore. This type of Nonce is called Multi-Nonce in Epoch Markers. ; Multi-Nonce ; a single nonce used by multiple entities multi-nonce = tstr / bstr / int Birkholz, et al. Expires 27 April 2023 [Page 7] Internet-Draft Epoch Markers October 2022 4.1.5. Multi-Nonce-List A list of nonces send to multiple consumers. The consumers use each Nonce in the list of Nonces sequentially. Technically, each sequential Nonce in the distributed list is not used just once, but by every Epoch Marker consumer involved. This renders each Nonce in the list a Multi-Nonce ; Multi-Nonce-List ; a list of nonces potentially used by multiple entities multi-nonce-list = [ + multi-nonce ] 4.1.6. Strictly Monotonically Increasing Counter A strictly monotonically increasing counter. The counter context is defined by the Epoch bell. strictly-monotonic-counter = uint 5. Security Considerations Epoch Markers are signed using [STD96] and inheritance of security considerations will be addressed here. 6. IANA Considerations TODO 7. References 7.1. Normative References [I-D.ietf-cbor-time-tag] Bormann, C., Gamari, B., and H. Birkholz, "Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period", Work in Progress, Internet-Draft, draft-ietf- cbor-time-tag-02, 4 October 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Birkholz, et al. Expires 27 April 2023 [Page 8] Internet-Draft Epoch Markers October 2022 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 2001, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [STD94] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [STD96] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [X.690] International Telecommunications Union, "Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, August 2015, . 7.2. Informative References [I-D.birkholz-scitt-receipts] Birkholz, H., Riechert, M., Delignat-Lavaud, A., and C. Fournet, "Countersigning COSE Envelopes in Transparency Services", Work in Progress, Internet-Draft, draft- birkholz-scitt-receipts-01, 5 September 2022, . [I-D.ietf-rats-architecture] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote Attestation Procedures Architecture", Work Birkholz, et al. Expires 27 April 2023 [Page 9] Internet-Draft Epoch Markers October 2022 in Progress, Internet-Draft, draft-ietf-rats-architecture- 22, 28 September 2022, . [I-D.ietf-rats-reference-interaction-models] Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference Interaction Models for Remote Attestation Procedures", Work in Progress, Internet-Draft, draft-ietf-rats- reference-interaction-models-06, 7 September 2022, . Appendix A. Examples The example in Figure 2 shows an epoch marker with a cbor-epoch-id and no bell veracity proof. [ / cbor-epoch-id / [ / 1996-12-19T16:39:57-08:00[America//Los_Angeles][u-ca=hebrew] / / etime / 1001({ 1: 851042397, -10: "America/Los_Angeles", -11: { "u-ca": "hebrew" } }) ] / no bell veracity proof / ] Figure 2: CBOR epoch id without bell veracity proof A.1. RFC 3161 TSTInfo As a reference for the definition of TST-info-based-on-CBOR-time-tag the code block below depects the original layout of the TSTInfo structure from [RFC3161]. Birkholz, et al. Expires 27 April 2023 [Page 10] Internet-Draft Epoch Markers October 2022 TSTInfo ::= SEQUENCE { version INTEGER { v1(1) }, policy TSAPolicyId, messageImprint MessageImprint, -- MUST have the same value as the similar field in -- TimeStampReq serialNumber INTEGER, -- Time-Stamping users MUST be ready to accommodate integers -- up to 160 bits. genTime GeneralizedTime, accuracy Accuracy OPTIONAL, ordering BOOLEAN DEFAULT FALSE, nonce INTEGER OPTIONAL, -- MUST be present if the similar field was present -- in TimeStampReq. In that case it MUST have the same value. tsa [0] GeneralName OPTIONAL, extensions [1] IMPLICIT Extensions OPTIONAL } Acknowledgements TBD Authors' Addresses Henk Birkholz Fraunhofer SIT Rheinstrasse 75 64295 Darmstadt Germany Email: henk.birkholz@sit.fraunhofer.de Thomas Fossati Arm Limited United Kingdom Email: Thomas.Fossati@arm.com Wei Pan Huawei Technologies Email: william.panwei@huawei.com Carsten Bormann Universität Bremen TZI Bibliothekstr. 1 D-28359 Bremen Germany Birkholz, et al. Expires 27 April 2023 [Page 11] Internet-Draft Epoch Markers October 2022 Phone: +49-421-218-63921 Email: cabo@tzi.org Birkholz, et al. Expires 27 April 2023 [Page 12]