Epoch Markers

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 13 April 2025.¶

Copyright Notice

Copyright (c) 2024 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

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 [RFC9334] 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.¶

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.ietf-scitt-architecture] associated with the trust status of the Epoch Bell.¶

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 [RFC9334].¶

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]¶
• solicited distribution (e.g., via a subscription to Epoch Bells), corresponding to Section 7.3 in [I-D.ietf-rats-reference-interaction-models]¶

In all three interaction models, Epoch Markers can be used as content for the generic information element 'handle'. Handles are most useful to establish freshness in unsolicited and solicited distribution by the Epoch Bell. An Epoch Marker can be used as a nonce in challenge-response remote attestation (e.g., for limiting the number of ad-hoc requests by a Verifier). Using an Epoch Marker requires the challenger to acquire an Epoch Marker beforehand, which may introduce a sensible overhead compared to using a simple nonce.¶

4. Epoch Marker Structure

At the top level, an Epoch Marker is a CBOR array carrying the actual epoch id (Section 4.1) and an optional veracity proof about the Epoch Bell.¶

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(epoch-tick)
$tagged-epoch-id /= #6.26983(epoch-tick-list)
$tagged-epoch-id /= #6.26984(strictly-monotonic-counter)

The veracity proof can be encoded in an Evidence or Attestation Result conceptual message [RFC9334], e.g., using [I-D.ietf-rats-eat], [TCG-CoEvidence], [I-D.ietf-rats-ar4si], or SCITT receipts [I-D.ietf-scitt-architecture].¶

cbor-epoch-id = [
   cbor-time
   ? nonce
]

etime = #6.1001({* (int/tstr) => any})

cbor-time = tdate / time / etime

nonce = tstr / bstr / int

classical-rfc3161-TST-info = bytes

SEQUENCE {
  SEQUENCE {
    OBJECT      2.16.840.1.101.3.4.2.1 (sha256)
    NULL
  }
  OCTET STRING
    BF4EE9143EF2329B1B778974AAD445064940B9CAE373C9E35A7B23361282698F
}

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}

GeneralName = [ GeneralNameType : int, GeneralNameValue : any ]
; See Section 4.2.1.6 of RFC 5280 for type/value

[
    / hashAlg   / -16, / sha-256 /
    / hashValue / h'BF4EE9143EF2329B1B778974AAD44506
                    4940B9CAE373C9E35A7B23361282698F'
]

; Epoch-Tick

epoch-tick = tstr / bstr / int

; Epoch-Tick-List

epoch-tick-list = [ + epoch-tick ]

strictly-monotonic-counter = uint

5. Security Considerations

TODO¶

6. IANA Considerations

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

7. References

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 /
]

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