idnits 2.17.1 draft-voit-rats-trustworthy-path-routing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 22 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 364 has weird spacing: '...M2_Algo ide...' == Line 411 has weird spacing: '...gnature bin...' == Line 416 has weird spacing: '...M2_Algo ide...' -- The document date (June 25, 2020) is 1401 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'RATS-Arch' -- Possible downref: Non-RFC (?) normative reference: ref. 'RATS-YANG' ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-07 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 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 June 25, 2020 5 Expires: December 27, 2020 7 Trusted Path Routing 8 draft-voit-rats-trustworthy-path-routing-00 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. These end-users want their flows to 15 traverse devices which have been freshly appraised and verified. 16 This specification describes Trusted Path Routing. Trusted Path 17 Routing protects sensitive flows as they transit a network by 18 forwarding traffic to/from sensitive subnets across network devices 19 recently appraised as trustworthy. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 27, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4 59 3. Protocol Independent Definitions . . . . . . . . . . . . . . 4 60 3.1. Trusted Path Routing Service . . . . . . . . . . . . . . 4 61 3.2. Network Topology Assembly . . . . . . . . . . . . . . . . 4 62 3.3. Link Appraisal . . . . . . . . . . . . . . . . . . . . . 5 63 3.4. Trustworthiness Vector . . . . . . . . . . . . . . . . . 6 64 3.5. Attestation Results . . . . . . . . . . . . . . . . . . . 8 65 3.6. Stamped Passport . . . . . . . . . . . . . . . . . . . . 9 66 3.7. Appraising the Stamped Passport . . . . . . . . . . . . . 11 67 4. Implementable Solution . . . . . . . . . . . . . . . . . . . 13 68 4.1. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 13 69 4.2. Protocol Bindings . . . . . . . . . . . . . . . . . . . . 14 70 5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 23 74 7.2. Informative References . . . . . . . . . . . . . . . . . 24 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24 76 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25 77 Appendix C. Open Questions . . . . . . . . . . . . . . . . . . . 25 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 80 1. Introduction 82 There are end-users who believe encryption technologies like IPSec 83 alone are insufficient to protect the confidentiality of their highly 84 sensitive traffic flows. These customers want their highly sensitive 85 flows to be transported over only network devices recently verified 86 as trustworthy. 88 With the inclusion of TPM based cryptoprocessors into network 89 devices, it is now possible for network providers to identify 90 potentially compromised devices as well as potentially exploitable 91 (or even exploited) vulnerabilities. Using this knowledge, it then 92 becomes possible to redirect sensitive flows around these devices. 94 Trusted Path Routing provides a method of establishing Trusted 95 Topologies which only include trust-verified network devices. 96 Membership in a Trusted Topology is established and maintained via an 97 exchange of Stamped Passports at the link layer between peering 98 network devices. As links to Attesting Devices are appraised as 99 meeting at least a minimum set of formally defined Trustworthiness 100 Levels, the links are then included as members of this Trusted 101 Topology. Routing protocols like [I-D.ietf-lsr-flex-algo] can then 102 used to propagate topology state throughout a network. IP Packets to 103 and from end-user designated Sensitive Subnets are then forwarded 104 into this Trusted Topology at each network boundary. 106 The specification works under the following assumptions: 108 o All network devices supports the TPM remote attestation profile as 109 laid out in [RATS-Device] 111 o A routing protocol capable of maintaining multiple topologies 112 connects the network devices which span the network domain. 114 o One or more Verifiers continuously appraise the set of network 115 devices in that network domain, and these Verifiers can return the 116 Attestation Results back to the attesting network device. 118 2. Terminology 120 2.1. Terms 122 The following terms are imported from [RATS-Arch]: Attester, 123 Evidence, Passport, Relying Party, and Verifier. 125 Newly defined terms for this document: 127 Attested Device - a device where a Verifier's most recent appraisal 128 of Evidence has returned a Trustworthiness Vector. 130 Stamped Passport - a bundle of Evidence which includes at least 131 signed Attestation Results from a Verifier, and two independent 132 TPM quotes from an Attester. 134 Sensitive Subnet - an IP address range where IP packets to or from 135 that range must only have their IP headers and encapsulated 136 payloads accessible/visible only by Attested Devices. 138 Transparently-Transited Device - a network device within an IGP 139 domain where any packets passed into that IGP domain are 140 completely opaque at Layer 3 and above. 142 Trusted Topology - a topology which includes only Attested Devices 143 and Transparently-Transited Devices. 145 Trustworthiness Level - a specific quanta of trustworthiness which 146 can be assigned by a Verifier. 148 Trustworthiness Vector - a set of Trustworthiness Levels assigned 149 during a single assessment cycle by a Verfier using Evidence and 150 Claims related to an Attested Device. The vector is included 151 within Attestation Results. 153 2.2. Requirements Notation 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in 158 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 159 capitals, as shown here. 161 3. Protocol Independent Definitions 163 3.1. Trusted Path Routing Service 165 An end user identifies sensitive IP subnets where flows with 166 applications using these IP subnets need enhanced privacy guarantees. 167 Trusted Path Routing passes flows to/from these Sensitive Subnets 168 over a Trusted Topology able to meet these guarantees. The Trusted 169 Topology itself consists of the interconnection of network devices 170 where each potentially transited device has passed a recent 171 trustworthiness appraisal. 173 Different guarantees of end-to-end trustworthiness appraisal may be 174 offered to network users. These guarantees are network operator 175 specific, but might include options such as: 177 o all transited devices are currently boot integrity verified 179 o all transited devices are from a specific set of vendors and are 180 running known software containing the latest patches 182 o no guarantees provided 184 3.2. Network Topology Assembly 186 To be included in a Trusted Topology, Evidence of trustworthiness is 187 shared between network device peers (such as routers). Upon 188 receiving and appraising this Evidence as part of link layer 189 authentication, the network device peer decides if this link should 190 be added as an active adjacency for the Trusted Topology. 192 When enough links have been successfully added, a Trusted Topology 193 will come into existence as routing protocols flood the adjacency 194 information across the network domain. 196 .-------------. .---------. 197 | Compromised | | Edge | 198 .---------. | Router | | Router | 199 | Router | | | | | 200 | | | trust>---------------====================| | 242 | time(rg) | 243 |<----------Attestation Result---(2) | 244 ~ ~ ~ 245 time(vg')? | | 246 ~ ~ ~ 247 |<------nonce--------------------------------------(3)time(ns') 248 | | | 249 time(eg')(4)------Stamped Passport--------------------------->| 250 | | (5)time(rg',ra') 251 (6) 252 ~ 253 time(rx') 255 Figure 2: Trusted Path Timing 257 Specific of each of these information flows, included what happens at 258 the items numbered (1) through (5) are described in Section 3.6. 260 3.4. Trustworthiness Vector 262 For Trusted Path Routing to operate, fresh Attestation Results need 263 to be communicated by a Verifier back to the Attester. These 264 Attestation Results must be encoded in a way which is known and 265 actionable. 267 To support this requirement, specific levels of appraised 268 trustworthiness have been defined; it is these Trustworthiness Levels 269 which are asserted as Attestation Results by a Verifier. It is out 270 of the scope of this document for the Verifier to provide proof or 271 logic on how the assertion was derived. 273 Following are the set of available Trustworthiness Levels: 275 +------------------------+------------------------------------------+ 276 | Trustworthiness Level | Definition | 277 +------------------------+------------------------------------------+ 278 | hw-authentic | A Verifier has appraised an Attester as | 279 | | having authentic hardware | 280 | | | 281 | fw-authentic | A Verifier has appraised an Attester as | 282 | | having authentic firmware | 283 | | | 284 | hw-verification-fail | A Verifier has appraised an Attester has | 285 | | failed its hardware or firmware | 286 | | verification | 287 | | | 288 | identity-verified | A Verifier has appraised and verified an | 289 | | Attester's unique identity | 290 | | | 291 | identity-fail | A Verifier has been unable to assess or | 292 | | verify an Attester's unique identity | 293 | | | 294 | boot-verified | A Verifier has appraised an Attester as | 295 | | Boot Integrity Verified | 296 | | | 297 | boot-verification-fail | A Verifier has appraised an Attester has | 298 | | failed its Boot Integrity verification | 299 | | | 300 | files-verified | A Verifier has appraised an Attester's | 301 | | file system, and asserts that it | 302 | | recognizes relevant files | 303 | | | 304 | file-blacklisted | A Verifier has found a file on an | 305 | | Attester which should not be present | 306 +------------------------+------------------------------------------+ 308 A quick look at the list above shows that multiple Trustworthiness 309 Level will often be applicable at single point in time. To support 310 this, the Attestation Results will include a single Trustworthiness 311 Vector consisting of a set of Trustworthiness Levels. The 312 establishment of this Trustworthiness Vector follows the following 313 logic on the Verifier: 315 Start: TPM Quote Received, log received, or appraisal timer expired 317 Step 0: set Trustworthiness Vector = Null 319 Step 1: Is there sufficient fresh signed evidence to appraise? 320 (yes) - No Action 321 (no) - Goto Step 6 323 Step 2: Appraise Hardware Integrity 324 (if hw-verification-fail) - push onto vector, go to Step 6 325 (if hw-authentic) - push onto vector 326 (if fw-authentic) - push onto vector 327 (if not evaluated, or insufficient data to conclude: take no action) 329 Step 3: Appraise attester identity 330 (if identity-verified) - push onto vector 331 (if identity-fail) - push onto vector 332 (if not evaluated, or insufficient data to conclude: take no action) 334 Step 4: Appraise boot integrity 335 (if boot-verified) - push onto vector 336 (if boot-verification-fail) - push onto vector 337 (if not evaluated, or insufficient data to conclude: take no action) 339 Step 5: Appraise filesystem integrity 340 (if files-verified) - push onto vector 341 (if file-blacklisted) - push onto vector 342 (if not evaluated, or insufficient data to conclude: take no action) 344 Step 6: Assemble Attestation Results, and push to Attester 346 End 348 3.5. Attestation Results 350 As Evidence changes, a new Trustworthiness Vector needs to be 351 returned to the Attester as Attestation Results. But this 352 Trustworthiness Vector is not all that needs to be returned. 353 Following is a YANG tree for all the returned objects. Each of these 354 objects will later be used as Evidence by another Verifier which is 355 co-resident with the Relying Party. 357 module: ietf-attestation-results-vector 358 +--rw attestation-results! 359 +--rw trustworthiness-vector* identityref 360 +--rw (tpm-specification-version)? 361 | +--:(TPM2.0) {tpm:TPM20}? 362 | | +--rw TPM2B_DIGEST binary 363 | | +--rw pcr-list* [TPM2_Algo] 364 | | | +--rw TPM2_Algo identityref 365 | | | +--rw pcr-index* tpm:pcr 366 | | +--rw clock uint64 367 | | +--rw reset-counter uint32 368 | | +--rw restart-counter uint32 369 | | +--rw safe boolean 370 | +--:(TPM1.2) {tpm:TPM12}? 371 | +--rw pcr-index* pcr 372 | +--rw tpm12-pcr-value* binary 373 | +--rw timestamp yang:date-and-time 374 +--rw public-key-format identityref 375 +--rw public-key binary 376 +--rw public-key-algorithm-type identityref 377 +--rw verifier-signature-key-name? string 378 +--rw verifier-signature binary 380 Figure 3: Attestation Results Tree 382 Looking at the objects above, if the Attester has a TPM2, then the 383 values of the TPM PCRs are included (i.e., , 384 , and ), as are the timing counters from the 385 TPM (i.e., , , , and ). 387 Likewise if the Attester has a TPM1.2, the TPM PCR values of the 388 and are included. Timing information comes 389 from the Verifier itself via the object. 391 For both the TPM1.2 and the TPM2, there are other Attestation Results 392 which are sent. These are the Attester's TPM key (i.e., , , and ). This 394 key later will allow the Relying Party router to appraise a 395 subsequent TPM Quote. It is this signature which allows the 396 Trustworthiness Vector to be later provably associated with a recent 397 TPM Quote. 399 3.6. Stamped Passport 401 The Attestation Results are not the only item which a Relying Party 402 needs to consider during its appraisal. A provably recent TPM Quote 403 from the Attester must also be included. With these two items, the 404 resulting Stamped Passports formats described below must be converted 405 and passed over EAP. If an Attester includes a TPM2, the objects 406 are: 408 YANG structure for a TPM2 Stamped Passport 409 +--ro latest-tpm-quote 410 | +--ro quote binary 411 | +--ro quote-signature binary 412 +--ro latest-attestation-results 413 +--ro trustworthiness-vector* identityref 414 +--ro TPM2B_DIGEST binary 415 +--ro pcr-list* [TPM2_Algo] 416 | +--ro TPM2_Algo identityref 417 | +--ro pcr-index* tpm:pcr 418 +--ro clock uint64 419 +--ro reset-counter uint32 420 +--ro restart-counter uint32 421 +--ro safe boolean 422 +--ro public-key-format identityref 423 +--ro public-key binary 424 +--ro public-key-algorithm-type identityref 425 +--ro verifier-signature-key-name? string 426 +--ro verifier-signature binary 428 And if the Attester is a TPM1.2, the object are: 430 YANG structure for a TPM1.2 Stamped Passport 431 +--ro latest-tpm-quote 432 | +--ro version* [] 433 | | +--ro major? uint8 434 | | +--ro minor? uint8 435 | | +--ro revMajor? uint8 436 | | +--ro revMinor? uint8 437 | +--ro digest-value? binary 438 +--ro latest-tpm12-attestation-results 439 +--ro trustworthiness-vector* identityref 440 +--ro pcr-index* pcr 441 +--ro tpm12-pcr-value* binary 442 +--ro timestamp yang:date-and-time 443 +--ro public-key-format identityref 444 +--ro public-key binary 445 +--ro public-key-algorithm-type identityref 446 +--ro verifier-signature-key-name? string 447 +--ro verifier-signature binary 449 With either of these passport formats, if the is 450 verifiably fresh, then the state of the Attester can be appraised by 451 a network peer. 453 3.7. Appraising the Stamped Passport 455 When it receives a Stamped Passport, a Verifier co-resident with the 456 Relying Party on a network peer can make nuanced decisions about how 457 to handle traffic coming from that link. For example, when the 458 Attester's TPM hardware identity credentials can be verified, it 459 might choose to accept link layer connections and forward generic 460 Internet traffic. 462 Additionally, if the Attester's Trustworthiness Vector is acceptable 463 to the Relying Party, and it hasn't been too long since the Verifier 464 has provided a Stamped Passport, the Relying Party can include that 465 link in a Trusted Topology. 467 As the process described above repeats across the set of links within 468 a network domain, Trusted Topologies can be extended and maintained. 469 Traffic to and from Sensitive Subnets is then identified at the edges 470 of the network domain and passed into this Trusted Topology. 472 .--------------. 473 | Verifier A | 474 '---------(2)--' 475 ^ | 476 | Attestation Results 477 Evidence | 478 | V 479 .-(1)---------. .---------------. 480 | Attester | | Relying Party | 481 | (Router) |<--------------------nonce(3) / Verifier B | 482 | .-----. | | (Router) | 483 | | TPM | (4)-Stamped Passport-------->| | 484 | '-----' | | (5) & (6) | 485 '-------------' '---------------' 487 Figure 4: Stamped Passport Generation and Appraisal 489 In Figure 4 above, Evidence from a TPM is generated and signed by 490 that TPM. This Evidence is appraised by Verifier A, and the Attester 491 is given a Trustworthiness Vector which is signed and returned as 492 Attestation Results to the Attester. Later, when a request comes in 493 from a Relying Party, the Attester assembles and returns three 494 independently signed elements of Evidence. These three comprise the 495 Stamped Passport which when taken together allow Verifier B to 496 appraise and set the current Trustworthiness Vector of the Attester. 498 More details on the mechanisms used in the construction and 499 verification of the Stamped Passport are listed below. These numbers 500 match to the numbered steps of Figure 4: 502 1. An Attester sends a signed TPM Quote which includes PCR 503 measurements to Verifier A at time(eg). 505 2. Verifier A appraises (1), then sends the following items back to 506 that Attester as Attestation Results: 508 1. the Trustworthiness Vector of an Attester, 510 2. the PCR state information from the TPM Quote of (1), 512 3. time information associated with the TPM Quote of (1), 514 4. the Public Attestation Key which it used to validate the TPM 515 Quote of (1), and 517 5. a Verifier signature across (2.1) though (2.4). 519 3. At time(eg') a nonce known to the Relying Party is sent to the 520 Attester . 522 4. The Attester generates and sends a Stamped Passport. This 523 Stamped Passport includes: 525 1. The Attestation Results from (2) 527 2. New signed, verifiably fresh PCR measurements from time(eg'), 528 which incorporates the nonce from (3). 530 5. On receipt of (4), the Relying Party makes its determination of 531 how the Stamped Passport will impact adjacencies within a Trusted 532 Topology. The decision process is: 534 1. Verify that (4.2) includes the nonce from (3). 536 2. Use a local certificate to validate the signature (4.1). 538 3. Use the Attestation Results provided public key info of (2.4) 539 to validate the signatures of (4.2). 541 4. Failure of (5.1) through (5.3) means the link does not meet 542 minimum validation criteria, therefore appraise the link as 543 having a null Trustworthiness Vector. Jump to step (6). 545 5. If all PCR values from (2.2) equal those (4.2), then Relying 546 Party can accept (2.1) as the link's Trustworthiness Vector. 547 Jump to step (6). 549 6. If the PCR state information of (2.2) doesn't equal (4.2), 550 and not much time has passed between time(eg) and time(eg'), 551 the Relying Party accepts any previous Trustworthiness 552 Vector. (Note: rather than accepting, it is also viable to 553 attempt to acquire a new Stamped Passport. Where 554 [stream-subscription] is used, it should only be a few 555 seconds before a new Attestation Results are delivered to an 556 Attester via (2).) 558 7. When the PCR state information is different, and there is a 559 large or uncertain time gap between time(eg) and time(eg'), 560 the link should be assigned a null Trustworthiness Vector. 562 6. Take action based on Verifier B's appraised Trustworthiness 563 Vector: 565 1. Include the link within any Trusted Topology for which that 566 Trustworthiness Vector is qualified. 568 2. Remove the link from any Trusted Topology for which that 569 Trustworthiness Vector is not qualified. 571 4. Implementable Solution 573 This section defines one set of protocols which can be used for 574 Trusted Path Routing. The protocols include [MACSEC] or 575 [IEEE-802.1X], ISIS [I-D.ietf-lsr-flex-algo], YANG subscriptions 576 [RFC8639], and [RFC3748] methods. Other alternatives are also 577 viable. 579 4.1. Prerequisites 581 o A Trusted Topology such as one established by ISIS exists in an 582 IGP domain for the forwarding of Sensitive Subnet traffic. This 583 Topology will carry traffic across a set of devices which 584 currently meet at a defined set of Trustworthiness Vectors. 586 o Customer designated Sensitive Subnets and their requested 587 Trustworthiness Vectors have been identified and associated with 588 external interfaces to/from the edge of a network. Traffic to a 589 Sensitive Subnet can be passed into the Trusted Topology. 591 o Verifiers A and B are able to verify [TPM1.2] or [TPM2.0] 592 signatures of an Attester. 594 o Verifier B trusts information signed by Verifier A. Verifier B 595 has also been pre-provisioned with certificates or public keys 596 necessary to confirm that Stamped Passports came from Verifier A 598 o Within a network, a Relying Party is able to use affinity to 599 include/exclude links as part of the Trusted Topology based on 600 this appraisal. 602 4.2. Protocol Bindings 604 The numbering in below matches to the steps in Figure 4. 606 Step (1) 608 There are two alternatives for Verifier A to acquires Evidence 609 including a TPM Quote from the Attester: 611 o Subscription to the stream defined in 612 [stream-subscription]. Note: this method is recommended as it 613 will minimize the interval between when a PCR change is made in a 614 TPM, and when the PCR change appraisal is incorporated within a 615 subsequent Stamped Passport. 617 o The RPCs or defined in device [RATS-YANG] 620 Step (2) 622 The delivery of these Attestation Results back to the Attester MAY be 623 done via an operational datastore write to the YANG module . 626 Step (3) 628 At time(ns') a Relying Party makes a Link Layer authentication 629 request to an Attester via a either [MACSEC] or [IEEE-802.1X]. This 630 connection request must include [RFC3748] credentials. Specifics of 631 the EAP mapping to the Stamped Passport is tbd. 633 Step (4) 635 Upon receipt of (3), a Stamped Passport is generated as per 636 Section 3.6, and sent to the Relying Party. Note that with [MACSEC] 637 or [IEEE-802.1X], steps (3) & (4) will repeat periodically 638 independently of any subsequent iteration (1) and (2). This allows 639 for periodic reauthentication of the link layer in a way not bound to 640 the updating of Verifier A's Attestation Results. 642 Step (5) 644 Upon receipt of (4), the Relying Party appraises the Stamped Passport 645 as per Section 3.6. Following are relevant mappings which replace 646 generic steps from Section 3.6 with specific objects available with a 647 TPM1.2 or TPM2.0. 649 +-------------------------------------------------------------------+ 650 | TPM2.0 - Bindings/details | 651 +-------------------------------------------------------------------+ 652 | (5.5): If the , , , and are equal between the | 654 | Attestation Results and the TPM Quote at time(eg') then Relying | 655 | Party can accept (2.1) as the link's Trustworthiness Vector. Jump | 656 | to step (6). | 657 | | 658 | (5.6): If the , and are | 659 | equal between the Attestation Results and the TPM Quote at | 660 | time(eg'), and the object from time(eg') has not | 661 | incremented by an unacceptable number of seconds since the | 662 | Attestation Result, then Relying Party can accept (2.1) as the | 663 | link's Trustworthiness Vector. Jump to step (6). | 664 | | 665 | (5.7): Assign the link a null Trustworthiness Vector. | 666 +-------------------------------------------------------------------+ 668 +-------------------------------------------------------------------+ 669 | TPM1.2 - Bindings/details | 670 +-------------------------------------------------------------------+ 671 | (5.5): If the 's and 's are equal | 672 | between the Attestation Results and the TPM Quote at time(eg'), | 673 | then Relying Party can accept (2.1) as the link's Trustworthiness | 674 | Vector. Jump to step (6). | 675 | | 676 | (5.6): If the time hasn't incremented an unacceptable number of | 677 | seconds from the Attestation Results and the system | 678 | clock of the Relying Party, then Relying Party can accept (2.1) | 679 | as the link's Trustworthiness Vector. Jump to step (6). | 680 | | 681 | (5.7): Assign the link a null Trustworthiness Vector. | 682 +-------------------------------------------------------------------+ 684 Step (6) 686 After the Trustworthiness Vector has been validated or reset, based 687 on the link's Trustworthiness Vector, the Relying Party may adjust 688 the link affinity of the corresponding ISIS [I-D.ietf-lsr-flex-algo] 689 topology. ISIS will then replicate the link state across the IGP 690 domain. Traffic will then avoid links which do not have a qualifying 691 Trustworthiness Vector. 693 5. YANG Module 695 This YANG module imports modules from [RATS-YANG], [crypto-types] and 696 [RFC6021]. 698 ietf-attestation-results-vector@2020-06-23.yang 699 module ietf-attestation-results-vector { 700 yang-version 1.1; 701 namespace 702 "urn:ietf:params:xml:ns:yang:ietf-attestation-results-vector"; 703 prefix arv; 705 import ietf-yang-types { 706 prefix yang; 707 } 708 import ietf-tpm-remote-attestation { 709 prefix tpm; 710 reference 711 "draft-ietf-rats-yang-tpm-charra"; 712 } 713 import ietf-asymmetric-algs { 714 prefix aa; 715 } 716 import ietf-crypto-types { 717 prefix ct; 718 reference 719 "RFC XXXX: Common YANG Data Types for Cryptography 720 (currently draft-ietf-netconf-crypto-types)"; 721 } 723 organization "IETF"; 724 contact 725 "WG Web: 726 WG List: 728 Editor: Eric Voit 729 "; 731 description 732 "This module contains conceptual YANG specifications for 733 subscribing to attestation streams being generated from TPM chips. 735 Copyright (c) 2020 IETF Trust and the persons identified as authors 736 of the code. All rights reserved. 738 Redistribution and use in source and binary forms, with or without 739 modification, is permitted pursuant to, and subject to the license 740 terms contained in, the Simplified BSD License set forth in Section 741 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 742 (https://trustee.ietf.org/license-info). 744 This version of this YANG module is part of RFC XXXX; see the RFC 745 itself for full legal notices."; 747 revision 2020-06-23 { 748 description 749 "Initial version."; 750 reference 751 "draft-voit-rats-trustworthy-path-routing"; 752 } 754 /* 755 * IDENTITIES 756 */ 758 identity trustworthiness-level { 759 description 760 "Base identity for a Verifier that uses its Appraisal Policy for 761 Evidence to establish a trustworthiness level."; 762 } 764 identity trustworthiness-pass { 765 description 766 "A trustworthiness-level which successfully meets an Appraisal Policy for 767 Evidence."; 768 } 770 identity trustworthiness-fail { 771 description 772 "A trustworthiness-level which hit Appraisal Policy for Evidence 773 necessary to fail an evaluation. Note: this failure might or might not 774 consider whether sufficient Evidence has been provided. In other words 775 having insufficient evidence might not drive the setting of this failing 776 trustworthiness-level."; 777 } 779 identity boot-verified { 780 base trustworthiness-pass; 781 description 782 "A Verifier has appraised an Attester as Boot Integrity Verified."; 783 } 785 identity boot-verification-fail { 786 base trustworthiness-fail; 787 description 788 "A Verifier has appraised an Attester has failed its Boot Integrity 789 verification."; 790 } 792 identity hw-authentic { 793 base trustworthiness-pass; 794 description 795 "A Verifier has appraised an Attester as having authentic hardware."; 796 } 798 identity fw-authentic { 799 base trustworthiness-pass; 800 description 801 "A Verifier has appraised an Attester as having authentic firmware."; 802 } 804 identity hw-verification-fail { 805 base trustworthiness-fail; 806 description 807 "A Verifier has appraised an Attester has failed its hardware or 808 firmware verification."; 809 } 810 identity identity-verified { 811 base trustworthiness-pass; 812 description 813 "A Verifier has appraised and verified an Attester's unique identity."; 814 } 816 identity identity-fail { 817 base trustworthiness-fail; 818 description 819 "A Verifier has been unable to assess or verify an Attester's unique 820 identity"; 821 } 823 identity files-verified { 824 base trustworthiness-pass; 825 description 826 "A Verifier has appraised an Attester's file system, and asserts that 827 it recognizes relevant files."; 828 } 830 identity file-blacklisted { 831 base trustworthiness-fail; 832 description 833 "A Verifier has found a file on an Attester which should not be 834 present."; 835 } 836 grouping TPM20-unsigned-internals { 837 description 838 "The unsigned extract of a TPM2 Quote."; 839 leaf TPM2B_DIGEST { 840 mandatory true; 841 type binary; 842 description 843 "A hash of the latest PCR values (and the hash algorithm used) 844 which have been returned from a Verifier for the selected PCRs 845 identified within TPML_PCR_SELECTION."; 846 reference 847 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 848 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.12.1"; 849 } 850 uses tpm:tpm20-pcr-selection { 851 description 852 "Specifies the list of PCRs and Hash Algorithms used for the 853 latest returned TPM2B_DIGEST. Identifying 854 this object simplifies Stamped Passport troubleshooting if the 855 same PCRs and Hash algorithms are not used when attempting to 856 correlate independent TPM2B_DIGESTs."; 857 } 858 leaf clock { 859 mandatory true; 860 type uint64; 861 description 862 "Clock is a monotonically increasing counter that advances whenever 863 power is applied to a TPM2. The value of Clock is incremented each 864 millisecond."; 865 reference 866 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 867 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.2"; 868 } 869 leaf reset-counter { 870 mandatory true; 871 type uint32; 872 description 873 "This counter increments on each TPM Reset. The most common 874 TPM Reset would be due to a hardware power cycle."; 875 reference 876 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 877 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.3"; 878 } 879 leaf restart-counter { 880 mandatory true; 881 type uint32; 882 description 883 "This counter shall increment by one for each TPM Restart or 884 TPM Resume. The restartCount shall be reset to zero on a TPM 885 Reset."; 886 reference 887 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 888 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.4"; 889 } 890 leaf safe { 891 mandatory true; 892 type boolean; 893 description 894 "This parameter is set to YES when the value reported in Clock 895 is guaranteed to be unique for the current Owner. It is set to 896 NO when the value of Clock may have been reported in a previous 897 attestation or access."; 898 reference 899 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 900 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.5"; 901 } 902 } 904 grouping TPM12-unsigned-internals-extended { 905 description 906 "The unsigned extract of a TPM12 Quote, with extra content from the 907 Verifier specific to a TPM12."; 908 uses tpm:tpm12-pcr-selection; 909 leaf-list tpm12-pcr-value { 910 type binary; 911 description 912 "The list of TPM_PCRVALUEs from each PCR selected in sequence 913 of tpm12-pcr-selection."; 914 reference 915 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 916 TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf 917 Section 10.9.7"; 918 } 919 leaf timestamp { 920 type yang:date-and-time; 921 mandatory true; 922 description 923 "The timestamp of the Verifier's appraisal. This can be used by 924 a Relying Party to determine the freshness of the attestation 925 results."; 926 } 927 } 929 /* 930 * DATA NODES 931 */ 933 container attestation-results { 934 presence 935 "Indicates that Verifier has appraised the security posture of the 936 Attester, and returned the results within this container. If the 937 Attester believes this information is no longer fresh, this container 938 should automatically be deleted."; 939 description 940 "Retains the most recent Attestation Results for this Attester. 941 It must only be written by a Verfier which is to be trusted by a 942 Relying Party."; 943 leaf-list trustworthiness-vector { 944 type identityref { 945 base trustworthiness-level; 946 } 947 ordered-by system; 948 description 949 "One or more Trustworthiness Levels assigned which expose the 950 Verifier's evaluation of the Evidence associated with the 951 'tpmt-signature'."; 952 } 953 choice tpm-specification-version { 954 description 955 "Identifies the cryptoprocessor API set which drove the Attestation 956 Results."; 957 case TPM2.0 { 958 if-feature "tpm:TPM20"; 959 description 960 "The Attestation Results are from a TPM2."; 961 uses TPM20-unsigned-internals; 962 } 963 case TPM1.2 { 964 if-feature "tpm:TPM12"; 965 description 966 "The most recent Attestation Results from a TPM1.2."; 967 uses TPM12-unsigned-internals-extended; 968 } 969 } 970 uses ct:public-key-grouping { 971 description 972 "In order to avoid having to provision AIK certificates on a Relying 973 Party network device, it is possible to send the AIK public key as 974 from the Verifier as part of the passport. This is safe because the 975 key is signed by the Verifier (hence vouching for its validity.) 976 The two objects within this group allow the Verifier to include this 977 information as part of the Attestation Results."; 978 } 979 leaf public-key-algorithm-type { 980 mandatory true; 981 type identityref { 982 base aa:asymmetric-algorithm-type; 983 } 984 description 985 "Indicates what kind of algorithm is used with the Attester's 986 Public Key Value."; 987 } 988 leaf verifier-signature-key-name { 989 type string; 990 description 991 "Name of the key the Verifier used to sign the results."; 992 } 993 leaf verifier-signature { 994 type binary; 995 mandatory true; 996 description 997 "Signature of the Verifier across all the objects within the 998 attestation-results container. The signature will assume the 999 sequence of objects as defined in the YANG model schema."; 1000 } 1001 leaf verifier-key-algorithm-type { 1002 mandatory true; 1003 type identityref { 1004 base aa:asymmetric-algorithm-type; 1005 } 1006 description 1007 "Indicates what kind of algorithm was used for the 1008 'verifier-signature'."; 1009 } 1010 } 1011 } 1012 1014 6. Security Considerations 1016 Verifiers are limited to the Evidence available for appraisal from a 1017 Router. Although the state of the art is improving, some exploits 1018 may not be visible via Evidence. 1020 Only security measurements which are placed into PCRs are capable of 1021 being exposed via TPM Quote at time(eg') 1023 Successful attacks on an Verifier have the potential of affecting 1024 traffic on the Trusted Topology. 1026 For Trusted Path Routing, links which are part of the FlexAlgo are 1027 visible across the entire IGP domain. Therefore a compromised device 1028 will know when it is being bypassed. 1030 Access control for the objects in Figure 3 should be tightly 1031 controlled so that it becomes difficult for the Stamped Passport to 1032 become a denial of service vector. 1034 7. References 1036 7.1. Normative References 1038 [crypto-types] 1039 "Common YANG Data Types for Cryptography", May 2020, 1040 . 1043 [RATS-Arch] 1044 "Remote Attestation Procedures Architecture", March 2020, 1045 . 1048 [RATS-YANG] 1049 "A YANG Data Model for Challenge-Response-based Remote 1050 Attestation Procedures using TPMs", June 2020, 1051 . 1054 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1055 Requirement Levels", BCP 14, RFC 2119, 1056 DOI 10.17487/RFC2119, March 1997, 1057 . 1059 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 1060 RFC 6021, DOI 10.17487/RFC6021, October 2010, 1061 . 1063 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1064 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1065 May 2017, . 1067 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1068 E., and A. Tripathy, "Subscription to YANG Notifications", 1069 RFC 8639, DOI 10.17487/RFC8639, September 2019, 1070 . 1072 [TPM1.2] TCG, ., "TPM 1.2 Main Specification", October 2003, 1073 . 1076 [TPM2.0] TCG, ., "TPM 2.0 Library Specification", March 2013, 1077 . 1080 7.2. Informative References 1082 [I-D.ietf-lsr-flex-algo] 1083 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1084 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1085 algo-07 (work in progress), April 2020. 1087 [IEEE-802.1X] 1088 Parsons, G., "802.1AE: MAC Security (MACsec)", January 1089 2020, 1090 . 1092 [MACSEC] Seaman, M., "802.1AE: MAC Security (MACsec)", January 1093 2006, . 1095 [RATS-Device] 1096 "Network Device Remote Integrity Verification", n.d., 1097 . 1100 [RATS-Interactions] 1101 "Reference Interaction Models for Remote Attestation 1102 Procedures", June 2020, . 1106 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1107 Levkowetz, Ed., "Extensible Authentication Protocol 1108 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1109 . 1111 [stream-subscription] 1112 "Attestation Event Stream Subscription", June 2020, 1113 . 1116 Appendix A. Acknowledgements 1118 Shwetha Bhandari, Henk Birkholz, Chennakesava Reddy Gaddam, Sujal 1119 Sheth, Peter Psenak, Nancy Cam Winget, Ned Smith, Guy Fedorkow. 1121 Appendix B. Change Log 1123 [THIS SECTION TO BE REMOVED BY THE RFC EDITOR.] 1125 v02-v00 of draft-voit-rats-trustworthy-path-routing-00 1127 o file rename was due to an IETF tool submission glitch 1129 o The Attester's AIK is included within the Stamped Passport. This 1130 eliminates the need to provision to AIK certificate on the Relying 1131 Party. 1133 o Removed Centralized variant 1135 o Added timing diagram, and moved content around to match 1137 v01-v02 of draft-voit-rats-trusted-path-routing 1139 o Extracted the attestation stream, and placed into draft-birkholz- 1140 rats-network-device-subscription 1142 o Introduced the Trustworthiness Vector 1144 v00-v01 of draft-voit-rats-trusted-path-routing 1146 o Move all FlexAlgo terminology to Section 4.2. This allows 1147 Section 3.6 to be more generic. 1149 o Edited Figure 1 so that (4) points to the egress router. 1151 o Added text freshness mechanisms, and articulated configured 1152 subscription support. 1154 o Minor YANG model clarifications. 1156 o Added a few open questions which Frank thinks interesting to work. 1158 Appendix C. Open Questions 1160 (1) When there is no available Trusted Topology? 1162 Do we need functional requirements on how to handle traffic to/from 1163 Sensitive Subnets when no Trusted Topology exists between IGP edges? 1164 The network typically can make this unnecessary. For example it is 1165 possible to construct a local IPSec tunnel to make untrusted devices 1166 appear as Transparently-Transited Devices. This way Secure Subnets 1167 could be tunneled between FlexAlgo nodes where an end-to-end path 1168 doesn't currently exist. However there still is a corner case where 1169 all IGP egress points are not considered sufficiently trustworthy. 1171 (2) Extension of the Stamped Passport? 1173 We might move to 'verifier-certificate' and 'verifier-certificate- 1174 name' based on WG desire to include more information in the Stamped 1175 Passport. The format used could be extracted from ietf- 1176 keystore.yang, grouping keystore-grouping. 1178 Author's Address 1180 Eric Voit 1181 Cisco Systems, Inc. 1183 Email: evoit@cisco.com