idnits 2.17.1 draft-birkholz-rats-tuda-01.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 9 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 (September 12, 2019) is 1680 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'AIK-Cert' is mentioned on line 3183, but not defined == Missing Reference: 'TSA-Cert' is mentioned on line 3183, but not defined == Outdated reference: A later version (-03) exists of draft-birkholz-rats-architecture-01 == Outdated reference: A later version (-03) exists of draft-birkholz-rats-reference-interaction-model-01 == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-07 == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-12 -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7320 (Obsoleted by RFC 8820) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group A. Fuchs 3 Internet-Draft H. Birkholz 4 Intended status: Standards Track Fraunhofer SIT 5 Expires: March 15, 2020 I. McDonald 6 High North Inc 7 C. Bormann 8 Universitaet Bremen TZI 9 September 12, 2019 11 Time-Based Uni-Directional Attestation 12 draft-birkholz-rats-tuda-01 14 Abstract 16 This documents defines the method and bindings used to conduct Time- 17 based Uni-Directional Attestation (TUDA) between two RATS (Remote 18 ATtestation procedureS) Principals over the Internet. TUDA does not 19 require a challenge-response handshake and thereby does not rely on 20 the conveyance of a nonce to prove freshness of remote attestation 21 Evidence. Conversely, TUDA enables the creation of Secure Audit Logs 22 that can constitute Evidence about current and past operational 23 states of an Attester. As a prerequisite for TUDA, every RATS 24 Principal requires access to a trusted and synchronized time-source. 25 Per default, in TUDA this is a Time Stamp Authority (TSA) issuing 26 signed Time Stamp Tokens (TST). 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 15, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 64 1.2. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.3. Creating Evidence about Software Component Integrity . . 5 66 1.3.1. Data Items . . . . . . . . . . . . . . . . . . . . . 5 67 1.3.2. System Components . . . . . . . . . . . . . . . . . . 5 68 1.3.3. Operations . . . . . . . . . . . . . . . . . . . . . 6 69 1.4. Remote Attestation Principles . . . . . . . . . . . . . . 6 70 1.5. System Component Requirements . . . . . . . . . . . . . . 7 71 1.6. Evidence Appraisal . . . . . . . . . . . . . . . . . . . 7 72 1.7. Activities and Actions . . . . . . . . . . . . . . . . . 8 73 1.8. Attestation and Verification . . . . . . . . . . . . . . 8 74 1.9. Information Elements and Conveyance . . . . . . . . . . . 8 75 1.10. TUDA Objectives . . . . . . . . . . . . . . . . . . . . . 9 76 1.11. Hardware Dependencies . . . . . . . . . . . . . . . . . . 10 77 2. TUDA Core Concept . . . . . . . . . . . . . . . . . . . . . . 10 78 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 3.1. Universal Terms . . . . . . . . . . . . . . . . . . . . . 11 80 3.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 3.2.1. General Types . . . . . . . . . . . . . . . . . . . . 13 82 3.2.2. RoT specific terms . . . . . . . . . . . . . . . . . 13 83 3.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 13 84 4. Time-Based Uni-Directional Attestation . . . . . . . . . . . 13 85 4.1. TUDA Information Elements Update Cycles . . . . . . . . . 15 86 5. Sync Base Protocol . . . . . . . . . . . . . . . . . . . . . 17 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 89 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 93 10.2. Informative References . . . . . . . . . . . . . . . . . 20 94 Appendix A. REST Realization . . . . . . . . . . . . . . . . . . 24 95 Appendix B. SNMP Realization . . . . . . . . . . . . . . . . . . 24 96 B.1. Structure of TUDA MIB . . . . . . . . . . . . . . . . . . 25 97 B.1.1. Cycle Index . . . . . . . . . . . . . . . . . . . . . 25 98 B.1.2. Instance Index . . . . . . . . . . . . . . . . . . . 25 99 B.1.3. Fragment Index . . . . . . . . . . . . . . . . . . . 25 100 B.2. Relationship to Host Resources MIB . . . . . . . . . . . 26 101 B.3. Relationship to Entity MIB . . . . . . . . . . . . . . . 26 102 B.4. Relationship to Other MIBs . . . . . . . . . . . . . . . 26 103 B.5. Definition of TUDA MIB . . . . . . . . . . . . . . . . . 26 104 Appendix C. YANG Realization . . . . . . . . . . . . . . . . . . 42 105 Appendix D. Realization with TPM functions . . . . . . . . . . . 57 106 D.1. TPM Functions . . . . . . . . . . . . . . . . . . . . . . 57 107 D.1.1. Tick-Session and Tick-Stamp . . . . . . . . . . . . . 57 108 D.1.2. Platform Configuration Registers (PCRs) . . . . . . . 58 109 D.1.3. PCR restricted Keys . . . . . . . . . . . . . . . . . 58 110 D.1.4. CertifyInfo . . . . . . . . . . . . . . . . . . . . . 59 111 D.2. IE Generation Procedures for TPM 1.2 . . . . . . . . . . 59 112 D.2.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 59 113 D.2.2. Synchronization Token . . . . . . . . . . . . . . . . 60 114 D.2.3. RestrictionInfo . . . . . . . . . . . . . . . . . . . 62 115 D.2.4. Measurement Log . . . . . . . . . . . . . . . . . . . 64 116 D.2.5. Implicit Attestation . . . . . . . . . . . . . . . . 65 117 D.2.6. Attestation Verification Approach . . . . . . . . . . 66 118 D.3. IE Generation Procedures for TPM 2.0 . . . . . . . . . . 68 119 D.3.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 68 120 D.3.2. Synchronization Token . . . . . . . . . . . . . . . . 69 121 D.3.3. Measurement Log . . . . . . . . . . . . . . . . . . . 69 122 D.3.4. Explicit time-based Attestation . . . . . . . . . . . 70 123 D.3.5. Sync Proof . . . . . . . . . . . . . . . . . . . . . 70 124 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 71 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71 127 1. Introduction 129 Remote ATtestation procedureS (RATS) describe the attempt to 130 determine and appraise properties, such as integrity and 131 trustworthiness, of a communication partner - the Attester - over the 132 Internet to another communication parter - the Verifier - without 133 direct access. TUDA uses the architectural constituents of the RATS 134 Architecture [I-D.birkholz-rats-architecture] that defines the Roles 135 Attester and Verifier in detail. The RATS Architecture also defines 136 Role Messages. TUDA creates and conveys a specific type of Role 137 Message called Evidence, a composition of trustwrthiness Claims 138 provided by an Attester and consumed by a Verifier (potentially 139 relayed by another RATS Role that is a Relying Party). TUDA - in 140 contrast to traditional bi-directional challenge-response protocols 142 [I-D.birkholz-rats-reference-interaction-model] - enables a uni- 143 directional conveyance of attestation Evidence that allows for 144 providing attestation information without solicitation (e.g. as 145 beacons or push data via YANG Push [RFC8641], [RFC8640], [RFC8639]). 147 As a result, this document introduces the term Forward Authenticity. 149 Forward Authenticity (FA): A property of secure communication 150 protocols, in which later compromise of the long-term keys of a 151 data origin does not compromise past authentication of data from 152 that origin. FA is achieved by timely recording of assessments of 153 the authenticity from system components (via "audit logs" during 154 "audit sessions") that are authorized for this purpose and 155 trustworthy (e.g via endorsed roots of trust), in a time frame 156 much shorter than that expected for the compromise of the long- 157 term keys. 159 Forward Authenticity enables new levels of assurance and can be 160 included in basically every protocol, such as ssh, YANG Push, 161 router advertisements, link layer neighbor discovery, or even ICMP 162 echo. 164 1.1. Requirements Notation 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 168 "OPTIONAL" in this document are to be interpreted as described in 169 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 170 capitals, as shown here. 172 1.2. Evidence 174 Remote attestation Evidence is basically a set of trustworthiness 175 claims (assertions about the Attester and its system characteristics 176 including security posture and protection characteristics) that are 177 accompanied by a proof of their veracity - typically a signature 178 based on shielded, private and potentially restricted key material. 179 As key material alone is typically not self-descriptive with respect 180 to its intended use (its semantics), the remote attestation Evidence 181 created via TUDA is accompanied by two kinds of certificates that are 182 cryptographically associated with a Trust Anchor (TA) [RFC4949] via a 183 certification path: 185 o an Attestation Key (AK) Certificate (AK-Cert) that represents the 186 attestation provenance of the created Evidence, and 188 o an Endorsement Key (EK) Certificate (EK-Cert) that represents the 189 protection characteristics of the system components the AK is 190 stored in. 192 If a Verifier decides to trust both the TA of an AK-Cert and an EK- 193 Cert presented by an Attester - and the included assertions about the 194 system characteristics describing the Attester, the attestation 195 Evidence created via TUDA by the Attester is considered believable. 196 Ultimately, believable Evidence is appraised by a Verifier in order 197 to assess the trustworthiness of the corresponding Attester. 199 1.3. Creating Evidence about Software Component Integrity 201 The TUDA protocol mechanism uses hash values of all started software 202 components as a basis to provide and create Evidence about the 203 integrity of the software components of an Attester. This section 204 defines the processed data items, the required system components, and 205 corresponding operations to enable the creation of Evidence about 206 software component integrity for TUDA. 208 1.3.1. Data Items 210 The hash value of a software component created before it is executed 211 is referred to as a "measurement" in the remainder of this document. 212 Measurements are chained using a rolling hash function. Each 213 measurement added to the sequence of all measurements results in a 214 new current hash value that is referred to as a "digest" in the 215 remainder of this document. 217 1.3.2. System Components 219 The function to store these measurements via a rolling hash function 220 is provided by a root of trust for storage - a system component that 221 MUST be a component of the attester. 223 With respect to the boot sequence of an Attester, the very first 224 measurements of software components (e.g. the BIOS, or a sometimes a 225 bootloader) have to be conducted by a root of trust for measurement 226 that is implemented in hardware and MUST be a system component of the 227 Attester. 229 All measurements retained in the root of trust for measurements are 230 handed over to the root of trust for storage when it becomes 231 available during the boot procedure of the Attester. During that 232 hand-over the sequence of measurements retained in the root of trust 233 for measurement are processed by the rolling hash function of the 234 root of trust for storage. 236 The function of retrieving the current output value of the rolling 237 hash function, including a signature to provide a proof of veracity, 238 is provided by a root of trust for reporting and MUST be a system 239 component of the Attester. 241 Typically, a root of trust for storage and a root of trust for 242 reporting are tightly coupled. Analogously, a root of trust for 243 measurement is typically independent from the root of trust for 244 storage, but has to be able to interact with root of trust for 245 storage at some point of the boot sequence of the Attester to hand 246 over the retained measurements. 248 1.3.3. Operations 250 The operation of processing a measurement and adding it to the 251 sequence of measurements via the rolling hash function is called 252 "extend" and is provided by the root of trust for storage. 254 The operation of retrieving the current available hash value that is 255 the result of the rolling hash function including a signature based 256 on an Attestation Key is called "quote" and is provided by the 257 corresponding root of trust for reporting. 259 1.4. Remote Attestation Principles 261 In essence, RATS are composed of three base activities. The 262 following definitions are derived from the definitions presented in 263 [PRIRA] and [TCGGLOSS], and are a simplified summary of the RATS 264 Architecture relevant for TUDA. The complete RATS Architecture and 265 every corresponding constituent, message and interaction is defined 266 in [I-D.birkholz-rats-architecture]. 268 Attestation: The creation of one ore more claims about the 269 trustworthiness properties of an Attester, such that the claims 270 can be used as Evidence. 272 Conveyance: The transfer of Evidence from the Attester to the 273 Verifier via an interconnect. 275 Verification: The appraisal of Evidence by evaluating it against 276 known-good-values (a type of declarative guidance). 278 With TUDA, the claims that compose the evidence are signatures over 279 trustworthy integrity measurements created by leveraging roots of 280 trust. The evidence is appraised via corresponding signatures over 281 reference integrity measurements (RIM, represented, for example via 282 [I-D.ietf-sacm-coswid]). 284 Protocols that facilitate Trust-Anchor based signatures in order to 285 provide RATS are usually bi-directional challenge/response protocols, 286 such as the Platform Trust Service protocol [PTS] or CAVES [PRIRA], 287 where one entity sends a challenge that is included inside the 288 response to prove the recentness - the freshness (see fresh in 289 [RFC4949]) - of the attestation information. The corresponding 290 interaction model tightly couples the three activities of creating, 291 transferring and appraising evidence. 293 The Time-Based Uni-directional Attestation family of protocols - TUDA 294 - described in this document can decouple the three activities RATS 295 are composed of. As a result, TUDA provides additional capabilities, 296 such as: 298 o remote attestation for Attesters that might not always be able to 299 reach the Internet by enabling the verification of past states, 301 o secure audit logs by combining the evidence created via TUDA with 302 integrity measurement logs that represent a detailed record of 303 corresponding past states, 305 o an uni-directional interaction model that can traverse "diode- 306 like" network security functions (NSF) or can be leveraged in 307 RESTful architectures (e.g. CoAP [RFC7252]), analogously. 309 1.5. System Component Requirements 311 TUDA is a family of protocols that bundles results from specific 312 attestation activities. The attestation activities of TUDA are based 313 on a hardware roots of trust that provides the following 314 capabilities: 316 o Platform Configuration Registers (PCR) that can extend 317 measurements consecutively and represent the sequence of 318 measurements as a single digest, 320 o Restricted Signing Keys (RSK) that can only be accessed, if a 321 specific signature about a set of measurements can be provided as 322 authentication, and 324 o a dedicated source of (relative) time, e.g. a tick counter (a tick 325 being a specific time interval, for example 10 ms). 327 1.6. Evidence Appraisal 329 To appraise the evidence created by an Attester, the Verifier 330 requires corresponding Reference Integrity Measurements (RIM). 331 Typical set of RIMs are required to assess the integrity of an 332 Attester. These sets are called RIM Bundles. The scope of a RIM 333 Bundle encompasses, e.g., a platform, a device, a computing context, 334 or a virtualised function. In order to be comparable, the hashing 335 algorithms used by the Attester to create the integrity measurements 336 have to match the hashing algorithms used to create the corresponding 337 RIM that are used by the Verifier to appraise the attestation 338 Evidence about software component integrity. 340 1.7. Activities and Actions 342 Depending on the platform (i.e. one or more computing contexts 343 including a dedicated hardware RoT), a generic RA activity results in 344 platform-specific actions that have to be conducted. In consequence, 345 there are multiple specific operations and data models (defining the 346 input and output of operations). Hence, specific actions are are not 347 covered by this document. Instead, the requirements on operations 348 and the information elements that are the input and output to these 349 operations are illustrated using pseudo code in Appendix C and D. 351 1.8. Attestation and Verification 353 Both the attestation and the verification activity of TUDA also 354 require a trusted Time Stamp Authority (TSA) as an additional third 355 party next to the Attester and the Verifier. The protocol uses a 356 Time Stamp Authority based on [RFC3161]. The combination of the 357 local source of time provided by the hardware RoT (located on the 358 Attester) and the Time Stamp Tokens provided by the TSA (to both the 359 Attester and the Verifier) enable the attestation and verification of 360 an appropriate freshness of the evidence conveyed by the Attester -- 361 without requiring a challenge/response interaction model that uses a 362 nonce to ensure the freshness. 364 Typically, the verification activity requires declarative guidance 365 (representing desired or compliant endpoint characteristics in the 366 form of RIM, see above) to appraise the individual integrity 367 measurements the conveyed evidence is composed on. The acquisition 368 or representation (data models) of declarative guidance as well as 369 the corresponding evaluation methods are out of the scope of this 370 document. 372 1.9. Information Elements and Conveyance 374 TUDA defines a set of information elements (IE) that are created and 375 stored on the Attester and are intended to be transferred to the 376 Verifier in order to enable appraisal. Each TUDA IE: 378 o is encoded in the Concise Binary Object Representation (CBOR 379 [RFC7049]) to minimize the volume of data in motion. In this 380 document, the composition of the CBOR data items that represent IE 381 is described using the Concise Data Definition Language, CDDL 382 [RFC8610] 384 o that requires a certain freshness is only created/updated when 385 out-dated, which reduces the overall resources required from the 386 Attester, including the utilization of the hardware root of trust. 387 The IE that have to be created are determined by their age or by 388 specific state changes on the Attester (e.g. state changes due to 389 a reboot-cycle) 391 o is only transferred when required, which reduces the amount of 392 data in motion necessary to conduct remote attestation 393 significantly. Only IE that have changed since their last 394 conveyance have to be transferred 396 o that requires a certain freshness can be reused for multiple 397 remote attestation procedures in the limits of its corresponding 398 freshness-window, further reducing the load imposed on the 399 Attester and its corresponding hardware RoT. 401 1.10. TUDA Objectives 403 The Time-Based Uni-directional Attestation family of protocols is 404 designed to: 406 o increase the confidence in authentication and authorization 407 procedures, 409 o address the requirements of constrained-node networks, 411 o support interaction models that do not maintain connection-state 412 over time, such as REST architectures [REST], 414 o be able to leverage existing management interfaces, such as SNMP 415 [RFC3411]. RESTCONF [RFC8040] or CoMI [I-D.ietf-core-comi] -- and 416 corresponding bindings, 418 o support broadcast and multicast schemes (e.g. [IEEE1609]), 420 o be able to cope with temporary loss of connectivity, and to 422 o provide trustworthy audit logs of past endpoint states. 424 1.11. Hardware Dependencies 426 The binding of the attestation scheme used by TUDA to generate the 427 TUDA IE is specific to the methods provided by the hardware RoT used 428 (see above). In this document,expositional text and pseudo-code that 429 is provided as a reference to instantiate the TUDA IE is based on TPM 430 1.2 and TPM 2.0 operations. The corresponding TPM commands are 431 specified in [TPM12] and [TPM2]. The references to TPM commands and 432 corresponding pseudo-code only serve as guidance to enable a better 433 understanding of the attestation scheme and is intended to encourage 434 the use of any appropriate hardware RoT or equivalent set of 435 functions available to a CPU or Trusted Execution Environment [TEE]. 437 2. TUDA Core Concept 439 There are significant differences between conventional bi-directional 440 attestation and TUDA regarding both the information elements conveyed 441 between Attester and Verifier and the time-frame, in which an 442 attestation can be considered to be fresh (and therefore 443 trustworthy). 445 In general, remote attestation using a bi-directional communication 446 scheme includes sending a nonce-challenge within a signed attestation 447 token. Using the TPM 1.2 as an example, a corresponding nonce- 448 challenge would be included within the signature created by the 449 TPM_Quote command in order to prove the freshness of the attestation 450 response, see e.g. [PTS]. 452 In contrast, the TUDA protocol uses the combined output of 453 TPM_CertifyInfo and TPM_TickStampBlob. The former provides a proof 454 about the platform's state by creating evidence that a certain key is 455 bound to that state. The latter provides proof that the platform was 456 in the specified state by using the bound key in a time operation. 457 This combination enables a time-based attestation scheme. The 458 approach is based on the concepts introduced in [SCALE] and 459 [SFKE2008]. 461 Each TUDA IE has an individual time-frame, in which it is considered 462 to be fresh (and therefore trustworthy). In consequence, each TUDA 463 IE that composes data in motion is based on different methods of 464 creation. 466 The freshness properties of a challenge-response based protocol 467 define the point-of-time of attestation between: 469 o the time of transmission of the nonce, and 471 o the reception of the corresponding response. 473 Given the time-based attestation scheme, the freshness property of 474 TUDA is equivalent to that of bi-directional challenge response 475 attestation, if the point-in-time of attestation lies between: 477 o the transmission of a TUDA time-synchronization token, and 479 o the typical round-trip time between the Verifier and the Attester. 481 The accuracy of this time-frame is defined by two factors: 483 o the time-synchronization between the Attester and the TSA. The 484 time between the two tickstamps acquired via the hardware RoT 485 define the scope of the maximum drift ("left" and "right" in 486 respect to the timeline) to the TSA timestamp, and 488 o the drift of clocks included in the hardware RoT. 490 Since the conveyance of TUDA evidence does not rely upon a Verifier 491 provided value (i.e. the nonce), the security guarantees of the 492 protocol only incorporate the TSA and the hardware RoT. In 493 consequence, TUDA evidence can even serve as proof of integrity in 494 audit logs with precise point-in-time guarantees, in contrast to 495 classical attestations. 497 Appendix A contains guidance on how to utilize a REST architecture. 499 Appendix B contains guidance on how to create an SNMP binding and a 500 corresponding TUDA-MIB. 502 Appendix C contains a corresponding YANG module that supports both 503 RESTCONF and CoMI. 505 Appendix D.2 contains a realization of TUDA using TPM 1.2 primitives. 507 Appendix D.3 contains a realization of TUDA using TPM 2.0 primitives. 509 3. Terminology 511 This document introduces roles, information elements and types 512 required to conduct TUDA and uses terminology (e.g. specific 513 certificate names) typically seen in the context of attestation or 514 hardware security modules. 516 3.1. Universal Terms 518 Attestation Identity Key (AIK): a special purpose signature 519 (therefore asymmetric) key that supports identity related 520 operations. The private portion of the key pair is maintained 521 confidential to the entity via appropriate measures (that have an 522 impact on the scope of confidence). The public portion of the key 523 pair may be included in AIK credentials that provide a claim about 524 the entity. 526 Claim: A piece of information asserted about a subject [RFC4949]. A 527 claim is represented as a name/value pair consisting of a Claim 528 Name and a Claim Value [RFC7519]. 530 In the context of SACM, a claim is also specialized as an 531 attribute/value pair that is intended to be related to a statement 532 [I-D.ietf-sacm-terminology]. 534 Endpoint Attestation: the creation of evidence on the Attester that 535 provides proof of a set of the endpoints's integrity measurements. 536 This is done by digitally signing a set of PCRs using an AIK 537 shielded by the hardware RoT. 539 Endpoint Characteristics: the context, composition, configuration, 540 state, and behavior of an endpoint. 542 Evidence: a trustworthy set of claims about an endpoint's 543 characteristics. 545 Identity: a set of claims that is intended to be related to an 546 entity. 548 Integrity Measurements: Metrics of endpoint characteristics (i.e. 549 composition, configuration and state) that affect the confidence 550 in the trustworthiness of an endpoint. Digests of integrity 551 measurements can be stored in shielded locations (i.e. PCR of a 552 TPM). 554 Reference Integrity Measurements: Signed measurements about the 555 characteristics of an endpoint's characteristics that are provided 556 by a vendor and are intended to be used as declarative guidance 557 [I-D.ietf-sacm-terminology] (e.g. a signed CoSWID). 559 Trustworthy: the qualities of an endpoint that guarantee a specific 560 behavior and/or endpoint characteristics defined by declarative 561 guidance. Analogously, trustworthiness is the quality of being 562 trustworthy with respect to declarative guidance. Trustworthiness 563 is not an absolute property but defined with respect to an entity, 564 corresponding declarative guidance, and has a scope of confidence. 566 Trustworthy Endpoint: an endpoint that guarantees trustworthy 567 behavior and/or composition (with respect to certain declarative 568 guidance and a scope of confidence). 570 Trustworthy Statement: evidence that is trustworthy conveyed by an 571 endpoint that is not necessarily trustworthy. 573 3.2. Roles 575 Attester: the endpoint that is the subject of the attestation to 576 another endpoint. 578 Verifier: the endpoint that consumes the attestation of another 579 endpoint to conduct a verification. 581 TSA: a Time Stamp Authority [RFC3161] 583 3.2.1. General Types 585 Byte: the now customary synonym for octet 587 Cert: an X.509 certificate represented as a byte-string 589 3.2.2. RoT specific terms 591 PCR: a Platform Configuration Register that is part of a hardware 592 root of trust and is used to securely store and report 593 measurements about security posture 595 PCR-Hash: a hash value of the security posture measurements stored 596 in a TPM PCR (e.g. regarding running software instances) 597 represented as a byte-string 599 3.3. Certificates 601 TSA-CA: the Certificate Authority that provides the certificate for 602 the TSA represented as a Cert 604 AIK-CA: the Certificate Authority that provides the certificate for 605 the attestation identity key of the TPM. This is the client 606 platform credential for this protocol. It is a placeholder for a 607 specific CA and AIK-Cert is a placeholder for the corresponding 608 certificate, depending on what protocol was used. The specific 609 protocols are out of scope for this document, see also 610 [AIK-Enrollment] and [IEEE802.1AR]. 612 4. Time-Based Uni-Directional Attestation 614 A Time-Based Uni-Directional Attestation (TUDA) consists of the 615 following seven information elements. They are used to gain 616 assurance of the Attester's platform configuration at a certain point 617 in time: 619 TSA Certificate: The certificate of the Time Stamp Authority that is 620 used in a subsequent synchronization protocol token. This 621 certificate is signed by the TSA-CA. 623 AIK Certificate: A certificate about the Attestation Identity Key 624 (AIK) used. This may or may not also be an [IEEE802.1AR] IDevID 625 or LDevID, depending on their setting of the corresponding 626 identity property. ([AIK-Credential], [AIK-Enrollment]; see 627 Appendix D.2.1.) 629 Synchronization Token: The reference for attestations are the 630 relative timestanps provided by the hardware RoT. In order to put 631 attestations into relation with a Real Time Clock (RTC), it is 632 necessary to provide a cryptographic synchronization between these 633 trusted relative timestamps and the regular RTC that is a hardware 634 component of the Attester. To do so, a synchronization protocol 635 is run with a Time Stamp Authority (TSA). 637 Restriction Info: The attestation relies on the capability of the 638 hardware RoT to operate on restricted keys. Whenever the PCR 639 values for the machine to be attested change, a new restricted key 640 is created that can only be operated as long as the PCRs remain in 641 their current state. 643 In order to prove to the Verifier that this restricted temporary 644 key actually has these properties and also to provide the PCR 645 value that it is restricted, the corresponding signing 646 capabilities of the hardware RoT are used. It creates a signed 647 certificate using the AIK about the newly created restricted key. 649 Measurement Log: Similarly to regular attestations, the Verifier 650 needs a way to reconstruct the PCRs' values in order to estimate 651 the trustworthiness of the device. As such, a list of those 652 elements that were extended into the PCRs is reported. Note 653 though that for certain environments, this step may be optional if 654 a list of valid PCR configurations (in the form of RIM available 655 to the Verifier) exists and no measurement log is required. 657 Implicit Attestation: The actual attestation is then based upon a 658 signed timestamp provided by the hardware RoT using the restricted 659 temporary key that was certified in the steps above. The signed 660 timestamp provides evidence that at this point in time (with 661 respect to the relative time of the hardware RoT) a certain 662 configuration existed (namely the PCR values associated with the 663 restricted key). Together with the synchronization token this 664 timestamp represented in relative time can then be related to the 665 real-time clock. 667 Concise SWID tags: As an option to better assess the trustworthiness 668 of an Attester, a Verifier can request the reference hashes (RIM, 669 which are often referred to as golden measurements) of all started 670 software components to compare them with the entries in the 671 measurement log. References hashes regarding installed (and 672 therefore running) software can be provided by the manufacturer 673 via SWID tags. SWID tags are provided by the Attester using the 674 Concise SWID representation [I-D.ietf-sacm-coswid] and bundled 675 into a CBOR array (a RIM Manifest). Ideally, the reference hashes 676 include a signature created by the manufacturer of the software to 677 prove their integrity. 679 These information elements could be sent en bloc, but it is 680 recommended to retrieve them separately to save bandwidth, since 681 these elements have different update cycles. In most cases, 682 retransmitting all seven information elements would result in 683 unnecessary redundancy. 685 Furthermore, in some scenarios it might be feasible not to store all 686 elements on the Attester endpoint, but instead they could be 687 retrieved from another location or be pre-deployed to the Verifier. 688 It is also feasible to only store public keys on the Verifier and 689 skip the whole certificate provisioning completely in order to save 690 bandwidth and computation time for certificate verification. 692 4.1. TUDA Information Elements Update Cycles 694 An endpoint can be in various states and have various information 695 associated with it during its life cycle. For TUDA, a subset of the 696 states (which can include associated information) that an endpoint 697 and its hardware root of trust can be in, is important to the 698 attestation process. States can be: 700 o persistent, even after a hard reboot. This includes certificates 701 that are associated with the endpoint itself or with services it 702 relies on. 704 o volatile to a degree, because they change at the beginning of each 705 boot cycle. This includes the capability of a hardware RoT to 706 provide relative time which provides the basis for the 707 synchronization token and implicit attestation--and which can 708 reset after an endpoint is powered off. 710 o very volatile, because they change during an uptime cycle (the 711 period of time an endpoint is powered on, starting with its boot). 712 This includes the content of PCRs of a hardware RoT and thereby 713 also the PCR-restricted signing keys used for attestation. 715 Depending on this "lifetime of state", data has to be transported 716 over the wire, or not. E.g. information that does not change due to 717 a reboot typically has to be transported only once between the 718 Attester and the Verifier. 720 There are three kinds of events that require a renewed attestation: 722 o The Attester completes a boot-cycle 724 o A relevant PCR changes 726 o Too much time has passed since the last attestation statement 728 The third event listed above is variable per application use case and 729 also depends on the precision of the clock included in the hardware 730 RoT. For usage scenarios, in which the device would periodically 731 push information to be used in an audit-log, a time-frame of 732 approximately one update per minute should be sufficient in most 733 cases. For those usage scenarios, where Verifiers request (pull) a 734 fresh attestation statement, an implementation could use the hardware 735 RoT continuously to always present the most freshly created results. 736 To save some utilization of the hardware RoT for other purposes, 737 however, a time-frame of once per ten seconds is recommended, which 738 would typically leave about 80% of utilization for other 739 applications. 741 Attester Verifier 742 | | 743 Boot | 744 | | 745 Create Sync-Token | 746 | | 747 Create Restricted Key | 748 Certify Restricted Key | 749 | | 750 | AIK-Cert ---------------------------------------------> | 751 | Sync-Token -------------------------------------------> | 752 | Certify-Info -----------------------------------------> | 753 | Measurement Log --------------------------------------> | 754 | Attestation ------------------------------------------> | 755 | Verify Attestation 756 | | 757 |