idnits 2.17.1 draft-voit-rats-trusted-path-routing-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 20 instances of too long lines in the document, the longest one being 6 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 641 has weird spacing: '...E-value uin...' -- The document date (March 09, 2020) is 1508 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-02 ** 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-YANG' == Outdated reference: A later version (-07) exists of draft-birkholz-rats-tuda-01 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-08 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-06 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group E. Voit 3 Internet-Draft Cisco 4 Intended status: Standards Track March 09, 2020 5 Expires: September 10, 2020 7 Trusted Path Routing using Remote Attestation 8 draft-voit-rats-trusted-path-routing-01 10 Abstract 12 There are end-users who believe encryption technologies like IPSec 13 alone are insufficient to protect the confidentiality of their highly 14 sensitive traffic flows. This specification describes two 15 alternatives for protecting these sensitive flows as they transit a 16 network. In both alternatives, protection is accomplished by 17 forwarding sensitive flows across network devices currently appraised 18 as trustworthy. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 10, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4 58 3. Centralized Trusted Path Routing . . . . . . . . . . . . . . 4 59 4. Distributed Trusted Path Routing . . . . . . . . . . . . . . 6 60 4.1. Trusted Topology . . . . . . . . . . . . . . . . . . . . 6 61 4.2. Passport with Composite Evidence . . . . . . . . . . . . 6 62 5. Attestation Event Stream . . . . . . . . . . . . . . . . . . 10 63 5.1. Subscribing to the stream . . . . . . . . . . . . . . . . 10 64 5.2. YANG notifications placed on the Event Stream . . . . . . 11 65 5.3. Pre-filtering the Event Stream . . . . . . . . . . . . . 13 66 5.4. Replaying previous PCR Extend events. . . . . . . . . . . 14 67 5.5. Configuring the Attestation Event Stream . . . . . . . . 14 68 6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 7. Passport Protocol Bindings . . . . . . . . . . . . . . . . . 22 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 73 9.2. Informative References . . . . . . . . . . . . . . . . . 26 74 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27 75 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 27 76 Appendix C. Open Questions . . . . . . . . . . . . . . . . . . . 27 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 79 1. Introduction 81 There are end-users who believe encryption technologies like IPSec 82 alone are insufficient to protect the confidentiality of their highly 83 sensitive traffic flows. These customers want their highly sensitive 84 flows to be transported over only network devices recently verified 85 as trustworthy. 87 With the inclusion of cryptoprocessor hardware into network devices, 88 it is now possible for network providers to identify those network 89 devices which have potentially exploitable or even exploited 90 vulnerabilities. Using this knowledge, it then becomes possible to 91 redirect sensitive flows around these potentially compromised 92 devices. 94 This specification describes two architectural alternatives for 95 exchanging traffic with end-user customer identified "sensitive 96 subnets". Traffic going to and from these subnets will transit a 97 path where the IP layer and above are only interpretable by those 98 network devices recently evaluated as trustworthy. These two 99 architectural alternatives are: 101 1. Centralized Trusted Path Routing - For sensitive subnets, trusted 102 end-to-end paths are pre-assigned through a network provider 103 domain. Along these paths, attestation evidence of potentially 104 transited components has been assessed. Each path is guaranteed 105 to only include devices meeting the needs of a formally defined 106 trustworthiness level. 108 2. Distributed Trusted Path Routing - Through the exchange of 109 attestation evidence between peering network devices, a trusted 110 topology is established and maintained. Only devices meeting the 111 needs of a formally defined trustworthiness level are included as 112 members of this topology. Traffic exchanged with sensitive 113 subnets is forwarded into this topology. 115 Beyond the definition of these two architectural alternatives, 116 incremental technology enhancements needed for each are also 117 specified within this document. The specification works under the 118 assumptions that cryptoprocessors capable of supporting [TPM1.2] or 119 [TPM2.0] interface specifications are available on each network 120 device, and the device supports the concepts of remote attestation 121 laid out in [RATS-Device]. 123 2. Terminology 125 2.1. Terms 127 The following terms are imported from [I-D.ietf-rats-architecture]: 128 Attester, Composite Evidence, Evidence, Passport, Relying Party, and 129 Verifier. 131 The following terms at imported from [RFC8639]: Event Stream. 133 Newly defined terms for this document: 135 Attested Device - a device where a Verifier's most recent appraisal 136 of attestation evidence has successfully met the criteria for a 137 specific Trustworthiness Level. Attested Devices cannot be 138 appraised as unverified or compromised. 140 Sensitive Subnet - an IP address range where IP packets to or from 141 that range must only have their IP headers and encapsulated 142 payloads accessible/visible only by Attested Devices. 144 Transparently-Transited Device - a network device within an IGP 145 domain where any packets passed into that IGP domain are 146 completely opaque at Layer 3 and above. 148 Trusted Topology - A topology which includes only Attested Devices 149 and Transparently-Transited Devices. 151 Trustworthiness Level - a specific grade of trust earned by a 152 device. The grade for a device is assigned by a Verifier during 153 the appraisal process and can be returned within Attestation 154 Results. Example levels include boot-verified, unverified and 155 compromised. (Note: significant discussion will be needed to 156 agree on definitions of these levels.) 158 2.2. Requirements Notation 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in 163 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 164 capitals, as shown here. 166 3. Centralized Trusted Path Routing 168 With this architectural alternative, a controller-based Verifier 169 ensures communications with Sensitive Subnets traverses a Trusted 170 Topology within the controller's IGP domain. To do this, the 171 Verifier continuously acquires Evidence about each potentially 172 transited device. This access is done via the context established 173 within [RATS-Device]. The controller then appraises all available 174 Evidence and decides on a Trustworthiness Level for each device. 175 Using the set of all appraisals, the controller identifies end-to-end 176 path(s) which avoid any devices with an insufficient Trustworthiness 177 Level. Finally, the controller provisions Sensitive Subnets to use 178 just these end-to-end paths. 180 Evidence passed to the Verifier which are used to establish a 181 device's Trustworthiness Level will include but is not limited to: 183 o An Attester's security measurements being extended into [TPM1.2] 184 or [TPM2.0] compliant Platform Configuration Registers (PCR). 186 o An Attester's current PCR measurements. 188 It is the consideration of all Evidence which allows the 189 establishment and maintenance of a Trustworthiness Level. Note that 190 it is outside the scope of this specification to include algorithms 191 for determining a Trustworthiness Level. 193 The prerequisites for this solution are: 195 1. Customer designated Sensitive Subnet ranges and their demanded 196 Trustworthiness Levels have been identified and associated with 197 external interfaces to/from the edge of an IGP domain. 199 2. A Verifier which can continuously acquire Evidence and appraise 200 the Trustworthiness Levels of all network devices within the IGP 201 domain. 203 3. A Verifier which continuously optimizes a set of network paths/ 204 tunnels. These paths must traverse only Attested Devices or 205 Transparently-Transited Devices while on their way to an egress 206 interface for an IGP Domain. 208 4. A Verifier which can provision and maintain the set of Sensitive 209 Subnets associated with specific network paths/tunnels. 211 Figure 1 provides a network diagram of where these four sit within a 212 network topology. 214 .------------------------------------------------. 215 | Verifier + Relying Party (3) | 216 '------------------------------------------------' 217 (4) ^ ^ ^ ^ ^ (4) 218 | | (2) | | | | 219 | | .-------. | | (2) V 220 V (2) |Hacked | (2) (2) .--------. 221 .--------. |Router | .-------. .-------. | Edge | 222 | Edge | |(Attest| |Router | |Switch | | Router | 223 | Router | | =Fail)| |(Attest| |(Attest| | (Attest| 224 | | '-------' | =OK) | | =OK) | | =OK) | 225 (1) path==================================> (1)--- Sensitive 226 | <==================================path | Subnet 227 '--------' '-------' '-------' '--------' 229 Figure 1: Centralized Trusted Path Routing 231 The feature functionality describing how to achieve (1), (3), and (4) 232 are outside the scope of this specification. The reasoning is that 233 each of these can be accomplished via existing standard-based or 234 standards-track technologies. For example, in step (4), it is 235 possible for a Verifier to provision each ingress device with the set 236 of Sensitive Subnets for which traffic would be placed into a 237 specific [I-D.ietf-idr-segment-routing-te-policy] tunnel. 239 The new requirements which need to be supported for this 240 specification come from prerequisite (2). To accomplish prerequisite 241 (2), it is necessary for each network device to stream changes in 242 Evidence to a Verifier. This can be accomplished by the Verifier 243 establishing an [RFC8639] subscription to the Event 244 Stream described in Section 5 below within this document. 246 With this new Event Stream, a Verifier can consume and 247 continuously determine the Trustworthiness Level of various network 248 devices within the IGP domain. Maintaining this information allows 249 the Controller to calculate an appropriate network path (3). 251 4. Distributed Trusted Path Routing 253 4.1. Trusted Topology 255 With this architectural alternative, Composite Evidence is assembled 256 into a passport [I-D.ietf-rats-architecture] by the Attester network 257 device. Upon receiving this passport as part of link layer 258 authentication credentials, a peer Relying Party decides if this 259 Attester is trustworthy enough to be an Attested Device. It also 260 appraises its Trustworthiness Level. If found trustworthy, the 261 relevant link is included into any Trusted Topologies capable of 262 supporting that Trustworthiness Level. 264 When enough links have been included, a Trusted Topology will now 265 exist for a specified Trustworthiness Level. And traffic exchanged 266 with Sensitive Subnets can be forwarded into that Trusted Topology 267 from all edges of an IGP domain. 269 .--------. .---------. 270 | Hacked | | Edge | 271 .---------. | Router | | Router | 272 | Router | | | | | 273 | | | trust>---------------===============| | 366 | '-----' | Composite Evidence | (5) | 367 '-------------' '---------------' 369 Figure 3: Distributed Trusted Path Passport Generation and Delivery 371 In Figure 3 above, Evidence from a TPM1.2 or TPM2.0 is generated and 372 signed by that TPM. This Evidence is appraised by Verifier A, and 373 the Attester is given a Trustworthiness Level which is signed and 374 returned as Attestation Results to the Attester. Later, when a 375 request comes in from a Relying Party, the Attester assembles and 376 returns three independently signed elements of Evidence. These three 377 comprise the Composite Evidence which when taken together allow 378 Verifier B to appraise the current Trustworthiness Level of the 379 Attester. 381 More details on the mechanisms used in the construction and 382 verification of the passport match to the numbered steps of Figure 3: 384 1. An Attester sends a signed TPM Quote which includes PCR 385 measurements to Verifier A at time(x). 387 2. Verifier A appraises (1), then sends the following items back to 388 that Attester as Attestation Results: 390 1. the appraised Trustworthiness Level of an Attester, 392 2. the signature from the TPM Quote of (1), 394 3. a Verifier signature across (2.1) and (2.2). 396 3. A nonce known to the Relying Party is received by the Attester at 397 time(y). 399 4. The Attester generates and sends a passport. The encapsulated 400 Composite Evidence includes: 402 1. (1) 404 2. (2) 406 3. New signed, verifiably fresh PCR measurements at time(y), 407 which incorporates the nonce from (3). 409 5. On receipt of (4), the Relying Party makes its determination of 410 how the Composite Evidence will impact adjacencies within a 411 Trusted Topology. The decision process is: 413 1. Verify that (4.3) includes the nonce from (3). 415 2. Verify the TPM signature within (4.2) matches the signature 416 of (4.1). 418 3. Validate the signatures of (4.1), (4.2), (4.3). 420 4. Failure of (5.1), (5.2), or (5.3) means the link should be 421 assigned a Trustworthiness Level, and 422 additionally jump to step (5.8). 424 5. If selected PCR values of (1) match (4.3), then Relying Party 425 can accept (2.1) as the link's Trustworthiness Level. 427 6. When the PCR values are different, and not much time has 428 passed between time(x) and time(y), the Relying Party can 429 either accept any previous Trustworthiness Level, or attempt 430 to acquire a new passport. In many cases, it should only be 431 a few seconds before a new Attestation Results should be 432 delivered to an Attester via (2). 434 7. When the PCR values are different, but there is a large time 435 gap between time(x) and time(y), the link should be assigned 436 an Trustworthiness Level. 438 8. Based on the link's Trustworthiness Level, add or remove it 439 from the appropriate Trusted Topology. 441 5. Attestation Event Stream 443 The Event Stream is an [RFC8639] complaint Event Stream 444 which is defined within this section and within the YANG Module of 445 Section 6. The Event Stream contains YANG notifications which carry 446 Evidence which assists a Verifier in appraising the Trustworthiness 447 Level of an Attester. Data Nodes allow the configuration of this 448 Event Stream's contents on a particular Attester. 450 This Event Stream may only be exposed on Attesters 451 capable of signing cryptoprocessor PCRs using a private key 452 unavailable elsewhere within the Attester. There is not a 453 requirement that the underlying cryptoprocessor of the Attester has 454 undergone TCG certification. 456 5.1. Subscribing to the stream 458 To establish the subscription in a way which results in provably 459 fresh Evidence, randomness must be provided to the Attester. One way 460 this can be done for an [RFC8639] dynamic subscriptions is via the 461 augmentation of the RPC: 463 augment /sn:establish-subscription/sn:input: 464 +---w nonce-value? binary 466 As part of the response to the , a YANG 467 notification defined in this document is retuned. This notification 468 MUST incorporate the randomness provided by the . By 469 including this YANG notification in the response, critical 470 measurements are delivered in a way which provides protection against 471 replay attacks. Additionally, the Verifier has immediate access to 472 current measurements. 474 augment /sn:establish-subscription/sn:output: 475 +--ro latest-attestation 476 +--(instance of or ) 478 It is also possible to subscribe to the Event Stream 479 via an [RFC8639] configured subscription. In this case the Verifier 480 needs some proof of Evidence freshness. Where a TPM2 exists, this 481 may be accomplished via the creation and exposure of a Sync-Token as 482 described in [I-D.birkholz-rats-tuda]. For any type of TPM, 483 centrally created nonces could by signed, and broacast to both the 484 Attester and Verifier. 486 5.2. YANG notifications placed on the Event Stream 488 5.2.1. tpm-extend 490 This notification is generated every time a PCR is extended within a 491 cryptoprocessor. The notification contains a list of the one or more 492 strings which have extended a PCR. 494 +--n tpm-extend 495 +--ro tpm_name string 496 +--ro tpm-physical-index? int32 {ietfhw:entity-mib}? 497 +--ro pcr-index-changed uint8 498 +--ro extended-with* binary 500 All notifications since boot MUST be retained, and replayable. 502 5.2.2. tpm12-attestation 504 This notification contains an instance of a TPM1.2 style signed 505 cryptoprocessor measurement. It is supplemented by Attester 506 information which is not signed. This notification is generated and 507 emitted from an Attester every time at least one PCR identified 508 within the has changed from the previous 509 notification: 511 +---n tpm12-attestation 512 +--ro tpm_name? string 513 +--ro up-time? uint32 514 +--ro node-name? string 515 +--ro node-physical-index? int32 {ietfhw:entity-mib}? 516 +--ro fixed? binary 517 +--ro external-data? binary 518 +--ro signature-size? uint32 519 +--ro signature? binary 520 +--ro (tpm12-quote) 521 +--:(tpm12-quote1) 522 | +--ro version* [] 523 | | +--ro major? uint8 524 | | +--ro minor? uint8 525 | | +--ro revMajor? uint8 526 | | +--ro revMinor? uint8 527 | +--ro digest-value? binary 528 | +--ro TPM_PCR_COMPOSITE* [] 529 | +--ro pcr-indices* uint8 530 | +--ro value-size? uint32 531 | +--ro tpm12-pcr-value* binary 532 +--:(tpm12-quote2) 533 +--ro tag? uint8 534 +--ro pcr-indices* uint8 535 +--ro locality-at-release? uint8 536 +--ro digest-at-release? binary 538 The vast majority of the YANG objects above are defined within 539 [RATS-YANG]. As a result, these objects are not redefined in this 540 draft. The objects which are new include: 542 o pcr-index-changed* - this is a list of a PCRs which have new 543 values since the last notification. 545 o pcr-index-attested* - this is a list of all the PCRs contained in 546 the . 548 Only the most recent is replayable. All others 549 are discarded from the Event Stream history. 551 Note that this notification alone does not fully handle replay attack 552 protection for Centralized Trusted Path Routing. As a result, a 553 Verifier MUST periodically receive a nonce based TPM1.2 style quote 554 response. This can be done in several ways including via the RPC specified in [RATS-YANG]. This 556 periodic query allows a synching on the freshness of the results. 557 Such a periodic synching is not required for the Distributed Trusted 558 Path Routing architecture as the nonce based quote at time(y) proves 559 the freshness of every passport. 561 5.2.3. tpm20-attestation 563 This notification contains an instance of TPM2 style signed 564 cryptoprocessor measurements. It is supplemented by Attester 565 information which is not signed. This notification is generated at 566 two points in time: 568 o every time at least one PCR has changed from a previous 569 tpm20-attestation. 571 o after a locally configurable minimum heartbeat period since a 572 previous tpm20-attestation was sent. This heartbeat is 573 identifiable as the will be missing from the 574 notification. As a result, there is no need to match it to one or 575 more notifications. 577 Only the most recent is replayable. All others 578 are discarded from the Event Stream history. 580 Note that [RATS-YANG] does not yet include the full set of [TPM2.0] 581 objects. As soon as [RATS-YANG] is updated with the necessary 582 information, a new version of this draft will include a tree diagram 583 which identifies those objects within this notification. 585 5.3. Pre-filtering the Event Stream 587 It is possible for a receive just those PCR changes of interest from 588 an Attester. To accomplish this, a RFC8639 589 RPC is made against the Event Stream. To limit the set 590 of notifications, a as per RFC8639, Section 2.2 can 591 be set to select the following: 593 o each containing a of a desired 594 PCR 596 o each containing a of a 597 desired PCR 599 o each containing a of a 600 desired PCR 602 5.4. Replaying previous PCR Extend events. 604 To verify the value of a PCR, a Verifier must either know that the 605 value is a known good value [KGV] or be able to reconstruct the hash 606 value by viewing all the PCR-Extends since the Attester rebooted. 607 Wherever a hash reconstruction might be needed, the 608 Event Stream MUST support the RFC8639 feature. Through the 609 feature, it is possible for a Verifier to retrieve and 610 sequentially hash all of the PCR extending events since an Attester 611 booted. And thus, the Verifier has access to all the evidence needed 612 to verify a PCR's current value. 614 5.5. Configuring the Attestation Event Stream 616 Figure 4 is tree diagram which exposes the configurable elements of 617 the Event Stream. This allows an Attester to select 618 what information should be available on the stream. A fetch 619 operation also allows an external device such as a Verifier to 620 understand the current configuration of stream. 622 The majority of the YANG objects below are defined via reference from 623 [RATS-YANG]. 625 +--rw attestation-config! 626 +--rw tpm12-stream 627 | +--rw tpm12-stream-config* [tpm_name] 628 | | +--rw tpm_name string 629 | | +--rw pcr-indices* uint8 630 | | +--rw (key-identifier)? 631 | | +--:(public-key) 632 | | | +--rw pub-key-id? binary 633 | | +--:(TSS_UUID) 634 | | +--rw TSS_UUID-value 635 | | +--rw ulTimeLow? uint32 636 | | +--rw usTimeMid? uint16 637 | | +--rw usTimeHigh? uint16 638 | | +--rw bClockSeqHigh? uint8 639 | | +--rw bClockSeqLow? uint8 640 | | +--rw rgbNode* uint8 641 | +--rw TPM_SIG_SCHEME-value uint8 642 +--rw tpm20-stream 643 +--rw tpm20-stream-config* [tpm_name] 644 | +--rw tpm_name string 645 | +--rw pcr-list* [pcr-index] 646 | | +--rw pcr-index uint8 647 | | +--rw (algo-registry-type) 648 | | +--:(tcg) 649 | | | +--rw tcg-hash-algo-id? uint16 650 | | +--:(ietf) 651 | | +--rw ietf-ni-hash-algo-id? uint8 652 | +--rw (key-identifier)? 653 | +--:(public-key) 654 | | +--rw pub-key-id? binary 655 | +--:(uuid) 656 | +--rw uuid-value? binary 657 +--rw (signature-identifier-type) 658 | +--:(TPM_ALG_ID) 659 | | +--rw TPM_ALG_ID-value? uint16 660 | +--:(COSE_Algorithm) 661 | +--rw COSE_Algorithm-value? int32 662 +--rw tpm2-heartbeat? uint8 664 Figure 4: Configuring the Attestation Stream 666 There is one object which is new with this model however. 667 defines the maximum amount of time which should pass 668 before a subscriber to the event stream should get a 669 notification from devices which contain a TPM2. 671 If there is no configuration of any information within 672 this model, all subscriptions should be rejected with an [RFC8639] 673 reason of . 675 6. YANG Module 677 This YANG module imports modules from [RATS-YANG] and [RFC8639]. It 678 is also work-in-progress. 680 ietf-rats-attestation-stream@2020-03-06.yang 681 module ietf-rats-attestation-stream { 682 yang-version 1.1; 683 namespace 684 "urn:ietf:params:xml:ns:yang:ietf-rats-attestation-stream"; 685 prefix ats; 687 import ietf-subscribed-notifications { 688 prefix sn; 689 reference 690 "RFC 8639: Subscription to YANG Notifications"; 691 } 692 import ietf-tpm-remote-attestation { 693 prefix yang-brat; 694 reference 695 "draft-ietf-rats-yang-tpm-charra-00"; 696 } 697 import ietf-yang-types { 698 prefix yang; 699 reference 700 "RFC 6991: Common YANG Data Types"; 701 } 703 organization "IETF"; 704 contact 705 "WG Web: 706 WG List: 708 Editor: Eric Voit 709 "; 711 description 712 "This module contains conceptual YANG specifications for 713 subscribing to attestation streams being generated from TPM chips. 715 Copyright (c) 2020 IETF Trust and the persons identified as authors 716 of the code. All rights reserved. 718 Redistribution and use in source and binary forms, with or without 719 modification, is permitted pursuant to, and subject to the license 720 terms contained in, the Simplified BSD License set forth in Section 721 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 722 (https://trustee.ietf.org/license-info). 724 This version of this YANG module is part of RFC XXXX; see the RFC 725 itself for full legal notices."; 727 revision 2020-03-06 { 728 description 729 "Initial version."; 730 reference 731 "draft-voit-rats-trusted-path-routing"; 732 } 734 /* 735 * FEATURES 736 */ 738 feature passport { 739 description 740 "This feature indicates that an Attester supports passports."; 741 } 743 /* 744 * IDENTITIES 745 */ 747 identity trustworthiness-level { 748 if-feature "passport"; 749 description 750 "Base identity for a verifier assessed trustworthiness level."; 751 } 753 identity compromised { 754 base trustworthiness-level; 755 description 756 "A Verifier has appraised an Attester as compromised."; 757 } 759 identity unverified { 760 base trustworthiness-level; 761 description 762 "There is no recent Verifier appraisal of an Attester."; 763 } 765 identity boot-verified { 766 base trustworthiness-level; 767 description 768 "A Verifier has appraised an Attester as Boot Integrity Verified."; 769 } 771 /* 772 * Groupings 773 */ 775 grouping tpm-name { 776 description 777 "Name of a TPM."; 778 leaf tpm_name { 779 type string; 780 description 781 "Name of the TPM or All"; 782 } 783 } 785 grouping tpm12-attestation { 786 description 787 "Contains an instance of TPM1.2 style signed cryptoprocessor 788 measurements. It is supplemented by unsigned Attester information. 789 The vast majority of the YANG objects in the YANG tree are defined 790 within [RATS-YANG]."; 791 uses tpm-name; 792 uses yang-brat:node-uptime; 793 uses yang-brat:compute-node; 794 uses yang-brat:tpm12-quote-info-common; 795 choice tpm12-quote { 796 mandatory true; 797 description 798 "Either a tpm12-quote-info or tpm12-quote-info2, depending 799 on whether TPM_Quote or TPM_Quote2 was used 800 (cf. input field add-verson)."; 801 case tpm12-quote1 { 802 description 803 "BIOS/UEFI event logs"; 804 uses yang-brat:tpm12-quote-info; 805 uses yang-brat:tpm12-pcr-composite; 806 } 807 case tpm12-quote2 { 808 description 809 "BIOS/UEFI event logs"; 810 uses yang-brat:tpm12-quote-info2; 811 } 812 } 814 } 816 /* 817 * RPCs 818 */ 820 augment "/sn:establish-subscription/sn:input" { 821 description 822 "This augmentation adds a nonce to as a subscription parameters 823 that apply specifically to datastore updates to RPC input."; 824 leaf nonce-value { 825 type binary; 826 description 827 "This nonce should be generated via a registered 828 cryptographic-strength algorithm. In consequence, the length 829 of the nonce depends on the hash algorithm used. The algorithm 830 used in this case is independent from the hash algorithm used to 831 create the hash-value in the response of the attestor."; 832 reference 833 "draft-ietf-rats-yang-tpm-charra"; 834 } 835 } 837 augment "/sn:establish-subscription/sn:output" { 838 description 839 "This augmentation allows a subscriber/verifier to understand the 840 state of the Attester at time of subscription."; 841 container latest-attestation { 842 description 843 "provides the current PCR values of a TPM."; 844 uses tpm12-attestation; 846 /* Awaiting WG progress on draft-ietf-rats-yang-tpm-charra 847 before completing for TPM2.0 style. */ 849 } 850 } 852 /* 853 * NOTIFICATIONS 854 */ 856 notification tpm-extend { 857 description 858 "This notification indicates that a PCR has extended within a TPM 1.x 859 or 2.0 cryptoprocessor. Within a small number of seconds, it should be 860 followed with a tpm12-attestation or tpm20-attestation."; 862 uses yang-brat:tpm-name; 863 leaf pcr-index-changed { 864 type uint8; 865 mandatory true; 866 description 867 "The number of the PCR extended."; 868 } 869 leaf-list extended-with { 870 type binary; 871 ordered-by user; 872 description 873 "Includes the one or more elements extending the PCR. The sequence of 874 elements represented in list must match the sequence entered into the 875 TPM."; 876 } 877 } 879 notification tpm12-attestation { 880 description 881 "Contains an instance of TPM1.2 style signed cryptoprocessor 882 measurements. It is supplemented by unsigned Attester information. 883 The vast majority of the YANG objects in the YANG tree are defined 884 within [RATS-YANG]."; 885 uses tpm12-attestation; 886 } 888 /* Awaiting WG progress on draft-ietf-rats-yang-tpm-charra before completing 889 notification tpm20-attestation { 890 description 891 "We still need to define the majority of the YANG objects in 892 within [RATS-YANG]. Redefining them here would just result in lots of 893 unnecessary churn."; 894 } 895 */ 897 /* 898 * DATA NODES 899 */ 901 container attestation-config { 902 presence 903 "Indicates that the set of notifications which comprise the attestation 904 stream can be modified or tuned by a network adminsitrator."; 905 description 906 "This allows an Attester to determine which TPMs and PCRs are evaluated 907 and included within the Attestation Stream."; 908 container tpm12-stream { 909 description 910 "Configuration elements for a TPM1.2 event stream. This includes 911 all of the TPM1.2s which are available on an Attester."; 912 list tpm12-stream-config { 913 key tpm_name; 914 description 915 "Allows the stream to be configured for the inclusion of TPM1.2 916 quotes and evidence."; 917 uses tpm-name; 918 uses yang-brat:tpm12-pcr-selection; 919 uses yang-brat:tpm12-attestation-key-identifier; 920 } 921 uses yang-brat:tpm12-signature-scheme; 922 } 923 container tpm20-stream { 924 description 925 "Configuration elements for a TPM2.0 event stream. This includes 926 all of the TPM2.0s which are available on an Attester."; 927 list tpm20-stream-config { 928 key "tpm_name"; 929 description 930 "Allows the stream to be configured for the inclusion of TPM2.0 931 quotes and evidence."; 932 uses tpm-name; 933 list pcr-list { 934 key "pcr-index"; 935 description 936 "For each PCR in this list an individual list of banks 937 (hash-algo) can be requested."; 938 leaf pcr-index { 939 type uint8; 940 description 941 "The number of the PCR. At the moment this is limited 32"; 942 } 943 uses yang-brat:hash-algo; 944 } 945 uses yang-brat:tpm20-attestation-key-identifier; 946 } 947 uses yang-brat:tpm20-signature-scheme; 948 leaf tpm2-heartbeat { 949 type uint8; 950 description 951 "Number of seconds before the Attestation stream should send a new 952 Notification which with a fresh quote. This allows confirmation 953 that the PCR values haven't changed since the last 954 tpm20-attestation."; 955 } 956 } 957 } 958 container attestation-results { 959 if-feature "passport"; 960 presence 961 "An attestation Verifier has appraised the security posture of the 962 device, and returned the results within this container."; 963 description 964 "Containes the latest Verifier appraisal of an Attester."; 965 leaf-list trustworthiness-level { 966 type identityref { 967 base trustworthiness-level; 968 } 969 min-elements 1; 970 description 971 "One or more Trustworthiness Levels assigned."; 972 } 973 leaf timestamp { 974 type yang:date-and-time; 975 mandatory true; 976 description 977 "The timestamp of the Verifier's appraisal."; 978 } 979 leaf tpmt-signature { 980 type binary; 981 description 982 "Must match a recent tpmt-signature sent in a notification to 983 a Verifier. This allows correlation of the Attestation Results to 984 a recent PCR change."; 985 } 986 leaf verifier-signature { 987 type binary; 988 description 989 "Signature of the Verifier across all the current objects in the 990 attestation-results container."; 991 } 992 leaf verifier-signature-key-name { 993 type binary; 994 description 995 "Name of the key the Verifier used to sign the results."; 996 } 997 } 998 } 999 1001 7. Passport Protocol Bindings 1003 This section provides details of how Composite Evidence described in 1004 Section 4.2 interacts with link layer protocols like [MACSEC] or 1005 [IEEE-802.1X], YANG subscriptions [RFC8639], and [RFC3748] methods. 1007 Additional linkages to the YANG module defined in Section 6 are 1008 described. 1010 .--------------. 1011 | Verifier A | 1012 '--------------' 1013 ^ (2) 1014 | Verifier A signed Attestation Results @time(x) ( 1015 Evidence( | Trustworthiness Level, 1016 TpmQuote | signature from TpmQuote@time(x) ) 1017 @time(x)) | 1018 (1) V 1019 .-------------. .---------------. 1020 | Attester |<------nonce @time(y)---(3)| Relying Party | 1021 | .-----. | | / Verifier B | 1022 | | Tpm | |(4)-Composite Evidence ( ->| (Router) | 1023 | '-----' | TpmQuote@time(y), | (5) | 1024 '-------------' TpmQuote@time(x), '---------------' 1025 Verifier A signed Attestation Results @time(x) ) 1027 Figure 5: Details of Passport Generation 1029 Figure 5 above expands upon the previously described Figure 3. The 1030 numbering in both figures is the same. 1032 Step (1) 1034 Verifier A subscribes to an Attester's Event Stream on 1035 via [RFC8639]. Within the RPC, a nonce is 1036 delivered as per Section 5.1. This nonce then is included into TPM 1037 quotes requests driven for the Attester's cryptoprocessor. The 1038 result of the TPM quote is appended to the 1039 response. Following this delivery of a provably current TPM state, 1040 all the historical evidence needed to validate specific PCRs within 1041 this quote are delivered on the Event Stream via the 1042 feature. Any changes to PCRs results in new notifications 1043 as described in Section 5.2. These are continuously streamed to 1044 Verifier A. 1046 Step (2) 1048 Whenever a PCR changes, Verifier A evaluates the totality of the 1049 Evidence received. This Evidence may include information not 1050 provided on the Event Stream. Verifier A then decides 1051 the Trustworthiness Level of the Attester. Subsequently it sends 1052 back a signed Attestation Result which includes the Trustworthiness 1053 Level and the signature sent as part of (1) from the Attester. It is 1054 this signature which allows the Trustworthiness Level to be later 1055 provably associated with a recent TPM Quote. 1057 The delivery of Attestation Results back to the Attester can be done 1058 via a YANG operational datastore write of the following objects: 1060 +--rw attestation-results! {passport}? 1061 +--rw trustworthiness-level* identityref 1062 +--rw timestamp yang:date-and-time 1063 +--rw tpmt-signature? binary 1064 +--rw verifier-signature? binary 1065 +--rw verifier-signature-key-name? binary 1067 Figure 6: Attestation Results Tree 1069 Step (3) 1071 At time(y) a Relying Party makes a Link Layer connection request to 1072 an Attester via a protocol such as [MACSEC] or [IEEE-802.1X]. This 1073 connection request must include [RFC3748] credentials. Specifics of 1074 the EAP credentials are TBD. If there is no central distribution of 1075 time via [I-D.birkholz-rats-tuda] a nonce must be included to ensure 1076 freshness of a response. 1078 This step can repeat periodically independently of any subsequent 1079 iteration (1) and (2). This allows for periodic reauthentication of 1080 the link layer in a way not bound to the updating of Verifier A's 1081 Attestation Results. 1083 Step (4) 1085 Upon receipt of (3), a passport is generated as per Section 4.2, and 1086 sent to the Relying Party. 1088 Step (5) 1090 Upon receipt of (4), the Relying Party verifies the Composite 1091 Evidence as per Section 4.2. Most often, the relevant PCR values at 1092 time(x) will be the same as the PCR values at time(y). In this case, 1093 the Relying Party can simply accept the Trustworthiness Level 1094 assigned by the Verifier A. When the PCR values are different, and 1095 not much time has passed between time(x) and time(y), the Relying 1096 Party can either accept the previous Trustworthiness Level, or 1097 attempt another EAP request in a few seconds as new Attestation 1098 Results are delivered by Step (2). When there is a large time gap 1099 between time(x) and time(y) and the PCR values are different, the 1100 Attester should be given an Trustworthiness Level. 1102 Based on the link's Trustworthiness Level, the Relying Party may 1103 adjust the link affinity of the corresponding 1104 [I-D.ietf-lsr-flex-algo] topology. 1106 8. Security Considerations 1108 Successful attacks on an IGP domain Verifier has the potential of 1109 affecting traffic on the Trusted Topology. 1111 For Distributed Trusted Path Routing, links which are part of the 1112 FlexAlgo are visible across the entire IGP domain. Therefore a 1113 compromised device will know when it is being bypassed. 1115 Access control for the objects in Figure 6 should be tightly 1116 controlled so that it becomes difficult for the passport to become a 1117 denial of service vector. 1119 9. References 1121 9.1. Normative References 1123 [I-D.ietf-rats-architecture] 1124 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 1125 W. Pan, "Remote Attestation Procedures Architecture", 1126 draft-ietf-rats-architecture-02 (work in progress), March 1127 2020. 1129 [RATS-YANG] 1130 "A YANG Data Model for Challenge-Response-based Remote 1131 Attestation Procedures using TPMs", January 2020, 1132 . 1135 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1136 Requirement Levels", BCP 14, RFC 2119, 1137 DOI 10.17487/RFC2119, March 1997, 1138 . 1140 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1141 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1142 May 2017, . 1144 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1145 E., and A. Tripathy, "Subscription to YANG Notifications", 1146 RFC 8639, DOI 10.17487/RFC8639, September 2019, 1147 . 1149 [TPM1.2] TCG, ., "TPM 1.2 Main Specification", October 2003, 1150 . 1153 [TPM2.0] TCG, ., "TPM 2.0 Library Specification", October 2003, 1154 . 1157 9.2. Informative References 1159 [I-D.birkholz-rats-tuda] 1160 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 1161 "Time-Based Uni-Directional Attestation", draft-birkholz- 1162 rats-tuda-01 (work in progress), September 2019. 1164 [I-D.ietf-idr-segment-routing-te-policy] 1165 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 1166 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 1167 Routing Policies in BGP", draft-ietf-idr-segment-routing- 1168 te-policy-08 (work in progress), November 2019. 1170 [I-D.ietf-lsr-flex-algo] 1171 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1172 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1173 algo-06 (work in progress), February 2020. 1175 [IEEE-802.1X] 1176 Parsons, G., "802.1AE: MAC Security (MACsec)", January 1177 2020, 1178 . 1180 [KGV] TCG, ., "KGV", October 2003, 1181 . 1184 [MACSEC] Seaman, M., "802.1AE: MAC Security (MACsec)", January 1185 2006, . 1187 [RATS-Device] 1188 Fedorkow, G. and J. Fitzgerald-McKay, "Network Device 1189 Remote Integrity Verification", n.d., 1190 . 1193 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1194 Levkowetz, Ed., "Extensible Authentication Protocol 1195 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1196 . 1198 Appendix A. Acknowledgements 1200 Shwetha Bhandari, Henk Birkholz, Chennakesava Reddy Gaddam, Sujal 1201 Sheth, Peter Psenak, Nancy Cam Winget, Siva Sivabalan, Ned Smith, Guy 1202 Fedorkow, Liang Xia. 1204 Appendix B. Change Log 1206 [THIS SECTION TO BE REMOVED BY THE RFC EDITOR.] 1208 v00-v01 1210 o Move all FlexAlgo terminology to Section 7. This allows 1211 Section 4.2 to be more generic. 1213 o Edited Figure 1 so that (4) points to the egress router. 1215 o Added text freshness mechanisms, and articulated configured 1216 subscription support. 1218 o Minor YANG model clarifications. 1220 o Added a few open questions which Frank thinks interesting to work. 1222 Appendix C. Open Questions 1224 Do we need functional requirements on how to handle traffic to/from 1225 Sensitive Subnets when no Trusted Topology exists between IGP edges? 1226 The network typically can make this unnecessary. For example it is 1227 possible to construct a local IPSec tunnel to make untrusted devices 1228 appear as Transparently-Transited Devices. This way Secure Subnets 1229 could be tunneled between FlexAlgo nodes where an end-to-end path 1230 doesn't currently exist. However there still is a corner case where 1231 all IGP egress points are not considered sufficiently trustworthy. 1233 Deep discussions on the Trustworthiness Levels which need 1234 standardization. Perhaps these could be mapped to the "Figure 2: 1235 Attested Objects" from [RATS-Device]. 1237 Should the "extended-with" object support a choice of structured 1238 data, or should it be binary only. 1240 Should we have multiple attestation streams identified? E.g.: pcr- 1241 trust-evidence, bios-log-trust-evidence, and ima-log-trust-evidence? 1242 Should each stream have its own draft? 1244 Should we include define how to acquires attestation-certificates. 1245 Perhaps through something like draft-ietf-netconf-keystore? 1247 Author's Address 1249 Eric Voit 1250 Cisco Systems, Inc. 1252 Email: evoit@cisco.com