idnits 2.17.1 draft-birkholz-tuda-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 08, 2016) is 2842 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: Informational ---------------------------------------------------------------------------- == Missing Reference: 'AIK-Cert' is mentioned on line 1574, but not defined == Missing Reference: 'TSA-Cert' is mentioned on line 1574, but not defined == Unused Reference: 'AIK-Credential' is defined on line 1357, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-birkholz-sacm-coswid-00 == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-08 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-15 -- 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: 0 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Fuchs 3 Internet-Draft H. Birkholz 4 Intended status: Informational Fraunhofer SIT 5 Expires: January 9, 2017 I. McDonald 6 High North Inc 7 C. Bormann 8 Universitaet Bremen TZI 9 July 08, 2016 11 Time-Based Uni-Directional Attestation 12 draft-birkholz-tuda-02 14 Abstract 16 This memo documents the method and bindings used to conduct time- 17 based uni-directional attestation between distinguishable endpoints 18 over the network. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 9, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 56 1.2. Concept . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.3.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.3.2. General Types . . . . . . . . . . . . . . . . . . . . 6 60 1.3.3. TPM-Specific Terms . . . . . . . . . . . . . . . . . 6 61 1.3.4. Certificates . . . . . . . . . . . . . . . . . . . . 6 62 2. Time-Based Uni-Directional Attestation . . . . . . . . . . . 6 63 2.1. TUDA Information Elements Update Cycles . . . . . . . . . 8 64 3. REST Realization . . . . . . . . . . . . . . . . . . . . . . 10 65 4. SNMP Realization . . . . . . . . . . . . . . . . . . . . . . 10 66 4.1. Structure of TUDA MIB . . . . . . . . . . . . . . . . . . 11 67 4.1.1. Cycle Index . . . . . . . . . . . . . . . . . . . . . 11 68 4.1.2. Instance Index . . . . . . . . . . . . . . . . . . . 12 69 4.1.3. Fragment Index . . . . . . . . . . . . . . . . . . . 12 70 4.2. Relationship to Host Resources MIB . . . . . . . . . . . 12 71 4.3. Relationship to Entity MIB . . . . . . . . . . . . . . . 12 72 4.4. Relationship to Other MIBs . . . . . . . . . . . . . . . 13 73 4.5. Definition of TUDA MIB . . . . . . . . . . . . . . . . . 13 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 76 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 28 77 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 29 80 9.2. Informative References . . . . . . . . . . . . . . . . . 29 81 Appendix A. Realization with TPM 1.2 functions . . . . . . . . . 32 82 A.1. TPM Functions . . . . . . . . . . . . . . . . . . . . . . 32 83 A.1.1. Tick-Session and Tick-Stamp . . . . . . . . . . . . . 32 84 A.1.2. Platform Configuration Registers (PCRs) . . . . . . . 32 85 A.1.3. PCR restricted Keys . . . . . . . . . . . . . . . . . 33 86 A.1.4. CertifyInfo . . . . . . . . . . . . . . . . . . . . . 33 87 A.2. Protocol and Procedure . . . . . . . . . . . . . . . . . 33 88 A.2.1. AIK and AIK Certificate . . . . . . . . . . . . . . . 33 89 A.2.2. Synchronization Token . . . . . . . . . . . . . . . . 34 90 A.2.3. RestrictionInfo . . . . . . . . . . . . . . . . . . . 36 91 A.2.4. Measurement Log . . . . . . . . . . . . . . . . . . . 38 92 A.2.5. Implicit Attestation . . . . . . . . . . . . . . . . 39 93 A.2.6. Attestation Verification Approach . . . . . . . . . . 40 94 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 42 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 97 1. Introduction 99 Remote attestation describes the attempt to determine the integrity 100 and trustworthiness of an endpoint -- the attestee -- over a network 101 to another endpoint -- the verifier -- without direct access. One 102 way to do so is based on measurements of software components running 103 on the attestee, where the hash values of all started software 104 components are stored (extended into) a Trust Anchor implemented as a 105 Hardware Security Module (e.g. a Trusted Platform Module or similar) 106 and reported via a signature over these measurements. Protocols that 107 facilitate these Trust Anchor based signatures in order to provide 108 remote attestations are usually bi-directional protocols [PTS], where 109 one entity sends a challenge that is included inside the response to 110 ensure the recentness -- the freshness -- of the attestation 111 information. 113 In many contexts and scenarios it is not feasible to deploy bi- 114 directional protocols, due to constraints in the underlying 115 communication schemes. Furthermore, many communication schemes do 116 not have a notion of connection, which disallows the usage of 117 connection context related state information. These constraints may 118 make it impossible to deploy challenge-response based schemes to 119 achieve freshness of messages in security protocols. Examples of 120 these constrained environments include broadcast and multicast 121 schemes such as automotive IEEE802.11p as well as communication 122 models that do not maintain connection state over time, such as REST 123 [REST] and SNMP [RFC3411]. 125 This document describes the time-based uni-directional attestation 126 protocol -- TUDA -- that requires only uni-directional communication 127 channels between verifier and attestee. whilst still providing up- 128 to-date information about the integrity and thereby trustworthiness 129 of the attested device. There are two important prerequisites next 130 to the Hardware Security Module (HSM) itself: 132 o a source of (relative) time (i.e. a tick counter) integrated in 133 the HSM, and 135 o network access to a trusted time stamp authority (TSA) [RFC3161]. 137 Both prerequisites are mandatory to attest the appropriate freshness 138 of the remotes attestation without bi-directional communication. The 139 attestation scheme of TUDA is based on a set of TUDA information 140 elements that are generated on the attestee and transported to the 141 verifier. TUDA information elements are encoded in the Concise 142 Binary Object Representation, CBOR [RFC7049]. In this document, the 143 composition of the CBOR data items that represent the information 144 elements is described using the CBOR Data Definition Language, CDDL 145 [I-D.greevenbosch-appsawg-cbor-cddl]. 147 The binding of the attestation scheme used by TUDA to generate the 148 TUDA information elements is specific to the methods provided by the 149 HSM used. As a reference, this document includes pseudo-code that 150 illustrates the production of TUDA information elements using a TPM 151 1.2 and the corresponding TPM commands specified in [TPM12] as an 152 example. The references to TPM 1.2 commands and corresponding 153 pseudo-code only serves as guidance to enable a better understanding 154 of the attestation scheme and does not imply the use of a specific 155 HSM (excluding, of course, the requirements highlighted above). 157 1.1. Requirements Notation 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 161 "OPTIONAL" in this document are to be interpreted as described in RFC 162 2119, BCP 14 [RFC2119]. 164 1.2. Concept 166 There are significant differences between conventional bi-directional 167 attestation and TUDA regarding both the information elements 168 transmitted between attestee and verifier and the time-frame, in 169 which an attestation can be considered to be fresh (and therefore 170 trustworthy). 172 In general, remote attestation using a bi-directional communication 173 scheme includes sending a nonce-challenge within a signed attestation 174 token. Using the TPM 1.2 as an example, a corresponding nonce- 175 challenge would be included within the signature created by the 176 TPM_Quote command in order to prove the freshness of the attestation 177 response, see e.g. [PTS]. 179 In contrast, the TUDA protocol would use a combination output of 180 TPM_CertifyInfo and TPM_TickStampBlob. The former provides a proof 181 about the platform's state by attesting that a certain key is bound 182 to said state. The latter provides proof that the platform was in 183 the specified state by using the bound key in a time operation. This 184 combination enables a time-based attestation scheme. This approach 185 is based on the concepts introduced in [SCALE] and [SFKE2008]. 187 The payload of information elements transmitted is based on different 188 methods, because the time-frame, in which an attestation is 189 considered to be fresh (and therefore trustworthy), is defined 190 differently. 192 The freshness properties of a challenge-response based protocol 193 define the point-of-time of attestation between: 195 o the time of transmission of the nonce, and 197 o the reception of the response 199 Given the time-based attestation scheme, the freshness property of 200 TUDA is equivalent to that of bi-directional challenge response 201 attestation, if the point-in-time of attestation lies between: 203 o the transmission of a TUDA time-synchronization token, and 205 o the typical round-trip time between the verifier and the attestee, 207 The accuracy of this time-frame is defined by two factors: 209 o the time-synchronization between the attestee and the TSA. The 210 time between the two TPM tickstamps give the maximum drift (left 211 and right) to the TSA timestamp, and 213 o the drift of local TPM clocks 215 Since TUDA attestations do not rely upon a verifier provided value 216 (i.e. the nonce), the security guarantees of the protocol only 217 incorporate the TSA and the TPM. As a consequence TUDA attestations 218 can even serve as proof of integrity in audit logs with point in time 219 guarantees, in contrast to classical attestations. 221 Appendix A contains a realization of TUDA using TPM 1.2 primitives. 222 A realization of TUDA using TPM 2.0 primitives will be added with the 223 next iteration of this document. 225 1.3. Terminology 227 This document introduces roles, information elements and types 228 required to conduct TUDA and uses terminology (e.g. specific 229 certificate names) typically seen in the context of attestation or 230 hardware security modules. 232 1.3.1. Roles 234 Attestee: the endpoint that is the subject of the attestation to 235 another endpoint. 237 Verifier: the endpoint that consumes the attestation of another 238 endpoint. 240 TSA: a Time Stamp Authority [RFC3161] 242 1.3.2. General Types 244 Byte: the now customary synonym for octet 246 Cert: an X.509 certificate represented as a byte-string 248 PCR-Hash: a hash value of the security posture measurements stored 249 in a TPM Platform Configuration Register (e.g. regarding running 250 software instances) represented as a byte-string 252 1.3.3. TPM-Specific Terms 254 AIK: an Attestation Identity Key, a special key type used within a 255 TPM for identity-related operations (such as TPM_Certify or 256 TPM_Quote) 258 PCR: a Platform Configuration Register that is part of a TPM and is 259 used to securely store and report measurements about security 260 posture 262 1.3.4. Certificates 264 TSA-CA: the Certificate Authority that provides the certificate for 265 the TSA represented as a Cert 267 AIK-CA: the Certificate Authority that provides the certificate for 268 the attestation identity key of the TPM. This is the client 269 platform credential for this protocol. It is a placeholder for a 270 specific CA and AIK-Cert is a placeholder for the corresponding 271 certificate, depending on what protocol was used. The specific 272 protocols are out of scope for this document, see also 273 [AIK-Enrollment] and [IEEE802.1AR]. 275 2. Time-Based Uni-Directional Attestation 277 A Time-Based Uni-Directional Attestation (TUDA) consists of the 278 following seven information elements. They are used to gain 279 assurance of the Attestee's platform configuration at a certain point 280 in time: 282 TSA Certificate: The certificate of the Time Stamp Authority that is 283 used in a subsequent synchronization protocol token. This 284 certificate is signed by the TSA-CA. 286 AIK Certificate (, ; see ): 289 A certificate about the Attestation Identity Key (AIK) used. This 290 may or may not also be an [IEEE802.1AR] IDevID or LDevID, 291 depending on their setting of the corresponding identity property. 293 Synchronization Token: The reference for Attestations are the Tick- 294 Sessions of the TPM. In order to put Attestations into relation 295 with a Real Time Clock (RTC), it is necessary to provide a 296 cryptographic synchronization between the tick session and the 297 RTC. To do so, a synchronization protocol is run with a Time 298 Stamp Authority (TSA). 300 Restriction Info: The attestation relies on the capability of the 301 TPM to operate on restricted keys. Whenever the PCR values for 302 the machine to be attested change, a new restricted key is created 303 that can only be operated as long as the PCRs remain in their 304 current state. 306 In order to prove to the Verifier that this restricted temporary 307 key actually has these properties and also to provide the PCR 308 value that it is restricted, the TPM command TPM_CertifyInfo is 309 used. It creates a signed certificate using the AIK about the 310 newly created restricted key. 312 Measurement Log: Similarly to regular attestations, the Verifier 313 needs a way to reconstruct the PCRs' values in order to estimate 314 the trustworthiness of the device. As such, a list of those 315 elements that were extended into the PCRs is reported. Note 316 though that for certain environments, this step may be optional if 317 a list of valid PCR configurations exists and no measurement log 318 is required. 320 Implicit Attestation: The actual attestation is then based upon a 321 TPM_TickStampBlob operation using the restricted temporary key 322 that was certified in the steps above. The TPM_TickStampBlob is 323 executed and thereby provides evidence that at this point in time 324 (with respect to the TPM internal tick-session) a certain 325 configuration existed (namely the PCR values associated with the 326 restricted key). Together with the synchronization token this 327 tick-related timing can then be related to the real-time clock. 329 Concise SWID tags: As an option to better assess the trustworthiness 330 of an Attestee, a Verifier can request the reference hashes (often 331 referred to as golden measurements) of all started software 332 components to compare them with the entries in the measurement 333 log. References hashes regarding installed (and therefore 334 running) software can be provided by the manufacturer via SWID 335 tags. SWID tags are provided by the Attestee using the Concise 336 SWID representation [I-D-birkholz-sacm-coswid] and bundled into a 337 CBOR array. Ideally, the reference hashes include a signature 338 created by the manufacturer of the software. 340 These information elements could be sent en bloc, but it is 341 recommended to retrieve them separately to save bandwidth, since 342 these elements have different update cycles. In most cases, 343 retransmitting all seven information elements would result in 344 unnecessary redundancy. 346 Furthermore, in some scenarios it might be feasible not to store all 347 elements on the Attestee endpoint, but instead they could be 348 retrieved from another location or pre-deployed to the Verifier. It 349 is also feasible to only store public keys at the Verifier and skip 350 the whole certificate provisioning completely in order to save 351 bandwidth and computation time for certificate verification. 353 2.1. TUDA Information Elements Update Cycles 355 An endpoint can be in various states and have various information 356 associated with it during its life cycle. For TUDA, a subset of the 357 states (which can include associated information) that an endpoint 358 and its TPM can be in, is important to the attestation process. 360 o Some states are persistent, even after reboot. This includes 361 certificates that are associated with the endpoint itself or with 362 services it relies on. 364 o Some states are more volatile and change at the beginning of each 365 boot cycle. This includes the TPM-internal Tick-Session which 366 provides the basis for the synchronization token and implicit 367 attestation. 369 o Some states are even more volatile and change during an uptime 370 cycle (the period of time an endpoint is powered on, starting with 371 its boot). This includes the content of PCRs of a TPM and thereby 372 also the PCR-restricted keys used during attestation. 374 Depending on this "lifetime of state", data has to be transported 375 over the wire, or not. E.g. information that does not change due to 376 a reboot typically has to be transported only once between the 377 Attestee and the Verifier. 379 There are three kinds of events that require a renewed attestation: 381 o The Attestee completes a boot-cycle 383 o A relevant PCR changes 384 o Too much time has passed since the last attestation statement 386 The third event listed above is variable per application use case and 387 can therefore be set appropriately. For usage scenarios, in which 388 the device would periodically push information to be used in an 389 audit-log, a time-frame of approximately one update per minute should 390 be sufficient in most cases. For those usage scenarios, where 391 verifiers request (pull) a fresh attestation statement, an 392 implementation could use the TPM continuously to always present the 393 most freshly created results. To save some utilization of the TPM 394 for other purposes, however, a time-frame of once per ten seconds is 395 recommended, which would leave 80% of utilization for applications. 397 Attestee Verifier 398 | | 399 Boot | 400 | | 401 Create Sync-Token | 402 | | 403 Create Restricted Key | 404 Certify Restricted Key | 405 | | 406 | AIK-Cert ---------------------------------------------> | 407 | Sync-Token -------------------------------------------> | 408 | Certify-Info -----------------------------------------> | 409 | Measurement Log --------------------------------------> | 410 | Attestation ------------------------------------------> | 411 | Verify Attestation 412 | | 413 |