idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- ** 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 401 has weird spacing: '...e-value bin...' == Line 498 has weird spacing: '...-number uin...' == Line 589 has weird spacing: '...r-index pcr...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (7 March 2022) is 779 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-15 ** 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-05 ** 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-13 ** 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-16 == Outdated reference: A later version (-07) exists of draft-birkholz-rats-tuda-06 Summary: 4 errors (**), 0 flaws (~~), 10 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: 8 September 2022 Cisco 6 W. Pan 7 Huawei 8 7 March 2022 10 Attestation Event Stream Subscription 11 draft-ietf-rats-network-device-subscription-01 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 8 September 2022. 42 Copyright Notice 44 Copyright (c) 2022 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 Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised 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 . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . . . . 23 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 84 9.2. Informative References . . . . . . . . . . . . . . . . . 24 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 96 conceptual interaction model (CHARRA 97 [I-D.ietf-rats-reference-interaction-models]) upon which these 98 documents are based. One of these limitation is that it is up to a 99 Verifier to request signed Evidence as provided by 100 [I-D.ietf-rats-yang-tpm-charra], from a separate Attester which 101 contains a TPM. The result is that the interval between the 102 occurrence of a security-relevant change event, and the event's 103 visibility within the interested RATS entity, such as a Verifier or a 104 Relying Party, can be unacceptably long. It is common to convey 105 Conceptual Messages ad-hoc or periodically via requests. As new 106 technologies emerge, some of these solutions require Conceptual 107 Messages to be conveyed from one RATS entity to another without the 108 need of continuous polling. Subscription to YANG Notifications 109 [RFC8639] provides a set of standardized tools to facilitate these 110 emerging requirements. This memo specifies a YANG augment to 111 subscribe to YANG modeled remote attestation Evidence as defined in 112 [I-D.ietf-rats-yang-tpm-charra]. Additionally, this memo provides 113 the means to define further Event Streams to convey Conceptional 114 Messages other than Evidence, such as Attestation Results, 115 Endorsements, or Event Logs. 117 In essence, the limitation of poll-based interactions results in two 118 adverse effects: 120 1. Conceptual Messages are not streamed to an interested consumer of 121 information, e.g., Verifiers or Relying Parties, as soon as they 122 are generated. 124 2. If they were to be streamed, Conceptual Messages are not 125 appraisable for their freshness in every scenario. This becomes 126 more important with Conceptional Messages that have a strong 127 dependency on freshness, such as Evidence and corresponding 128 Attestation Results. 130 This specification addresses the first adverse effect by enabling a 131 consumer of Conceptual Messages (the subscriber) to request a 132 continuous stream of new or updated Conceptual Messages via an 133 [RFC8639] subscription to an Event Stream. This new 134 Event Stream is defined in this document and exists upon the producer 135 of Conceptual Messages (the publisher). In the case of a Verifier's 136 subscription to an Attester's Evidence, the Attester will 137 continuously stream a requested set of freshly generated Evidence to 138 the subscribing Verifier. 140 The second adverse effect results from the use of nonces in the 141 challenge-response interaction model 142 [I-D.ietf-rats-reference-interaction-models] realized in 143 [I-D.ietf-rats-yang-tpm-charra]. In [I-D.ietf-rats-yang-tpm-charra], 144 an Attester must wait for a new nonce from a Verifier before it 145 generates a new TPM Quote. To address delays resulting from such a 146 wait, this specification enables freshness to be asserted 147 asynchronously via the streaming attestation interaction model 148 [I-D.ietf-rats-reference-interaction-models]. To convey a RATS 149 Conceptual Message, an initial nonce is provided during the 150 subscription to an Event Stream. 152 There are several options to refresh a nonce provided by the initial 153 subscription or its freshness characteristics. All of these methods 154 are out-of-band of an established subscription to YANG Notifications. 155 Two complementary methods are taken into account by this memo: 157 1. a central provider supplies new fresh nonces, e.g. via a Handle 158 Provider that distributes Epoch IDs to all entities in a domain 159 as described in [I-D.ietf-rats-architecture] and as facilitated 160 by the Uni-Directional Remote Attestation described in 161 [I-D.ietf-rats-reference-interaction-models] or 163 2. the freshness characteristics of a received nonce are updated by 164 -- potentially periodic or ad-hoc -- out-of-band TPM Quote 165 requests as facilitated by [I-D.ietf-rats-yang-tpm-charra]. 167 Both approaches to update the freshness characteristics of the 168 Conceptual Messages conveyed via subscription to YANG Notification 169 that are taken into account by this memo assume that clock drift 170 between involved entities can occur. In consequence, in some usage 171 scenarios the timing considerations for freshness 172 [I-D.ietf-rats-architecture] might have to be updated in some regular 173 interval. Analogously, there are can be additional methods that are 174 not describe by but nevertheless supported by this memo. 176 This memo enables to remove the two adverse effects described by 177 using the YANG augment specified. The YANG augment supports, for 178 example, a RATS Verifier to maintain a continuous appraisal procedure 179 of verifiably fresh Attester Evidence without relying on continuous 180 polling. 182 2. Terminology 184 The following terms are imported from [I-D.ietf-rats-architecture]: 185 Attester, Conceptual Message, Evidence, Relying Party, and Verifier. 186 Also imported are the time definitions time(VG), time(NS), time(EG), 187 time(RG), and time(RA) from that document's Appendix A. The 188 following terms are imported from [RFC8639]: Event Stream, 189 Subscription, Event Stream Filter, Dynamic Subscription. 191 2.1. Requirements Notation 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 195 "OPTIONAL" in this document are to be interpreted as described in BCP 196 14 RFC2119 [RFC8174] when, and only when, they appear in all 197 capitals, as shown here. 199 3. Operational Model 201 [I-D.ietf-rats-tpm-based-network-device-attest] describes the 202 conveyance of TPM-based Evidence from a Verifier to an Attester using 203 the CHARRA interaction model 204 [I-D.ietf-rats-reference-interaction-models]. The operational model 205 and corresponding sequence diagram described in this section is based 206 on [I-D.ietf-rats-yang-tpm-charra]. The basis for interoperability 207 required for additional types of Event Streams is covered in 208 Section 6. The following sub-section focuses on subscription to YANG 209 Notifications to the Event Stream. 211 3.1. Sequence Diagram 213 Figure 1 below is a sequence diagram which updates Figure 5 of 214 [I-D.ietf-rats-tpm-based-network-device-attest]. This sequence 215 diagram replaces the [I-D.ietf-rats-tpm-based-network-device-attest] 216 TPM-specific challenge-response interaction model with a [RFC8639] 217 Dynamic Subscription to an Event Stream. The contents 218 of the Event Stream are defined below within Section 4. 220 .----------. .--------------------------. 221 | Attester | | Relying Party / Verifier | 222 '----------' '--------------------------' 223 time(VG) | 224 generateClaims(targetEnvironment) | 225 | => claims, eventLogs | 226 | | 227 |<---------establish-subscription()------time(NS) 228 | | 229 time(EG) | 230 generateEvidence(nonce, PcrSelection, collectedClaims) | 231 | => SignedPcrEvidence(nonce, PcrSelection) | 232 | => LogEvidence(collectedClaims) | 233 | | 234 |--filter()---------------------------------->| 235 |-- or ------------>| 236 | | 237 | time(RG,RA) 238 | appraiseEvidence(SignedPcrEvidence, eventLog, refClaims) 239 | attestationResult <= | 240 | | 241 ~ ~ 242 time(VG') | 243 generateClaimes(targetEnvironment) | 244 | => claims | 245 | | 246 time(EG') | 247 generateEvidence(handle, PcrSelection, collectedClaims) | 248 | => SignedPcrEvidence(nonce, PcrSelection) | 249 | => LogEvidence(collectedClaims) | 250 | | 251 |--filter()---------------------------------->| 252 |-- or ------------>| 253 | | 254 | time(RG',RA') 255 | appraiseEvidence(SignedPcrEvidence, eventLog, refClaims) 256 | attestationResult <= | 257 | | 259 Figure 1: YANG Subscription Model for Remote Attestation 261 * time(VG,RG,RA) are identical to the corresponding time definitions 262 from [I-D.ietf-rats-tpm-based-network-device-attest]. 264 * time(VG',RG',RA') are subsequent instances of the corresponding 265 times from Figure 5 in 266 [I-D.ietf-rats-tpm-based-network-device-attest]. 268 * time(NS) - the subscriber generates a nonce and makes an [RFC8639] 269 request based on a nonce. This request 270 also includes the augmentations defined in this document's YANG 271 model. Key subscription RPC parameters include: 273 - the nonce, 275 - a set of PCRs of interest which the wants to appraise, and 277 - an optional filter which can reduce the logged events on the 278 stream pushed to the Verifier. 280 * time(EG) - an initial response of Evidence is returned to the 281 Verifier. This includes: 283 - a replay of filtered log entries which have extended into a PCR 284 of interest since boot are sent in the 285 notification, and 287 - a signed TPM quote that contains at least the PCRs from the 288 RPC are included in a 289 or ). This quote must 290 have included the nonce provided at time(NS). 292 * time(VG',EG') - this occurs when a PCR is extended subsequent to 293 time(EG). Immediately after the extension, the following 294 information needs to be pushed to the Verifier: 296 - any values extended into a PCR of interest, 298 - a signed TPM Quote showing the result the PCR extension, and 300 - and a handle (see Section 6. in 301 [I-D.ietf-rats-reference-interaction-models], which is either 302 the initially received nonce or a more recently received Epoch 303 ID (see Section 10.3. in [I-D.ietf-rats-architecture] that 304 contains a new nonce or equivalent qualified data. 306 One way to acquire a new time synchronisation that allows for the 307 reuse of the initially received nonce as a fresh handle is elaborated 308 on in the follow section Section 3.2. 310 3.2. Continuously Verifying Freshness 312 As there is no new Verifier nonce provided at time(EG'), it is 313 important to validate the freshness of TPM Quotes which are delivered 314 at that time. The method of doing this verification will vary based 315 on the capabilities of the TPM cryptoprocessor used. 317 3.2.1. TPM 1.2 Quote 319 The [RFC8639] notification format includes the object. 320 This can be used to determine the amount of time subsequent to the 321 initial subscription each notification was sent. However this time 322 is not part of the signed results which are returned from the Quote, 323 and therefore is not trustworthy as objects returned in the Quote. 324 Therefore a Verifier MUST periodically issue a new nonce, and receive 325 this nonce within a TPM quote response in order to ensure the 326 freshness of the results. This can be done using the RPC from 328 [I-D.ietf-rats-yang-tpm-charra]. 330 3.2.2. TPM 2 Quote 332 When the Attester includes a TPM2 compliant cryptoprocessor, internal 333 time-related counters are included within the signed TPM Quote. By 334 including a initial nonce in the [RFC8639] subscription request, 335 fresh values for these counters are pushed as part of the first TPM 336 Quote returned to the Verifier. And then as shown by 337 [I-D.birkholz-rats-tuda], subsequent TPM Quotes delivered to the 338 Verifier can the be appraised for freshness based on the predictable 339 incrementing of these time-related countersr. 341 The relevant internal time-related counters defined within [TPM2.0] 342 can be seen within . These counters include the 343 , , and objects. The rules 344 for appraising these objects are as follows: 346 * If the has incremented for no more than the same duration 347 as both the and the Verifier's internal time since the 348 initial time(EG) and any previous time(EG'), then the TPM Quote 349 may be considered fresh. Note that [TPM2.0] allows for +/- 15% 350 clock drift. However many chips significantly improve on this 351 maximum drift. If available, chip specific maximum drifts SHOULD 352 be considered during the appraisal process. 354 * If the , has incremented. The 355 existing subscription MUST be terminated, and a new SHOULD be generated. 358 * If a TPM Quote on any subscribed PCR has not been pushed to the 359 Verifier for a duration of an Attester defined heartbeat interval, 360 then a new TPM Quote notification should be sent to the Verifier. 361 This may often be the case, as certain PCRs might be infrequently 362 updated. 364 .----------. .--------------------------. 365 | Attester | | Relying Party / Verifier | 366 '----------' '--------------------------' 367 time(VG',EG') | 368 |------------------------------->| 369 | : | 370 ~ Heartbeat interval ~ 371 | : | 372 time(EG') : | 373 |------------------------------->| 374 | | 376 4. Remote Attestation Event Stream 378 The Event Stream is an [RFC8639] compliant Event Stream 379 which is defined within this section and within the YANG Module of 380 [I-D.ietf-rats-yang-tpm-charra]. This Event Stream contains YANG 381 notifications which carry Evidence to assists a Verifier in 382 appraising the Trustworthiness Level of an Attester. Data Nodes 383 within Section 4.6 allow the configuration of this Event Stream's 384 contents on an Attester. 386 This Event Stream may only be exposed on Attesters 387 supporting [I-D.ietf-rats-tpm-based-network-device-attest]. As with 388 [I-D.ietf-rats-tpm-based-network-device-attest], it is up to the 389 Verifier to understand which types of cryptoprocessors and keys are 390 acceptable. 392 4.1. Subscription to the Event Stream 394 To establish a subscription to an Attester in a way which provides 395 provably fresh Evidence, initial randomness must be provided to the 396 Attester. This is done via the augmentation of a into 397 [RFC8639] the RPC. Additionally, a Verifier 398 must ask for PCRs of interest from a platform. 400 augment /sn:establish-subscription/sn:input: 401 +---w nonce-value binary 402 +---w pcr-index* tpm:pcr 404 The result of the subscription will be that passing of the following 405 information: 407 1. and notifications which 408 include the provided . These attestation 409 notifications MUST at least include all the 410 requested in the RPC. 412 2. a series of notifications which reference the 413 requested PCRs on all TPM based cryptoprocessors on the Attester. 415 3. and notifications 416 generated within a few seconds of the notifications. 417 These attestation notifications MUST at least include any PCRs 418 extended. 420 If the Verifier does not want to see the logged extend operations for 421 all PCRs available from an Attester, an Event Stream Filter should be 422 applied. This filter will remove Evidence from any PCRs which are 423 not interesting to the Verifier. 425 4.2. Replaying a history of previous TPM extend operations 427 Unless it is relying on Known Good Values, a Verifier will need to 428 acquire a history of PCR extensions since the Attester has been 429 booted. This history may be requested from the Attester as part of 430 the RPC. This request is accomplished by 431 placing a very old within the original RPC 432 request. As the very old will pre-date the time 433 of Attester boot, a will be returned in 434 the RPC response, indicating when the 435 Attester booted. Immediately following the response (and before the 436 notifications above) one or more notifications which 437 document all extend operations which have occurred for the requested 438 PCRs since boot will be sent. Many extend operations to a single PCR 439 index on a single TPM SHOULD be included within a single 440 notification. 442 Note that if a Verifier has a partial history of extensions, the 443 can be adjusted so that known extensions are not 444 forwarded. 446 The end of this history replay will be indicated with the [RFC8639] 447 notification. For more on this sequence, see 448 Section 2.4.2.1 of [RFC8639]. 450 After the notification is provided, a TPM Quote 451 will be requested and the result passed to the Verifier via a 452 and notification. If there 453 have been any additional extend operations which have changed a 454 subscribed PCR value in this quote, these MUST be pushed to the 455 Verifier before the and 456 notification. 458 At this point the Verifier has sufficient Evidence appraise the 459 reported extend operations for each PCR, as well compare the expected 460 value of the PCR value against that signed by the TPM. 462 4.2.1. TPM2 Heartbeat 464 For TPM2, make sure that every requested PCR is sent within an 465 no less frequently than once per heartbeat 466 interval. This MAY be done with a single 467 notification that includes all requested PCRs every heartbeat 468 interval. This MAY be done with several 469 notifications at different times during that heartbeat interval. 471 4.3. YANG notifications placed on the Event Stream 473 4.3.1. pcr-extend 475 This notification documents when a subscribed PCR is extended within 476 a single TPM cryptoprocessor. It SHOULD be emmitted no less than the 477 after an the PCR is first extended. (The reason 478 for the marshalling is that it is quite possible that multiple 479 extensions to the same PCR have been made in quick succession, and 480 these should be reflected in the same notification.) This 481 notification MUST be emmitted prior to a or 482 notification which has included and signed the 483 results of any specific PCR extension. If pcr extending events occur 484 during the generation of the or 485 notification, the marshalling period MUST be 486 extended so that a new is not sent until the 487 corresponding notifications have been sent. 489 +---n pcr-extend 490 +--ro certificate-name certificate-name-ref 491 +--ro pcr-index-changed* tpm:pcr 492 +--ro attested-event* [] 493 +--ro attested-event 494 +--ro extended-with binary 495 +--ro (event-details)? 496 +--:(bios-event-log) {tpm:bios}? 497 | +--ro bios-event-entry* [event-number] 498 | +--ro event-number uint32 499 | +--ro event-type? uint32 500 | +--ro pcr-index? pcr 501 | +--ro digest-list* [] 502 | | +--ro hash-algo? identityref 503 | | +--ro digest* binary 504 | +--ro event-size? uint32 505 | +--ro event-data* uint8 506 +--:(ima-event-log) {tpm:ima}? 507 | +--ro ima-event-entry* [event-number] 508 | +--ro event-number uint64 509 | +--ro ima-template? string 510 | +--ro filename-hint? string 511 | +--ro filedata-hash? binary 512 | +--ro filedata-hash-algorithm? string 513 | +--ro template-hash-algorithm? string 514 | +--ro template-hash? binary 515 | +--ro pcr-index? pcr 516 | +--ro signature? binary 517 +--:(netequip-boot-event-log) {tpm:netequip_boot}? 518 +--ro boot-event-entry* [event-number] 519 +--ro event-number uint64 520 +--ro ima-template? string 521 +--ro filename-hint? string 522 +--ro filedata-hash? binary 523 +--ro filedata-hash-algorithm? string 524 +--ro template-hash-algorithm? string 525 +--ro template-hash? binary 526 +--ro pcr-index? pcr 527 +--ro signature? binary 529 Each MUST include one or more values being extended into 530 the PCR. These are passed within the object. For 531 each extension, details of the event SHOULD be provided within the 532 object. The format of any included 533 is identified by the . This document includes two YANG 534 structures which may be inserted into the . These two 535 structures are: and . 536 Implementations wanting to provide additional documentation of a type 537 of PCR extension may choose to define additional YANG structures 538 which can be placed into . 540 4.3.2. tpm12-attestation 542 This notification contains an instance of a TPM1.2 style signed 543 cryptoprocessor measurement. It is supplemented by Attester 544 information which is not signed. This notification is generated and 545 emitted from an Attester when at least one PCR identified within the 546 subscribed has changed from the previous 547 notification. This notification MUST NOT include 548 the results of any PCR extensions not previously reported by a . This notification SHOULD be emitted as soon as a TPM Quote 550 can extract the latest PCR hashed values. This notification MUST be 551 emitted prior to a subsequent . 553 +---n tpm12-attestation {taa:TPM12}? 554 +--ro certificate-name tpm:certificate-name-ref 555 +--ro up-time? uint32 556 +--ro TPM_QUOTE2? binary 557 +--ro TPM12-hash-algo? identityref 558 +--ro unsigned-pcr-values* [] 559 +--ro pcr-index* tpm:pcr 560 +--ro pcr-value* binary 562 All YANG objects above are defined within 563 [I-D.ietf-rats-yang-tpm-charra]. The is not 564 replayable. 566 4.3.3. tpm20-attestation 568 This notification contains an instance of TPM2 style signed 569 cryptoprocessor measurements. It is supplemented by Attester 570 information which is not signed. This notification is generated at 571 two points in time: 573 * every time at least one PCR has changed from a previous 574 tpm20-attestation. In this case, the notification SHOULD be 575 emitted within 10 seconds of the corresponding being 576 sent: 578 * after a locally configurable minimum heartbeat period since a 579 previous tpm20-attestation was sent. 581 +---n tpm20-attestation {taa:TPM20}? 582 +--ro certificate-name tpm:certificate-name-ref 583 +--ro TPMS_QUOTE_INFO binary 584 +--ro quote-signature? binary 585 +--ro up-time? uint32 586 +--ro unsigned-pcr-values* [] 587 +--ro TPM20-hash-algo? identityref 588 +--ro pcr-values* [pcr-index] 589 +--ro pcr-index pcr 590 +--ro pcr-value? binary 592 All YANG objects above are defined within 593 [I-D.ietf-rats-yang-tpm-charra]. The is not 594 replayable. 596 4.4. Filtering Evidence at the Attester 598 It can be useful _not_ to receive all Evidence related to a PCR. An 599 example of this is would be a when a Verifier maintains known good 600 values of a PCR. In this case, it is not necessary to send each 601 extend operation. 603 To accomplish this reduction, when an RFC8639 RPC is sent, a as per RFC8639, 605 Section 2.2 can be set to discard a notification when 606 the is uninteresting to the verifier. 608 4.5. Replaying previous PCR Extend events 610 To verify the value of a PCR, a Verifier must either know that the 611 value is a known good value [KGV] or be able to reconstruct the hash 612 value by viewing all the PCR-Extends since the Attester rebooted. 613 Wherever a hash reconstruction might be needed, the 614 Event Stream MUST support the RFC8639 feature. Through the 615 feature, it is possible for a Verifier to retrieve and 616 sequentially hash all of the PCR extending events since an Attester 617 booted. And thus, the Verifier has access to all the evidence needed 618 to verify a PCR's current value. 620 4.6. Configuring the Event Stream 622 Figure 2 is tree diagram which exposes the operator configurable 623 elements of the Event Stream. This allows an Attester 624 to select what information should be available on the stream. A 625 fetch operation also allows an external device such as a Verifier to 626 understand the current configuration of stream. 628 Almost all YANG objects below are defined via reference from 629 [I-D.ietf-rats-yang-tpm-charra]. There is one object which is new 630 with this model however. defines the maximum amount 631 of time which should pass before a subscriber to the Event Stream 632 should get a notification from devices which 633 contain a TPM2. 635 augment /tpm:rats-support-structures: 636 +--rw tras:marshalling-period? uint8 637 +--rw tras:tpm12-subscribed-signature-scheme? 638 | -> ../tpm:attester-supported-algos/tpm12-asymmetric-signing 639 | {taa:TPM12}? 640 +--rw tras:tpm20-subscribed-signature-scheme? 641 | -> ../tpm:attester-supported-algos/tpm20-asymmetric-signing 642 | {taa:TPM20}? 643 +--rw tras:tpm20-subscription-heartbeat? uint16 644 {taa:TPM20}? 646 augment /tpm:rats-support-structures/tpm:tpms: 647 +--rw tras:subscription-aik? tpm:certificate-name-ref 648 +--rw (tras:subscribable)? 649 +--:(tras:tpm12-stream) {taa:tpm12}? 650 | +--rw tras:tpm12-hash-algo? identityref 651 | +--rw tras:tpm12-pcr-index* tpm:pcr 652 +--:(tras:tpm20-stream) {taa:tpm20}? 653 +--rw tras:tpm20-hash-algo? identityref 654 +--rw tras:tpm20-pcr-index* tpm:pcr 656 Figure 2: Configuring the \ Event Stream 658 5. YANG Module 660 This YANG module imports modules from [I-D.ietf-rats-yang-tpm-charra] 661 and [RFC8639]. It is also work-in-progress. 663 ietf-rats-attestation-stream@2021-05-11.yang 664 module ietf-tpm-remote-attestation-stream { 665 yang-version 1.1; 666 namespace 667 "urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation-stream"; 668 prefix tras; 670 import ietf-subscribed-notifications { 671 prefix sn; 672 reference 673 "RFC 8639: Subscription to YANG Notifications"; 674 } 675 import ietf-tpm-remote-attestation { 676 prefix tpm; 677 reference 678 "draft-ietf-rats-yang-tpm-charra"; 679 } 680 import ietf-tcg-algs { 681 prefix taa; 682 } 684 organization "IETF"; 685 contact 686 "WG Web: 687 WG List: 688 Editor: Eric Voit 689 "; 691 description 692 "This module contains conceptual YANG specifications for 693 subscribing to attestation streams being generated from TPM chips. 695 Copyright (c) 2021 IETF Trust and the persons identified 696 as authors of the code. All rights reserved. 697 Redistribution and use in source and binary forms, with 698 or without modification, is permitted pursuant to, and 699 subject to the license terms contained in, the Simplified 700 BSD License set forth in Section 4.c of the IETF Trust's 701 Legal Provisions Relating to IETF Documents 702 (https://trustee.ietf.org/license-info). 703 This version of this YANG module is part of RFC XXXX 704 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 705 itself for full legal notices."; 707 revision 2021-05-11 { 708 description 709 "Initial version."; 710 reference 711 "draft-birkholz-rats-network-device-subscription"; 712 } 714 /* 715 * IDENTITIES 716 */ 718 identity pcr-unsubscribable { 719 base sn:establish-subscription-error; 720 description 721 "Requested PCR is subscribable by the Attester."; 722 } 724 /* 725 * Groupings 726 */ 728 grouping heartbeat { 729 description 730 "Allows an Attester to push verifiable, current TPM PCR values 731 even when there have been no recent changes to PCRs."; 732 leaf tpm20-subscription-heartbeat { 733 type uint16; 734 description 735 "Number of seconds before the Attestation stream should send a 736 new notification with a fresh quote. This allows confirmation 737 that the PCR values haven't changed since the last 738 tpm20-attestation."; 739 } 740 } 742 /* 743 * RPCs 744 */ 746 augment "/sn:establish-subscription/sn:input" { 747 when 'derived-from-or-self(sn:stream, "attestation")'; 748 description 749 "This augmentation adds a nonce to as a subscription parameters 750 that apply specifically to datastore updates to RPC input."; 751 uses tpm:nonce; 752 leaf-list pcr-index { 753 type tpm:pcr; 754 min-elements 1; 755 description 756 "The numbers/indexes of the PCRs. This will act as a filter for 757 the subscription so that 'tpm-extend' notifications related to 758 non-requested PCRs will not be sent to a subscriber."; 759 } 760 } 762 /* 763 * NOTIFICATIONS 764 */ 766 notification pcr-extend { 767 description 768 "This notification indicates that one or more PCRs have been 769 extended within a TPM based cryptoprocessor. In less than the 770 'marshalling-period', it MUST be followed with either a 771 corresponding tpm12-attestation or tpm20-attestation notification 772 which exposes the result of the PCRs updated."; 773 uses tpm:certificate-name-ref; 774 leaf-list pcr-index-changed { 775 type tpm:pcr; 776 min-elements 1; 777 description 778 "The number of each PCR extended. This list MUST contain the 779 set of PCRs descibed within the event log details. This leaf 780 can be derived from the list of attested events, but exposing 781 it here allows for easy filtering of the notifications of 782 interest to a verifier."; 783 } 784 list attested-event { 785 description 786 "A set of events which extended an Attester PCR. The sequence 787 of elements represented in list must match the sequence of 788 events placed into the TPM's PCR."; 789 container attested-event { 790 description 791 "An instance of an event which extended an Attester PCR"; 792 leaf extended-with { 793 type binary; 794 mandatory true; 795 description 796 "Information extending the PCR."; 797 } 798 choice event-details { 799 description 800 "Contains the event happened the Attester thought 801 was worthy of recording in a PCR. 803 choices are of types defined by the identityref 804 base tpm:attested_event_log_type"; 806 case bios-event-log { 807 if-feature "tpm:bios"; 808 description 809 "BIOS/UEFI event log format"; 810 uses tpm:bios-event-log; 811 } 812 case ima-event-log { 813 if-feature "tpm:ima"; 814 description 815 "IMA event log format"; 816 uses tpm:ima-event-log; 817 } 818 case netequip-boot-event-log { 819 if-feature "tpm:netequip_boot"; 820 description 821 "IMA event log format"; 822 uses tpm:network-equipment-boot-event-log; 823 } 824 } 825 } 826 } 827 } 829 notification tpm12-attestation { 830 if-feature "taa:tpm12"; 831 description 832 "Contains an instance of TPM1.2 style signed cryptoprocessor 833 measurements. It is supplemented by unsigned Attester 834 information."; 835 leaf certificate-name { 836 type tpm:certificate-name-ref; 837 mandatory true; 838 description 839 "Allows a TPM quote to be associated with a certificate."; 840 } 841 uses tpm:tpm12-attestation; 842 uses tpm:tpm12-hash-algo; 843 list unsigned-pcr-values { 844 description 845 "Allows notifications to be filtered by PCR number or 846 PCR value based on via YANG related mechanisms such as PATH. 847 This is done without requiring the filtering structure to be 848 applied against TCG structured data."; 849 leaf-list pcr-index { 850 type tpm:pcr; 851 min-elements 1; 852 description 853 "PCR index number."; 855 } 856 leaf-list pcr-value { 857 type binary; 858 description 859 "PCR value in a sequence which matches to the 'pcr-index'."; 860 } 861 } 862 } 864 notification tpm20-attestation { 865 if-feature "taa:tpm20"; 866 description 867 "Contains an instance of TPM2 style signed cryptoprocessor 868 measurements. It is supplemented by unsigned Attester 869 information."; 870 leaf certificate-name { 871 type tpm:certificate-name-ref; 872 mandatory true; 873 description 874 "Allows a TPM quote to be associated with a certificate."; 875 } 876 uses tpm:tpm20-attestation { 877 description 878 "Provides the attestation info. Also ensures PCRs can be XPATH 879 filtered by refining the unsigned data so that it appears."; 880 refine unsigned-pcr-values { 881 min-elements 1; 882 } 883 refine unsigned-pcr-values/pcr-values { 884 min-elements 1; 885 } 886 } 887 } 889 /* 890 * DATA NODES 891 */ 893 augment "/tpm:rats-support-structures" { 894 description 895 "Defines platform wide 'attestation' stream subscription 896 parameters."; 897 leaf marshalling-period { 898 type uint8; 899 default 5; 900 description 901 "The maximum number of seconds between the time an event 902 extends a PCR, and the 'tpm-extend' notification which reports 903 it to a subscribed Verifier. This period allows multiple 904 extend operations bundled together and handled as a group."; 905 } 906 leaf tpm12-subscribed-signature-scheme { 907 if-feature "taa:tpm12"; 908 type leafref { 909 path "../tpm:attester-supported-algos" + 910 "/tpm:tpm12-asymmetric-signing"; 911 } 912 description 913 "A single signature-scheme which will be used to sign the 914 evidence from a TPM 1.2. which is then placed onto the 915 'attestation' event stream."; 916 } 917 leaf tpm20-subscribed-signature-scheme { 918 if-feature "taa:tpm20"; 919 type leafref { 920 path "../tpm:attester-supported-algos" + 921 "/tpm:tpm20-asymmetric-signing"; 922 } 923 description 924 "A single signature-scheme which will be used to sign the 925 evidence from a TPM 2.0. which is then placed onto the 926 'attestation' event stream."; 927 } 928 uses heartbeat{ 929 if-feature "taa:tpm20"; 930 } 931 } 933 augment "/tpm:rats-support-structures/tpm:tpms" { 934 description 935 "Allows the configuration 'attestation' stream parameters for a 936 TPM."; 937 leaf subscription-aik { 938 type tpm:certificate-name-ref; 939 description 940 "Identifies the certificate-name associated with the 941 notifications in the 'attestation' stream."; 942 } 943 choice subscribable { 944 config true; 945 description 946 "Indicates that the set of notifications which comprise the 947 'attestation' event stream can be modified or tuned by a 948 network administrator."; 949 case tpm12-stream { 950 if-feature "taa:tpm12"; 951 description 952 "Configuration elements for a TPM1.2 event stream."; 953 uses tpm:tpm12-hash-algo; 954 leaf-list tpm12-pcr-index { 955 type tpm:pcr; 956 description 957 "The numbers/indexes of the PCRs which can be subscribed."; 958 } 959 } 960 case tpm20-stream { 961 if-feature "taa:tpm20"; 962 description 963 "Configuration elements for a TPM2.0 event stream."; 964 uses tpm:tpm20-hash-algo; 965 leaf-list tpm20-pcr-index { 966 type tpm:pcr; 967 description 968 "The numbers/indexes of the PCRs which can be subscribed."; 969 } 970 } 971 } 972 } 973 } 974 976 6. Event Streams for Conceptual Messages 978 Analogous to the [RFC8639] compliant Event Stream for 979 the conveyance of remote attestation Evidence as defined in 980 Section Section 4, additional Event Streams can be defined for this 981 YANG augment. Additional Event Streams require separate YANG augment 982 specifications that provide the Event Stream definition and 983 optionally a content format definition either via subscriptions to 984 YANG datastores or dedicated YANG Notifications. It is possible to 985 use either YANG subscription methods to other YANG modules for RATS 986 Conceptual Messages or to define Event Streams for other none-YANG- 987 modeled data. In the context of RATS Conceptual Messages, both 988 options MUST be a specified via YANG augments to this specification. 990 7. Security Considerations 992 To be written. 994 8. IANA Considerations 996 To be written. 998 9. References 1000 9.1. Normative References 1002 [I-D.ietf-rats-architecture] 1003 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 1004 W. Pan, "Remote Attestation Procedures Architecture", Work 1005 in Progress, Internet-Draft, draft-ietf-rats-architecture- 1006 15, 8 February 2022, . 1009 [I-D.ietf-rats-reference-interaction-models] 1010 Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference 1011 Interaction Models for Remote Attestation Procedures", 1012 Work in Progress, Internet-Draft, draft-ietf-rats- 1013 reference-interaction-models-05, 26 January 2022, 1014 . 1017 [I-D.ietf-rats-tpm-based-network-device-attest] 1018 Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- 1019 based Network Device Remote Integrity Verification", Work 1020 in Progress, Internet-Draft, draft-ietf-rats-tpm-based- 1021 network-device-attest-13, 1 March 2022, 1022 . 1025 [I-D.ietf-rats-yang-tpm-charra] 1026 Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen, 1027 B., (Frank), L. X., Laffey, T., and G. C. Fedorkow, "A 1028 YANG Data Model for Challenge-Response-based Remote 1029 Attestation Procedures using TPMs", Work in Progress, 1030 Internet-Draft, draft-ietf-rats-yang-tpm-charra-16, 2 1031 March 2022, . 1034 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1035 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1036 May 2017, . 1038 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1039 E., and A. Tripathy, "Subscription to YANG Notifications", 1040 RFC 8639, DOI 10.17487/RFC8639, September 2019, 1041 . 1043 [TPM2.0] TCG, "TPM 2.0 Library Specification", n.d., 1044 . 1047 9.2. Informative References 1049 [I-D.birkholz-rats-tuda] 1050 Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann, 1051 "Time-Based Uni-Directional Attestation", Work in 1052 Progress, Internet-Draft, draft-birkholz-rats-tuda-06, 12 1053 January 2022, . 1056 [KGV] TCG, "KGV", October 2003, 1057 . 1060 Appendix A. Change Log 1062 v00-v01 1064 * minor updates, party based on the dependent Charra going through 1065 IESG. 1067 Acknowledgements 1069 Thanks to ... 1071 Authors' Addresses 1073 Henk Birkholz 1074 Fraunhofer SIT 1075 Rheinstrasse 75 1076 64295 Darmstadt 1077 Germany 1078 Email: henk.birkholz@sit.fraunhofer.de 1080 Eric Voit 1081 Cisco Systems, Inc. 1082 Email: evoit@cisco.com 1084 Wei Pan 1085 Huawei Technologies 1086 101 Software Avenue, Yuhuatai District 1087 Nanjing, Jiangsu 1088 210012 1089 China 1090 Email: william.panwei@huawei.com