idnits 2.17.1 draft-birkholz-rats-epoch-markers-01.txt: -(9): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 25 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (4 May 2022) is 716 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 310 -- Looks like a reference, but probably isn't: '1' on line 311 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-15 == Outdated reference: A later version (-09) exists of draft-ietf-rats-reference-interaction-models-05 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Standards Track T. Fossati 5 Expires: 5 November 2022 Arm Limited 6 W. Pan 7 Huawei Technologies 8 C. Bormann 9 Universität Bremen TZI 10 4 May 2022 12 Epoch Markers 13 draft-birkholz-rats-epoch-markers-01 15 Abstract 17 Abstract Text 19 About This Document 21 This note is to be removed before publishing as an RFC. 23 Status information for this document may be found at 24 https://datatracker.ietf.org/doc/draft-birkholz-rats-epoch-markers/. 26 Discussion of this document takes place on the rats Working Group 27 mailing list (mailto:rats@ietf.org), which is archived at 28 https://mailarchive.ietf.org/arch/browse/rats/. 30 Source for this draft and an issue tracker can be found at 31 https://github.com/ietf-rats/draft-birkholz-rats-epoch-marker. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 5 November 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 68 2. Epoch IDs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Interaction Models . . . . . . . . . . . . . . . . . . . . . 4 70 4. Epoch Marker CDDL . . . . . . . . . . . . . . . . . . . . . . 4 71 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 5.2. Informative References . . . . . . . . . . . . . . . . . 6 74 Appendix A. RFC 3161 TSTInfo . . . . . . . . . . . . . . . . . . 7 75 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 Systems that are required to interact via secure interactions often 81 require a shared understanding of the freshness of conveyed 82 information, especially in the domain of remote attestation 83 procedures. Establishing a notion of freshness between various 84 involved entities taking on roles that rely on information that is 85 not outdated is not simple. In general, establishing a shared 86 understanding of freshness in a secure manner is not simple. The 87 RATS architecture [I-D.ietf-rats-architecture] dedicates an extensive 88 appendix solely on the topic of freshness considerations and that 89 fact alone should be considered a telltale sign on how necessary yet 90 complex establishing a trusted and shared understanding of freshness 91 between systems actually is. 93 This document provides a prominent way to establish a notion of 94 freshness between systems: Epoch Markers. Epoch Markers are messages 95 that are like time ticks produced and conveyed by a system in a 96 freshness domain: the Epoch Bell. Systems that receive Epoch Markers 97 do not have to track freshness with their own local understanding of 98 time (e.g., a local real time clock). Instead, each reception of a 99 specific Epoch Marker rings in a new age of freshness that is shared 100 between all recipients. In essence, the emissions and corresponding 101 receptions of Epoch Markers are like the ticks of a clock where the 102 ticks are conveyed by the Internet. 104 The layout of the freshness domain in which Epoch Markers are 105 conveyed like the ticks of a clock, introduces a domain-specific 106 latency -- and therefore a certain uncertainty about tick accuracy. 108 While all Epoch Markers share the common characteristic of being like 109 clock ticks in a freshness domain, there are various payload types 110 that can make up the content of an Epoch Marker. These different 111 types of Epoch Marker payloads address several specific use cases and 112 are laid out in this document. While Epoch Markers are encoded in 113 CBOR and many of the payload types are encoded in CBOR as well, a 114 prominent payload is the Time Stamp Token content as defined by 115 [RFC3161]: a DER-encoded TSTInfo value. Time Stamp Tokens (TST) 116 produced by Time Stamp Authorities (TSA) are conveyed by the Time 117 Stamp Protocol (TSP). At the time of writing, TSAs are the most 118 common world-wide implemented secure timestamp token systems. 119 Reusing the essential TST payload structure as a payload type for 120 CBOR encoded Epoch Markers makes sense with respect to migration 121 paths and general interoperability. But there is more than one way 122 to represent a signed timestamp and other kinds of freshness ticks 123 that can be used for Epoch Markers. 125 In this document, basic interaction models on how to convey Epoch 126 Marchers are illustrated as they impact the message design of a 127 generic Epoch Marker. Then, the structure of Epoch Markers is 128 specified using CDDL and the corresponding payload types are 129 introduced and elaborated on. To increase the level of 130 trustworthiness in the Epoch Bell and the system that produces them, 131 Epoch Markers also provide the option to include (concise) remote 132 attestation evidence or corresponding remote attestation results. 134 1.1. Requirements Notation 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in 139 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 2. Epoch IDs 144 The RATS architecture introduces the concept of Epoch IDs that mark 145 certain events during remote attestation procedures ranging from 146 simple handshakes to rather complex interactions including elaborate 147 freshness proofs. The Epoch Markers defined in this document are a 148 solution that includes the lessons learned from TSAs, the concept of 149 Epoch IDs and provides several means to identify a new freshness 150 epoch. Some of these methods are introduced and discussed in 151 Section 10.3 of [I-D.ietf-rats-architecture]. 153 3. Interaction Models 155 The interaction models illustrated in this section are derived from 156 the RATS Reference Interaction Models. In general there are three of 157 them: 159 * ad-hoc requests (e.g., via challenge-response requests addressed 160 at Epoch Bells), corresponding to Section 7.1 in 161 [I-D.ietf-rats-reference-interaction-models] 163 * unsolicited distribution (e.g., via uni-directional methods, such 164 as broad- or multicasting from Epoch Bells), corresponding to 165 Section 7.2 in [I-D.ietf-rats-reference-interaction-models] 167 * solicited distribution (e.g., via a subscription to Epoch Bells), 168 corresponding to Section 7.3 in 169 [I-D.ietf-rats-reference-interaction-models] 171 4. Epoch Marker CDDL 173 epoch-marker = [ 174 header, 175 $payload, 176 ] 178 header = { 179 ? challenge-response-nonce, 180 ? remote-attestation-evidence, ; could be EAT or Concise Evidence 181 ? remote-attestation-results, ; hopefully EAT with AR4SI Claims 182 } 184 challenge-response-nonce = (1: "PLEASE DEFINE") 185 remote-attestation-evidence = (2: "PLEASE DEFINE") 186 remote-attestation-results = (3: "PLEASE DEFINE") 188 ;payload types independent on interaction model 189 $payload /= native-rfc3161-TST-info 190 $payload /= TST-info-based-on-CBOR-time-tag 191 $payload /= CBOR-time-tag 192 $payload /= multi-nonce 193 $payload /= multi-nonce-list 194 $payload /= strictly-monotonically-increasing-counter 196 native-rfc3161-TST-info = bytes ; DER-encoded value of TSTInfo 198 ; ~~~ 199 ; ~~~ translation with a few poetic licenses of ASN.1 TSTInfo into CDDL 200 ; ~~~ 201 TST-info-based-on-CBOR-time-tag = { 202 &(version : 0) => int .default 1 ; obsolete? 203 &(policy : 1) => oid 204 &(messageImprint : 2) => MessageImprint 205 &(serialNumber : 3) => int 206 &(eTime : 4) => profiled-etime 207 ? &(accuracy : 5) => rfc3161-accuracy 208 &(ordering : 6) => bool .default false 209 ? &(nonce : 7) => int 210 ? &(tsa : 8) => GeneralName 211 * $$TSTInfoExtensions 212 } 214 ; based on COSE_Hash_Find (draft-ietf-cose-hash-algs) 215 MessageImprint = [ 216 hashAlg : int 217 hashValue : bstr 218 ] 220 rfc3161-accuracy = non-empty<{ 221 ? &(seconds : 0) => int 222 ? &(millis: 1) => 1..999 223 ? &(micros: 2) => 1..999 224 }> 226 ; timeMap profiles etime from https://datatracker.ietf.org/doc/html/draft-ietf-cbor-time-tag 227 profiled-etime = #6.1001(timeMap) 228 timeMap = { 229 1 => #6.1(int / float) ; TIME_T 230 * int => any 231 } 233 ; Section 11.8 of I-D.ietf-cose-cbor-encoded-cert 234 GeneralName = [ GeneralNameType : int, GeneralNameValue : any ] 236 ; stuff 237 oid = #6.111(bstr) 238 non-empty = (M) .and ({ + any => any }) 240 CBOR-time-tag = [ 241 time-tag, 242 ? nonce 243 ] 245 time-tag = "PLEASE DEFINE" 246 nonce = "PLEASE DEFINE" 248 multi-nonce = tstr / bstr / int 250 multi-nonce-list = [+ multi-nonce] 252 strictly-monotonically-increasing-counter = uint ; counter context? per issuer? per indicator? 254 5. References 256 5.1. Normative References 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", BCP 14, RFC 2119, 260 DOI 10.17487/RFC2119, March 1997, 261 . 263 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 264 "Internet X.509 Public Key Infrastructure Time-Stamp 265 Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 266 2001, . 268 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 269 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 270 May 2017, . 272 5.2. Informative References 274 [I-D.ietf-rats-architecture] 275 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 276 W. Pan, "Remote Attestation Procedures Architecture", Work 277 in Progress, Internet-Draft, draft-ietf-rats-architecture- 278 15, 8 February 2022, . 281 [I-D.ietf-rats-reference-interaction-models] 282 Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference 283 Interaction Models for Remote Attestation Procedures", 284 Work in Progress, Internet-Draft, draft-ietf-rats- 285 reference-interaction-models-05, 26 January 2022, 286 . 289 Appendix A. RFC 3161 TSTInfo 291 As a reference for the definition of TST-info-based-on-CBOR-time-tag 292 the code block below depicts the original layout of the TSTInfo 293 structure from [RFC3161]. 295 TSTInfo ::= SEQUENCE { 296 version INTEGER { v1(1) }, 297 policy TSAPolicyId, 298 messageImprint MessageImprint, 299 -- MUST have the same value as the similar field in 300 -- TimeStampReq 301 serialNumber INTEGER, 302 -- Time-Stamping users MUST be ready to accommodate integers 303 -- up to 160 bits. 304 genTime GeneralizedTime, 305 accuracy Accuracy OPTIONAL, 306 ordering BOOLEAN DEFAULT FALSE, 307 nonce INTEGER OPTIONAL, 308 -- MUST be present if the similar field was present 309 -- in TimeStampReq. In that case it MUST have the same value. 310 tsa [0] GeneralName OPTIONAL, 311 extensions [1] IMPLICIT Extensions OPTIONAL } 313 Acknowledgements 315 TBD 317 Authors' Addresses 319 Henk Birkholz 320 Fraunhofer SIT 321 Rheinstrasse 75 322 64295 Darmstadt 323 Germany 324 Email: henk.birkholz@sit.fraunhofer.de 326 Thomas Fossati 327 Arm Limited 328 United Kingdom 329 Email: Thomas.Fossati@arm.com 330 Wei Pan 331 Huawei Technologies 332 Email: william.panwei@huawei.com 334 Carsten Bormann 335 Universität Bremen TZI 336 Bibliothekstr. 1 337 D-28359 Bremen 338 Germany 339 Phone: +49-421-218-63921 340 Email: cabo@tzi.org