idnits 2.17.1 draft-birkholz-rats-network-device-subscription-03.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 13 instances of too long lines in the document, the longest one being 2 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 400 has weird spacing: '...e-value bin...' == Line 497 has weird spacing: '...-number uin...' == Line 586 has weird spacing: '...r-index pcr...' -- The document date (17 August 2021) is 983 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-12 ** Downref: Normative reference to an Informational draft: draft-ietf-rats-architecture (ref. 'I-D.ietf-rats-architecture') == Outdated reference: A later version (-09) exists of draft-ietf-rats-reference-interaction-models-04 ** Downref: Normative reference to an Informational draft: draft-ietf-rats-reference-interaction-models (ref. 'I-D.ietf-rats-reference-interaction-models') == Outdated reference: A later version (-14) exists of draft-ietf-rats-tpm-based-network-device-attest-08 ** 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-10 == Outdated reference: A later version (-07) exists of draft-birkholz-rats-tuda-05 Summary: 4 errors (**), 0 flaws (~~), 9 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: 18 February 2022 Cisco 6 W. Pan 7 Huawei 8 17 August 2021 10 Attestation Event Stream Subscription 11 draft-birkholz-rats-network-device-subscription-03 13 Abstract 15 This memo defines how to subscribe to YANG Event Streams for Remote 16 Attestation Procedures (RATS). In RATS, Conceptional Messages, are 17 defined. Analogously, the YANG module defined in this memo augments 18 the YANG module for TPM-based Challenge-Response based Remote 19 Attestation (CHARRA) to allow for subscription to remote attestation 20 Evidence. Additionally, this memo provides the methods and means to 21 define additional Event Streams for other Conceptual Message as 22 illustrated in the RATS Architecture, e.g. Attestation Results, 23 Endorsements, or Event Logs. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 18 February 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 61 3. Operational Model . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Sequence Diagram . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Continuously Verifying Freshness . . . . . . . . . . . . 7 64 3.2.1. TPM 1.2 Quote . . . . . . . . . . . . . . . . . . . . 8 65 3.2.2. TPM 2 Quote . . . . . . . . . . . . . . . . . . . . . 8 66 4. Remote Attestation Event Stream . . . . . . . . . . . . . . . 9 67 4.1. Subscription to the Event Stream . . . . . 9 68 4.2. Replaying a history of previous TPM extend operations . . 10 69 4.2.1. TPM2 Heartbeat . . . . . . . . . . . . . . . . . . . 11 70 4.3. YANG notifications placed on the Event 71 Stream . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.3.1. pcr-extend . . . . . . . . . . . . . . . . . . . . . 11 73 4.3.2. tpm12-attestation . . . . . . . . . . . . . . . . . . 13 74 4.3.3. tpm20-attestation . . . . . . . . . . . . . . . . . . 13 75 4.4. Filtering Evidence at the Attester . . . . . . . . . . . 14 76 4.5. Replaying previous PCR Extend events . . . . . . . . . . 14 77 4.6. Configuring the Event Stream . . . . . . . 14 78 5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 6. Event Streams for Conceptual Messages . . . . . . . . . . . . 22 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 84 9.2. Informative References . . . . . . . . . . . . . . . . . 23 85 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24 86 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 89 1. Introduction 91 [I-D.ietf-rats-tpm-based-network-device-attest] and 92 [I-D.ietf-rats-yang-tpm-charra] define the operational prerequisites 93 and a YANG Model for the acquisition of Evidence and other 94 Conceptional Messages from a TPM-based network device. However, 95 there are limitations inherent in the challenge-response based remote 96 attestation (CHARRA [I-D.ietf-rats-reference-interaction-models]) 97 upon which these documents are based. One of these limitation is 98 that it is a RATS role's duty to request Conceptional Messages, such 99 as Evidence as provided by [I-D.ietf-rats-yang-tpm-charra], from 100 another RATS entity. The result is that the interval between the 101 occurrence of a security-relevant change event, and the event's 102 visibility within the interested RATS entity, such as a Verifier or a 103 Relying Party, can be unacceptably long. It is common to convey 104 Conceptual Messages ad-hoc or periodically via requests. As new 105 technologies emerge, some of these solutions require Conceptual 106 Messages to be conveyed from one RATS entity to another without the 107 need of continuous polling. Subscription to YANG Notifications 108 [RFC8639] provides a set of standardized tools to facilitate these 109 emerging requirements. This memo specifies a YANG augment to 110 subscribe to YANG modeled remote attestation Evidence as defined in 111 [I-D.ietf-rats-yang-tpm-charra]. Additionally, this memo provides 112 the means to define further Event Streams to convey Conceptional 113 Messages other than Evidence, such as Attestation Results, 114 Endorsements, or Event Logs. 116 In essence, the limitation of poll-based interactions results in two 117 adverse effects: 119 1. Conceptual Messages are not streamed to an interested consumer of 120 information, e.g., Verifiers or Relying Parties, as soon as they 121 are generated. 123 2. If they were to be streamed, Conceptual Messages are not 124 appraisable for their freshness in every scenario. This becomes 125 more important with Conceptional Messages that have a strong 126 dependency on freshness, such as Evidence and corresponding 127 Attestation Results. 129 This specification addresses the first adverse effect by enabling a 130 consumer of Conceptual Messages (the subscriber) to request a 131 continuous stream of new or updated Conceptual Messages via an 132 [RFC8639] subscription to an Event Stream. This new 133 Event Stream is defined in this document and exists upon the producer 134 of Conceptual Messages (the publisher). In the case of a Verifier's 135 subscription to an Attester's Evidence, the Attester will 136 continuously stream a requested set of freshly generated Evidence to 137 the subscribing Verifier. 139 The second adverse effect results from the use of nonces in the 140 challenge-response interaction model 141 [I-D.ietf-rats-reference-interaction-models] realized in 142 [I-D.ietf-rats-yang-tpm-charra]. In [I-D.ietf-rats-yang-tpm-charra], 143 an Attester must wait for a new nonce from a Verifier before it 144 generates a new TPM Quote. To address delays resulting from such a 145 wait, this specification enables freshness to be asserted 146 asynchronously via the streaming attestation interaction model 147 [I-D.ietf-rats-reference-interaction-models]. To convey a RATS 148 Conceptual Message, an initial nonce is provided during the 149 subscription to an Event Stream. 151 There are several options to refresh a nonce provided by the initial 152 subscription or its freshness characteristics. All of these methods 153 are out-of-band of an established subscription to YANG Notifications. 154 Two complementary methods are taken into account by this memo: 156 1. a central provider supplies new fresh nonces, e.g. via a Handle 157 Provider that distributes Epoch IDs to all entities in a domain 158 as described in [I-D.ietf-rats-architecture] and as facilitated 159 by the Uni-Directional Remote Attestation described in 160 [I-D.ietf-rats-reference-interaction-models] or 162 2. the freshness characteristics of a received nonce are updated by 163 -- potentially periodic or ad-hoc -- out-of-band TPM Quote 164 requests as facilitated by [I-D.ietf-rats-yang-tpm-charra]. 166 Both approaches to update the freshness characteristics of the 167 Conceptual Messages conveyed via subscription to YANG Notification 168 that are taken into account by this memo assume that clock drift 169 between involved entities can occur. In consequence, in some usage 170 scenarios the timing considerations for freshness 171 [I-D.ietf-rats-architecture] might have to be updated in some regular 172 interval. Analogously, there are can be additional methods that are 173 not describe by but nevertheless supported by this memo. 175 This memo enables to remove the two adverse effects described by 176 using the YANG augment specified. The YANG augment supports, for 177 example, a RATS Verifier to maintain a continuous appraisal procedure 178 of verifiably fresh Attester Evidence without relying on continuous 179 polling. 181 2. Terminology 183 The following terms are imported from [I-D.ietf-rats-architecture]: 184 Attester, Conceptual Message, Evidence, Relying Party, and Verifier. 185 Also imported are the time definitions time(VG), time(NS), time(EG), 186 time(RG), and time(RA) from that document's Appendix A. The 187 following terms are imported from [RFC8639]: Event Stream, 188 Subscription, Event Stream Filter, Dynamic Subscription. 190 2.1. Requirements Notation 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 194 "OPTIONAL" in this document are to be interpreted as described in 195 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 196 capitals, as shown here. 198 3. Operational Model 200 [I-D.ietf-rats-tpm-based-network-device-attest] describes the 201 conveyance of TPM-based Evidence from a Verifier to an Attester using 202 the CHARRA interaction model 203 [I-D.ietf-rats-reference-interaction-models]. The operational model 204 and corresponding sequence diagram described in this section is based 205 on [I-D.ietf-rats-yang-tpm-charra]. The basis for interoperability 206 required for additional types of Event Streams is covered in 207 Section 6. The following sub-section focuses on subscription to YANG 208 Notifications to the Event Stream. 210 3.1. Sequence Diagram 212 Figure 1 below is a sequence diagram which updates Figure 5 of 213 [I-D.ietf-rats-tpm-based-network-device-attest]. This sequence 214 diagram replaces the [I-D.ietf-rats-tpm-based-network-device-attest] 215 TPM-specific challenge-response interaction model with a [RFC8639] 216 Dynamic Subscription to an Event Stream. The contents 217 of the Event Stream are defined below within Section 4. 219 .----------. .--------------------------. 220 | Attester | | Relying Party / Verifier | 221 '----------' '--------------------------' 222 time(VG) | 223 generateClaims(targetEnvironment) | 224 | => claims, eventLogs | 225 | | 226 |<---------establish-subscription()------time(NS) 227 | | 228 time(EG) | 229 generateEvidence(nonce, PcrSelection, collectedClaims) | 230 | => SignedPcrEvidence(nonce, PcrSelection) | 231 | => LogEvidence(collectedClaims) | 232 | | 233 |--filter()---------------------------------->| 234 |-- or ------------>| 235 | | 236 | time(RG,RA) 237 | appraiseEvidence(SignedPcrEvidence, eventLog, refClaims) 238 | attestationResult <= | 239 | | 240 ~ ~ 241 time(VG') | 242 generateClaimes(targetEnvironment) | 243 | => claims | 244 | | 245 time(EG') | 246 generateEvidence(handle, PcrSelection, collectedClaims) | 247 | => SignedPcrEvidence(nonce, PcrSelection) | 248 | => LogEvidence(collectedClaims) | 249 | | 250 |--filter()---------------------------------->| 251 |-- or ------------>| 252 | | 253 | time(RG',RA') 254 | appraiseEvidence(SignedPcrEvidence, eventLog, refClaims) 255 | attestationResult <= | 256 | | 258 Figure 1: YANG Subscription Model for Remote Attestation 260 * time(VG,RG,RA) are identical to the corresponding time definitions 261 from [I-D.ietf-rats-tpm-based-network-device-attest]. 263 * time(VG',RG',RA') are subsequent instances of the corresponding 264 times from Figure 5 in 265 [I-D.ietf-rats-tpm-based-network-device-attest]. 267 * time(NS) - the subscriber generates a nonce and makes an [RFC8639] 268 request based on a nonce. This request 269 also includes the augmentations defined in this document's YANG 270 model. Key subscription RPC parameters include: 272 - the nonce, 274 - a set of PCRs of interest which the wants to appraise, and 276 - an optional filter which can reduce the logged events on the 277 stream pushed to the Verifier. 279 * time(EG) - an initial response of Evidence is returned to the 280 Verifier. This includes: 282 - a replay of filtered log entries which have extended into a PCR 283 of interest since boot are sent in the 284 notification, and 286 - a signed TPM quote that contains at least the PCRs from the 287 RPC are included in a 288 or ). This quote must 289 have included the nonce provided at time(NS). 291 * time(VG',EG') - this occurs when a PCR is extended subsequent to 292 time(EG). Immediately after the extension, the following 293 information needs to be pushed to the Verifier: 295 - any values extended into a PCR of interest, 297 - a signed TPM Quote showing the result the PCR extension, and 299 - and a handle (see Section 6. in 300 [I-D.ietf-rats-reference-interaction-models], which is either 301 the initially received nonce or a more recently received Epoch 302 ID (see Section 10.3. in [I-D.ietf-rats-architecture] that 303 contains a new nonce or equivalent qualified data. 305 One way to acquire a new time synchronization that allows for the 306 reuse of the initially received nonce as a fresh handle is elaborated 307 on in the follow section Section 3.2. 309 3.2. Continuously Verifying Freshness 311 As there is no new Verifier nonce provided at time(EG'), it is 312 important to validate the freshness of TPM Quotes which are delivered 313 at that time. The method of doing this verification will vary based 314 on the capabilities of the TPM cryptoprocessor used. 316 3.2.1. TPM 1.2 Quote 318 The [RFC8639] notification format includes the object. 319 This can be used to determine the amount of time subsequent to the 320 initial subscription each notification was sent. However this time 321 is not part of the signed results which are returned from the Quote, 322 and therefore is not trustworthy as objects returned in the Quote. 323 Therefore a Verifier MUST periodically issue a new nonce, and receive 324 this nonce within a TPM quote response in order to ensure the 325 freshness of the results. This can be done using the RPC from 327 [I-D.ietf-rats-yang-tpm-charra]. 329 3.2.2. TPM 2 Quote 331 When the Attester includes a TPM2 compliant cryptoprocessor, internal 332 time-related counters are included within the signed TPM Quote. By 333 including a initial nonce in the [RFC8639] subscription request, 334 fresh values for these counters are pushed as part of the first TPM 335 Quote returned to the Verifier. And then as shown by 336 [I-D.birkholz-rats-tuda], subsequent TPM Quotes delivered to the 337 Verifier can the be appraised for freshness based on the predictable 338 incrementing of these time-related countersr. 340 The relevant internal time-related counters defined within [TPM2.0] 341 can be seen within . These counters include the 342 , , and objects. The rules 343 for appraising these objects are as follows: 345 * If the has incremented for no more than the same duration 346 as both the and the Verifier's internal time since the 347 initial time(EG) and any previous time(EG'), then the TPM Quote 348 may be considered fresh. Note that [TPM2.0] allows for +/- 15% 349 clock drift. However many chips significantly improve on this 350 maximum drift. If available, chip specific maximum drifts SHOULD 351 be considered during the appraisal process. 353 * If the , has incremented. The 354 existing subscription MUST be terminated, and a new SHOULD be generated. 357 * If a TPM Quote on any subscribed PCR has not been pushed to the 358 Verifier for a duration of an Attester defined heartbeat interval, 359 then a new TPM Quote notification should be sent to the Verifier. 360 This may often be the case, as certain PCRs might be infrequently 361 updated. 363 .----------. .--------------------------. 364 | Attester | | Relying Party / Verifier | 365 '----------' '--------------------------' 366 time(VG',EG') | 367 |------------------------------->| 368 | : | 369 ~ Heartbeat interval ~ 370 | : | 371 time(EG') : | 372 |------------------------------->| 373 | | 375 4. Remote Attestation Event Stream 377 The Event Stream is an [RFC8639] compliant Event Stream 378 which is defined within this section and within the YANG Module of 379 [I-D.ietf-rats-yang-tpm-charra]. This Event Stream contains YANG 380 notifications which carry Evidence to assists a Verifier in 381 appraising the Trustworthiness Level of an Attester. Data Nodes 382 within Section 4.6 allow the configuration of this Event Stream's 383 contents on an Attester. 385 This Event Stream may only be exposed on Attesters 386 supporting [I-D.ietf-rats-tpm-based-network-device-attest]. As with 387 [I-D.ietf-rats-tpm-based-network-device-attest], it is up to the 388 Verifier to understand which types of cryptoprocessors and keys are 389 acceptable. 391 4.1. Subscription to the Event Stream 393 To establish a subscription to an Attester in a way which provides 394 provably fresh Evidence, initial randomness must be provided to the 395 Attester. This is done via the augmentation of a into 396 [RFC8639] the RPC. Additionally, a Verifier 397 must ask for PCRs of interest from a platform. 399 augment /sn:establish-subscription/sn:input: 400 +---w nonce-value binary 401 +---w pcr-index* tpm:pcr 403 The result of the subscription will be that passing of the following 404 information: 406 1. and notifications which 407 include the provided . These attestation 408 notifications MUST at least include all the 409 requested in the RPC. 411 2. a series of notifications which reference the 412 requested PCRs on all TPM based cryptoprocessors on the Attester. 414 3. and notifications 415 generated within a few seconds of the notifications. 416 These attestation notifications MUST at least include any PCRs 417 extended. 419 If the Verifier does not want to see the logged extend operations for 420 all PCRs available from an Attester, an Event Stream Filter should be 421 applied. This filter will remove Evidence from any PCRs which are 422 not interesting to the Verifier. 424 4.2. Replaying a history of previous TPM extend operations 426 Unless it is relying on Known Good Values, a Verifier will need to 427 acquire a history of PCR extensions since the Attester has been 428 booted. This history may be requested from the Attester as part of 429 the RPC. This request is accomplished by 430 placing a very old within the original RPC 431 request. As the very old will pre-date the time 432 of Attester boot, a will be returned in 433 the RPC response, indicating when the 434 Attester booted. Immediately following the response (and before the 435 notifications above) one or more notifications which 436 document all extend operations which have occurred for the requested 437 PCRs since boot will be sent. Many extend operations to a single PCR 438 index on a single TPM SHOULD be included within a single 439 notification. 441 Note that if a Verifier has a partial history of extensions, the 442 can be adjusted so that known extensions are not 443 forwarded. 445 The end of this history replay will be indicated with the [RFC8639] 446 notification. For more on this sequence, see 447 Section 2.4.2.1 of [RFC8639]. 449 After the notification is provided, a TPM Quote 450 will be requested and the result passed to the Verifier via a 451 and notification. If there 452 have been any additional extend operations which have changed a 453 subscribed PCR value in this quote, these MUST be pushed to the 454 Verifier before the and 455 notification. 457 At this point the Verifier has sufficient Evidence appraise the 458 reported extend operations for each PCR, as well compare the expected 459 value of the PCR value against that signed by the TPM. 461 4.2.1. TPM2 Heartbeat 463 For TPM2, make sure that every requested PCR is sent within an 464 no less frequently than once per heartbeat 465 interval. This MAY be done with a single 466 notification that includes all requested PCRs every heartbeat 467 interval. This MAY be done with several 468 notifications at different times during that heartbeat interval. 470 4.3. YANG notifications placed on the Event Stream 472 4.3.1. pcr-extend 474 This notification documents when a subscribed PCR is extended within 475 a single TPM cryptoprocessor. It SHOULD be emmitted no less than the 476 after an the PCR is first extended. (The reason 477 for the marshalling is that it is quite possible that multiple 478 extensions to the same PCR have been made in quick succession, and 479 these should be reflected in the same notification.) This 480 notification MUST be emmitted prior to a or 481 notification which has included and signed the 482 results of any specific PCR extension. If pcr extending events occur 483 during the generation of the or 484 notification, the marshalling period MUST be 485 extended so that a new is not sent until the 486 corresponding notifications have been sent. 488 +---n pcr-extend 489 +--ro certificate-name certificate-name-ref 490 +--ro pcr-index-changed* tpm:pcr 491 +--ro attested-event* [] 492 +--ro attested-event 493 +--ro extended-with binary 494 +--ro (event-details)? 495 +--:(bios-event-log) 496 | +--ro bios-event-entry* [event-number] 497 | +--ro event-number uint32 498 | +--ro event-type? uint32 499 | +--ro pcr-index? pcr 500 | +--ro digest-list* [] 501 | | +--ro hash-algo? identityref 502 | | +--ro digest* binary 503 | +--ro event-size? uint32 504 | +--ro event-data* uint8 505 +--:(ima-event-log) 506 | +--ro ima-event-entry* [event-number] 507 | +--ro event-number uint64 508 | +--ro ima-template? string 509 | +--ro filename-hint? string 510 | +--ro filedata-hash? binary 511 | +--ro filedata-hash-algorithm? string 512 | +--ro template-hash-algorithm? string 513 | +--ro template-hash? binary 514 | +--ro pcr-index? pcr 515 | +--ro signature? binary 516 +--:(netequip-boot-event-log) 517 +--ro boot-event-entry* [event-number] 518 +--ro event-number uint64 519 +--ro filename-hint? string 520 +--ro filedata-hash? binary 521 +--ro filedata-hash-algorithm? string 522 +--ro file-version? string 523 +--ro file-type? string 524 +--ro pcr-index? pcr 526 Each MUST include one or more values being extended into 527 the PCR. These are passed within the object. For 528 each extension, details of the event SHOULD be provided within the 529 object. The format of any included 530 is identified by the . This document includes two YANG 531 structures which may be inserted into the . These two 532 structures are: . 533 Implementations wanting to provide additional documentation of a type 534 of PCR extension may choose to define additional YANG structures 535 which can be placed into . 537 4.3.2. tpm12-attestation 539 This notification contains an instance of a TPM1.2 style signed 540 cryptoprocessor measurement. It is supplemented by Attester 541 information which is not signed. This notification is generated and 542 emitted from an Attester when at least one PCR identified within the 543 subscribed has changed from the previous 544 notification. This notification MUST NOT include 545 the results of any PCR extensions not previously reported by a . This notification SHOULD be emitted as soon as a TPM Quote 547 can extract the latest PCR hashed values. This notification MUST be 548 emitted prior to a subsequent . 550 +---n tpm12-attestation {taa:TPM12}? 551 +--ro certificate-name tpm:certificate-name-ref 552 +--ro up-time? uint32 553 +--ro TPM_QUOTE2? binary 554 +--ro TPM12-hash-algo? identityref 555 +--ro unsigned-pcr-values* [] 556 +--ro pcr-index* tpm:pcr 557 +--ro pcr-value* binary 559 All YANG objects above are defined within 560 [I-D.ietf-rats-yang-tpm-charra]. The is not 561 replayable. 563 4.3.3. tpm20-attestation 565 This notification contains an instance of TPM2 style signed 566 cryptoprocessor measurements. It is supplemented by Attester 567 information which is not signed. This notification is generated at 568 two points in time: 570 * every time at least one PCR has changed from a previous 571 tpm20-attestation. In this case, the notification SHOULD be 572 emitted within 10 seconds of the corresponding being 573 sent: 575 * after a locally configurable minimum heartbeat period since a 576 previous tpm20-attestation was sent. 578 +---n tpm20-attestation {taa:TPM20}? 579 +--ro certificate-name tpm:certificate-name-ref 580 +--ro TPMS_QUOTE_INFO binary 581 +--ro quote-signature? binary 582 +--ro up-time? uint32 583 +--ro unsigned-pcr-values* [] 584 +--ro TPM20-hash-algo? identityref 585 +--ro pcr-values* [pcr-index] 586 +--ro pcr-index pcr 587 +--ro pcr-value? binary 589 All YANG objects above are defined within 590 [I-D.ietf-rats-yang-tpm-charra]. The is not 591 replayable. 593 4.4. Filtering Evidence at the Attester 595 It can be useful _not_ to receive all Evidence related to a PCR. An 596 example of this is would be a when a Verifier maintains known good 597 values of a PCR. In this case, it is not necessary to send each 598 extend operation. 600 To accomplish this reduction, when an RFC8639 RPC is sent, a as per RFC8639, 602 Section 2.2 can be set to discard a notification when 603 the is uninteresting to the verifier. 605 4.5. Replaying previous PCR Extend events 607 To verify the value of a PCR, a Verifier must either know that the 608 value is a known good value [KGV] or be able to reconstruct the hash 609 value by viewing all the PCR-Extends since the Attester rebooted. 610 Wherever a hash reconstruction might be needed, the 611 Event Stream MUST support the RFC8639 feature. Through the 612 feature, it is possible for a Verifier to retrieve and 613 sequentially hash all of the PCR extending events since an Attester 614 booted. And thus, the Verifier has access to all the evidence needed 615 to verify a PCR's current value. 617 4.6. Configuring the Event Stream 619 Figure 2 is tree diagram which exposes the operator configurable 620 elements of the Event Stream. This allows an Attester 621 to select what information should be available on the stream. A 622 fetch operation also allows an external device such as a Verifier to 623 understand the current configuration of stream. 625 Almost all YANG objects below are defined via reference from 626 [I-D.ietf-rats-yang-tpm-charra]. There is one object which is new 627 with this model however. defines the maximum amount 628 of time which should pass before a subscriber to the Event Stream 629 should get a notification from devices which 630 contain a TPM2. 632 augment /tpm:rats-support-structures: 633 +--rw marshalling-period? uint8 634 +--rw tpm12-subscribed-signature-scheme? 635 | -> ../tpm:attester-supported-algos/tpm12-asymmetric-signing 636 | {taa:TPM12}? 637 +--rw tpm20-subscribed-signature-scheme? 638 | -> ../tpm:attester-supported-algos/tpm20-asymmetric-signing 639 | {taa:TPM20}? 640 +--rw tpm20-subscription-heartbeat? uint16 641 augment /tpm:rats-support-structures/tpm:tpms: 642 +--rw subscription-aik? tpm:certificate-name-ref 643 +--rw (subscribable)? 644 +--:(tpm12-stream) {taa:TPM12}? 645 | +--rw TPM12-hash-algo? identityref 646 | +--rw tpm12-pcr-index* tpm:pcr 647 +--:(tpm20-stream) {taa:TPM20}? 648 +--rw TPM20-hash-algo? identityref 649 +--rw tpm20-pcr-index* tpm:pcr 651 Figure 2: Configuring the \ Event Stream 653 5. YANG Module 655 This YANG module imports modules from [I-D.ietf-rats-yang-tpm-charra] 656 and [RFC8639]. It is also work-in-progress. 658 ietf-rats-attestation-stream@2020-12-15.yang 659 module ietf-tpm-remote-attestation-stream { 660 yang-version 1.1; 661 namespace 662 "urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation-stream"; 663 prefix tras; 665 import ietf-subscribed-notifications { 666 prefix sn; 667 reference 668 "RFC 8639: Subscription to YANG Notifications"; 669 } 670 import ietf-tpm-remote-attestation { 671 prefix tpm; 672 reference 673 "draft-ietf-rats-yang-tpm-charra"; 674 } 675 import ietf-tcg-algs { 676 prefix taa; 677 } 679 organization "IETF"; 680 contact 681 "WG Web: 682 WG List: 684 Editor: Eric Voit 685 "; 687 description 688 "This module contains conceptual YANG specifications for 689 subscribing to attestation streams being generated from TPM chips. 691 Copyright (c) 2021 IETF Trust and the persons identified 692 as authors of the code. All rights reserved. 694 Redistribution and use in source and binary forms, with 695 or without modification, is permitted pursuant to, and 696 subject to the license terms contained in, the Simplified 697 BSD License set forth in Section 4.c of the IETF Trust's 698 Legal Provisions Relating to IETF Documents 699 (https://trustee.ietf.org/license-info). 701 This version of this YANG module is part of RFC XXXX 702 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 703 itself for full legal notices."; 705 revision 2021-05-11 { 706 description 707 "Initial version."; 708 reference 709 "draft-birkholz-rats-network-device-subscription"; 710 } 712 /* 713 * IDENTITIES 714 */ 716 identity pcr-unsubscribable { 717 base sn:establish-subscription-error; 718 description 719 "Requested PCR is subscribable by the Attester."; 720 } 721 /* 722 * Groupings 723 */ 725 grouping heartbeat { 726 description 727 "Allows an Attester to push verifiable, current TPM PCR values 728 even when there have been no recent changes to PCRs."; 729 leaf tpm20-subscription-heartbeat { 730 type uint16; 731 description 732 "Number of seconds before the Attestation stream should send a 733 new notification with a fresh quote. This allows confirmation 734 that the PCR values haven't changed since the last 735 tpm20-attestation."; 736 } 737 } 739 /* 740 * RPCs 741 */ 743 augment "/sn:establish-subscription/sn:input" { 744 when 'derived-from-or-self(sn:stream, "attestation")'; 745 description 746 "This augmentation adds a nonce to as a subscription parameters 747 that apply specifically to datastore updates to RPC input."; 748 uses tpm:nonce; 749 leaf-list pcr-index { 750 type tpm:pcr; 751 min-elements 1; 752 description 753 "The numbers/indexes of the PCRs. This will act as a filter for 754 the subscription so that 'tpm-extend' notifications related to 755 non-requested PCRs will not be sent to a subscriber."; 756 } 757 } 759 /* 760 * NOTIFICATIONS 761 */ 763 notification pcr-extend { 764 description 765 "This notification indicates that one or more PCRs have been 766 extended within a TPM based cryptoprocessor. In less than the 767 'marshalling-period', it MUST be followed with either a 768 corresponding tpm12-attestation or tpm20-attestation notification 769 which exposes the result of the PCRs updated."; 770 uses tpm:certificate-name-ref; 771 leaf-list pcr-index-changed { 772 type tpm:pcr; 773 min-elements 1; 774 description 775 "The number of each PCR extended. This list MUST contain the 776 set of PCRs descibed within the event log details. This leaf 777 can be derived from the list of attested events, but exposing 778 it here allows for easy filtering of the notifications of 779 interest to a verifier."; 780 } 781 list attested-event { 782 description 783 "A set of events which extended an Attester PCR. The sequence 784 of elements represented in list must match the sequence of 785 events placed into the TPM's PCR."; 786 container attested-event { 787 description 788 "An instance of an event which extended an Attester PCR"; 789 leaf extended-with { 790 type binary; 791 mandatory true; 792 description 793 "Information extending the PCR."; 794 } 795 choice event-details { 796 description 797 "Contains the event happened the Attester thought 798 was worthy of recording in a PCR. 800 choices are of types defined by the identityref 801 base tpm:attested_event_log_type"; 802 case bios-event-log { 803 if-feature "tpm:bios"; 804 description 805 "BIOS/UEFI event log format"; 806 uses tpm:bios-event-log; 807 } 808 case ima-event-log { 809 if-feature "tpm:ima"; 810 description 811 "IMA event log format"; 812 uses tpm:ima-event-log; 813 } 814 case netequip-boot-event-log { 815 if-feature "tpm:netequip_boot"; 816 description 817 "IMA event log format"; 818 uses tpm:network-equipment-boot-event-log; 819 } 820 } 821 } 822 } 823 } 825 notification tpm12-attestation { 826 if-feature "taa:tpm12"; 827 description 828 "Contains an instance of TPM1.2 style signed cryptoprocessor 829 measurements. It is supplemented by unsigned Attester 830 information."; 831 leaf certificate-name { 832 type tpm:certificate-name-ref; 833 mandatory true; 834 description 835 "Allows a TPM quote to be associated with a certificate."; 836 } 837 uses tpm:tpm12-attestation; 838 uses tpm:tpm12-hash-algo; 839 list unsigned-pcr-values { 840 description 841 "Allows notifications to be filtered by PCR number or 842 PCR value based on via YANG related mechanisms such as PATH. 843 This is done without requiring the filtering structure to be 844 applied against TCG structured data."; 845 leaf-list pcr-index { 846 type tpm:pcr; 847 min-elements 1; 848 description 849 "PCR index number."; 850 } 851 leaf-list pcr-value { 852 type binary; 853 description 854 "PCR value in a sequence which matches to the 'pcr-index'."; 855 } 856 } 857 } 859 notification tpm20-attestation { 860 if-feature "taa:tpm20"; 861 description 862 "Contains an instance of TPM2 style signed cryptoprocessor 863 measurements. It is supplemented by unsigned Attester 864 information."; 865 leaf certificate-name { 866 type tpm:certificate-name-ref; 867 mandatory true; 868 description 869 "Allows a TPM quote to be associated with a certificate."; 870 } 871 uses tpm:tpm20-attestation { 872 description 873 "Provides the attestation info. Also ensures PCRs can be XPATH 874 filtered by refining the unsigned data so that it appears."; 875 refine unsigned-pcr-values { 876 min-elements 1; 877 } 878 refine unsigned-pcr-values/pcr-values { 879 min-elements 1; 880 } 881 } 882 } 884 /* 885 * DATA NODES 886 */ 888 augment "/tpm:rats-support-structures" { 889 description 890 "Defines platform wide 'attestation' stream subscription 891 parameters."; 892 leaf marshalling-period { 893 type uint8; 894 default 5; 895 description 896 "The maximum number of seconds between the time an event 897 extends a PCR, and the 'tpm-extend' notification which reports 898 it to a subscribed Verifier. This period allows multiple 899 extend operations bundled together and handled as a group."; 900 } 901 leaf tpm12-subscribed-signature-scheme { 902 if-feature "taa:tpm12"; 903 type leafref { 904 path "../tpm:attester-supported-algos" + 905 "/tpm:tpm12-asymmetric-signing"; 906 } 907 description 908 "A single signature-scheme which will be used to sign the 909 evidence from a TPM 1.2. which is then placed onto the 910 'attestation' event stream."; 912 } 913 leaf tpm20-subscribed-signature-scheme { 914 if-feature "taa:tpm20"; 915 type leafref { 916 path "../tpm:attester-supported-algos" + 917 "/tpm:tpm20-asymmetric-signing"; 918 } 919 description 920 "A single signature-scheme which will be used to sign the 921 evidence from a TPM 2.0. which is then placed onto the 922 'attestation' event stream."; 923 } 924 uses heartbeat{ 925 if-feature "taa:tpm20"; 926 } 927 } 929 augment "/tpm:rats-support-structures/tpm:tpms" { 930 description 931 "Allows the configuration 'attestation' stream parameters for a 932 TPM."; 933 leaf subscription-aik { 934 type tpm:certificate-name-ref; 935 description 936 "Identifies the certificate-name associated with the 937 notifications in the 'attestation' stream."; 938 } 939 choice subscribable { 940 config true; 941 description 942 "Indicates that the set of notifications which comprise the 943 'attestation' event stream can be modified or tuned by a 944 network administrator."; 945 case tpm12-stream { 946 if-feature "taa:tpm12"; 947 description 948 "Configuration elements for a TPM1.2 event stream."; 949 uses tpm:tpm12-hash-algo; 950 leaf-list tpm12-pcr-index { 951 type tpm:pcr; 952 description 953 "The numbers/indexes of the PCRs which can be subscribed."; 954 } 955 } 956 case tpm20-stream { 957 if-feature "taa:tpm20"; 958 description 959 "Configuration elements for a TPM2.0 event stream."; 961 uses tpm:tpm20-hash-algo; 962 leaf-list tpm20-pcr-index { 963 type tpm:pcr; 964 description 965 "The numbers/indexes of the PCRs which can be subscribed."; 966 } 967 } 968 } 969 } 970 } 971 973 6. Event Streams for Conceptual Messages 975 Analogous to the [RFC8639] compliant Event Stream for 976 the conveyance of remote attestation Evidence as defined in 977 Section Section 4, additional Event Streams can be defined for this 978 YANG augment. Additional Event Streams require separate YANG augment 979 specifications that provide the Event Stream definition and 980 optionally a content format definition either via subscriptions to 981 YANG datastores or dedicated YANG Notifications. It is possible to 982 use either YANG subscription methods to other YANG modules for RATS 983 Conceptual Messages or to define Event Streams for other none-YANG- 984 modeled data. In the context of RATS Conceptual Messages, both 985 options MUST be a specified via YANG augments to this specification. 987 7. Security Considerations 989 To be written. 991 8. IANA Considerations 993 To be written. 995 9. References 997 9.1. Normative References 999 [I-D.ietf-rats-architecture] 1000 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 1001 W. Pan, "Remote Attestation Procedures Architecture", Work 1002 in Progress, Internet-Draft, draft-ietf-rats-architecture- 1003 12, 23 April 2021, . 1006 [I-D.ietf-rats-reference-interaction-models] 1007 Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference 1008 Interaction Models for Remote Attestation Procedures", 1009 Work in Progress, Internet-Draft, draft-ietf-rats- 1010 reference-interaction-models-04, 26 July 2021, 1011 . 1014 [I-D.ietf-rats-tpm-based-network-device-attest] 1015 Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- 1016 based Network Device Remote Integrity Verification", Work 1017 in Progress, Internet-Draft, draft-ietf-rats-tpm-based- 1018 network-device-attest-08, 26 July 2021, 1019 . 1022 [I-D.ietf-rats-yang-tpm-charra] 1023 Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen, 1024 B., (Frank), L. X., Laffey, T., and G. C. Fedorkow, "A 1025 YANG Data Model for Challenge-Response-based Remote 1026 Attestation Procedures using TPMs", Work in Progress, 1027 Internet-Draft, draft-ietf-rats-yang-tpm-charra-10, 12 1028 August 2021, . 1031 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1032 Requirement Levels", BCP 14, RFC 2119, 1033 DOI 10.17487/RFC2119, March 1997, 1034 . 1036 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1037 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1038 May 2017, . 1040 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1041 E., and A. Tripathy, "Subscription to YANG Notifications", 1042 RFC 8639, DOI 10.17487/RFC8639, September 2019, 1043 . 1045 [TPM2.0] TCG, "TPM 2.0 Library Specification", n.d., 1046 . 1049 9.2. Informative References 1051 [I-D.birkholz-rats-tuda] 1052 Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann, 1053 "Time-Based Uni-Directional Attestation", Work in 1054 Progress, Internet-Draft, draft-birkholz-rats-tuda-05, 12 1055 July 2021, . 1058 [KGV] TCG, "KGV", October 2003, 1059 . 1062 Appendix A. Change Log 1064 v01-v02 1066 * Match YANG changes/simplifications made to charra 1068 v00-v01 1070 * rename notification: pcr-extended, which supports multiple PCRs 1072 * netequip boot added 1074 * YANG structure extension removed 1076 * Matched to structural changes made within charra 1078 Acknowledgements 1080 Thanks to ... 1082 Authors' Addresses 1084 Henk Birkholz 1085 Fraunhofer SIT 1086 Rheinstrasse 75 1087 64295 Darmstadt 1088 Germany 1090 Email: henk.birkholz@sit.fraunhofer.de 1092 Eric Voit 1093 Cisco Systems, Inc. 1095 Email: evoit@cisco.com 1097 Wei Pan 1098 Huawei Technologies 1099 101 Software Avenue, Yuhuatai District 1100 Nanjing, Jiangsu 1101 210012 1102 China 1103 Email: william.panwei@huawei.com