idnits 2.17.1 draft-voit-rats-trustworthy-path-routing-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 447 has weird spacing: '...sh-algo ide...' == Line 511 has weird spacing: '...sh-algo ide...' == Line 527 has weird spacing: '...te-name cer...' == Line 552 has weird spacing: '...te-name cer...' -- The document date (May 13, 2021) is 1079 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) == Unused Reference: 'RFC8639' is defined on line 1122, but no explicit reference was found in the text == 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. 'RATS-Arch') ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-15 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group E. Voit 3 Internet-Draft C. Gaddam 4 Intended status: Standards Track Cisco 5 Expires: November 14, 2021 G. Fedorkow 6 Juniper 7 H. Birkholz 8 Fraunhofer SIT 9 May 13, 2021 11 Trusted Path Routing 12 draft-voit-rats-trustworthy-path-routing-03 14 Abstract 16 There are end-users who believe encryption technologies like IPSec 17 alone are insufficient to protect the confidentiality of their highly 18 sensitive traffic flows. These end-users want their flows to 19 traverse devices which have been freshly appraised and verified for 20 trustworthiness. This specification describes Trusted Path Routing. 21 Trusted Path Routing protects sensitive flows as they transit a 22 network by forwarding traffic to/from sensitive subnets across 23 network devices recently appraised as trustworthy. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 14, 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4 63 3. Implementation Prerequisites . . . . . . . . . . . . . . . . 4 64 4. End-to-end Solution . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. Network Topology Assembly . . . . . . . . . . . . . . . . 5 66 4.2. Attestation Information Flows . . . . . . . . . . . . . . 6 67 4.2.1. Step 1 . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.2.2. Step 2 . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.2.3. Step 3 . . . . . . . . . . . . . . . . . . . . . . . 11 70 4.2.4. Step 4 . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.2.5. Step 5 . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.2.6. Step 6 . . . . . . . . . . . . . . . . . . . . . . . 15 73 5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 24 77 7.2. Informative References . . . . . . . . . . . . . . . . . 25 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26 79 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26 80 Appendix C. Open Questions . . . . . . . . . . . . . . . . . . . 27 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 83 1. Introduction 85 There are end-users who believe encryption technologies like IPSec 86 alone are insufficient to protect the confidentiality of their highly 87 sensitive traffic flows. These customers want their highly sensitive 88 flows to be transported over only network devices recently verified 89 as trustworthy. 91 By using a router's embedded TPM based cryptoprocessors in 92 conjunction with the Remote Attestation context established by 93 [attestation-results], a network provider can identify potentially 94 compromised devices as well as potentially exploitable (or even 95 exploited) vulnerabilities. Using this knowledge, it is then 96 possible to redirect sensitive flows around these devices while other 97 remediations are potentially considered by Network Operations. 99 Trusted Path Routing allows the establishing Trusted Topologies which 100 only include trust-verified network devices. Membership in a Trusted 101 Topology is established and maintained via an exchange of Stamped 102 Passports at the link layer between peering network devices. As 103 links to Attesting Devices are appraised as meeting at least a 104 minimum set of formally defined Trustworthiness Claims, the links are 105 then included as members of this Trusted Topology. Routing protocols 106 are then used to propagate topology state throughout a network. 108 IP Packets to and from end-user designated Sensitive Subnets are then 109 forwarded into this Trusted Topology at each network boundary. This 110 is done by an end user identifying sensitive IP subnets where flows 111 with applications using these IP subnets need enhanced privacy 112 guarantees. Trusted Path Routing passes flows to/from these 113 Sensitive Subnets over a Trusted Topology able to meet these 114 guarantees. The Trusted Topology itself consists of the 115 interconnection of network devices where each potentially transited 116 device has been verified as achieving a specific set of 117 Trustworthiness Claims during its most recent trustworthiness 118 appraisal. Interesting sets of Trustworthiness Claims might be 119 marketed to end-users in the following ways: 121 o all transited devices have booted with known hardware and firmware 123 o all transited devices are from a specific set of vendors and are 124 running known software containing the latest patches 126 o no guarantees provided 128 2. Terminology 130 2.1. Terms 132 The following terms are imported from [RATS-Arch]: Attester, 133 Evidence, Passport, Relying Party, and Verifier. 135 The following terms are impored from [attestation-results]: 136 Trustworthiness Claim, Trustworthiness Vector, AR-augmented Evidence 138 Newly defined terms for this document: 140 Attested Device - a network connected Attester where a Verifier's 141 most recent appraisal of Evidence has returned a Trustworthiness 142 Vector. 144 Stamped Passport - AR-augmented Evidence which can take two forms. 145 First if the Attester uses a TPM2, the the Verifier Proof-of- 146 Freshness includes the , , 147 and objects from a recent TPM2 quote made by that Attester, 148 and the Relying Party Proof-of-Freshness is returned along with 149 the timeticks as objects embedded within the most recent TPM quote 150 signed by the same TPM2. Second, if the Attester uses a TPM1.2: 151 the Verifier Proof-of-Freshness includes a global timestamp from 152 that Verifier, and the Relying Party Proof-of-Freshness is 153 embedded within a more recent TPM quote signed by the same TPM 154 Attesting Environment. 156 Sensitive Subnet - an IP address range where IP packets to or from 157 that range desire confidentially guarantees beyond those of non- 158 identified subnets. In practice, flows to or from a Sensitive 159 Subnet must only have their IP headers and encapsulated payloads 160 accessible/visible only by Attested Devices supporting one or more 161 Trustworthiness Vectors. 163 Transparently-Transited Device - a network device within an network 164 domain where any packets originally passed into that network 165 domain are completely opaque on that network device at Layer 3 and 166 above. 168 Trusted Topology - a topology which includes only Attested Devices 169 and Transparently-Transited Devices. 171 2.2. Requirements Notation 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 175 "OPTIONAL" in this document are to be interpreted as described in 176 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 177 capitals, as shown here. 179 3. Implementation Prerequisites 181 The specification is a valid instance of [attestation-results]. This 182 specification works under the following protocol and preconfiguration 183 prerequisite assumptions: 185 o All Attested Devices support the TPM remote attestation profile as 186 laid out in [RATS-Device]. 188 o One or more Verifier A's as defined in [attestation-results] 189 'Interaction Model' continuously appraise each of the Attested 190 Devices in a network domain, and these Verifiers return the 191 Attestation Results back to each originating Attested Device. 193 o The Attested Devices are connected via link layer protocols such 194 as [MACSEC] or [IEEE-802.1X]. 196 o Each Attester can pass a Stamped Passport to a Relying Party / 197 Verifier B as defined in [attestation-results] 'Interaction Model' 198 within [RFC3748] over that link layer protocol. 200 o A Trusted Topology such as [I-D.ietf-lsr-flex-algo] exists in an 201 IGP domain for the forwarding of Sensitive Subnet traffic. This 202 Topology will carry traffic across a set of Attested Devices which 203 currently meet at a defined set of Trustworthiness Vectors. 205 o A Relying Party is able to use mechanisms such as 206 [I-D.ietf-lsr-flex-algo]'s affinity to include/exclude links as 207 part of the Trusted Topology based on the appraisal of a Stamped 208 Passport. 210 o Customer designated Sensitive Subnets and their requested 211 Trustworthiness Vectors have been identified and associated with 212 external interfaces to/from Attested Devices at the edge of a 213 network. Traffic to a Sensitive Subnet can be passed into the 214 Trusted Topology by the Attested Device. 216 o Relying Party/Verifier B trusts information signed by Verifier A. 217 Verifier B has also been pre-provisioned with certificates or 218 public keys necessary to confirm that Stamped Passports came from 219 Verifier A. 221 4. End-to-end Solution 223 4.1. Network Topology Assembly 225 To be included in a Trusted Topology, Stamped Passports are shared 226 between Attested Devices (such as routers). Upon receiving and 227 appraising the Stamped Passport as part of link layer authentication, 228 the Relying Party Attested Device decides if this link should be 229 added as an active adjacency for a particular Trusted Topology. In 230 Figure 1 below, this might be done by applying an Appraisal Policy 231 for Attestation Results which requires any Attesting Device be most 232 recently appraised with the Trustworthiness Claim 'hw-authentic'. If 233 Attested Device 'x' has been appraised with 'hw-verification-fail' is 234 would not become part of the Trustworthy Topology. 236 When enough links have been successfully added, the Trusted Topology 237 will support edge-to-edge forwarding as routing protocols flood the 238 adjacency information across the network domain. 240 .------------. .----------. 241 | Attested | | Edge | 242 .----------. | Device 'x' | | Attested | 243 | Attested | | | | Device | 244 | Device | | | | | 245 | | | trust>-----------------====================| | 308 | time(RG) | 309 |<------Attestation Results-(2) | 310 ~ ~ ~ 311 time(VG')? | | 312 ~ ~ ~ 313 |<------nonce---------------------------------(3)time(NS') 314 | | | 315 time(EG')(4)------Stamped Passport---------------------->| 316 | | time(RG',RA')(5) 317 (6) 318 ~ 319 time(RX') 321 Figure 2: Trusted Path Timing 323 To summarize Figure 2 above, Evidence about a specific Attester is 324 generated. Some subset of this evidence will be in the form of PCR 325 quotes which are signed by a TPM that exists as the Attester's 326 Attesting Environment. This Evidence will be delibered to and 327 appraised by Verifier A. Verifier A will then appraise the Attester 328 and give it a Trustworthiness Vector. This Trustworthiness Vector is 329 then signed by Verifier A and be returned as Attestation Results to 330 the Attester. Later, when a request comes in from a Relying Party, 331 the Attester assembles and returns a Stamped Passport. The Stamped 332 Passport contains all the information necessary for Verifier B to 333 appraise the most recent Trustworthiness Vector of the Attester. 334 Based on the Verifier B appraisal, the link will be included or not 335 in a Trusted Topology maintained on the Relying Party. 337 More details on the mechanisms used in the construction, 338 verification, and transmitting of the Stamped Passport are listed 339 below. These numbers match to both the numbered steps of Figure 2 340 and numbered steps described in Section 3 of [attestation-results]: 342 4.2.1. Step 1 344 Evidence about and Attester is generated. A portion of this Evidence 345 will include a PCR quote signed by a TPM private LDevID key that 346 exists within the Attester's TPM based Attesting Environment. The 347 Attester sends a signed TPM Quote which includes PCR measurements to 348 Verifier A at time(EG). 350 There are two alternatives for Verifier A to acquire this signed 351 Evidence: 353 o Subscription to the stream defined in 354 [stream-subscription]. Note: this method is recommended as it 355 will minimize the interval between when a PCR change is made in a 356 TPM, and when the PCR change appraisal is incorporated within a 357 subsequent Stamped Passport. 359 o Periodic polling of RPC or 360 the RPC which are defined 361 in [RATS-YANG]. 363 4.2.2. Step 2 365 Verifier A appraises the Evidence from Step 1. A portion of this 366 appraisal process will follow the appraisal process flow described 367 below. This appraisal process MUST be able to set at least the 368 following set of Trustworthiness Claims from [attestation-results]: 369 'hw-authentic', 'hw-verification-fail', 'tee-identity-verified', 370 'tee-identity-fail', 'executables-verified', and 'executables-fail'. 371 The establishment of a Trustworthiness Vector uses the following 372 Figure 3 logic on the Verifier: 374 Start: TPM Quote Received, log received, or appraisal timer expired 375 for the the Attesting network device. 377 Appraisal 0: set Trustworthiness Vector = Null 379 Appraisal 1: Is there sufficient fresh signed evidence to appraise? 380 yes - No action 381 no - Go to End 383 Appraisal 2: Appraise Hardware Integrity 384 if not evaluated, or insufficient data to conclude: take no action 385 else if (hw-authentic) - push onto vector 386 else (if hw-verification-fail) - push onto vector, go to End 388 Appraisal 3: Appraise attester identity 389 if not evaluated, or insufficient data to conclude: take no action 390 else if (tee-identity-verified) - push onto vector 391 else if (tee-identity-fail) - push onto vector 393 Appraisal 4: Appraise executable loaded 394 if not evaluated, or insufficient data to conclude: take no action 395 else if (executables-verified) - push onto vector 396 else (if executables-fail) - push onto vector, go to End 398 Appraisal 5: a Verifier has the option of appraising and asserting 399 additional non-standard Trustworthiness Claims. It can do so here. 401 End 403 Figure 3: Verifier A Appraisal Flow 405 After the appraisal and generation of the Trustworthiness Vector, the 406 following are assembled as the set of Attestation Results from this 407 particular appraisal cycle: 409 (2.1) the Public Attestation Key which was used to validate the TPM 410 Quote of Step 1. This is encoded by , , and . 413 (2.2) the appraised Trustworthiness Vector of the Attester as 414 calculated in Figure 3 416 (2.3) the PCR state information from the TPM Quote of (1) plus the 417 time information associated with the TPM Quote of (1). Specifically 418 if the Attester has a TPM2, then the values of the TPM PCRs are 419 included (i.e., , , and ), 420 as are the timing counters from the TPM (i.e., , , , and ). Likewise if the Attester 422 has a TPM1.2, the TPM PCR values of the and 423 are included. Timing information comes from the Verifier itself via 424 the object. 426 (2.4) a Verifier A signature across (2.1) though (2.3). This 427 signature is encoded by , , and . 430 Immediately subsequent to each Verifier appraisal cycle of an 431 Attester, these Attestation Results MUST be pushed to the Attesting 432 Router. This is done via a daatstore write to the following YANG 433 model on the Attester. A YANG tree showing the relevant YANG objects 434 is below. The YANG model describing each of these objects is 435 described later in the document. Note however that although the YANG 436 model shows the specific objects which are needed, the specific set 437 of objects needs to be encoded in CDDL. This makes the payload going 438 over TLS more efficient. Look for this encoding in a new version of 439 the draft which is coming shortly. 441 module: ietf-trustworthiness-claims 442 +--rw attestation-results! 443 +--rw (tpm-specification-version)? 444 +--:(tpm20-attestation-results-cddl) {taa:tpm20}? 445 | +--rw trustworthiness-vector* identityref 446 | +--rw tpm20-pcr-selection* [tpm20-hash-algo] 447 | | +--rw tpm20-hash-algo identityref 448 | | +--rw pcr-index* tpm:pcr 449 | +--rw TPM2B_DIGEST binary 450 | +--rw clock uint64 451 | +--rw reset-counter uint32 452 | +--rw restart-counter uint32 453 | +--rw safe boolean 454 | +--rw appraisal-timestamp 455 | | yang:date-and-time 456 | +--rw verifier-algorithm-type identityref 457 | +--rw verifier-signature binary 458 | +--rw verifier-certificate-keystore-ref 459 | tpm:certificate-name-ref 460 +--:(tpm12-attestation-results-cddl) {taa:TPM12}? 461 +--rw trustworthiness-vector* identityref 462 +--rw pcr-index* pcr 463 +--rw tpm12-pcr-value* binary 464 +--rw TPM12-quote-timestamp 465 | yang:date-and-time 466 +--rw appraisal-timestamp 467 | yang:date-and-time 468 +--rw verifier-algorithm-type identityref 469 +--rw verifier-signature binary 470 +--rw verifier-certificate-keystore-ref 471 tpm:certificate-name-ref 473 (Do we want the Verifier signature across the keystore-ref?) 475 Figure 4: Attestation Results Tree 477 4.2.3. Step 3 479 At time(NS') some form of time-based freshness (such as a nonce or 480 Epoch Handle [RATS-Interactions]) will be generated in a way which 481 makes it available to the Relying Party. Soon after time(NS'), a 482 Relying Party will make a Link Layer authentication request to an 483 Attester via a either [MACSEC] or [IEEE-802.1X]. This connection 484 request MUST expect the return of [RFC3748] credentials from the 485 Attester. 487 4.2.4. Step 4 489 Upon receipt of the Link Layer request from Step 3, a Stamped 490 Passport is generated and sent to the Relying Party. The Stamped 491 Passport MUST include the following: 493 (4.1) The Attestation Results from Step 2 495 (4.2) New signed, verifiably fresh PCR measurements based on a TPM 496 quote at time(EG') which incorporates the freshness information known 497 by the Relying Party from Step 3. If it is a nonce, the freshness 498 information will have been delivered as part of the link layer 499 connection request in Steps 3. 501 Stamped Passports contain following objects, defined in this document 502 via YANG. A subsequent draft will convert the objects below into 503 CDDL format so that the objects can efficiently be passed over EAP. 505 If an Attester includes a TPM2, these YANG objects are: 507 +---n tpm20-stamped-passport 508 +--ro attestation-results 509 | +--ro trustworthiness-vector* identityref 510 | +--ro tpm20-pcr-selection* [tpm20-hash-algo] 511 | | +--ro tpm20-hash-algo identityref 512 | | +--ro pcr-index* tpm:pcr 513 | +--ro TPM2B_DIGEST binary 514 | +--ro clock uint64 515 | +--ro reset-counter uint32 516 | +--ro restart-counter uint32 517 | +--ro safe boolean 518 | +--ro appraisal-timestamp 519 | | yang:date-and-time 520 | +--ro verifier-algorithm-type identityref 521 | +--ro verifier-signature binary 522 | +--ro verifier-certificate-keystore-ref 523 | tpm:certificate-name-ref 524 +--ro tpm20-quote 525 +--ro TPMS_QUOTE_INFO binary 526 +--ro quote-signature? binary 527 +--ro certificate-name certificate-name-ref 529 Figure 5: YANG Tree for a TPM2 Stamped Passport 531 Note that where a TPM2.0 is used, the PCR numbers and hash algorithms 532 quoted in Step 1 MUST match the PCR numbers and hash algorithms 533 quoted in this step. 535 And if the Attester is a TPM1.2, the YANG object are: 537 +---n tpm12-stamped-passport 538 +--ro attestation-results 539 | +--ro trustworthiness-vector* identityref 540 | +--ro pcr-index* pcr 541 | +--ro tpm12-pcr-value* binary 542 | +--ro TPM12-quote-timestamp 543 | | yang:date-and-time 544 | +--ro appraisal-timestamp 545 | | yang:date-and-time 546 | +--ro verifier-algorithm-type identityref 547 | +--ro verifier-signature binary 548 | +--ro verifier-certificate-keystore-ref 549 | tpm:certificate-name-ref 550 +--ro tpm12-quote 551 +--ro TPM_QUOTE2? binary 552 +--ro certificate-name certificate-name-ref 554 Figure 6: YANG Tree for a TPM1.2 Stamped Passport 556 With either of these passport formats, if the TPM quote is verifiably 557 fresh, then the state of the Attester can be appraised by a network 558 peer. 560 Note that with [MACSEC] or [IEEE-802.1X], Step 3 plus Step 4 will 561 repeat periodically independently of any subsequent iteration Steps 1 562 and Step 2. This allows for periodic reauthentication of the link 563 layer in a way not bound to the updating of Verifier A's Attestation 564 Results. 566 4.2.5. Step 5 568 Upon receipt of the Stamped Passport generated in Step 4, the Relying 569 Party appraises this Stamped Passport as per its Appraisal Policy for 570 Attestation Results. The result of this application will determine 571 how the Stamped Passport will impact adjacencies within a Trusted 572 Topology. The decision process is as follows: 574 (5.1) Verify that (4.2) includes the freshness context from Step 3. 576 (5.2) Use a local certificate to validate the signature (4.1). 578 (5.3) Verify that the hash from (4.2) matches (4.1) 580 (5.4) Use the identity of (2.1) to validate the signature of (4.2). 582 (5.5) Failure of any steps (5.1) through (5.4) means the link does 583 not meet minimum validation criteria, therefore appraise the link as 584 having a null Verifier B Trustworthiness Vector. Jump to Step 6. 586 (5.6) Compare the time(EG) TPM state to the time(EG') TPM state 588 o If TPM2.0 590 1. If the , , and 591 are equal between the Attestation Results and the TPM 592 Quote at time(EG') then Relying Party can accept (2.1) as the 593 link's Trustworthiness Vector. Jump to Step 6. 595 2. If the , and are equal 596 between the Attestation Results and the TPM Quote at 597 time(EG'), and the object from time(EG') has not 598 incremented by an unacceptable number of seconds since the 599 Attestation Result, then Relying Party can accept (2.1) as the 600 link's Trustworthiness Vector. Jump to Step 6.) 602 3. Assign the link a null Trustworthiness Vector. 604 o If TPM1.2 606 1. If the 's and 's are equal between 607 the Attestation Results and the TPM Quote at time(EG'), then 608 Relying Party can accept (2.1) as the link's Trustworthiness 609 Vector. Jump to step (6). 611 2. If the time hasn't incremented an unacceptable number of 612 seconds from the Attestation Results and the 613 system clock of the Relying Party, then Relying Party can 614 accept (2.1) as the link's Trustworthiness Vector. Jump to 615 step 6.) 617 3. Assign the link a null Trustworthiness Vector. 619 (5.7) Assemble the Verifier B Trustworthiness Vector 621 1. Copy Verifier A Trustworthiness Vector to Verifier B 622 Trustworthiness Vector 624 2. Prune any Trustworthiness Claims the Relying Party doesn't accept 625 from this Verifier. 627 4.2.6. Step 6 629 After the Trustworthiness Vector has been validated or reset, based 630 on the link's Trustworthiness Vector, the Relying Party adjusts the 631 link affinity of the corresponding ISIS [I-D.ietf-lsr-flex-algo] 632 topology. ISIS will then replicate the link state across the IGP 633 domain. Traffic will then avoid links which do not have a qualifying 634 Trustworthiness Vector. 636 5. YANG Module 638 This YANG module imports modules from [RATS-YANG], [crypto-types] and 639 [RFC6021]. 641 ietf-trustworthiness-claims@2021-05-12.yang 642 module ietf-trustworthiness-claims { 643 yang-version 1.1; 644 namespace 645 "urn:ietf:params:xml:ns:yang:ietf-trustworthiness-claims"; 646 prefix tc; 648 import ietf-yang-types { 649 prefix yang; 650 } 651 import ietf-tcg-algs { 652 prefix taa; 653 reference 654 "draft-ietf-rats-yang-tpm-charra"; 655 } 656 import ietf-keystore { 657 prefix ks; 658 } 659 import ietf-tpm-remote-attestation { 660 prefix tpm; 661 reference 662 "draft-ietf-rats-yang-tpm-charra"; 663 } 665 organization "IETF"; 666 contact 667 "WG Web: 668 WG List: 670 Editor: Eric Voit 671 "; 673 description 674 "This module contains conceptual YANG specifications for 675 subscribing to attestation streams being generated from TPM chips. 677 Copyright (c) 2020 IETF Trust and the persons identified as 678 authors of the code. All rights reserved. 680 Redistribution and use in source and binary forms, with or without 681 modification, is permitted pursuant to, and subject to the license 682 terms contained in, the Simplified BSD License set forth in 683 Section 4.c of the IETF Trust's Legal Provisions Relating to IETF 684 Documents (https://trustee.ietf.org/license-info). 686 This version of this YANG module is part of RFC XXXX; see the RFC 687 itself for full legal notices."; 689 revision 2021-05-12 { 690 description 691 "Initial version."; 692 reference 693 "draft-voit-rats-trustworthy-path-routing"; 694 } 696 /* 697 * IDENTITIES 698 */ 700 identity trustworthiness-claim { 701 base trustworthiness-claim; 702 description 703 "Base identity for a Verifier that uses its Appraisal Policy for 704 Evidence to establish a trustworthiness level."; 705 } 707 identity trustworthiness-pass { 708 base trustworthiness-claim; 709 description 710 "A trustworthiness-claim which successfully meets an Appraisal 711 Policy for Evidence."; 712 } 714 identity trustworthiness-fail { 715 description 716 "A trustworthiness-claim which hit Appraisal Policy for Evidence 717 necessary to fail an evaluation. Note: this failure might or 718 might not consider whether sufficient Evidence has been 719 provided. In other words having insufficient evidence might 720 not drive the setting of this failing trustworthiness-claim."; 721 } 722 identity hw-authentic { 723 base trustworthiness-pass; 724 description 725 "A Verifier has appraised an Attester as having authentic 726 hardware, as well as authentic firmwhere where that can be 727 verified."; 728 } 730 identity hw-verification-fail { 731 base trustworthiness-fail; 732 description 733 "A Verifier has appraised an Attester has failed its hardware or 734 firmware verification."; 735 } 737 identity tee-identity-verified { 738 base trustworthiness-pass; 739 description 740 "A Verifier has appraised and verified an Attester's unique 741 identity stored within the hardware of a Trusted Execution 742 Environment."; 743 } 745 identity tee-identity-fail { 746 base trustworthiness-fail; 747 description 748 "A Verifier has been unable to assess or verify an Attester's 749 unique identity"; 750 } 752 identity executables-verified { 753 base trustworthiness-pass; 754 description 755 "A Verifier has appraised the executables loaded on Attester's, 756 and asserts that it recognizes and approves of all relevant 757 executiable files loaded."; 758 } 760 identity executables-fail { 761 base trustworthiness-fail; 762 description 763 "A Verifier has appraised the executables loaded on Attester's, 764 and has not been able to recognize or does not approved of all 765 the executible files which have been loaded."; 766 } 768 identity file-system-anomaly { 769 base trustworthiness-fail; 770 description 771 "A Verifier has found a file on an Attester which should not be 772 present."; 773 } 775 /* 776 * GROUPINGS 777 */ 779 grouping trustworthiness-vector { 780 leaf-list trustworthiness-vector { 781 type identityref { 782 base trustworthiness-claim; 783 } 784 ordered-by system; 785 description 786 "One or more Trustworthiness Claims assigned which expose the 787 Verifiers evaluation of the Evidence associated with the 788 AIK which signed as associated TPM Quote."; 789 } 790 } 792 grouping tpm-signature { 793 leaf aik-algorithm-type { 794 type identityref { 795 base taa:asymmetric; 796 } 797 mandatory true; 798 description 799 "Platform asymmetric algorithm used in the Attester signature 800 process."; 801 } 802 leaf aik-signature { 803 type binary; 804 mandatory true; 805 description 806 "Signature of the Attester across a TPM Quote."; 807 } 808 uses tpm:certificate-name-ref; 809 } 811 grouping verifier-evidence { 812 description 813 "Evidence generated by the Verifier."; 814 leaf appraisal-timestamp { 815 type yang:date-and-time; 816 mandatory true; 817 description 818 "The timestamp of the Verifier's appraisal. This can be used 819 by a Relying Party to determine the freshness of the 820 attestation results."; 821 } 822 leaf verifier-algorithm-type { 823 type identityref { 824 base taa:asymmetric; 825 } 826 mandatory true; 827 description 828 "Platform asymmetric algorithm used in the Verifier signature 829 process."; 830 } 831 leaf verifier-signature { 832 type binary; 833 mandatory true; 834 description 835 "Signature of the Verifier across all the current objects in 836 the attestation-results container except for 'verifier- 837 signature' and 'verifier-certificate-keystore-ref'. 838 This assumes CDDL encoding of the objects in the current 839 order of this YANG model."; 840 } 841 leaf verifier-certificate-keystore-ref { 842 type tpm:certificate-name-ref; 843 mandatory true; 844 description 845 "A reference to a specific certificate to an asymmetric key 846 in the Keystore for the Verifier which can be used to validate 847 the 'verifier-signature'. Note that the 848 'name' reference must be globally unique so that it can be 849 read by the Relying Party in a way which identifies a 850 specific Verifier."; 851 } 852 } 854 grouping tpm20-cddl-attestation-results { 855 description 856 "Elements combined into a CDDL representation for TPM2.0."; 857 uses trustworthiness-vector; 858 list tpm20-pcr-selection { 859 key "tpm20-hash-algo"; 860 description 861 "Specifies the list of PCRs and Hash Algorithms used by the 862 Verifier."; 863 reference 864 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 865 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.9.7"; 866 uses tpm:tpm20-hash-algo; 867 leaf-list pcr-index { 868 type tpm:pcr; 869 description 870 "The numbers of the PCRs associated with the TPM2B_DIGEST."; 871 } 872 } 873 leaf TPM2B_DIGEST { 874 mandatory true; 875 type binary; 876 description 877 "A hash of the latest PCR values (and the hash algorithm used) 878 which have been returned from a Verifier for the selected PCRs 879 identified within TPML_PCR_SELECTION."; 880 reference 881 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 882 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.12.1"; 883 } 884 leaf clock { 885 mandatory true; 886 type uint64; 887 description 888 "Clock is a monotonically increasing counter that advances 889 whenever power is applied to a TPM2. The value of Clock is 890 incremented each millisecond."; 891 reference 892 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 893 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.2"; 894 } 895 leaf reset-counter { 896 mandatory true; 897 type uint32; 898 description 899 "This counter increments on each TPM Reset. The most common 900 TPM Reset would be due to a hardware power cycle."; 901 reference 902 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 903 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.3"; 904 } 905 leaf restart-counter { 906 mandatory true; 907 type uint32; 908 description 909 "This counter shall increment by one for each TPM Restart or 910 TPM Resume. The restartCount shall be reset to zero on a TPM 911 Reset."; 912 reference 913 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 914 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.4"; 915 } 916 leaf safe { 917 mandatory true; 918 type boolean; 919 description 920 "This parameter is set to YES when the value reported in Clock 921 is guaranteed to be unique for the current Owner. It is set to 922 NO when the value of Clock may have been reported in a previous 923 attestation or access."; 924 reference 925 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 926 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.5"; 927 } 928 uses tpm-aik-certificate; 929 uses verifier-evidence; 930 } 932 grouping tpm12-cddl-attestation-results { 933 description 934 "Elements combined into a CDDL representation for TPM1.2."; 935 uses trustworthiness-vector; 936 uses tpm:tpm12-pcr-selection; 937 leaf-list tpm12-pcr-value { 938 type binary; 939 description 940 "The list of TPM_PCRVALUEs from each PCR selected in sequence 941 of tpm12-pcr-selection."; 942 reference 943 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 944 TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf 945 Section 10.9.7"; 946 } 947 leaf TPM12-quote-timestamp { 948 type yang:date-and-time; 949 mandatory true; 950 description 951 "The timestamp for when the indicator of freshness (such as a 952 nonce) was generated. This is the indicator of freshness 953 which was used in the generation of the TPM1.2 quote. This 954 timestamp can be used by a Relying Party to determine the 955 freshness of the attestation results."; 956 } 957 uses tpm-aik-certificate; 958 uses verifier-evidence; 959 } 960 /* 961 * NOTIFICATIONS 962 */ 964 notification tpm20-stamped-passport { 965 description 966 "The augmentation of the most recent Attestation Results 967 delivered from a Verifier with a TPM2.0 Quote."; 968 container attestation-results { 969 description 970 "The latest Verifier delivered Attestation Results."; 971 uses tpm20-cddl-attestation-results; 972 } 973 container tpm20-quote { 974 description 975 "The TPM2.0 quote delivered in response to a connectivity 976 request."; 977 leaf TPMS_QUOTE_INFO { 978 type binary; 979 mandatory true; 980 description 981 "A hash of the latest PCR values (and the hash algorithm 982 used) which have been returned from a Verifier for the 983 selected PCRs and Hash Algorithms."; 984 reference 985 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 986 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.12.1"; 987 } 988 leaf quote-signature { 989 type binary; 990 description 991 "Quote signature returned by TPM Quote. The signature was 992 generated using the key associated with the 993 certificate 'name'."; 994 reference 995 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 996 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 11.2.1"; 997 } 998 uses tpm:certificate-name-ref; 999 } 1000 } 1002 notification tpm12-stamped-passport { 1003 description 1004 "The augmentation of the most recent Attestation Results 1005 delivered from a Verifier with a TPM1.2 Quote."; 1006 container attestation-results { 1007 description 1008 "The latest Verifier delivered Attestation Results."; 1009 uses tpm12-cddl-attestation-results; 1010 } 1011 container tpm12-quote { 1012 description 1013 "The TPM1.2 quote delivered in response to a connectivity 1014 request."; 1015 leaf TPM_QUOTE2 { 1016 type binary; 1017 description 1018 "Result of a TPM1.2 Quote2 operation. This includes PCRs, 1019 signatures, locality, the provided nonce and other data which 1020 can be further parsed to appraise the Attester."; 1021 reference 1022 "TPM1.2 commands rev116 July 2007, Section 16.5"; 1023 } 1024 uses tpm:certificate-name-ref; 1025 } 1026 } 1028 /* 1029 * DATA NODES 1030 */ 1032 container attestation-results { 1033 presence 1034 "Indicates that Verifier has appraised the security posture of 1035 the Attester, and returned the results within this container."; 1036 description 1037 "Retains the most recent Attestation Results for this Attester. 1038 It must only be written by a Verfier which is to be trusted by a 1039 Relying Party."; 1041 choice tpm-specification-version { 1042 description 1043 "Identifies the cryptoprocessor API set which drove the 1044 Attestation Results."; 1045 case tpm20-attestation-results-cddl { 1046 if-feature "taa:tpm20"; 1047 description 1048 "Attestation Results which are returned from the 1049 evaluation of Evidence which includes a TPM2 quote."; 1050 uses tpm20-cddl-attestation-results; 1051 } 1052 case tpm12-attestation-results-cddl { 1053 if-feature "taa:TPM12"; 1054 description 1055 "Attestation Results which are returned from the 1056 evaluation of Evidence which includes a TPM1.2 quote."; 1057 uses tpm12-cddl-attestation-results; 1058 } 1059 } 1060 } 1061 } 1062 1064 6. Security Considerations 1066 Verifiers are limited to the Evidence available for appraisal from a 1067 Router. Although the state of the art is improving, some exploits 1068 may not be visible via Evidence. 1070 Only security measurements which are placed into PCRs are capable of 1071 being exposed via TPM Quote at time(EG'). 1073 Successful attacks on an Verifier have the potential of affecting 1074 traffic on the Trusted Topology. 1076 For Trusted Path Routing, links which are part of the FlexAlgo are 1077 visible across the entire IGP domain. Therefore a compromised device 1078 will know when it is being bypassed. 1080 Access control for the objects in Figure 4 should be tightly 1081 controlled so that it becomes difficult for the Stamped Passport to 1082 become a denial of service vector. 1084 7. References 1086 7.1. Normative References 1088 [attestation-results] 1089 "Attestation Results for Connectivity", April 2021, 1090 . 1093 [crypto-types] 1094 "Common YANG Data Types for Cryptography", May 2020, 1095 . 1098 [RATS-Arch] 1099 "Remote Attestation Procedures Architecture", March 2020, 1100 . 1103 [RATS-YANG] 1104 "A YANG Data Model for Challenge-Response-based Remote 1105 Attestation Procedures using TPMs", June 2020, 1106 . 1109 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1110 Requirement Levels", BCP 14, RFC 2119, 1111 DOI 10.17487/RFC2119, March 1997, 1112 . 1114 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 1115 RFC 6021, DOI 10.17487/RFC6021, October 2010, 1116 . 1118 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1119 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1120 May 2017, . 1122 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1123 E., and A. Tripathy, "Subscription to YANG Notifications", 1124 RFC 8639, DOI 10.17487/RFC8639, September 2019, 1125 . 1127 [TPM1.2] TCG, ., "TPM 1.2 Main Specification", October 2003, 1128 . 1131 [TPM2.0] TCG, ., "TPM 2.0 Library Specification", March 2013, 1132 . 1135 7.2. Informative References 1137 [I-D.ietf-lsr-flex-algo] 1138 Cisco Systems, Juniper Networks, Cisco Systems, Cisco 1139 Systems, and Edward Jones, "IGP Flexible Algorithm", 1140 draft-ietf-lsr-flex-algo-15 (work in progress), April 1141 2021. 1143 [IEEE-802.1X] 1144 Parsons, G., "802.1AE: MAC Security (MACsec)", January 1145 2020, 1146 . 1148 [MACSEC] Seaman, M., "802.1AE: MAC Security (MACsec)", January 1149 2006, . 1151 [RATS-Device] 1152 "Network Device Remote Integrity Verification", n.d., 1153 . 1156 [RATS-Interactions] 1157 "Reference Interaction Models for Remote Attestation 1158 Procedures", June 2020, . 1162 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1163 Levkowetz, Ed., "Extensible Authentication Protocol 1164 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1165 . 1167 [stream-subscription] 1168 "Attestation Event Stream Subscription", June 2020, 1169 . 1172 Appendix A. Acknowledgements 1174 Peter Psenak, Shwetha Bhandari, Adwaith Gautham, Annu Singh, Sujal 1175 Sheth, Nancy Cam Winget, and Ned Smith. 1177 Appendix B. Change Log 1179 [THIS SECTION TO BE REMOVED BY THE RFC EDITOR.] 1181 v02-v03 1183 o Integrated [attestation-results] as prerequisite context. 1185 o Totally rearranged content. But there were not meaningful process 1186 changes. 1188 o Redid YANG model, and highlighted CDDL needs. 1190 v01-v02 1192 o Minor tweaks such as renaming and removal of a few 1193 trustworthiness-claims 1195 v00-v01 1197 o Minor tweaks 1198 v02-v00 of draft-voit-rats-trustworthy-path-routing-00 1200 o file rename was due to an IETF tool submission glitch 1202 o The Attester's AIK is included within the Stamped Passport. This 1203 eliminates the need to provision to AIK certificate on the Relying 1204 Party. 1206 o Removed Centralized variant 1208 o Added timing diagram, and moved content around to match 1210 v01-v02 of draft-voit-rats-trusted-path-routing 1212 o Extracted the attestation stream, and placed into draft-birkholz- 1213 rats-network-device-subscription 1215 o Introduced the Trustworthiness Vector 1217 v00-v01 of draft-voit-rats-trusted-path-routing 1219 o Move all FlexAlgo terminology to allow passport definition to be 1220 more generic. 1222 o Edited Figure 1 so that (4) points to the egress router. 1224 o Added text freshness mechanisms, and articulated configured 1225 subscription support. 1227 o Minor YANG model clarifications. 1229 o Added a few open questions which Frank thinks interesting to work. 1231 Appendix C. Open Questions 1233 (1) When there is no available Trusted Topology? 1235 Do we need functional requirements on how to handle traffic to/from 1236 Sensitive Subnets when no Trusted Topology exists between IGP edges? 1237 The network typically can make this unnecessary. For example it is 1238 possible to construct a local IPSec tunnel to make untrusted devices 1239 appear as Transparently-Transited Devices. This way Secure Subnets 1240 could be tunneled between FlexAlgo nodes where an end-to-end path 1241 doesn't currently exist. However there still is a corner case where 1242 all IGP egress points are not considered sufficiently trustworthy. 1244 (2) Extension of the Stamped Passport? 1245 Format of the reference to the 'verifier-certificate-name' based on 1246 WG desire to include more information in the Stamped Passport. Also 1247 we need to make sure that the keystore referenced names are globally 1248 unique, else we will need to include a node name in the object set. 1250 (3) Encoding of objects in CDDL. A Verifier will want to sign 1251 encoded objects rather than YANG structures. It is most efficient to 1252 encode the Attestation Results once on the Verifier, and push these 1253 down via a YANG model to the Attester. 1255 Authors' Addresses 1257 Eric Voit 1258 Cisco Systems, Inc. 1259 8135 Maple Lawn Blvd 1260 Fulton, Maryland 20759 1261 USA 1263 Email: evoit@cisco.com 1265 Chennakesava Reddy Gaddam 1266 Cisco Systems, Inc. 1267 Cessna Business Park, Kadubeesanahalli 1268 Bangalore, Karnataka 560103 1269 India 1271 Email: chgaddam@cisco.com 1273 Guy C. Fedorkow 1274 Juniper Networks 1275 10 Technology Park Drive 1276 Westford, Massachusetts 01886 1277 USA 1279 Email: gfedorkow@juniper.net 1281 Henk Birkholz 1282 Fraunhofer SIT 1283 Rheinstrasse 75 1284 Darmstadt 64295 1285 Germany 1287 Email: henk.birkholz@sit.fraunhofer.de