idnits 2.17.1 draft-birkholz-rats-network-device-subscription-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 296 has weird spacing: '...e-value bin...' == Line 393 has weird spacing: '...-number uin...' == Line 504 has weird spacing: '...r-index pcr...' -- The document date (October 06, 2020) is 1297 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) == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-06 ** Downref: Normative reference to an Informational draft: draft-ietf-rats-architecture (ref. 'I-D.ietf-rats-architecture') == Outdated reference: A later version (-14) exists of draft-ietf-rats-tpm-based-network-device-attest-04 ** Downref: Normative reference to an Informational draft: draft-ietf-rats-tpm-based-network-device-attest (ref. 'I-D.ietf-rats-tpm-based-network-device-attest') == Outdated reference: A later version (-22) exists of draft-ietf-rats-yang-tpm-charra-03 == Outdated reference: A later version (-07) exists of draft-birkholz-rats-tuda-03 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). 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 E. Voit 5 Expires: April 9, 2021 Cisco 6 W. Pan 7 Huawei 8 October 06, 2020 10 Attestation Event Stream Subscription 11 draft-birkholz-rats-network-device-subscription-01 13 Abstract 15 This document defines how to subscribe to an Event Stream of 16 attestation related Evidence on TPM-based network devices. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 9, 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 55 3. Operational Model . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Sequence Diagram . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Continuously Verifying Freshness . . . . . . . . . . . . 5 58 3.2.1. TPM 1.2 Quote . . . . . . . . . . . . . . . . . . . . 5 59 3.2.2. TPM 2 Quote . . . . . . . . . . . . . . . . . . . . . 5 60 4. Remote Attestation Event Stream . . . . . . . . . . . . . . . 6 61 4.1. Subscription to the Event Stream . . . . . 7 62 4.2. Replaying a history of previous TPM extend operations . . 7 63 4.2.1. TPM2 Heartbeat . . . . . . . . . . . . . . . . . . . 8 64 4.3. YANG notifications placed on the Event 65 Stream . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.3.1. pcr-extend . . . . . . . . . . . . . . . . . . . . . 8 67 4.3.2. tpm12-attestation . . . . . . . . . . . . . . . . . . 10 68 4.3.3. tpm20-attestation . . . . . . . . . . . . . . . . . . 11 69 4.4. Filtering Evidence at the Attester . . . . . . . . . . . 11 70 4.5. Replaying previous PCR Extend events . . . . . . . . . . 12 71 4.6. Configuring the Event Stream . . . . . . . 12 72 5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 77 8.2. Informative References . . . . . . . . . . . . . . . . . 21 78 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 79 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 82 1. Introduction 84 [I-D.ietf-rats-tpm-based-network-device-attest] and 85 [I-D.ietf-rats-yang-tpm-charra] define the operational prerequisites 86 and a YANG Model for the acquisition of Evidence from a TPM-based 87 network device. However there is a limitation inherant in the 88 challenge-response interaction models upon which these documents are 89 based. This limitation is that it is up to the Verifier to request 90 Evidence. The result is that the interval between the occurrence of 91 a security event, and the event's visibility within the Relying Party 92 can be unacceptably long. 94 This limitation results in two adverse effects: 96 1. Evidence is not streamed to an interested Verifier as soon as it 97 is generated. 99 2. If it were to be streamed, the Evidence is not appraisable for 100 freshness. 102 This specification addresses the first adverse effect by enabling a 103 Verifier to subscribe via [RFC8639] to an Event Stream 104 which exists upon the Attester. When subscribed, the Attester will 105 continuously stream a requested set of Evidence to the Verifier. 107 The second adverse effect results from the nonce based challenge- 108 response of [I-D.ietf-rats-yang-tpm-charra]. In that document an 109 Attester must wait for a new nonce from a Verifier before it 110 generates a new TPM Quote. To address delays resulting from such a 111 wait, this specification enables freshness to be asserted 112 asynchronously. 114 By removing these two adverse effects, it becomes possible for a 115 Verifier to continously maintain an appraisal of the Attested device 116 without relying on continous polling. 118 2. Terminology 120 The following terms are imported from [I-D.ietf-rats-architecture]: 121 Attester, Evidence, Relying Party, and Verifier. Also imported are 122 the time definitions time(VG), time(NS), time(EG), time(RG), and 123 time(RA) from that document's Appendix A. The following terms at 124 imported from [RFC8639]: Event Stream, Subscription, Event Stream 125 Filter, Dynamic Subscription. 127 2.1. Requirements Notation 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in 132 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 3. Operational Model 137 3.1. Sequence Diagram 139 Figure 1 below is a sequence diagram which updates Figure 5 of 140 [I-D.ietf-rats-tpm-based-network-device-attest]. This sequence 141 diagram replaces the [I-D.ietf-rats-tpm-based-network-device-attest] 142 challenge-response interaction model with an [RFC8639] Dynamic 143 Subscription to an Event Stream. The contents of the 144 Event Stream are defined below within Section 4. 146 .----------. .--------------------------. 147 | Attester | | Relying Party / Verifier | 148 '----------' '--------------------------' 149 time(VG) | 150 |<---------establish-subscription()--time(NS) 151 | | 152 time(EG) | 153 |--filter()---------------------------->| 154 |-- or ------>| 155 | | 156 | verify time(EG) Evidence @ time(RG,RA) 157 | | 158 ~ ~ 159 time(VG',EG') | 160 |--filter()---------------------------->| 161 |-- or ------>| 162 | | 163 | verify time(EG') Evidence @ time(RG',RA') 165 Figure 1: YANG Subscription Model for Remote Attestation 167 o time(VG,RG,RA) are identical to the corresponding times from 168 Figure 5 of [I-D.ietf-rats-tpm-based-network-device-attest]. 170 o time(RG',RA') are subsequent instances of the corresponding times 171 from Figure 5 of [I-D.ietf-rats-tpm-based-network-device-attest]. 173 o time(NS): The Verifier generates a nonce and makes an [RFC8639] 174 request. This request also includes the 175 augmentations defined in this document's YANG model. Key 176 subscription RPC parameters include: 178 * the nonce 180 * a set of PCRs of interest which the Verifier wants to appraise 182 * an optional filter which can reduce the logged events on the 183 stream pushed to the Verifier. 185 o time(EG) - An initial response of Evidence is returned to the 186 Verifier. This includes: 188 * A replay of filtered log entries which have extended into a PCR 189 of interest since boot are sent in the 190 notification. 192 * A signed TPM quote that contains at least the PCRs from the 193 RPC are included in a 194 or ). This quote must 195 have included the nonce provided at time(NS). 197 o time(VG',EG') - This occurs when a PCR is extended subsequent to 198 time(EG). Immediately after the extension, the following 199 information needs to be pushed to the Verifier: 201 * Any values extended into a PCR of interest, and 203 * a signed TPM Quote showing the result the PCR extension. 205 3.2. Continuously Verifying Freshness 207 As there is no new Verifier nonce provided at time(EG'), it is 208 important to validate the freshness of TPM Quotes which are delivered 209 at that time. The method of doing this verification will vary based 210 on the capabilities of the TPM cryptoprocessor used. 212 3.2.1. TPM 1.2 Quote 214 The [RFC8639] notification format includes the object. 215 This can be used to determine the amount of time subsequent to the 216 initial subscription each notification was sent. However this time 217 is not part of the signed results which are returned from the Quote, 218 and therefore is not trustworthy as objects returned in the Quote. 219 Therefore a Verifier MUST periodically issue a new nonce, and receive 220 this nonce within a TPM quote response in order to ensure the 221 freshness of the results. This can be done using the RPC from 223 [I-D.ietf-rats-yang-tpm-charra]. 225 3.2.2. TPM 2 Quote 227 When the Attester includes a TPM2 compliant cryptoprocessor, internal 228 time-related counters are included within the signed TPM Quote. By 229 including a initial nonce in the [RFC8639] subscription request, 230 fresh values for these counters are pushed as part of the first TPM 231 Quote returned to the Verifier. And then as shown by 232 [I-D.birkholz-rats-tuda], subsequent TPM Quotes delivered to the 233 Verifier can the be appraised for freshness based on the predictable 234 incrementing of these time-related countersr. 236 The relevant internal time-related counters defined within [TPM2.0] 237 can be seen within . These counters include the 238 , , and objects. The rules 239 for appraising these objects are as follows: 241 o If the has incremented for no more than the same duration 242 as both the and the Verifier's internal time since the 243 initial time(EG) and any previous time(EG'), then the TPM Quote 244 may be considered fresh. Note that [TPM2.0] allows for +/- 15% 245 clock drift. However many chips significantly improve on this 246 maximum drift. If available, chip specific maximum drifts SHOULD 247 be considered during the appraisal process. 249 o If the , has incremented. The 250 existing subscription MUST be terminated, and a new SHOULD be generated. 253 o If a TPM Quote on any subscribed PCR has not been pushed to the 254 Verifier for a duration of an Attester defined heartbeat interval, 255 then a new TPM Quote notification should be sent to the Verifier. 256 This may often be the case, as certain PCRs might be infrequently 257 updated. 259 .----------. .--------------------------. 260 | Attester | | Relying Party / Verifier | 261 '----------' '--------------------------' 262 time(VG',EG') | 263 |------------------------------->| 264 | : | 265 ~ Heartbeat interval ~ 266 | : | 267 time(EG') : | 268 |------------------------------->| 269 | | 271 4. Remote Attestation Event Stream 273 The Event Stream is an [RFC8639] complaint Event Stream 274 which is defined within this section and within the YANG Module of 275 [I-D.ietf-rats-yang-tpm-charra]. This Event Stream contains YANG 276 notifications which carry Evidence which assists a Verifier in 277 appraising the Trustworthiness Level of an Attester. Data Nodes 278 within Section 4.6 allow the configuration of this Event Stream's 279 contents on an Attester. 281 This Event Stream may only be exposed on Attesters 282 supporting [I-D.ietf-rats-tpm-based-network-device-attest]. As with 283 [I-D.ietf-rats-tpm-based-network-device-attest], it is up to the 284 Verifier to understand which types of cryptoprocessors and keys are 285 acceptable. 287 4.1. Subscription to the Event Stream 289 To establish a subscription to an Attester in a way which provides 290 provably fresh Evidence, initial randomness must be provided to the 291 Attester. This is done via the augmentation of a into 292 [RFC8639] the RPC. Additionally, a Verifier 293 must ask for PCRs of interest from a platform. 295 augment /sn:establish-subscription/sn:input: 296 +---w nonce-value binary 297 +---w pcr-index* tpm:pcr 299 The result of the subscription will be that passing of the following 300 information: 302 1. and notifications which 303 include the provided . These attestation 304 notifications MUST at least include all the 305 requested in the RPC. 307 2. a series of notifications which reference the 308 requested PCRs on all TPM based cryptoprocessors on the Attester. 310 3. and notifications 311 generated within a few seconds of the notifications. 312 These attestation notifications MUST at least include any PCRs 313 extended. 315 If the Verifier does not want to see the logged extend operations for 316 all PCRs available from an Attester, an Event Stream Filter should be 317 applied. This filter will remove Evidence from any PCRs which are 318 not interesting to the Verifier. 320 4.2. Replaying a history of previous TPM extend operations 322 Unless it is relying on Known Good Values, a Verifier will need to 323 acquire a history of PCR extensions since the Attester has been 324 booted. This history may be requested from the Attester as part of 325 the RPC. This request is accomplished by 326 placing a very old within the original RPC 327 request. As the very old will pre-date the time 328 of Attester boot, a will be returned in 329 the RPC response, indicating when the 330 Attester booted. Immediately following the response (and before the 331 notifications above) one or more notifications which 332 document all extend operations which have occurred for the requested 333 PCRs since boot will be sent. Many extend operations to a single PCR 334 index on a single TPM SHOULD be included within a single 335 notification. 337 Note that if a Verifier has a partial history of extensions, the 338 can be adjusted so that known extensions are not 339 forwarded. 341 The end of this history replay will be indicated with the [RFC8639] 342 notification. For more on this sequence, see 343 Section 2.4.2.1 of [RFC8639]. 345 After the notification is provided, a TPM Quote 346 will be requested and the result passed to the Verifier via a 347 and notification. If there 348 have been any additional extend operations which have changed a 349 subscribed PCR value in this quote, these MUST be pushed to the 350 Verifier before the and 351 notification. 353 At this point the Verifier has sufficient Evidence appraise the 354 reported extend operations for each PCR, as well compare the expected 355 value of the PCR value against that signed by the TPM. 357 4.2.1. TPM2 Heartbeat 359 For TPM2, make sure that every requested PCR is sent within an 360 no less frequently than once per heartbeat 361 interval. This MAY be done with a single 362 notification that includes all requested PCRs every heartbeat 363 interval. This MAY be done with several 364 notifications at different times during that heartbeat interval. 366 4.3. YANG notifications placed on the Event Stream 368 4.3.1. pcr-extend 370 This notification documents when a subscribed PCR is extended within 371 a single TPM cryptoprocessor. It SHOULD be emmitted no less than the 372 after an the PCR is first extended. (The reason 373 for the marshalling is that it is quite possible that multiple 374 extensions to the same PCR have been made in quick succession, and 375 these should be reflected in the same notification.) This 376 notification MUST be emmitted prior to a or 377 notification which has included and signed the 378 results of any specific PCR extension. If pcr extending events occur 379 during the generation of the or 380 notification, the marshalling period MUST be 381 extended so that a new is not sent until the 382 corresponding notifications have been sent. 384 +---n tpm-extend 385 +--ro certificate-name? certificate-name-ref 386 +--ro pcr-index-changed* tpm:pcr 387 +--ro attested-event* [] 388 +--ro attested-event 389 +--ro extended-with binary 390 +--ro (event-details)? 391 +--:(bios-event-log) 392 | +--ro bios-event-entry* [event-number] 393 | +--ro event-number uint32 394 | +--ro event-type? uint32 395 | +--ro pcr-index? pcr 396 | +--ro digest-list* [] 397 | | +--ro hash-algo? identityref 398 | | +--ro digest* binary 399 | +--ro event-size? uint32 400 | +--ro event-data* uint8 401 +--:(ima-event-log) 402 | +--ro ima-event-entry* [event-number] 403 | +--ro event-number uint64 404 | +--ro ima-template? string 405 | +--ro filename-hint? string 406 | +--ro filedata-hash? binary 407 | +--ro filedata-hash-algorithm? string 408 | +--ro template-hash-algorithm? string 409 | +--ro template-hash? binary 410 | +--ro pcr-index? pcr 411 | +--ro signature? binary 412 +--:(netequip-boot) 413 +--ro boot-event-entry* [event-number] 414 +--ro event-number uint64 415 +--ro filename-hint? string 416 +--ro filedata-hash? binary 417 +--ro filedata-hash-algorithm? string 418 +--ro file-version? string 419 +--ro file-type? string 420 +--ro pcr-index? pcr 422 Each MUST include one or more values being extended into 423 the PCR. These are passed within the object. For 424 each extension, details of the event SHOULD be provided within the 425 object. 426 The format of any included is identified by the 427 . This document includes two YANG structures which may 428 be inserted into the . These two structures are: 430 . Implementations wanting to 431 provide additional documentation of a type of PCR extension may 432 choose to define additional YANG structures which can be placed into 433 . 435 4.3.2. tpm12-attestation 437 This notification contains an instance of a TPM1.2 style signed 438 cryptoprocessor measurement. It is supplemented by Attester 439 information which is not signed. This notification is generated and 440 emitted from an Attester when at least one PCR identified within the 441 subscribed has changed from the previous 442 notification. This notification MUST NOT include 443 the results of any PCR extensions not previously reported by a . This notification SHOULD be emitted as soon as a TPM Quote 445 can extract the latest PCR hashed values. This notification MUST be 446 emitted prior to a subsequent . 448 +---n tpm12-attestation {taa:TPM12}? 449 +--ro certificate-name? certificate-name-ref 450 +--ro up-time? uint32 451 +--ro node-id? string 452 +--ro node-physical-index? int32 {ietfhw:entity-mib}? 453 +--ro fixed? binary 454 +--ro external-data? binary 455 +--ro signature-size? uint32 456 +--ro signature? binary 457 +--ro (tpm12-quote) 458 +--:(tpm12-quote1) 459 | +--ro version* [] 460 | | +--ro major? uint8 461 | | +--ro minor? uint8 462 | | +--ro revMajor? uint8 463 | | +--ro revMinor? uint8 464 | +--ro digest-value? binary 465 | +--ro TPM_PCR_COMPOSITE* [] 466 | +--ro pcr-index* pcr 467 | +--ro value-size? uint32 468 | +--ro tpm12-pcr-value* binary 469 +--:(tpm12-quote2) 470 +--ro tag? uint8 471 +--ro pcr-index* pcr 472 +--ro locality-at-release? uint8 473 +--ro digest-at-release? binary 475 All YANG objects above are defined within 476 [I-D.ietf-rats-yang-tpm-charra]. The is not 477 replayable. 479 4.3.3. tpm20-attestation 481 This notification contains an instance of TPM2 style signed 482 cryptoprocessor measurements. It is supplemented by Attester 483 information which is not signed. This notification is generated at 484 two points in time: 486 o every time at least one PCR has changed from a previous 487 tpm20-attestation. In this case, the notification SHOULD be 488 emitted within 10 seconds of the corresponding being 489 sent: 491 o after a locally configurable minimum heartbeat period since a 492 previous tpm20-attestation was sent. 494 +---n tpm20-attestation {taa:TPM20}? 495 +--ro certificate-name? certificate-name-ref 496 +--ro TPMS_QUOTE_INFO binary 497 +--ro quote-signature? binary 498 +--ro up-time? uint32 499 +--ro node-id? string 500 +--ro node-physical-index? int32 {ietfhw:entity-mib}? 501 +--ro unsigned-pcr-values* [] 502 +--ro TPM20-hash-algo? identityref 503 +--ro pcr-values* [pcr-index] 504 +--ro pcr-index pcr 505 +--ro pcr-value? binary 507 All YANG objects above are defined within 508 [I-D.ietf-rats-yang-tpm-charra]. The is not 509 replayable. 511 4.4. Filtering Evidence at the Attester 513 It can be useful _not_ to receive all Evidence related to a PCR. An 514 example of this is would be a when a Verifier maintains known good 515 values of a PCR. In this case, it is not necessary to send each 516 extend operation. 518 To accomplish this reduction, when an RFC8639 RPC is sent, a as per RFC8639, 520 Section 2.2 can be set to discard a notification when 521 the is uninteresting to the verifier. 523 4.5. Replaying previous PCR Extend events 525 To verify the value of a PCR, a Verifier must either know that the 526 value is a known good value [KGV] or be able to reconstruct the hash 527 value by viewing all the PCR-Extends since the Attester rebooted. 528 Wherever a hash reconstruction might be needed, the 529 Event Stream MUST support the RFC8639 feature. Through the 530 feature, it is possible for a Verifier to retrieve and 531 sequentially hash all of the PCR extending events since an Attester 532 booted. And thus, the Verifier has access to all the evidence needed 533 to verify a PCR's current value. 535 4.6. Configuring the Event Stream 537 Figure 2 is tree diagram which exposes the operator configurable 538 elements of the Event Stream. This allows an Attester 539 to select what information should be available on the stream. A 540 fetch operation also allows an external device such as a Verifier to 541 understand the current configuration of stream. 543 Almost all YANG objects below are defined via reference from 544 [I-D.ietf-rats-yang-tpm-charra]. There is one object which is new 545 with this model however. defines the maximum amount 546 of time which should pass before a subscriber to the Event Stream 547 should get a notification from devices which 548 contain a TPM2. 550 +--ro rats-support-structures 551 +--ro tpms* [tpm-name] 552 | +--ro tpms:leafref-to-keystore? string 553 | +--ro (tpms:subscribable)? 554 | +--:(tpms:tpm12-stream) {tpm:TPM12}? 555 | | +--ro tpms:pcr-index* pcr 556 | +--:(tpms:tpm20-stream) {tpm:TPM20}? 557 | +--ro tpms:pcr-list* [] 558 | +--ro tpms:pcr 559 | +--ro tpms:pcr-index* pcr 560 | +--ro (tpms:algo-registry-type) 561 | +--:(tpms:tcg) 562 | | +--ro tpms:tcg-hash-algo-id? uint16 563 | +--:(tpms:ietf) 564 | +--ro tpms:ietf-ni-hash-algo-id? uint8 565 +--ro tpms:marshalling-period? uint8 566 +--ro tpms:TPM_SIG_SCHEME-value? enumeration {tpm:TPM12}? 567 +--ro (tpms:signature-identifier-type) {tpm:TPM20}? 568 | +--:(tpms:TPM_ALG_ID) 569 | | +--ro tpms:TPM_ALG_ID-value? enumeration 570 | +--:(tpms:COSE_Algorithm) 571 | +--ro tpms:COSE_Algorithm-value? int32 572 +--ro tpms:tpm20-heartbeat? uint8 574 Figure 2: Configuring the \ Event Stream 576 5. YANG Module 578 This YANG module imports modules from [I-D.ietf-rats-yang-tpm-charra] 579 and [RFC8639]. It is also work-in-progress. 581 ietf-rats-attestation-stream@2020-09-17.yang 582 module ietf-tpm-remote-attestation-stream { 583 yang-version 1.1; 584 namespace 585 "urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation-stream"; 586 prefix tras; 588 import ietf-subscribed-notifications { 589 prefix sn; 590 reference 591 "RFC 8639: Subscription to YANG Notifications"; 592 } 593 import ietf-tpm-remote-attestation { 594 prefix tpm; 595 reference 596 "draft-ietf-rats-yang-tpm-charra"; 597 } 598 import ietf-tcg-algs { 599 prefix taa; 600 } 602 organization "IETF"; 603 contact 604 "WG Web: 605 WG List: 607 Editor: Eric Voit 608 "; 610 description 611 "This module contains conceptual YANG specifications for 612 subscribing to attestation streams being generated from TPM chips. 614 Copyright (c) 2020 IETF Trust and the persons identified 615 as authors of the code. All rights reserved. 617 Redistribution and use in source and binary forms, with 618 or without modification, is permitted pursuant to, and 619 subject to the license terms contained in, the Simplified 620 BSD License set forth in Section 4.c of the IETF Trust's 621 Legal Provisions Relating to IETF Documents 622 (https://trustee.ietf.org/license-info). 624 Redistribution and use in source and binary forms, with or 625 without modification, is permitted pursuant to, and subject to 626 the license terms contained in, the Simplified BSD License set 627 forth in Section 4.c of the IETF Trust's Legal Provisions 628 Relating to IETF Documents 629 (https://trustee.ietf.org/license-info). 631 This version of this YANG module is part of RFC XXXX 632 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 633 itself for full legal notices. 635 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 636 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 637 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 638 are to be interpreted as described in BCP 14 (RFC 2119) 639 (RFC 8174) when, and only when, they appear in all 640 capitals, as shown here."; 642 revision 2020-09-17 { 643 description 644 "Initial version."; 645 reference 646 "draft-birkholz-rats-network-device-subscription"; 647 } 649 /* 650 * IDENTITIES 651 */ 653 identity pcr-unsubscribable { 654 base sn:establish-subscription-error; 655 description 656 "Requested PCR is subscribable by the Attester."; 657 } 659 /* 660 * Groupings 661 */ 663 grouping heartbeat { 664 description 665 "Allows an Attester to push verifiable, current TPM PCR values 666 even when there have been no recent changes to PCRs."; 667 leaf tpm20-subscription-heartbeat { 668 type uint16; 669 description 670 "Number of seconds before the Attestation stream should send a 671 new notification with a fresh quote. This allows confirmation 672 that the PCR values haven't changed since the last 673 tpm20-attestation."; 674 } 675 } 677 /* 678 * RPCs 679 */ 681 augment "/sn:establish-subscription/sn:input" { 682 when 'derived-from-or-self(sn:stream, "attestation")'; 683 description 684 "This augmentation adds a nonce to as a subscription parameters 685 that apply specifically to datastore updates to RPC input."; 686 uses tpm:nonce; 687 leaf-list pcr-index { 688 type tpm:pcr; 689 min-elements 1; 690 description 691 "The numbers/indexes of the PCRs. This will act as a filter for 692 the subscription so that 'tpm-extend' notifications related to 693 non-requested PCRs will not be sent to a subscriber."; 694 } 695 } 697 /* 698 * NOTIFICATIONS 699 */ 701 notification pcr-extend { 702 description 703 "This notification indicates that one or more PCRs have been 704 extended within a TPM based cryptoprocessor. In less than the 705 'marshalling-period', it MUST be followed with either a 706 corresponding tpm12-attestation or tpm20-attestation notification 707 which exposes the result of the PCRs updated."; 708 uses tpm:certificate-name-ref; 709 leaf-list pcr-index-changed { 710 type tpm:pcr; 711 min-elements 1; 712 description 713 "The number of each PCR extended. This list MUST contain the 714 set of PCRs descibed within the event log details. This leaf 715 can be derived from the list of attested events, but exposing 716 it here allows for easy filtering of the notifications of 717 interest to a verifier."; 718 } 719 list attested-event { 720 description 721 "A set of events which extended an Attester PCR. The sequence 722 of elements represented in list must match the sequence of 723 events placed into the TPM's PCR."; 724 container attested-event { 725 description 726 "An instance of an event which extended an Attester PCR"; 727 leaf extended-with { 728 type binary; 729 mandatory true; 730 description 731 "Information extending the PCR."; 732 } 733 choice event-details { 734 description 735 "Contains the event happened the Attester thought 736 was worthy of recording in a PCR. 738 choices are of types defined by the identityref 739 base tpm:attested_event_log_type"; 741 case bios-event-log { 742 description 743 "BIOS/UEFI event log format"; 744 uses tpm:bios-event-log; 745 } 746 case ima-event-log { 747 description 748 "IMA event log format"; 749 uses tpm:ima-event-log; 750 } 751 case netequip-boot-event-log { 752 description 753 "IMA event log format"; 754 uses tpm:network-equipment-boot-event-log; 755 } 756 } 757 } 758 } 759 } 761 notification tpm12-attestation { 762 if-feature "taa:TPM12"; 763 description 764 "Contains an instance of TPM1.2 style signed cryptoprocessor 765 measurements. It is supplemented by unsigned Attester 766 information."; 767 uses tpm:certificate-name-ref { 768 description 769 "Certificate associated with this tpm20-attestation."; 770 } 771 uses tpm:tpm12-attestation; 772 } 774 notification tpm20-attestation { 775 if-feature "taa:TPM20"; 776 description 777 "Contains an instance of TPM2 style signed cryptoprocessor 778 measurements. It is supplemented by unsigned Attester 779 information."; 780 uses tpm:certificate-name-ref { 781 description 782 "Certificate associated with this tpm20-attestation."; 783 } 784 uses tpm:tpm20-attestation; 785 } 787 /* 788 * DATA NODES 789 */ 791 augment "/tpm:rats-support-structures" { 792 description 793 "Defines platform wide 'attestation' stream subscription 794 parameters."; 795 leaf marshalling-period { 796 config true; 797 type uint8; 798 default 5; 799 description 800 "The maximum number of seconds between the time an event 801 extends a PCR, and the 'tpm-extend' notification which reports 802 it to a subscribed Verifier. This period allows multiple 803 extend operations bundled together and handled as a group."; 804 } 805 leaf tpm12-subscribed-signature-scheme { 806 if-feature "taa:TPM12"; 807 type leafref { 808 path "../tpm:attester-supported-algos" + 809 "/tpm:tpm12-asymmetric-signing"; 810 } 811 description 812 "A single signature-scheme which will be used to sign the 813 evidence from a TPM 1.2. which is then placed onto the 814 'attestation' event stream."; 815 } 816 leaf tpm20-subscribed-signature-scheme { 817 if-feature "taa:TPM20"; 818 type leafref { 819 path "../tpm:attester-supported-algos" + 820 "/tpm:tpm20-asymmetric-signing"; 821 } 822 description 823 "A single signature-scheme which will be used to sign the 824 evidence from a TPM 2.0. which is then placed onto the 825 'attestation' event stream."; 826 } 827 uses heartbeat{ 828 if-feature "taa:TPM20"; 829 } 830 } 832 augment "/tpm:rats-support-structures/tpm:tpms" { 833 description 834 "Allows the configuration 'attestation' stream parameters for a 835 TPM."; 837 leaf subscription-aik { 838 config true; 839 type tpm:certificate-name-ref; 840 description 841 "Identifies the certificate-name associated with the 842 notifications in the 'attestation' stream."; 843 } 844 choice subscribable { 845 config true; 846 description 847 "Indicates that the set of notifications which comprise the 848 'attestation' event stream can be modified or tuned by a 849 network administrator."; 850 case tpm12-stream { 851 if-feature "taa:TPM12"; 852 description 853 "Configuration elements for a TPM1.2 event stream."; 854 uses tpm:TPM12-hash-algo; 855 leaf-list tpm12-pcr-index { 856 type tpm:pcr; 857 description 858 "The numbers/indexes of the PCRs which can be subscribed."; 859 } 860 } 861 case tpm20-stream { 862 if-feature "taa:TPM20"; 863 description 864 "Configuration elements for a TPM2.0 event stream."; 865 uses tpm:TPM20-hash-algo; 866 leaf-list tpm20-pcr-index { 867 type tpm:pcr; 868 description 869 "The numbers/indexes of the PCRs which can be subscribed."; 870 } 871 } 872 } 873 } 874 } 875 877 6. Security Considerations 879 To be written. 881 7. IANA Considerations 883 To be written. 885 8. References 887 8.1. Normative References 889 [I-D.ietf-rats-architecture] 890 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 891 W. Pan, "Remote Attestation Procedures Architecture", 892 draft-ietf-rats-architecture-06 (work in progress), 893 September 2020. 895 [I-D.ietf-rats-tpm-based-network-device-attest] 896 Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- 897 based Network Device Remote Integrity Verification", 898 draft-ietf-rats-tpm-based-network-device-attest-04 (work 899 in progress), September 2020. 901 [I-D.ietf-rats-yang-tpm-charra] 902 Birkholz, H., Eckel, M., Voit, E., Bhandari, S., Sulzen, 903 B., Xia, L., Laffey, T., and G. Fedorkow, "A YANG Data 904 Model for Challenge-Response-based Remote Attestation 905 Procedures using TPMs", draft-ietf-rats-yang-tpm-charra-03 906 (work in progress), September 2020. 908 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 909 Requirement Levels", BCP 14, RFC 2119, 910 DOI 10.17487/RFC2119, March 1997, 911 . 913 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 914 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 915 May 2017, . 917 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 918 E., and A. Tripathy, "Subscription to YANG Notifications", 919 RFC 8639, DOI 10.17487/RFC8639, September 2019, 920 . 922 [TPM2.0] TCG, "TPM 2.0 Library Specification", n.d., 923 . 926 8.2. Informative References 928 [I-D.birkholz-rats-tuda] 929 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 930 "Time-Based Uni-Directional Attestation", draft-birkholz- 931 rats-tuda-03 (work in progress), July 2020. 933 [KGV] TCG, "KGV", October 2003, 934 . 937 Appendix A. Change Log 939 v00-v01 941 o rename notification: pcr-extended, which supports multiple PCRs 943 o netequip boot added 945 o YANG structure extension removed 947 o Matched to structural changes made within charra 949 Acknowledgements 951 Thanks to ... 953 Authors' Addresses 955 Henk Birkholz 956 Fraunhofer SIT 957 Rheinstrasse 75 958 Darmstadt 64295 959 Germany 961 Email: henk.birkholz@sit.fraunhofer.de 963 Eric Voit 964 Cisco Systems, Inc. 966 Email: evoit@cisco.com 967 Wei Pan 968 Huawei Technologies 969 101 Software Avenue, Yuhuatai District 970 Nanjing, Jiangsu 210012 971 China 973 Email: william.panwei@huawei.com