Fraunhofer SIT

Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@sit.fraunhofer.de

Arm Limited

UK Thomas.Fossati@arm.com

Huawei Technologies

william.panwei@huawei.com

Universität Bremen TZI

Bibliothekstr. 1 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org

Security RATS Working Group Internet-Draft 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 Status information for this document may be found at . Discussion of this document takes place on the rats Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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 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 , 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 , a DER-encoded TSTInfo value wrapped in a CMS envelope . 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. 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 . 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 associated with the trust status of the Epoch Bell.

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 when, and only when, they appear in all capitals, as shown here. In this document, CDDL is used to describe the data formats. The examples in use CBOR diagnostic notation as defined in and .

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 .

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
• unsolicited distribution (e.g., via uni-directional methods, such as broad- or multicasting from Epoch Bells), corresponding to Section 7.2 in
• solicited distribution (e.g., via a subscription to Epoch Bells), corresponding to Section 7.3 in

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 definition 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) $tagged-epoch-id /= #6.26985(stateless-nonce) ]]>

Epoch Marker Payloads This memo comes with a set of predefined payloads.

CBOR Time Tag (etime) CBOR extended time tag (1001) optionally bundled with a nonce. See for the (many) details about the CBOR extended time format. cbor-epoch-id = [ etime ? nonce ] etime = #6.1001({* (int/tstr) => any}) nonce = tstr / bstr / int The following describes each member of the cbor-epoch-id map.

etime:

An extended time value as defined by .

nonce:

A never-repeating byte string used as extra data in challenge-response interaction models (see ).

Classical RFC 3161 TST Info DER-encoded TSTInfo . See for the layout. classical-rfc3161-TST-info = bytes The following describes the classical-rfc3161-TST-info type.

classical-rfc3161-TST-info:

The response message of a Time Stamp Authority including a Time Stamp Token Info structure.

CBOR-encoded RFC3161 TST Info Issue tracked at: https://github.com/ietf-rats/draft-birkholz-rats-epoch-marker/issues/18 The TST-info-based-on-CBOR-time-tag is semantically equivalent to classical TSTInfo, rewritten using the CBOR type system. TST-info-based-on-CBOR-time-tag = { &(version : 0) => v1 &(policy : 1) => oid &(messageImprint : 2) => MessageImprint &(serialNumber : 3) => integer &(eTime : 4) => profiled-etime ? &(ordering : 5) => bool .default false ? &(nonce : 6) => integer ? &(tsa : 7) => GeneralName * $$TSTInfoExtensions } v1 = 1 oid = #6.111(bstr) / #6.112(bstr) MessageImprint = [ hashAlg : int hashValue : bstr ] profiled-etime = #6.1001(timeMap) timeMap = { 1 => ~time ? -8 => profiled-duration * int => any } profiled-duration = {* int => any} GeneralNameAttr = ( GeneralNameType : int, GeneralNameValue : any ) GeneralName = [ + GeneralNameAttr ] The following describes each member of the TST-info-based-on-CBOR-time-tag map.

version:

The integer value 1. Cf. version, .

policy:

A object identifier tag (111 or 112) representing the TSA's policy under which the tst-info was produced. Cf. policy, .

messageImprint:

A COSE_Hash_Find array carrying the hash algorithm identifier and the hash value of the time-stamped datum. Cf. messageImprint, .

serialNumber:

A unique integer value assigned by the TSA to each issued tst-info. Cf. serialNumber, .

eTime:

The time at which the tst-info has been created by the TSA. Cf. genTime, . Encoded as extended time , indicated by CBOR tag 1001, profiled as follows:

• The "base time" is encoded using key 1, indicating Posix time as int or float.
• The stated "accuracy" is encoded using key -8, which indicates the maximum allowed deviation from the value indicated by "base time". The duration map is profiled to disallow string keys. This is an optional field.
• The map MAY also contain one or more integer keys, which may encode supplementary information Allowing unsigned integer (i.e., critical) keys goes counter interoperability.

ordering:

boolean indicating whether tst-info issued by the TSA can be ordered solely based on the "base time". This is an optional field, whose default value is "false". Cf. ordering, .

nonce:

int value echoing the nonce supplied by the requestor. Cf. nonce, .

tsa:

a single-entry GeneralNames array providing a hint in identifying the name of the TSA. Cf. tsa, .

$$TSTInfoExtensions:

A CDDL socket () to allow extensibility of the data format. Note that any extensions appearing here MUST match an extension in the corresponding request. Cf. extensions, .

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 The following describes the multi-nonce type.

multi-nonce:

A never-repeating byte string used by RATS roles in a trust domain as extra data included in the production of conceptual messages as specified by the RATS architecture to associate them with a certain epoch.

Multi-Nonce-List A list of nonces send to multiple consumer. 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 ] The following describes the multi-nonce type.

multi-nonce-list:

A sequence of never-repeating byte strings used by RATS roles in trust domain as extra data in the production of conceptual messages as specified by the RATS architecture to associate them with a certain epoch. Each nonce in the list is used in a consecutive production of a conceptual messages. Asserting freshness of a conceptual message including a nonce from the multi-nonce-list requires some state on the receiver side to assess, if that nonce is the appropriate next unused nonce from the multi-nonce-list.

Strictly Monotonically Increasing Counter A strictly monotonically increasing counter. The counter context is defined by the Epoch bell. strictly-monotonic-counter = uint The following describes the strictly-monotonic-counter type.

strictly-monotonic-counter:

An unsigned integer used by RATS roles in a trust domain as extra data in the production of of conceptual messages as specified by the RATS architecture to associate them with a certain epoch. Each new strictly-monotonic-counter value must be higher than the last one.

Stateless Nonce In a highly available service (e.g., a cloud attestation verifier) having to keep per-session nonce state poses scalablity problems. An alternative is to use time-synchronised servers that share a symmetric key, which produce and consume nonces based on coarse-grained clock ticks that are signed using the shared secret. This way, a nonce minted by a server in the pool can be processed by any other server in pool, which avoids the need for session "stickiness." A stateless-nonce supports the above use case by encoding a Posix time (i.e., the epoch identifier), alongside a minimal set of metadata, authenticated with a symmetric key in a self-contained and compact token. stateless-nonce = [ TimeToken AuthTag: bstr .size 32 ] TimeToken = ( Version: bytes .size 1 KeyID: bytes .size 1 Timestamp: posix-time Pad: bytes ) posix-time = #6.1(int) The following describes each member of the stateless-nonce array:

Version:

version of the TimeToken encoded as a single byte. The value MUST be 0x01.

KeyID:

opaque identifier shared across the server pool for the signing key used to compute AuthTag. It is semantically equivalent to the TID field defined in .

Timestamp:

the timestamp associated with the current epoch encoded as CBOR tag for Posix time. It MUST use the int format.

Pad:

zero or more pad bytes, used to make the stateless nonce the desired size.

AuthTag:

HMAC w/ SHA-256 computed over the CBOR serialisation of TimeToken encoded as a 32-bytes string.

Security Considerations TODO

IANA Considerations RFC Editor: please replace RFCthis with the RFC number of this RFC and remove this note.

New CBOR Tags IANA is requested to allocate the following tags in the "CBOR Tags" registry , preferably with the specific CBOR tag value requested: New CBOR Tags

Tag	Data Item	Semantics	Reference
26980	bytes	DER-encoded RFC3161 TSTInfo	of RFCthis
26981	map	CBOR-encoding of RFC3161 TSTInfo semantics	of RFCthis
26982	tstr / bstr / int	a nonce that is shared among many participants but that can only be used once by each participant	of RFCthis
26983	array	a list of multi-nonce	of RFCthis
26984	uint	strictly monotonically increasing counter	of RFCthis
26985	array	stateless nonce	of RFCthis

References Normative References This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind The Concise Binary Object Representation (CBOR), defined in RFC 8949, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. This document defines CBOR tags for object identifiers (OIDs) and is the reference document for the IANA registration of the CBOR tags so defined. The CBOR Object Signing and Encryption (COSE) syntax (see RFC 9052) does not define any direct methods for using hash algorithms. There are, however, circumstances where hash algorithms are used, such as indirect signatures, where the hash of one or more contents are signed, and identification of an X.509 certificate or other object by the use of a fingerprint. This document defines hash algorithms that are identified by COSE algorithm identifiers. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Universität Bremen TZI Well-Typed Fraunhofer Institute for Secure Information Technology The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 8949 defines two tags for time: CBOR tag 0 (RFC3339 time as a string) and tag 1 (Posix time as int or float). Since then, additional requirements have become known. The present document defines a CBOR tag for time that allows a more elaborate representation of time, as well as related CBOR tags for duration and time period. It is intended as the reference document for the IANA registration of the CBOR tags defined. // The present version (-05) adds CDDL definitions; this should now // address all WGLC comments. Ericsson AB Ericsson AB RISE AB RISE AB Nexus Group This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates with over 50%. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re- encoding for the signature to be verified. The document also specifies C509 COSE headers, a C509 TLS certificate type, and a C509 file format. International Telecommunications Union In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. IANA Informative References Fraunhofer SIT Microsoft Sandelman Software Works Intel Corporation Huawei Technologies In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. Fraunhofer SIT Fraunhofer SIT Huawei Technologies Cisco Systems This document describes interaction models for remote attestation procedures (RATS). Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. Fraunhofer SIT Microsoft Microsoft Microsoft A transparent and authentic Transparent Registry service in support of a supply chain's integrity, transparency, and trust requires all peers that contribute to the Registry operations to be trustworthy and authentic. In this document, a countersigning variant is specified that enables trust assertions on Merkle-tree based operations for global supply chain registries. A generic procedure for producing payloads to be signed and validated is defined and leverages solutions and principles from the Concise Signing and Encryption (COSE) space. This memo defines a generic URI and HTTP-header-friendly envelope for carrying symmetrically encrypted, authenticated, and origin-timestamped tokens. It also describes one possible usage of such tokens via a simple protocol based on HTTP cookies. Secure Cookie Session (SCS) use cases cover a wide spectrum of applications, ranging from distribution of authorized content via HTTP (e.g., with out-of-band signed URIs) to securing browser sessions with diskless embedded devices (e.g., Small Office, Home Office (SOHO) routers) or web servers with high availability or load- balancing requirements that may want to delegate the handling of the application state to clients instead of using shared storage or forced peering.

Examples The example in shows an epoch marker with a cbor-epoch-id and no bell veracity proof.

CBOR epoch id without bell veracity proof

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 . 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