idnits 2.17.1 draft-voit-rats-trustworthy-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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 374 has weird spacing: '...sh-algo ide...' == Line 388 has weird spacing: '...hm-type ide...' == Line 422 has weird spacing: '...gnature bin...' == Line 427 has weird spacing: '...sh-algo ide...' -- The document date (October 02, 2020) is 1301 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) == Missing Reference: 'TPM-hash-algo' is mentioned on line 426, but not defined -- 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-11 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group E. Voit 3 Internet-Draft Cisco 4 Intended status: Standards Track October 02, 2020 5 Expires: April 5, 2021 7 Trusted Path Routing 8 draft-voit-rats-trustworthy-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. 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 April 5, 2021. 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 . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . 23 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 23 74 7.2. Informative References . . . . . . . . . . . . . . . . . 24 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25 76 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25 77 Appendix C. Open Questions . . . . . . . . . . . . . . . . . . . 26 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 A set of network devices supporting the TPM remote attestation 109 profile as laid out in [RATS-Device] are connected within a 110 network domain. 112 o A routing protocol capable of maintaining multiple forwarding 113 topologies connects these network devices. 115 o One or more Verifiers continuously appraise each of network 116 devices, and these Verifiers can return the Attestation Results 117 back to the attesting network device. 119 2. Terminology 121 2.1. Terms 123 The following terms are imported from [RATS-Arch]: Attester, 124 Evidence, Passport, Relying Party, and Verifier. 126 Newly defined terms for this document: 128 Attested Device - a device where a Verifier's most recent appraisal 129 of Evidence has returned a Trustworthiness Vector. 131 Stamped Passport - a bundle of Evidence which includes at least 132 signed Attestation Results from a Verifier, and two independent 133 TPM quotes from an Attester. 135 Sensitive Subnet - an IP address range where IP packets to or from 136 that range desire confidentially guarantees beyond those of non- 137 identified subnets. In practice, flows to or from a Sensitive 138 Subnet must only have their IP headers and encapsulated payloads 139 accessible/visible only by Attested Devices supporting one or more 140 Trustworthiness Vectors. 142 Transparently-Transited Device - a network device within an network 143 domain where any packets originally passed into that network 144 domain are completely opaque on that network device at Layer 3 and 145 above. 147 Trusted Topology - a topology which includes only Attested Devices 148 and Transparently-Transited Devices. 150 Trustworthiness Level - a specific quanta of trustworthiness which 151 can be assigned by a Verifier. 153 Trustworthiness Vector - a set of Trustworthiness Levels assigned 154 during a single assessment cycle by a Verfier using Evidence and 155 Claims related to an Attested Device. The vector is included 156 within Attestation Results. 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. Protocol Independent Definitions 168 3.1. Trusted Path Routing Service 170 An end user identifies sensitive IP subnets where flows with 171 applications using these IP subnets need enhanced privacy guarantees. 172 Trusted Path Routing passes flows to/from these Sensitive Subnets 173 over a Trusted Topology able to meet these guarantees. The Trusted 174 Topology itself consists of the interconnection of network devices 175 where each potentially transited device has passed a recent 176 trustworthiness appraisal. 178 Different guarantees of end-to-end trustworthiness appraisal may be 179 offered to network users. These guarantees are network operator 180 specific, but might include options such as: 182 o all transited devices are currently boot integrity verified 184 o all transited devices are from a specific set of vendors and are 185 running known software containing the latest patches 187 o no guarantees provided 189 3.2. Network Topology Assembly 191 To be included in a Trusted Topology, Evidence of trustworthiness is 192 shared between network device peers (such as routers). Upon 193 receiving and appraising this Evidence as part of link layer 194 authentication, the network device peer decides if this link should 195 be added as an active adjacency for the Trusted Topology. 197 When enough links have been successfully added, a Trusted Topology 198 will come into existence as routing protocols flood the adjacency 199 information across the network domain. 201 .-------------. .---------. 202 | Compromised | | Edge | 203 .---------. | Router | | Router | 204 | Router | | | | | 205 | | | trust>---------------====================| | 250 | time(RG) | 251 |<------Attestation Result--(2) | 252 ~ ~ ~ 253 time(VG')? | | 254 ~ ~ ~ 255 |<------nonce---------------------------------(3)time(NS') 256 | | | 257 time(EG')(4)------Stamped Pat--------------------------->| 258 | | (5)time(RG',RA') 259 (6) 260 ~ 261 time(RX') 263 Figure 2: Trusted Path Timing 265 Specifics for each one of these information flows, including details 266 on what happens at the items numbered (1) through (5) are described 267 in Section 3.6. 269 3.4. Trustworthiness Vector 271 For Trusted Path Routing to operate, fresh Attestation Results need 272 to be communicated by a Verifier back to the Attester. These 273 Attestation Results must be encoded in a way which is known and 274 actionable. 276 To support this requirement, specific levels of appraised 277 trustworthiness have been defined. These are known as 278 Trustworthiness Levels. It is these Trustworthiness Levels which are 279 asserted as part of the Attestation Results by a Verifier. It is out 280 of the scope of this document for the Verifier to provide proof or 281 logic on how the assertion was derived. 283 Following are the set of available Trustworthiness Levels: 285 +------------------------+------------------------------------------+ 286 | Trustworthiness Level | Definition | 287 +------------------------+------------------------------------------+ 288 | hw-authentic | A Verifier has appraised an Attester as | 289 | | having authentic hardware | 290 | | | 291 | fw-authentic | A Verifier has appraised an Attester as | 292 | | having authentic firmware | 293 | | | 294 | hw-verification-fail | A Verifier has appraised an Attester has | 295 | | failed its hardware or firmware | 296 | | verification | 297 | | | 298 | identity-verified | A Verifier has appraised and verified an | 299 | | Attester's unique identity | 300 | | | 301 | identity-fail | A Verifier has been unable to assess or | 302 | | verify an Attester's unique identity | 303 | | | 304 | boot-verified | A Verifier has appraised an Attester as | 305 | | Boot Integrity Verified | 306 | | | 307 | boot-verification-fail | A Verifier has appraised an Attester has | 308 | | failed its Boot Integrity verification | 309 | | | 310 | files-verified | A Verifier has appraised an Attester's | 311 | | file system, and asserts that it | 312 | | recognizes relevant files | 313 | | | 314 | file-repudiated | A Verifier has found a file on an | 315 | | Attester which should not be present | 316 +------------------------+------------------------------------------+ 318 A quick look at the list above shows that multiple Trustworthiness 319 Level will often be applicable at single point in time. To support 320 this, the Attestation Results will include a single Trustworthiness 321 Vector consisting of a set of Trustworthiness Levels. The 322 establishment of this Trustworthiness Vector follows the following 323 logic on the Verifier: 325 Start: TPM Quote Received, log received, or appraisal timer expired 327 Step 0: set Trustworthiness Vector = Null 329 Step 1: Is there sufficient fresh signed evidence to appraise? 330 (yes) - No Action 331 (no) - Goto Step 6 333 Step 2: Appraise Hardware Integrity 334 (if hw-verification-fail) - push onto vector, go to Step 6 335 (if hw-authentic) - push onto vector 336 (if fw-authentic) - push onto vector 337 (if not evaluated, or insufficient data to conclude: take no action) 339 Step 3: Appraise attester identity 340 (if identity-verified) - push onto vector 341 (if identity-fail) - push onto vector 342 (if not evaluated, or insufficient data to conclude: take no action) 344 Step 4: Appraise boot integrity 345 (if boot-verified) - push onto vector 346 (if boot-verification-fail) - push onto vector 347 (if not evaluated, or insufficient data to conclude: take no action) 349 Step 5: Appraise filesystem integrity 350 (if files-verified) - push onto vector 351 (if file-repudiated) - push onto vector 352 (if not evaluated, or insufficient data to conclude: take no action) 354 Step 6: Assemble Attestation Results, and push to Attester 356 End 358 3.5. Attestation Results 360 As Evidence changes, a new Trustworthiness Vector needs to be 361 returned to the Attester as Attestation Results. But this 362 Trustworthiness Vector is not all that needs to be returned. 363 Following is a YANG tree for all the returned objects. Each of these 364 objects will later be used as Evidence by another Verifier which is 365 co-resident with the Relying Party. 367 module: ietf-attestation-results-vector 368 +--rw attestation-results! 369 +--rw trustworthiness-vector* identityref 370 +--rw (tpm-specification-version)? 371 | +--:(TPM2.0) {taa:TPM20}? 372 | | +--rw TPM2B_DIGEST binary 373 | | +--rw tpm20-pcr-bank* [TPM-hash-algo] 374 | | | +--rw TPM-hash-algo identityref 375 | | | +--rw pcr-index* tpm:pcr 376 | | +--rw clock uint64 377 | | +--rw reset-counter uint32 378 | | +--rw restart-counter uint32 379 | | +--rw safe boolean 380 | +--:(TPM1.2) {taa:TPM12}? 381 | +--rw pcr-index* pcr 382 | +--rw tpm12-pcr-value* binary 383 | +--rw timestamp yang:date-and-time 384 +--rw public-key-format identityref 385 +--rw public-key binary 386 +--rw public-key-algorithm-type identityref 387 +--rw verifier-signature-key-name? string 388 +--rw verifier-key-algorithm-type identityref 389 +--rw verifier-signature binary 391 Figure 3: Attestation Results Tree 393 Looking at the objects above, if the Attester has a TPM2, then the 394 values of the TPM PCRs are included (i.e., , 395 , and ), as are the timing counters from the 396 TPM (i.e., , , , and ). 398 Likewise if the Attester has a TPM1.2, the TPM PCR values of the 399 and are included. Timing information comes 400 from the Verifier itself via the object. 402 For both the TPM1.2 and the TPM2, there are other Attestation Results 403 which are sent. These are the Attester's TPM key (i.e., , , and ). This 405 key later will allow the Relying Party router to appraise a 406 subsequent TPM Quote. It is this signature which allows the 407 Trustworthiness Vector to be later provably associated with a recent 408 TPM Quote. 410 3.6. Stamped Passport 412 The Attestation Results are not the only item which a Relying Party 413 needs to consider during its appraisal. A provably recent TPM Quote 414 from the Attester must also be included. With these two items, the 415 resulting Stamped Passports formats described below must be converted 416 to CDDL and passed over EAP. If an Attester includes a TPM2, the 417 objects are: 419 YANG structure for a TPM2 Stamped Passport 420 +--ro latest-tpm-quote 421 | +--ro quote binary 422 | +--ro quote-signature binary 423 +--ro latest-attestation-results 424 +--ro trustworthiness-vector* identityref 425 +--ro TPM2B_DIGEST binary 426 +--ro tpm20-pcr-bank* [TPM-hash-algo] 427 | +--ro TPM-hash-algo identityref 428 | +--ro pcr-index* tpm:pcr 429 +--ro clock uint64 430 +--ro reset-counter uint32 431 +--ro restart-counter uint32 432 +--ro safe boolean 433 +--ro public-key-format identityref 434 +--ro public-key binary 435 +--ro public-key-algorithm-type identityref 436 +--ro verifier-signature-key-name? string 437 +--ro verifier-signature binary 439 And if the Attester is a TPM1.2, the object are: 441 YANG structure for a TPM1.2 Stamped Passport 442 +--ro latest-tpm-quote 443 | +--ro version* [] 444 | | +--ro major? uint8 445 | | +--ro minor? uint8 446 | | +--ro revMajor? uint8 447 | | +--ro revMinor? uint8 448 | +--ro digest-value? binary 449 +--ro latest-tpm12-attestation-results 450 +--ro trustworthiness-vector* identityref 451 +--ro pcr-index* pcr 452 +--ro tpm12-pcr-value* binary 453 +--ro timestamp yang:date-and-time 454 +--ro public-key-format identityref 455 +--ro public-key binary 456 +--ro public-key-algorithm-type identityref 457 +--ro verifier-signature-key-name? string 458 +--ro verifier-signature binary 460 With either of these passport formats, if the is 461 verifiably fresh, then the state of the Attester can be appraised by 462 a network peer. 464 3.7. Appraising the Stamped Passport 466 When it receives a Stamped Passport, a Verifier co-resident with the 467 Relying Party on a network peer can make nuanced decisions about how 468 to handle traffic coming from that link. For example, when the 469 Attester's TPM hardware identity credentials can be verified, it 470 might choose to accept link layer connections and forward generic 471 Internet traffic. 473 Additionally, if the Attester's Trustworthiness Vector is acceptable 474 to the Relying Party, and it hasn't been too long since the Verifier 475 has provided a Stamped Passport, the Relying Party can include that 476 link in a Trusted Topology. 478 As the process described above repeats across the set of links within 479 a network domain, Trusted Topologies can be extended and maintained. 480 Traffic to and from Sensitive Subnets is then identified at the edges 481 of the network domain and passed into this Trusted Topology. 483 .--------------. 484 | Verifier A | 485 '---------(2)--' 486 ^ | 487 | Attestation Results 488 Evidence | 489 | V 490 .-(1)---------. .---------------. 491 | Attester | | Relying Party | 492 | (Router) |<--------------------nonce(3) / Verifier B | 493 | .-----. | | (Router) | 494 | | TPM | (4)-Stamped Passport-------->| | 495 | '-----' | | (5) & (6) | 496 '-------------' '---------------' 498 Figure 4: Stamped Passport Generation and Appraisal 500 In Figure 4 above, Evidence from a TPM is generated and signed by 501 that TPM. This Evidence is appraised by Verifier A, and the Attester 502 is given a Trustworthiness Vector which is signed and returned as 503 Attestation Results to the Attester. Later, when a request comes in 504 from a Relying Party, the Attester assembles and returns three 505 independently signed elements of Evidence. These three comprise the 506 Stamped Passport which when taken together allow Verifier B to 507 appraise and set the current Trustworthiness Vector of the Attester. 509 More details on the mechanisms used in the construction and 510 verification of the Stamped Passport are listed below. These numbers 511 match to the numbered steps of Figure 4: 513 1. An Attester sends a signed TPM Quote which includes PCR 514 measurements to Verifier A at time(EG). 516 2. Verifier A appraises (1), then sends the following items back to 517 that Attester as Attestation Results: 519 1. the Trustworthiness Vector of an Attester, 521 2. the PCR state information from the TPM Quote of (1), 523 3. time information associated with the TPM Quote of (1), 525 4. the Public Attestation Key which it used to validate the TPM 526 Quote of (1), and 528 5. a Verifier signature across (2.1) though (2.4). 530 3. At time(EG') a nonce known to the Relying Party is sent to the 531 Attester . 533 4. The Attester generates and sends a Stamped Passport. This 534 Stamped Passport includes: 536 1. The Attestation Results from (2) 538 2. New signed, verifiably fresh PCR measurements from time(EG'), 539 which incorporates the nonce from (3). 541 5. On receipt of (4), the Relying Party makes its determination of 542 how the Stamped Passport will impact adjacencies within a Trusted 543 Topology. The decision process is: 545 1. Verify that (4.2) includes the nonce from (3). 547 2. Use a local certificate to validate the signature (4.1). 549 3. Use the Attestation Results provided public key info of (2.4) 550 to validate the signatures of (4.2). 552 4. Failure of (5.1) through (5.3) means the link does not meet 553 minimum validation criteria, therefore appraise the link as 554 having a null Trustworthiness Vector. Jump to step (6). 556 5. If all PCR values from (2.2) equal those (4.2), then Relying 557 Party can accept (2.1) as the link's Trustworthiness Vector. 558 Jump to step (6). 560 6. If the PCR state information of (2.2) doesn't equal (4.2), 561 and not much time has passed between time(EG) and time(EG'), 562 the Relying Party accepts any previous Trustworthiness 563 Vector. (Note: rather than accepting, it is also viable to 564 attempt to acquire a new Stamped Passport. Where 565 [stream-subscription] is used, it should only be a few 566 seconds before a new Attestation Results are delivered to an 567 Attester via (2).) 569 7. When the PCR state information is different, and there is a 570 large or uncertain time gap between time(EG) and time(EG'), 571 the link should be assigned a null Trustworthiness Vector. 573 6. Take action based on Verifier B's appraised Trustworthiness 574 Vector: 576 1. Include the link within any Trusted Topology for which that 577 Trustworthiness Vector is qualified. 579 2. Remove the link from any Trusted Topology for which that 580 Trustworthiness Vector is not qualified. 582 4. Implementable Solution 584 This section defines one set of protocols which can be used for 585 Trusted Path Routing. The protocols include [MACSEC] or 586 [IEEE-802.1X], ISIS [I-D.ietf-lsr-flex-algo], YANG subscriptions 587 [RFC8639], and [RFC3748] methods. Other alternatives are also 588 viable. 590 4.1. Prerequisites 592 o A Trusted Topology such as one established by ISIS exists in an 593 IGP domain for the forwarding of Sensitive Subnet traffic. This 594 Topology will carry traffic across a set of devices which 595 currently meet at a defined set of Trustworthiness Vectors. 597 o Customer designated Sensitive Subnets and their requested 598 Trustworthiness Vectors have been identified and associated with 599 external interfaces to/from the edge of a network. Traffic to a 600 Sensitive Subnet can be passed into the Trusted Topology. 602 o Verifiers A and B are able to verify [TPM1.2] or [TPM2.0] 603 signatures of an Attester. 605 o Verifier B trusts information signed by Verifier A. Verifier B 606 has also been pre-provisioned with certificates or public keys 607 necessary to confirm that Stamped Passports came from Verifier A 609 o Within a network, a Relying Party is able to use affinity to 610 include/exclude links as part of the Trusted Topology based on 611 this appraisal. 613 4.2. Protocol Bindings 615 The numbering in below matches to the steps in Figure 4. 617 Step (1) 619 There are two alternatives for Verifier A to acquires Evidence 620 including a TPM Quote from the Attester: 622 o Subscription to the stream defined in 623 [stream-subscription]. Note: this method is recommended as it 624 will minimize the interval between when a PCR change is made in a 625 TPM, and when the PCR change appraisal is incorporated within a 626 subsequent Stamped Passport. 628 o The RPCs or defined in device [RATS-YANG] 631 Step (2) 633 The delivery of these Attestation Results back to the Attester MAY be 634 done via an operational datastore write to the YANG module . 637 Step (3) 639 At time(NS') a Relying Party makes a Link Layer authentication 640 request to an Attester via a either [MACSEC] or [IEEE-802.1X]. This 641 connection request must include [RFC3748] credentials. Specifics of 642 the EAP mapping to the Stamped Passport is tbd. 644 Step (4) 646 Upon receipt of (3), a Stamped Passport is generated as per 647 Section 3.6, and sent to the Relying Party. Note that with [MACSEC] 648 or [IEEE-802.1X], steps (3) & (4) will repeat periodically 649 independently of any subsequent iteration (1) and (2). This allows 650 for periodic reauthentication of the link layer in a way not bound to 651 the updating of Verifier A's Attestation Results. 653 Step (5) 655 Upon receipt of (4), the Relying Party appraises the Stamped Passport 656 as per Section 3.6. Following are relevant mappings which replace 657 generic steps from Section 3.6 with specific objects available with a 658 TPM1.2 or TPM2.0. 660 +-------------------------------------------------------------------+ 661 | TPM2.0 - Bindings/details | 662 +-------------------------------------------------------------------+ 663 | (5.5): If the , , , and are equal between the | 665 | Attestation Results and the TPM Quote at time(EG') then Relying | 666 | Party can accept (2.1) as the link's Trustworthiness Vector. Jump | 667 | to step (6). | 668 | | 669 | (5.6): If the , and are | 670 | equal between the Attestation Results and the TPM Quote at | 671 | time(EG'), and the object from time(EG') has not | 672 | incremented by an unacceptable number of seconds since the | 673 | Attestation Result, then Relying Party can accept (2.1) as the | 674 | link's Trustworthiness Vector. Jump to step (6). | 675 | | 676 | (5.7): Assign the link a null Trustworthiness Vector. | 677 +-------------------------------------------------------------------+ 679 +-------------------------------------------------------------------+ 680 | TPM1.2 - Bindings/details | 681 +-------------------------------------------------------------------+ 682 | (5.5): If the 's and 's are equal | 683 | between the Attestation Results and the TPM Quote at time(EG'), | 684 | then Relying Party can accept (2.1) as the link's Trustworthiness | 685 | Vector. Jump to step (6). | 686 | | 687 | (5.6): If the time hasn't incremented an unacceptable number of | 688 | seconds from the Attestation Results and the system | 689 | clock of the Relying Party, then Relying Party can accept (2.1) | 690 | as the link's Trustworthiness Vector. Jump to step (6). | 691 | | 692 | (5.7): Assign the link a null Trustworthiness Vector. | 693 +-------------------------------------------------------------------+ 695 Step (6) 697 After the Trustworthiness Vector has been validated or reset, based 698 on the link's Trustworthiness Vector, the Relying Party may adjust 699 the link affinity of the corresponding ISIS [I-D.ietf-lsr-flex-algo] 700 topology. ISIS will then replicate the link state across the IGP 701 domain. Traffic will then avoid links which do not have a qualifying 702 Trustworthiness Vector. 704 5. YANG Module 706 This YANG module imports modules from [RATS-YANG], [crypto-types] and 707 [RFC6021]. 709 ietf-attestation-results-vector@2020-09-17.yang 710 module ietf-attestation-results-vector { 711 yang-version 1.1; 712 namespace 713 "urn:ietf:params:xml:ns:yang:ietf-attestation-results-vector"; 714 prefix arv; 716 import ietf-yang-types { 717 prefix yang; 718 } 719 import ietf-tpm-remote-attestation { 720 prefix tpm; 721 reference 722 "draft-ietf-rats-yang-tpm-charra"; 723 } 724 import ietf-crypto-types { 725 prefix ct; 726 reference 727 "RFC XXXX: Common YANG Data Types for Cryptography 728 (currently draft-ietf-netconf-crypto-types)"; 729 } 730 import ietf-tcg-algs { 731 prefix taa; 732 } 734 organization "IETF"; 735 contact 736 "WG Web: 737 WG List: 739 Editor: Eric Voit 740 "; 742 description 743 "This module contains conceptual YANG specifications for 744 subscribing to attestation streams being generated from TPM chips. 746 Copyright (c) 2020 IETF Trust and the persons identified as authors 747 of the code. All rights reserved. 749 Redistribution and use in source and binary forms, with or without 750 modification, is permitted pursuant to, and subject to the license 751 terms contained in, the Simplified BSD License set forth in Section 752 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 753 (https://trustee.ietf.org/license-info). 755 This version of this YANG module is part of RFC XXXX; see the RFC 756 itself for full legal notices."; 758 revision 2020-09-17 { 759 description 760 "Initial version."; 761 reference 762 "draft-voit-rats-trustworthy-path-routing"; 763 } 765 /* 766 * IDENTITIES 767 */ 769 identity trustworthiness-level { 770 description 771 "Base identity for a Verifier that uses its Appraisal Policy for 772 Evidence to establish a trustworthiness level."; 773 } 775 identity trustworthiness-pass { 776 description 777 "A trustworthiness-level which successfully meets an Appraisal 778 Policy for Evidence."; 779 } 781 identity trustworthiness-fail { 782 description 783 "A trustworthiness-level which hit Appraisal Policy for Evidence 784 necessary to fail an evaluation. Note: this failure might or 785 might not consider whether sufficient Evidence has been provided. 786 In other words having insufficient evidence might not drive the 787 setting of this failing trustworthiness-level."; 788 } 790 identity boot-verified { 791 base trustworthiness-pass; 792 description 793 "A Verifier has appraised an Attester as Boot Integrity 794 Verified."; 795 } 797 identity boot-verification-fail { 798 base trustworthiness-fail; 799 description 800 "A Verifier has appraised an Attester has failed its Boot 801 Integrity verification."; 802 } 804 identity hw-authentic { 805 base trustworthiness-pass; 806 description 807 "A Verifier has appraised an Attester as having authentic 808 hardware."; 809 } 811 identity fw-authentic { 812 base trustworthiness-pass; 813 description 814 "A Verifier has appraised an Attester as having authentic 815 firmware."; 816 } 818 identity hw-verification-fail { 819 base trustworthiness-fail; 820 description 821 "A Verifier has appraised an Attester has failed its hardware or 822 firmware verification."; 823 } 824 identity identity-verified { 825 base trustworthiness-pass; 826 description 827 "A Verifier has appraised and verified an Attester's unique 828 identity."; 829 } 831 identity identity-fail { 832 base trustworthiness-fail; 833 description 834 "A Verifier has been unable to assess or verify an Attester's 835 unique identity"; 836 } 838 identity files-verified { 839 base trustworthiness-pass; 840 description 841 "A Verifier has appraised an Attester's file system, and asserts 842 that it recognizes relevant files."; 843 } 845 identity file-repudiated { 846 base trustworthiness-fail; 847 description 848 "A Verifier has found a file on an Attester which should not be 849 present."; 850 } 852 grouping TPM20-unsigned-internals { 853 description 854 "The unsigned extract of a TPM2 Quote."; 855 leaf TPM2B_DIGEST { 856 mandatory true; 857 type binary; 858 description 859 "A hash of the latest PCR values (and the hash algorithm used) 860 which have been returned from a Verifier for the selected PCRs 861 identified within TPML_PCR_SELECTION."; 862 reference 863 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 864 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.12.1"; 865 } 866 list tpm20-pcr-bank { 867 min-elements 1; 868 key "TPM-hash-algo"; 869 description 870 "Specifies the list of PCRs and Hash Algorithms used for the 871 latest returned TPM2B_DIGEST. Identifying 872 this object simplifies Stamped Passport troubleshooting if the 873 same PCRs and Hash algorithms are not used when attempting to 874 correlate independent TPM2B_DIGESTs."; 875 reference 876 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 877 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.9.7"; 878 leaf TPM-hash-algo { 879 type identityref { 880 base taa:hash; 881 } 882 description 883 "The hash scheme actively being used to hash a PCRs."; 884 } 885 leaf-list pcr-index { 886 type tpm:pcr; 887 min-elements 1; 888 description 889 "Defines what TPM2 Banks are available. A bank is a set 890 of PCRs which are extended using a particular hash 891 algorithm."; 892 } 894 } 895 leaf clock { 896 mandatory true; 897 type uint64; 898 description 899 "Clock is a monotonically increasing counter that advances 900 whenever power is applied to a TPM2. The value of Clock is 901 incremented each millisecond."; 902 reference 903 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 904 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.2"; 905 } 906 leaf reset-counter { 907 mandatory true; 908 type uint32; 909 description 910 "This counter increments on each TPM Reset. The most common 911 TPM Reset would be due to a hardware power cycle."; 912 reference 913 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 914 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.3"; 915 } 916 leaf restart-counter { 917 mandatory true; 918 type uint32; 919 description 920 "This counter shall increment by one for each TPM Restart or 921 TPM Resume. The restartCount shall be reset to zero on a TPM 922 Reset."; 923 reference 924 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 925 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.4"; 926 } 927 leaf safe { 928 mandatory true; 929 type boolean; 930 description 931 "This parameter is set to YES when the value reported in Clock 932 is guaranteed to be unique for the current Owner. It is set to 933 NO when the value of Clock may have been reported in a previous 934 attestation or access."; 935 reference 936 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 937 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.5"; 938 } 939 } 941 grouping TPM12-unsigned-internals-extended { 942 description 943 "The unsigned extract of a TPM12 Quote, with extra content from 944 the Verifier specific to a TPM12."; 945 uses tpm:tpm12-pcr-selection; 946 leaf-list tpm12-pcr-value { 947 type binary; 948 description 949 "The list of TPM_PCRVALUEs from each PCR selected in sequence 950 of tpm12-pcr-selection."; 951 reference 952 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 953 TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf 954 Section 10.9.7"; 955 } 956 leaf timestamp { 957 type yang:date-and-time; 958 mandatory true; 959 description 960 "The timestamp of the Verifier's appraisal. This can be used by 961 a Relying Party to determine the freshness of the attestation 962 results."; 963 } 964 } 966 /* 967 * DATA NODES 968 */ 970 container attestation-results { 971 presence 972 "Indicates that Verifier has appraised the security posture of the 973 Attester, and returned the results within this container. If the 974 Attester believes this information is no longer fresh, this 975 container should automatically be deleted."; 976 description 977 "Retains the most recent Attestation Results for this Attester. 978 It must only be written by a Verfier which is to be trusted by a 979 Relying Party."; 980 leaf-list trustworthiness-vector { 981 type identityref { 982 base trustworthiness-level; 983 } 984 ordered-by system; 985 description 986 "One or more Trustworthiness Levels assigned which expose the 987 Verifier's evaluation of the Evidence associated with the 988 'tpmt-signature'."; 989 } 990 choice tpm-specification-version { 991 description 992 "Identifies the cryptoprocessor API set which drove the 993 Attestation Results."; 994 case TPM2.0 { 995 if-feature "taa:TPM20"; 996 description 997 "The Attestation Results are from a TPM2."; 998 uses TPM20-unsigned-internals; 999 } 1000 case TPM1.2 { 1001 if-feature "taa:TPM12"; 1002 description 1003 "The most recent Attestation Results from a TPM1.2."; 1004 uses TPM12-unsigned-internals-extended; 1005 } 1006 } 1007 uses ct:public-key-grouping { 1008 description 1009 "In order to avoid having to provision AIK certificates on a 1010 Relying Party network device, it is possible to send the AIK 1011 public key as from the Verifier as part of the passport. This 1012 is safe because the key is signed by the Verifier (hence 1013 vouching for its validity.) The two objects within this group 1014 allow the Verifier to include this information as part of the 1015 Attestation Results."; 1016 } 1017 leaf public-key-algorithm-type { 1018 mandatory true; 1019 type identityref { 1020 base taa:asymmetric; 1021 } 1022 description 1023 "Indicates what kind of algorithm is used with the Attester's 1024 Public Key Value."; 1025 } 1026 leaf verifier-signature-key-name { 1027 type string; 1028 description 1029 "Name of the key the Verifier used to sign the results."; 1030 } 1031 leaf verifier-key-algorithm-type { 1032 mandatory true; 1033 type identityref { 1034 base taa:asymmetric; 1035 } 1036 description 1037 "Indicates what kind of algorithm was used for the 1038 'verifier-signature'."; 1039 } 1040 leaf verifier-signature { 1041 type binary; 1042 mandatory true; 1043 description 1044 "Signature of the Verifier across all the other objects within 1045 the attestation-results container. The signature will assume 1046 the sequence of objects as defined in the YANG model schema."; 1047 } 1048 } 1049 } 1050 1052 6. Security Considerations 1054 Verifiers are limited to the Evidence available for appraisal from a 1055 Router. Although the state of the art is improving, some exploits 1056 may not be visible via Evidence. 1058 Only security measurements which are placed into PCRs are capable of 1059 being exposed via TPM Quote at time(EG'). 1061 Successful attacks on an Verifier have the potential of affecting 1062 traffic on the Trusted Topology. 1064 For Trusted Path Routing, links which are part of the FlexAlgo are 1065 visible across the entire IGP domain. Therefore a compromised device 1066 will know when it is being bypassed. 1068 Access control for the objects in Figure 3 should be tightly 1069 controlled so that it becomes difficult for the Stamped Passport to 1070 become a denial of service vector. 1072 7. References 1074 7.1. Normative References 1076 [crypto-types] 1077 "Common YANG Data Types for Cryptography", May 2020, 1078 . 1081 [RATS-Arch] 1082 "Remote Attestation Procedures Architecture", March 2020, 1083 . 1086 [RATS-YANG] 1087 "A YANG Data Model for Challenge-Response-based Remote 1088 Attestation Procedures using TPMs", June 2020, 1089 . 1092 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1093 Requirement Levels", BCP 14, RFC 2119, 1094 DOI 10.17487/RFC2119, March 1997, 1095 . 1097 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 1098 RFC 6021, DOI 10.17487/RFC6021, October 2010, 1099 . 1101 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1102 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1103 May 2017, . 1105 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1106 E., and A. Tripathy, "Subscription to YANG Notifications", 1107 RFC 8639, DOI 10.17487/RFC8639, September 2019, 1108 . 1110 [TPM1.2] TCG, ., "TPM 1.2 Main Specification", October 2003, 1111 . 1114 [TPM2.0] TCG, ., "TPM 2.0 Library Specification", March 2013, 1115 . 1118 7.2. Informative References 1120 [I-D.ietf-lsr-flex-algo] 1121 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1122 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1123 algo-11 (work in progress), September 2020. 1125 [IEEE-802.1X] 1126 Parsons, G., "802.1AE: MAC Security (MACsec)", January 1127 2020, 1128 . 1130 [MACSEC] Seaman, M., "802.1AE: MAC Security (MACsec)", January 1131 2006, . 1133 [RATS-Device] 1134 "Network Device Remote Integrity Verification", n.d., 1135 . 1138 [RATS-Interactions] 1139 "Reference Interaction Models for Remote Attestation 1140 Procedures", June 2020, . 1144 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1145 Levkowetz, Ed., "Extensible Authentication Protocol 1146 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1147 . 1149 [stream-subscription] 1150 "Attestation Event Stream Subscription", June 2020, 1151 . 1154 Appendix A. Acknowledgements 1156 Shwetha Bhandari, Henk Birkholz, Chennakesava Reddy Gaddam, Sujal 1157 Sheth, Peter Psenak, Adwaith Gautham, Annu Singh, Nancy Cam Winget, 1158 Ned Smith, and Guy Fedorkow. 1160 Appendix B. Change Log 1162 [THIS SECTION TO BE REMOVED BY THE RFC EDITOR.] 1164 v00-v01 1166 o Minor tweaks 1168 v02-v00 of draft-voit-rats-trustworthy-path-routing-00 1170 o file rename was due to an IETF tool submission glitch 1172 o The Attester's AIK is included within the Stamped Passport. This 1173 eliminates the need to provision to AIK certificate on the Relying 1174 Party. 1176 o Removed Centralized variant 1178 o Added timing diagram, and moved content around to match 1180 v01-v02 of draft-voit-rats-trusted-path-routing 1181 o Extracted the attestation stream, and placed into draft-birkholz- 1182 rats-network-device-subscription 1184 o Introduced the Trustworthiness Vector 1186 v00-v01 of draft-voit-rats-trusted-path-routing 1188 o Move all FlexAlgo terminology to Section 4.2. This allows 1189 Section 3.6 to be more generic. 1191 o Edited Figure 1 so that (4) points to the egress router. 1193 o Added text freshness mechanisms, and articulated configured 1194 subscription support. 1196 o Minor YANG model clarifications. 1198 o Added a few open questions which Frank thinks interesting to work. 1200 Appendix C. Open Questions 1202 (1) When there is no available Trusted Topology? 1204 Do we need functional requirements on how to handle traffic to/from 1205 Sensitive Subnets when no Trusted Topology exists between IGP edges? 1206 The network typically can make this unnecessary. For example it is 1207 possible to construct a local IPSec tunnel to make untrusted devices 1208 appear as Transparently-Transited Devices. This way Secure Subnets 1209 could be tunneled between FlexAlgo nodes where an end-to-end path 1210 doesn't currently exist. However there still is a corner case where 1211 all IGP egress points are not considered sufficiently trustworthy. 1213 (2) Extension of the Stamped Passport? 1215 We might move to 'verifier-certificate' and 'verifier-certificate- 1216 name' based on WG desire to include more information in the Stamped 1217 Passport. The format used could be extracted from ietf- 1218 keystore.yang, grouping keystore-grouping. 1220 Author's Address 1222 Eric Voit 1223 Cisco Systems, Inc. 1225 Email: evoit@cisco.com