idnits 2.17.1 draft-birkholz-rats-network-device-subscription-00.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 are 20 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 295 has weird spacing: '...e-value bin...' == Line 380 has weird spacing: '...changed tpm...' == Line 383 has weird spacing: '...ed-with bin...' == Line 477 has weird spacing: '...r-index pcr...' -- The document date (June 24, 2020) is 1395 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-04 ** Downref: Normative reference to an Informational draft: draft-ietf-rats-architecture (ref. 'I-D.ietf-rats-architecture') -- Possible downref: Non-RFC (?) normative reference: ref. 'RATS-Device' -- Possible downref: Non-RFC (?) normative reference: ref. 'RATS-YANG' == Outdated reference: A later version (-07) exists of draft-birkholz-rats-tuda-02 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Standards Track E. Voit 5 Expires: December 26, 2020 Cisco 6 W. Pan 7 Huawei 8 June 24, 2020 10 Attestation Event Stream Subscription 11 draft-birkholz-rats-network-device-subscription-00 13 Abstract 15 This document defines how to subscribe to a stream of attestation 16 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 December 26, 2020. 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. tpm-extend . . . . . . . . . . . . . . . . . . . . . 8 67 4.3.2. tpm12-attestation . . . . . . . . . . . . . . . . . . 9 68 4.3.3. tpm20-attestation . . . . . . . . . . . . . . . . . . 10 69 4.4. Filtering Evidence at the Attester . . . . . . . . . . . 11 70 4.5. Replaying previous PCR Extend events . . . . . . . . . . 11 71 4.6. Configuring the Event Stream . . . . . . . 12 72 5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 77 8.2. Informative References . . . . . . . . . . . . . . . . . 19 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 79 A.1. Open Questions . . . . . . . . . . . . . . . . . . . . . 20 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 82 1. Introduction 84 [RATS-Device] and [RATS-YANG] define the operational prerequisites 85 and a YANG Model for the acquisition of Evidence from a TPM-based 86 network device. However, there is a limitation inherent in the 87 challenge-response interaction models upon which these documents are 88 based. This limitation is that it is up to the Verifier to request 89 Evidence. The result is that the interval between the occurrence of 90 a security event, and the event's visibility within the Relying Party 91 can be unacceptably long. 93 This limitation results in two adverse effects: 95 1. Evidence is not streamed to an interested Verifier as soon as it 96 is generated. 98 2. If it were to be streamed, the Evidence is not appraisable for 99 freshness. 101 This specification addresses the first adverse effect by enabling a 102 Verifier to subscribe via [RFC8639] to a YANG Event 103 Stream which exists upon the Attester. When subscribed, the Attester 104 will continuously stream a subscribed set of Evidence to the 105 Verifier. 107 The second adverse effect results from the nonce based challenge- 108 response of [RATS-YANG]. In that document, an Attester must wait for 109 a new nonce from a Verifier before it generates a new TPM Quote. In 110 this case, the nonce acts as an implicit timestamp that a windows of 111 freshness is tied to. To address delays resulting from such a 112 synchronous wait for nonce based Evidence generation, this 113 specification enables freshness to be asserted in an asynchronous 114 manner. 116 By removing these two adverse effects, it becomes possible for a 117 Verifier to continuously maintain an appraisal of the Attested device 118 without relying on continuous polling. 120 2. Terminology 122 The following terms are imported from [I-D.ietf-rats-architecture]: 123 Attester, Evidence, Relying Party, and Verifier. Also imported are 124 the time definitions time(vg), time(ns), time(eg), time(rg), and 125 time(ra) from that document's appendices. The following terms at 126 imported from [RFC8639]: Event Stream, Subscription, Event Stream 127 Filter, Dynamic Subscription. 129 2.1. Requirements Notation 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in 134 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 3. Operational Model 139 3.1. Sequence Diagram 141 Figure 1 below is a sequence diagram which updates Figure 5 of 142 [RATS-Device]. This sequence diagram replaces the [RATS-Device] 143 challenge-response interaction model with an [RFC8639] Dynamic 144 Subscription to an Event Stream. The contents of the 145 Event Stream are defined below within Section 4. 147 .----------. .--------------------------. 148 | Attester | | Relying Party / Verifier | 149 '----------' '--------------------------' 150 time(vg) | 151 |<---------establish-subscription()--time(ns) 152 | | 153 time(eg) | 154 |--filter()---------------------------->| 155 |-- or ------>| 156 | | 157 | verify time(eg) Evidence @ time(rg,ra) 158 | | 159 ~ ~ 160 time(vg',eg') | 161 |--filter()---------------------------->| 162 |-- or ------>| 163 | | 164 | verify time(eg') Evidence @ time(rg',ra') 166 Figure 1: YANG Subscription Model for Remote Attestation 168 o time(vg,rg,ra) are identical to the corresponding times from 169 Figure 5 of [RATS-Device]. 171 o time(rg',ra') are subsequent instances of the corresponding times 172 from Figure 5 of [RATS-Device]. 174 o time(ns): The Verifier generates a nonce and makes an [RFC8639] 175 request. This request also includes the 176 augmentations defined in this document's YANG model. Key 177 subscription RPC parameters include: 179 * the nonce, 181 * a set of PCRs of interest which the Verifier wants to appraise, 182 and 184 * an optional filter which can reduce the logged events on the 185 stream pushed to the Verifier. 187 o time(eg) - An initial response of Evidence is returned to the 188 Verifier. This includes: 190 * a replay of filtered log entries which have extended into a PCR 191 of interest since boot are sent in the 192 notification, and a 194 * a signed TPM quote that contains at least the PCRs from the 195 RPC are included in a 196 or ). This quote must 197 have included the nonce provided at time(ns). 199 o time(vg',eg') - This occurs when a PCR is extended subsequent to 200 time(eg). Immediately after the extension, the following 201 information needs to be pushed to the Verifier: 203 * Any values extended into a PCR of interest, and 205 * a signed TPM Quote showing the result the PCR extension. 207 3.2. Continuously Verifying Freshness 209 As there is no new Verifier nonce provided at time(eg'), it is 210 important to validate the freshness of TPM Quotes which are delivered 211 at that time. The method of doing this verification will vary based 212 on the capabilities of the TPM cryptoprocessor used. 214 3.2.1. TPM 1.2 Quote 216 The [RFC8639] notification format includes the object. 217 This can be used to determine the amount of time subsequent to the 218 initial subscription each notification was sent. However, this time 219 is not part of the signed results which are returned from the Quote, 220 and therefore is not trustworthy as objects returned in the Quote. 221 Therefore, a Verifier MUST periodically issue a new nonce, and 222 receive this nonce within a TPM quote response in order to ensure the 223 freshness of the results. This can be done using the RPC from [RATS-YANG]. 226 3.2.2. TPM 2 Quote 228 When the Attester includes a TPM2 compliant cryptoprocessor, internal 229 time-related counters are included within the signed TPM Quote. By 230 including an initial nonce in the [RFC8639] subscription request, 231 fresh values for these counters are pushed as part of the first TPM 232 Quote returned to the Verifier. Then, as shown by 233 [I-D.birkholz-rats-tuda], subsequent TPM Quotes delivered to the 234 Verifier can the be appraised for freshness based on the predictable 235 incrementing of these time-related counters. 237 The relevant internal time-related counters defined within [TPM2.0] 238 can be seen within . These counters include the 239 , , and objects. Normative 240 rules for appraising these objects are as follows: 242 o If the has incremented for no more than the same duration 243 as both the and the Verifier's internal time since the 244 initial time(eg) and any previous time(eg'), then the TPM Quote 245 MAY be considered fresh. Note that [TPM2.0] allows for +/- 15% 246 clock drift. However, many chips significantly improve on this 247 maximum drift. If available, chip specific maximum drifts SHOULD 248 be considered during the appraisal process. 250 o If the , has incremented. The 251 existing subscription MUST be terminated, and a new SHOULD be generated. 254 o If a TPM Quote on any subscribed PCR has not been pushed to the 255 Verifier for a duration of an Attester defined heartbeat interval, 256 then a new TPM Quote notification SHOULD be sent to the Verifier. 257 This may often be the case, as certain PCRs might be infrequently 258 updated. 260 .----------. .--------------------------. 261 | Attester | | Relying Party / Verifier | 262 '----------' '--------------------------' 263 time(vg',eg') | 264 |------------------------------->| 265 | : | 266 ~ Heartbeat interval ~ 267 | : | 268 time(eg') : | 269 |------------------------------->| 270 | | 272 4. Remote Attestation Event Stream 274 The Event Stream is an [RFC8639] complaint Event 275 Stream which is defined within this section and within the YANG 276 Module of [RATS-YANG]. This Event Stream contains YANG notifications 277 which carry Evidence assisting a Verifier in the appraisal of an 278 Attester. Data Nodes within Section 4.6 allow the configuration of 279 this Event Stream's contents on an Attester. 281 This Event Stream may only be exposed on 282 Attesters supporting [RATS-Device]. As with [RATS-Device], it is up 283 to the Verifier to understand which types of cryptoprocessors and 284 keys are acceptable. 286 4.1. Subscription to the Event Stream 288 To establish a subscription to an Attester in a way which provides 289 provably fresh Evidence, initial randomness must be provided to the 290 Attester. This is done via the augmentation of a into 291 [RFC8639] the RPC. Additionally, a Verifier 292 must ask for PCRs of interest from a platform. 294 augment /sn:establish-subscription/sn:input: 295 +---w nonce-value binary 296 +---w pcr-index* tpm:pcr 298 The result of the subscription will be that passing of the following 299 information: 301 1. and notifications which 302 include the provided . These attestation 303 notifications MUST at least include all the 304 requested in the RPC. 306 2. a series of notifications which reference the 307 requested PCRs on all TPM based cryptoprocessors on the Attester. 309 3. and notifications 310 generated within a few seconds of the notifications. 311 These attestation notifications MUST at least include any PCRs 312 extended. 314 If the Verifier does not want to see the logged extend operations for 315 all PCRs available from an Attester, an Event Stream Filter should be 316 applied. This filter will remove Evidence from any PCRs which are 317 not interesting to the Verifier. 319 4.2. Replaying a history of previous TPM extend operations 321 Unless it is relying on Known Good Values, a Verifier will need to 322 acquire a history of PCR extensions since the Attester has been 323 booted. This history may be requested from the Attester as part of 324 the RPC. This request is accomplished by 325 placing a very old within the original RPC 326 request. As the very old will pre-date the time 327 of Attester boot, a will be returned in 328 the RPC response, indicating when the 329 Attester booted. Immediately following the response (and before the 330 notifications above) one or more notifications which 331 document all extend operations which have occurred for the requested 332 PCRs since boot will be sent. Many extend operations to a single PCR 333 index on a single TPM SHOULD be included within a single 334 notification. 336 Note that if a Verifier has a partial history of extensions, the 337 can be adjusted so that known extensions are not 338 forwarded. 340 The end of this history replay will be indicated with the [RFC8639] 341 notification. For more on this sequence, see 342 Section 2.4.2.1 of [RFC8639]. 344 After the notification is provided, a TPM Quote 345 will be requested and the result passed to the Verifier via a 346 and notification. If there 347 have been any additional extend operations which have changed a 348 subscribed PCR value in this quote, these MUST be pushed to the 349 Verifier before the and 350 notification. 352 At this point, the Verifier has sufficient Evidence to appraise the 353 reported extend operations for each PCR, as well as compare the 354 expected value of the PCR value against that signed by the TPM. 356 4.2.1. TPM2 Heartbeat 358 For TPM2, every requested PCR MUST at least be sent once within a 359 heartbeat interval. This MAY be done with a 360 single notification that includes all requested 361 PCRs every heartbeat interval. Alternatively, this MAY be done with 362 several notifications at different times during 363 that heartbeat interval. 365 4.3. YANG notifications placed on the Event Stream 367 4.3.1. tpm-extend 369 This notification documents when a single subscribed PCR is extended 370 within a single TPM cryptoprocessor. Corresponding notifications 371 SHOULD be emitted no less than a after the PCR 372 is first extended (the reason for the marshalling is that it is quite 373 possible that multiple extensions to the same PCR have been made in 374 quick succession). A notification MUST be emitted prior to a 375 or notification which has 376 included and signed the results of any specific PCR extension. 378 +---n tpm-extend 379 +--ro certificate-name? string 380 +--ro pcr-index-changed tpm:pcr 381 +--ro attested-event* [] 382 +--ro attested-event 383 +--ro extended-with binary 384 +--ro event-type? identityref 385 +--ro event-details? 387 Each MUST include one or more values being extended into 388 the PCR. These are conveyed within the object. For 389 each extension, details of the event MAY be provided within the 390 object. 392 The format of any included is identified by the 393 . This document includes two YANG structures which may 394 be inserted into the . These two structures are: 395 and . Implementations wanting to 396 provide additional documentation of a type of PCR extension may 397 choose to define additional YANG structures which can be placed into 398 . 400 4.3.2. tpm12-attestation 402 This notification type contains an instance of a TPM1.2 style signed 403 cryptoprocessor measurement. This notification is generated at two 404 points in time: 406 1. Upon initial subscription 408 2. Every time at least one subscribed PCR has changed from the 409 directly previous . In this case, the 410 notification SHOULD be emitted within a 411 since a the first subscribed PCR changed. 413 This notification MUST NOT include the returned quote digest the 414 results from any PCR extensions not previously reportable by a . 417 +---n tpm12-attestation {tpm:TPM12}? 418 +--ro certificate-name? string 419 +--ro up-time? uint32 420 +--ro node-id? string 421 +--ro node-physical-index? int32 {ietfhw:entity-mib}? 422 +--ro fixed? binary 423 +--ro external-data? binary 424 +--ro signature-size? uint32 425 +--ro signature? binary 426 +--ro (tpm12-quote) 427 +--:(tpm12-quote1) 428 | +--ro version* [] 429 | | +--ro major? uint8 430 | | +--ro minor? uint8 431 | | +--ro revMajor? uint8 432 | | +--ro revMinor? uint8 433 | +--ro digest-value? binary 434 | +--ro TPM_PCR_COMPOSITE* [] 435 | +--ro pcr-index* pcr 436 | +--ro value-size? uint32 437 | +--ro tpm12-pcr-value* binary 438 +--:(tpm12-quote2) 439 +--ro tag? uint8 440 +--ro pcr-index* pcr 441 +--ro locality-at-release? uint8 442 +--ro digest-at-release? binary 444 All YANG objects above are defined within [RATS-YANG]. The objects 445 MAY include Attester information such as which are 446 not signed. The is not replayable. 448 4.3.3. tpm20-attestation 450 This notification contains an instance of TPM2 style signed 451 cryptoprocessor measurements. This notification is generated at 452 three points in time: 454 1. Upon initial subscription 456 2. Every time at least one subscribed PCR has changed from the 457 directly previous . In this case, the 458 notification SHOULD be emitted within a 459 since a the first subscribed PCR changed. 461 3. After a minimum heartbeat interval since a previous 462 was sent. 464 This notification MUST NOT include the returned the results 465 from any PCR extensions not previously reportable by a . 467 +---n tpm20-attestation {tpm:TPM20}? 468 +--ro certificate-name? string 469 +--ro up-time? uint32 470 +--ro node-id? string 471 +--ro node-physical-index? int32 {ietfhw:entity-mib}? 472 +--ro quote? binary 473 +--ro quote-signature? binary 474 +--ro pcr-bank-values* [] 475 | +--ro TPM2_Algo? identityref 476 | +--ro pcr-values* [pcr-index] 477 | +--ro pcr-index pcr 478 | +--ro pcr-value? binary 479 +--ro pcr-digest-algo-in-quote 480 +--ro TPM2_Algo? identityref 482 All YANG objects above are defined within [RATS-YANG]. The objects 483 MAY include Attester information such as which are 484 not signed. The is not replayable. 486 4.4. Filtering Evidence at the Attester 488 It can be useful NOT to receive all Evidence related to a PCR. An 489 example of this is would be a when a Verifier maintains Known Good 490 Values of a PCR. In this case, it is not necessary to send each 491 extend operation. 493 To accomplish this reduction, when an RFC8639 RPC is sent, a as per RFC8639, 495 Section 2.2 can be set to discard a notification when 496 the is uninteresting to the verifier. 498 4.5. Replaying previous PCR Extend events 500 To verify the value of a PCR, a Verifier must either know that the 501 value is a Known Good Value [KGV] or be able to reconstruct the hash 502 value by viewing all the PCR-Extends since the Attester rebooted. 503 Wherever a hash reconstruction might be needed, the Event Stream MUST support the RFC8639 feature. 505 Through the feature, it is possible for a Verifier to 506 retrieve and sequentially hash all of the PCR extending events since 507 an Attester booted. And thus, the Verifier has access to all the 508 evidence needed to verify a PCR's current value. 510 4.6. Configuring the Event Stream 512 Figure 2 is tree diagram which exposes the operator configurable 513 elements of the Event Stream. This allows an 514 Attester to select what information should be available on the 515 stream. A fetch operation also allows an external device such as a 516 Verifier to understand the current configuration of stream. 518 Almost all YANG objects below are defined via reference from 519 [RATS-YANG]. There is one object which is new with this model 520 however. defines the maximum amount of time which 521 should pass before a subscriber to the Event Stream should get a 522 notification from devices which contain a TPM2. 524 +--rw rats-support-structures 525 +--rw rats-support-structures 526 +--rw supported-algos* identityref 527 +--rw tpms* [tpm-name] 528 | +--rw tpm-name string 529 | +--rw tras:leafref-to-keystore? string 530 | +--rw (tras:subscribable)? 531 | +--:(tras:tpm12-stream) {tpm:TPM12}? 532 | | +--rw tras:tpm12-pcr-index* tpm:pcr 533 | +--:(tras:tpm20-stream) {tpm:TPM20}? 534 | +--rw tras:tpm20-pcr-index* tpm:pcr 535 +--rw tras:marshalling-period? uint8 536 +--rw tras:tpm12-subscribed-signature-scheme? 537 | -> ../tpm:supported-algos {tpm:TPM12}? 538 +--rw tras:tpm20-subscribed-signature-scheme? 539 | -> ../tpm:supported-algos {tpm:TPM20}? 540 +--rw tras:tpm20-subscription-heartbeat? uint16 541 {tpm:TPM20}? 543 Figure 2: Configuring the Attestation Stream 545 5. YANG Module 547 This YANG module imports modules from [RATS-YANG] and [RFC8639]. It 548 is also work-in-progress. 550 ietf-tpm-remote-attestation-stream@2020-06-10.yang 551 module ietf-tpm-remote-attestation-stream { 552 yang-version 1.1; 553 namespace 554 "urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation-stream"; 555 prefix tras; 556 import ietf-subscribed-notifications { 557 prefix sn; 558 reference 559 "RFC 8639: Subscription to YANG Notifications"; 560 } 561 import ietf-tpm-remote-attestation { 562 prefix tpm; 563 reference 564 "draft-ietf-rats-yang-tpm-charra"; 565 } 566 import ietf-yang-structure-ext { 567 prefix sx; 568 reference 569 "draft-ietf-netmod-yang-data-ext"; 570 } 572 organization "IETF"; 573 contact 574 "WG Web: 575 WG List: 577 Editor: Eric Voit 578 "; 580 description 581 "This module contains conceptual YANG specifications for 582 subscribing to attestation streams being generated from TPM chips. 584 Copyright (c) 2020 IETF Trust and the persons identified 585 as authors of the code. All rights reserved. 587 Redistribution and use in source and binary forms, with 588 or without modification, is permitted pursuant to, and 589 subject to the license terms contained in, the Simplified 590 BSD License set forth in Section 4.c of the IETF Trust's 591 Legal Provisions Relating to IETF Documents 592 (https://trustee.ietf.org/license-info). 594 Redistribution and use in source and binary forms, with or 595 without modification, is permitted pursuant to, and subject to 596 the license terms contained in, the Simplified BSD License set 597 forth in Section 4.c of the IETF Trust's Legal Provisions 598 Relating to IETF Documents 599 (https://trustee.ietf.org/license-info). 601 This version of this YANG module is part of RFC XXXX 602 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 603 itself for full legal notices. 605 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 606 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 607 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 608 are to be interpreted as described in BCP 14 (RFC 2119) 609 (RFC 8174) when, and only when, they appear in all 610 capitals, as shown here."; 612 revision 2020-06-10 { 613 description 614 "Initial version."; 615 reference 616 "draft-birkholz-rats-network-device-subscription"; 617 } 619 /* 620 * IDENTITIES 621 */ 623 identity pcr-unsubscribable { 624 base sn:establish-subscription-error; 625 description 626 "Requested PCR is subscribable by the Attester."; 627 } 629 /* 630 * Groupings 631 */ 633 grouping heartbeat { 634 description 635 "Allows an Attester to push verifiable, current TPM PCR values even 636 when there have been no recent changes to PCRs."; 637 leaf tpm20-subscription-heartbeat { 638 type uint16; 639 description 640 "Number of seconds before the Attestation stream should send a new 641 notification with a fresh quote. This allows confirmation 642 that the PCR values haven't changed since the last 643 tpm20-attestation."; 644 } 645 } 647 /* 648 * RPCs 649 */ 651 augment "/sn:establish-subscription/sn:input" { 652 when 'derived-from-or-self(sn:stream, "attestation")'; 653 description 654 "This augmentation adds a nonce to as a subscription parameters 655 that apply specifically to datastore updates to RPC input."; 656 uses tpm:nonce; 657 leaf-list pcr-index { 658 type tpm:pcr; 659 min-elements 1; 660 description 661 "The numbers/indexes of the PCRs. This will act as a filter for the 662 subscription so that 'tpm-extend' notifications related to 663 non-requested PCRs will not be sent to a subscriber."; 664 } 665 } 667 /* 668 * NOTIFICATIONS 669 */ 671 notification tpm-extend { 672 description 673 "This notification indicates that a PCR has extended within a TPM based 674 cryptoprocessor. In less that 10 seconds, it should be followed with 675 either a tpm12-attestation or tpm20-attestation notification."; 676 uses tpm:certificate-name; 677 leaf pcr-index-changed { 678 type tpm:pcr; 679 mandatory true; 680 description 681 "The number of the PCR extended."; 682 } 683 list attested-event { 684 description 685 "A set of events which extended an Attester PCR. The sequence of 686 elements represented in list must match the sequence of events 687 placed into the TPM."; 688 container attested-event { 689 description 690 "An instance of an event which extended an Attester PCR"; 691 leaf extended-with { 692 type binary; 693 mandatory true; 694 description 695 "Information extending the PCR."; 696 } 697 leaf event-type { 698 type identityref { 699 base tpm:attested-event-log-type; 700 } 701 description 702 "Indicates what kind of event happened the Attester thought was 703 worthy of recording in a PCR."; 704 } 705 anydata event-details { 706 description 707 "Any structure reference 'event-type' contains supporting 708 information which allows an Attester to evaluate the trust 709 implications. 711 Event details may be populated with YANG log structures defined 712 at the bottom of this module."; 713 } 714 } 715 } 716 } 718 notification tpm12-attestation { 719 if-feature "tpm:TPM12"; 720 description 721 "Contains an instance of TPM1.2 style signed cryptoprocessor 722 measurements. It is supplemented by unsigned Attester information."; 723 uses tpm:tpm12-attestation; 724 } 726 notification tpm20-attestation { 727 if-feature "tpm:TPM20"; 728 description 729 "Contains an instance of TPM2 style signed cryptoprocessor 730 measurements. It is supplemented by unsigned Attester information."; 731 uses tpm:tpm20-attestation; 732 } 734 /* 735 * DATA NODES 736 */ 738 augment "/tpm:rats-support-structures" { 739 description 740 "Defines platform wide 'attestation' stream subscription parameters."; 741 leaf marshalling-period { 742 config true; 743 type uint8; 744 default 5; 745 description 746 "The maximum number of seconds between the time an event extends a PCR, 747 and the 'tpm-extend' notification which reports it to a subscribed 748 Verifier. This period allows multiple extend operations bundled 749 together and handled as a group."; 750 } 751 leaf tpm12-subscribed-signature-scheme { 752 if-feature "tpm:TPM12"; 753 type leafref { 754 path "../tpm:supported-algos"; 755 /* a specific algorithm, need to check syntax */ 756 } 757 description 758 "A single signature-scheme which will be used to sign the evidence 759 from a TPM 1.2. which is then placed onto the 'attestation' event 760 stream."; 761 } 762 leaf tpm20-subscribed-signature-scheme { 763 if-feature "tpm:TPM20"; 764 type leafref { 765 path "../tpm:supported-algos"; 766 /* a specific algorithm, need to check syntax */ 767 } 768 description 769 "A single signature-scheme which will be used to sign the evidence 770 from a TPM 2.0. which is then placed onto the 'attestation' event 771 stream."; 772 } 773 uses heartbeat{ 774 if-feature "tpm:TPM20"; 775 } 776 } 778 augment "/tpm:rats-support-structures/tpm:tpms" { 779 description 780 "Allows the configuration 'attestation' stream parameters for a TPM."; 781 leaf leafref-to-keystore { 782 config true; 783 type string; 784 description 785 "needs to be replaced with Reference to keystore draft."; 786 } 787 choice subscribable { 788 config true; 789 description 790 "Indicates that the set of notifications which comprise the attestation 791 stream can be modified or tuned by a network administrator."; 792 case tpm12-stream { 793 if-feature "tpm:TPM12"; 794 description 795 "Configuration elements for a TPM1.2 event stream."; 796 leaf-list tpm12-pcr-index { 797 type tpm:pcr; 798 description 799 "The numbers/indexes of the PCRs which can be subscribed."; 800 } 801 } 802 case tpm20-stream { 803 if-feature "tpm:TPM20"; 804 description 805 "Configuration elements for a TPM2.0 event stream."; 806 leaf-list tpm20-pcr-index { 807 type tpm:pcr; 808 description 809 "The numbers/indexes of the PCRs which can be subscribed."; 810 } 811 /* We need to decide if more than one hash-algo is subscribable */ 812 } 813 } 814 } 816 /* 817 * STRUCTURES - these contain the schema of reportable event types 818 */ 820 sx:structure bios-event-log { 821 when 'derived-from(../event-type, "bios-event-log")'; 822 description 823 "BIOS/UEFI event log format"; 824 uses tpm:bios-event-log; 825 } 827 sx:structure ima-event-log { 828 when 'derived-from(../event-type, "ima-event-log")'; 829 description 830 "IMA event log format"; 831 uses tpm:ima-event-log; 832 } 833 } 834 836 6. Security Considerations 838 To be written. 840 7. IANA Considerations 842 To be written. 844 8. References 846 8.1. Normative References 848 [I-D.ietf-rats-architecture] 849 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 850 W. Pan, "Remote Attestation Procedures Architecture", 851 draft-ietf-rats-architecture-04 (work in progress), May 852 2020. 854 [RATS-Device] 855 "Network Device Remote Integrity Verification", n.d., 856 . 859 [RATS-YANG] 860 "A YANG Data Model for Challenge-Response-based Remote 861 Attestation Procedures using TPMs", n.d., 862 . 865 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 866 Requirement Levels", BCP 14, RFC 2119, 867 DOI 10.17487/RFC2119, March 1997, 868 . 870 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 871 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 872 May 2017, . 874 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 875 E., and A. Tripathy, "Subscription to YANG Notifications", 876 RFC 8639, DOI 10.17487/RFC8639, September 2019, 877 . 879 [TPM2.0] TCG, "TPM 2.0 Library Specification", n.d., 880 . 883 8.2. Informative References 885 [I-D.birkholz-rats-tuda] 886 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 887 "Time-Based Uni-Directional Attestation", draft-birkholz- 888 rats-tuda-02 (work in progress), March 2020. 890 [KGV] TCG, "KGV", October 2003, 891 . 894 Appendix A. Acknowledgements 896 Tim Jenkins, Paul Merlo, Wayne Mills 898 A.1. Open Questions 900 o Do we need a notification correlator object to easily allow 901 correlation on which extensions have been embodied within a 902 specific attestation? 904 Authors' Addresses 906 Henk Birkholz 907 Fraunhofer SIT 908 Rheinstrasse 75 909 Darmstadt 64295 910 Germany 912 Email: henk.birkholz@sit.fraunhofer.de 914 Eric Voit 915 Cisco Systems, Inc. 917 Email: evoit@cisco.com 919 Wei Pan 920 Huawei Technologies 921 101 Software Avenue, Yuhuatai District 922 Nanjing, Jiangsu 210012 923 China 925 Email: william.panwei@huawei.com