idnits 2.17.1 draft-voit-rats-trustworthy-path-routing-05.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 3 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 460 has weird spacing: '...sh-algo ide...' == Line 536 has weird spacing: '...sh-algo ide...' == Line 553 has weird spacing: '...gnature bin...' -- The document date (2 March 2022) is 786 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-18 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 C. Gaddam 4 Intended status: Standards Track Cisco 5 Expires: 3 September 2022 G. Fedorkow 6 Juniper 7 H. Birkholz 8 Fraunhofer SIT 9 M. Chen 10 China Mobile 11 2 March 2022 13 Trusted Path Routing 14 draft-voit-rats-trustworthy-path-routing-05 16 Abstract 18 There are end-users who believe encryption technologies like IPSec 19 alone are insufficient to protect the confidentiality of their highly 20 sensitive traffic flows. These end-users want their flows to 21 traverse devices which have been freshly appraised and verified for 22 trustworthiness. This specification describes Trusted Path Routing. 23 Trusted Path Routing protects sensitive flows as they transit a 24 network by forwarding traffic to/from sensitive subnets across 25 network devices recently appraised as trustworthy. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 3 September 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4 64 3. Implementation Prerequisites . . . . . . . . . . . . . . . . 4 65 4. End-to-end Solution . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. Network Topology Assembly . . . . . . . . . . . . . . . . 5 67 4.2. Attestation Information Flows . . . . . . . . . . . . . . 6 68 4.2.1. Step 1 . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.2.2. Step 2 . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.2.3. Step 3 . . . . . . . . . . . . . . . . . . . . . . . 13 71 4.2.4. Step 4 . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.2.5. Step 5 . . . . . . . . . . . . . . . . . . . . . . . 15 73 4.2.6. Step 6 . . . . . . . . . . . . . . . . . . . . . . . 17 74 5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 28 78 7.2. Informative References . . . . . . . . . . . . . . . . . 29 79 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 30 80 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 30 81 Appendix C. Open Questions . . . . . . . . . . . . . . . . . . . 32 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 84 1. Introduction 86 There are end-users who believe encryption technologies like IPSec 87 alone are insufficient to protect the confidentiality of their highly 88 sensitive traffic flows. These customers want their highly sensitive 89 flows to be transported over only network devices recently verified 90 as trustworthy. 92 By using a router's embedded TPM based cryptoprocessors in 93 conjunction with the Remote Attestation context established by 94 [attestation-results], a network provider can identify potentially 95 compromised devices as well as potentially exploitable (or even 96 exploited) vulnerabilities. Using this knowledge, it is then 97 possible to redirect sensitive flows around these devices while other 98 remediations are potentially considered by Network Operations. 100 Trusted Path Routing allows the establishing Trusted Topologies which 101 only include trust-verified network devices. Membership in a Trusted 102 Topology is established and maintained via an exchange of Stamped 103 Passports at the link layer between peering network devices. As 104 links to Attesting Devices are appraised as meeting at least a 105 minimum set of formally defined Trustworthiness Claims, the links are 106 then included as members of this Trusted Topology. Routing protocols 107 are then used to propagate topology state throughout a network. 109 IP Packets to and from end-user designated Sensitive Subnets are then 110 forwarded into this Trusted Topology at each network boundary. This 111 is done by an end user identifying sensitive IP subnets where flows 112 with applications using these IP subnets need enhanced privacy 113 guarantees. Trusted Path Routing passes flows to/from these 114 Sensitive Subnets over a Trusted Topology able to meet these 115 guarantees. The Trusted Topology itself consists of the 116 interconnection of network devices where each potentially transited 117 device has been verified as achieving a specific set of 118 Trustworthiness Claims during its most recent trustworthiness 119 appraisal. Interesting sets of Trustworthiness Claims might be 120 marketed to end-users in the following ways: 122 * all transited devices have booted with known hardware and firmware 124 * all transited devices are from a specific set of vendors and are 125 running known software containing the latest patches 127 * no guarantees provided 129 2. Terminology 131 2.1. Terms 133 The following terms are imported from [RATS-Arch]: Attester, 134 Evidence, Passport, Relying Party, and Verifier. 136 The following terms are impored from [attestation-results]: 137 Trustworthiness Claim, Trustworthiness Vector, AR-augmented Evidence 139 Newly defined terms for this document: 141 Attested Device -- a network connected Attester where a Verifier's 142 most recent appraisal of Evidence has returned a Trustworthiness 143 Vector. 145 Stamped Passport -- AR-augmented Evidence which can take two forms. 146 First if the Attester uses a TPM2, the the Verifier Proof-of- 147 Freshness includes the , , 148 and objects from a recent TPM2 quote made by that Attester, 149 and the Relying Party Proof-of-Freshness is returned along with 150 the timeticks as objects embedded within the most recent TPM quote 151 signed by the same TPM2. Second, if the Attester uses a TPM1.2: 152 the Verifier Proof-of-Freshness includes a global timestamp from 153 that Verifier, and the Relying Party Proof-of-Freshness is 154 embedded within a more recent TPM quote signed by the same TPM 155 Attesting Environment. 157 Sensitive Subnet -- an IP address range where IP packets to or from 158 that range desire confidentially guarantees beyond those of non- 159 identified subnets. In practice, flows to or from a Sensitive 160 Subnet must only have their IP headers and encapsulated payloads 161 accessible/visible only by Attested Devices supporting one or more 162 Trustworthiness Vectors. 164 Transparently-Transited Device -- a network device within an network 165 domain where any packets originally passed into that network 166 domain are completely opaque on that network device at Layer 3 and 167 above. 169 Trusted Topology -- a topology which includes only Attested Devices 170 and Transparently-Transited Devices. 172 2.2. Requirements Notation 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 176 "OPTIONAL" in this document are to be interpreted as described in 177 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 178 capitals, as shown here. 180 3. Implementation Prerequisites 182 The specification is a valid instance of [attestation-results]. This 183 specification works under the following protocol and preconfiguration 184 prerequisite assumptions: 186 * All Attested Devices support the TPM remote attestation profile as 187 laid out in [RATS-Device], and include either [TPM2.0] or 188 [TPM1.2]. 190 * One or more Verifier A's as defined in [attestation-results] 191 'Interaction Model' continuously appraise each of the Attested 192 Devices in a network domain, and these Verifiers return the 193 Attestation Results back to each originating Attested Device. 195 * The Attested Devices are connected via link layer protocols such 196 as [MACSEC] or [IEEE-802.1X]. 198 * Each Attester can pass a Stamped Passport to a Relying Party / 199 Verifier B as defined in [attestation-results] 'Interaction Model' 200 within [RFC3748] over that link layer protocol. 202 * A Trusted Topology such as [I-D.ietf-lsr-flex-algo] exists in an 203 IGP domain for the forwarding of Sensitive Subnet traffic. This 204 Topology will carry traffic across a set of Attested Devices which 205 currently meet at a defined set of Trustworthiness Vectors. 207 * A Relying Party is able to use mechanisms such as 208 [I-D.ietf-lsr-flex-algo]'s affinity to include/exclude links as 209 part of the Trusted Topology based on the appraisal of a Stamped 210 Passport. 212 * Customer designated Sensitive Subnets and their requested 213 Trustworthiness Vectors have been identified and associated with 214 external interfaces to/from Attested Devices at the edge of a 215 network. Traffic to a Sensitive Subnet can be passed into the 216 Trusted Topology by the Attested Device. 218 * Relying Party/Verifier B trusts information signed by Verifier A. 219 Verifier B has also been pre-provisioned with certificates or 220 public keys necessary to confirm that Stamped Passports came from 221 Verifier A. 223 4. End-to-end Solution 225 4.1. Network Topology Assembly 227 To be included in a Trusted Topology, Stamped Passports are shared 228 between Attested Devices (such as routers) as part of link layer 229 authentication. Upon receiving and appraising the Stamped Passport 230 during the link layer authentication phase, the Relying Party 231 Attested Device decides if this link should be added as an active 232 adjacency for a particular Trusted Topology. In Figure 1 below, this 233 might be done by applying an Appraisal Policy for Attestation 234 Results. The policy within each device might specify the evalutation 235 of a 'hardware' claim as defined in [attestation-results], 236 Section 2.3.4. With the appraisal, an Attesting Device be most 237 recently appraised with the 'hardware' Trustworthiness Claim in the 238 'affirming' range. If Attested Device has been appraised outside 239 that range, it would not become part of the Trustworthy Topology. 241 When enough links have been successfully added, the Trusted Topology 242 will support edge-to-edge forwarding as routing protocols flood the 243 adjacency information across the network domain. 245 .------------. .----------. 246 | Attested | | Edge | 247 .----------. | Device 'x' | | Attested | 248 | Attested | | | | Device | 249 | Device | | | | | 250 | | | trust>-----------------====================| | 321 | time(RG) | 322 |<------Attestation Results-(2) | 323 ~ ~ ~ 324 time(VG')? | | 325 ~ ~ ~ 326 |<------nonce---------------------------------(3)time(NS') 327 | | | 328 time(EG')(4)------Stamped Passport---------------------->| 329 | | time(RG',RA')(5) 330 (6) 331 ~ 332 time(RX') 334 Figure 2: Trusted Path Timing 336 To summarize Figure 2 above, Evidence about a specific Attester is 337 generated. Some subset of this evidence will be in the form of PCR 338 quotes which are signed by a TPM that exists as the Attester's 339 Attesting Environment. This Evidence will be delibered to and 340 appraised by Verifier A. Verifier A will then appraise the Attester 341 and give it a Trustworthiness Vector. This Trustworthiness Vector is 342 then signed by Verifier A and be returned as Attestation Results to 343 the Attester. Later, when a request comes in from a Relying Party, 344 the Attester assembles and returns a Stamped Passport. The Stamped 345 Passport contains all the information necessary for Verifier B to 346 appraise the most recent Trustworthiness Vector of the Attester. 347 Based on the Verifier B appraisal, the link will be included or not 348 in a Trusted Topology maintained on the Relying Party. 350 More details on the mechanisms used in the construction, 351 verification, and transmitting of the Stamped Passport are listed 352 below. These numbers match to both the numbered steps of Figure 2 353 and numbered steps described in Section 3 of [attestation-results]: 355 4.2.1. Step 1 357 Evidence about and Attester is generated. A portion of this Evidence 358 will include a PCR quote signed by a TPM private LDevID key that 359 exists within the Attester's TPM based Attesting Environment. The 360 Attester sends a signed TPM Quote which includes PCR measurements to 361 Verifier A at time(EG). 363 There are two alternatives for Verifier A to acquire this signed 364 Evidence: 366 * Subscription to the stream defined in 367 [stream-subscription]. Note: this method is recommended as it 368 will minimize the interval between when a PCR change is made in a 369 TPM, and when the PCR change appraisal is incorporated within a 370 subsequent Stamped Passport. 372 * Periodic polling of RPC or 373 the RPC which are defined 374 in [RATS-YANG]. 376 4.2.2. Step 2 378 Verifier A appraises the Evidence from Step 1. A portion of this 379 appraisal process will follow the appraisal process flow described 380 below. This appraisal process MUST be able to set at least the 381 following set of Trustworthiness Claims from [attestation-results]: 382 'hardware', 'instance-identity', and 'executables'. The 383 establishment of a Trustworthiness Vector uses the following Figure 3 384 logic on the Verifier: 386 Start: TPM Quote Received, log received, or appraisal timer expired 387 for the the Attesting network device. 389 Appraisal 0: set Trustworthiness Vector = Null 391 Appraisal 1: Is there sufficient fresh signed evidence to appraise? 392 (yes) - No Action 393 (no) - Goto End 395 Appraisal 2: Appraise Hardware Integrity PCRs 396 if (hardware NOT "0") - push onto vector 397 if (hardware NOT affirming or warning), go to End 399 Appraisal 3: Appraise Attesting Environment identity 400 if (instance-identity <> "0") - push onto vector 402 Appraisal 4: Appraise executable loaded and filesystem integrity 403 if (executables NOT "0") - push onto vector 404 if (executables NOT affirming or warning), go to End 406 Appraisal 5: Appraise all remaining Trustworthiness Claims 407 Independently and set as appropriate. 409 End 411 Figure 3: Verifier A Appraisal Flow 413 After the appraisal and generation of the Trustworthiness Vector, the 414 following are assembled as the set of Attestation Results from this 415 particular appraisal cycle: 417 (2.1) the Public Attestation Key which was used to validate the TPM 418 Quote of Step 1. This is encoded by , , and . 421 (2.2) the appraised Trustworthiness Vector of the Attester as 422 calculated in Figure 3 424 (2.3) the PCR state information from the TPM Quote of (1) plus the 425 time information associated with the TPM Quote of (1). Specifically 426 if the Attester has a TPM2, then the values of the TPM PCRs are 427 included (i.e., , , and ), 428 as are the timing counters from the TPM (i.e., , , , and ). Likewise if the Attester 430 has a TPM1.2, the TPM PCR values of the and 431 are included. Timing information comes from the Verifier itself via 432 the object. 434 (2.4) a Verifier A signature across (2.1) though (2.3). This 435 signature is encoded by , , and . 438 Immediately subsequent to each Verifier appraisal cycle of an 439 Attester, these Attestation Results MUST be pushed to the Attesting 440 Router. This is done via a daatstore write to the following YANG 441 model on the Attester. A YANG tree showing the relevant YANG objects 442 is below. The YANG model describing each of these objects is 443 described later in the document. Note however that although the YANG 444 model shows the specific objects which are needed, the specific set 445 of objects needs to be encoded in CDDL. This makes the payload going 446 over TLS more efficient. Look for this encoding in a new version of 447 the draft which is pending. 449 module: ietf-trustworthiness-claims 450 +--rw attestation-results! 451 +--rw (tpm-specification-version)? 452 +--:(tpm20-attestation-results-cddl) {taa:tpm20}? 453 | +--rw tpm20-attestation-results-cddl 454 | +--rw trustworthiness-vector 455 | | +--rw hardware? hardware 456 | | +--rw instance-identity? instance-identity 457 | | +--rw executables? executables 458 | | +--rw configuration? configuration 459 | +--rw tpm20-pcr-selection* [tpm20-hash-algo] 460 | | +--rw tpm20-hash-algo identityref 461 | | +--rw pcr-index* tpm:pcr 462 | +--rw TPM2B_DIGEST binary 463 | +--rw clock uint64 464 | +--rw reset-counter uint32 465 | +--rw restart-counter uint32 466 | +--rw safe boolean 467 | +--rw attester-certificate-name 468 | | tpm:certificate-name-ref 469 | +--rw appraisal-timestamp 470 | | yang:date-and-time 471 | +--rw verifier-algorithm-type identityref 472 | +--rw verifier-signature binary 473 | +--rw verifier-certificate-keystore-ref 474 | tpm:certificate-name-ref 475 +--:(tpm12-attestation-results-cddl) {taa:tpm12}? 476 +--rw tpm12-attestation-results-cddl 477 +--rw trustworthiness-vector 478 | +--rw hardware? hardware 479 | +--rw instance-identity? instance-identity 480 | +--rw executables? executables 481 | +--rw configuration? configuration 482 +--rw pcr-index* pcr 483 +--rw tpm12-pcr-value* binary 484 +--rw tpm12-hash-algo identityref 485 +--rw TPM12-quote-timestamp 486 | yang:date-and-time 487 +--rw attester-certificate-name 488 | tpm:certificate-name-ref 489 +--rw appraisal-timestamp 490 | yang:date-and-time 491 +--rw verifier-algorithm-type identityref 492 +--rw verifier-signature binary 493 +--rw verifier-certificate-keystore-ref 494 tpm:certificate-name-ref 496 Figure 4: Attestation Results Tree 498 4.2.3. Step 3 500 At time(NS') some form of time-based freshness (such as a nonce or 501 Epoch Handle [RATS-Interactions]) will be generated in a way which 502 makes it available to the Relying Party. Soon after time(NS'), a 503 Relying Party will make a Link Layer authentication request to an 504 Attester via a either [MACSEC] or [IEEE-802.1X]. This connection 505 request MUST expect the return of [RFC3748] credentials from the 506 Attester. 508 4.2.4. Step 4 510 Upon receipt of the Link Layer request from Step 3, a Stamped 511 Passport is generated and sent to the Relying Party. The Stamped 512 Passport MUST include the following: 514 (4.1) The Attestation Results from Step 2 516 (4.2) New signed, verifiably fresh PCR measurements based on a TPM 517 quote at time(EG') which incorporates the freshness information known 518 by the Relying Party from Step 3. If it is a nonce, the freshness 519 information will have been delivered as part of the link layer 520 connection request in Steps 3. 522 Stamped Passports contain following objects, defined in this document 523 via YANG. A subsequent draft will convert the objects below into 524 CDDL format so that the objects can efficiently be passed over EAP. 526 If an Attester includes a TPM2, these YANG objects are: 528 +---n tpm20-stamped-passport 529 +--ro attestation-results 530 | +--ro trustworthiness-vector 531 | | +--ro hardware? hardware 532 | | +--ro instance-identity? instance-identity 533 | | +--ro executables? executables 534 | | +--ro configuration? configuration 535 | +--ro tpm20-pcr-selection* [tpm20-hash-algo] 536 | | +--ro tpm20-hash-algo identityref 537 | | +--ro pcr-index* tpm:pcr 538 | +--ro TPM2B_DIGEST binary 539 | +--ro clock uint64 540 | +--ro reset-counter uint32 541 | +--ro restart-counter uint32 542 | +--ro safe boolean 543 | +--ro attester-certificate-name 544 | | tpm:certificate-name-ref 545 | +--ro appraisal-timestamp 546 | | yang:date-and-time 547 | +--ro verifier-algorithm-type identityref 548 | +--ro verifier-signature binary 549 | +--ro verifier-certificate-keystore-ref 550 | tpm:certificate-name-ref 551 +--ro tpm20-quote 552 +--ro TPMS_QUOTE_INFO binary 553 +--ro quote-signature binary 555 Figure 5: YANG Tree for a TPM2 Stamped Passport 557 Note that where a TPM2.0 is used, the PCR numbers and hash algorithms 558 quoted in Step 1 MUST match the PCR numbers and hash algorithms 559 quoted in this step. 561 And if the Attester is a TPM1.2, the YANG object are: 563 +---n tpm12-stamped-passport 564 +--ro attestation-results 565 | +--ro trustworthiness-vector 566 | | +--ro hardware? hardware 567 | | +--ro instance-identity? instance-identity 568 | | +--ro executables? executables 569 | | +--ro configuration? configuration 570 | +--ro pcr-index* pcr 571 | +--ro tpm12-pcr-value* binary 572 | +--ro tpm12-hash-algo identityref 573 | +--ro TPM12-quote-timestamp 574 | | yang:date-and-time 575 | +--ro attester-certificate-name 576 | | tpm:certificate-name-ref 577 | +--ro appraisal-timestamp 578 | | yang:date-and-time 579 | +--ro verifier-algorithm-type identityref 580 | +--ro verifier-signature binary 581 | +--ro verifier-certificate-keystore-ref 582 | tpm:certificate-name-ref 583 +--ro tpm12-quote 584 +--ro TPM_QUOTE2? binary 586 Figure 6: YANG Tree for a TPM1.2 Stamped Passport 588 With either of these passport formats, if the TPM quote is verifiably 589 fresh, then the state of the Attester can be appraised by a network 590 peer. 592 Note that with [MACSEC] or [IEEE-802.1X], Step 3 plus Step 4 will 593 repeat periodically independently of any subsequent iteration Steps 1 594 and Step 2. This allows for periodic reauthentication of the link 595 layer in a way not bound to the updating of Verifier A's Attestation 596 Results. 598 4.2.5. Step 5 600 Upon receipt of the Stamped Passport generated in Step 4, the Relying 601 Party appraises this Stamped Passport as per its Appraisal Policy for 602 Attestation Results. The result of this application will determine 603 how the Stamped Passport will impact adjacencies within a Trusted 604 Topology. The decision process is as follows: 606 (5.1) Verify that (4.2) includes the freshness context from Step 3. 608 (5.2) Use a local certificate to validate the signature (4.1). 610 (5.3) Verify that the hash from (4.2) matches (4.1) 611 (5.4) Use the identity of (2.1) to validate the signature of (4.2). 613 (5.5) Failure of any steps (5.1) through (5.4) means the link does 614 not meet minimum validation criteria, therefore appraise the link as 615 having a null Verifier B Trustworthiness Vector. Jump to Step 6. 617 (5.6) Compare the time(EG) TPM state to the time(EG') TPM state 619 * If TPM2.0 621 1. If the , , and 622 are equal between the Attestation Results and the TPM 623 Quote at time(EG') then Relying Party can accept (2.1) as the 624 link's Trustworthiness Vector. Jump to Step 6. 626 2. If the , and are equal 627 between the Attestation Results and the TPM Quote at 628 time(EG'), and the object from time(EG') has not 629 incremented by an unacceptable number of seconds since the 630 Attestation Result, then Relying Party can accept (2.1) as the 631 link's Trustworthiness Vector. Jump to Step 6.) 633 3. Assign the link a null Trustworthiness Vector. 635 * If TPM1.2 637 1. If the 's and 's are equal between 638 the Attestation Results and the TPM Quote at time(EG'), then 639 Relying Party can accept (2.1) as the link's Trustworthiness 640 Vector. Jump to step (6). 642 2. If the time hasn't incremented an unacceptable number of 643 seconds from the Attestation Results and the 644 system clock of the Relying Party, then Relying Party can 645 accept (2.1) as the link's Trustworthiness Vector. Jump to 646 step 6.) 648 3. Assign the link a null Trustworthiness Vector. 650 (5.7) Assemble the Verifier B Trustworthiness Vector 652 1. Copy Verifier A Trustworthiness Vector to Verifier B 653 Trustworthiness Vector 655 2. Prune any Trustworthiness Claims the Relying Party doesn't accept 656 from this Verifier. 658 4.2.6. Step 6 660 After the Trustworthiness Vector has been validated or reset, based 661 on the link's Trustworthiness Vector, the Relying Party adjusts the 662 link affinity of the corresponding ISIS [I-D.ietf-lsr-flex-algo] 663 topology. ISIS will then replicate the link state across the IGP 664 domain. Traffic will then avoid links which do not have a qualifying 665 Trustworthiness Vector. 667 5. YANG Module 669 This YANG module imports modules from [RATS-YANG], [crypto-types] and 670 [RFC6021]. 672 ietf-trustworthiness-claims@2021-11-03.yang 673 module ietf-trustworthiness-claims { 674 yang-version 1.1; 675 namespace 676 "urn:ietf:params:xml:ns:yang:ietf-trustworthiness-claims"; 677 prefix tc; 679 import ietf-yang-types { 680 prefix yang; 681 } 682 import ietf-tcg-algs { 683 prefix taa; 684 reference 685 "draft-ietf-rats-yang-tpm-charra"; 686 } 687 import ietf-tpm-remote-attestation { 688 prefix tpm; 689 reference 690 "draft-ietf-rats-yang-tpm-charra"; 691 } 693 organization "IETF"; 694 contact 695 "WG Web: 696 WG List: 698 Editor: Eric Voit 699 "; 701 description 702 "This module contains conceptual YANG specifications for 703 subscribing to attestation streams being generated from TPM chips. 705 Copyright (c) 2020 IETF Trust and the persons identified as 706 authors of the code. All rights reserved. 708 Redistribution and use in source and binary forms, with or without 709 modification, is permitted pursuant to, and subject to the license 710 terms contained in, the Simplified BSD License set forth in 711 Section 4.c of the IETF Trust's Legal Provisions Relating to IETF 712 Documents (https://trustee.ietf.org/license-info). 714 This version of this YANG module is part of RFC XXXX; see the RFC 715 itself for full legal notices."; 717 revision 2021-11-03 { 718 description 719 "Initial version."; 720 reference 721 "draft-voit-rats-trustworthy-path-routing"; 722 } 724 /* 725 * TYPEDEF 726 */ 728 typedef trustworthiness-claim { 729 type int8; 730 description 731 "A Verifier asserted value designed to enable a common 732 understanding of a Verifier trustworthiness appraisal. The 733 value assignments for this 8 bit signed integer will follow 734 these guidelines: 736 Affirming: The Verifier affirms the Attester support for this 737 aspect of trustworthiness 738 - Values 2 to 31: A standards enumerated reason for affirming. 739 - Values -2 to -32: A non-standard reason for affirming. 741 Warning: The Verifier warns about this aspect of trustworthiness. 742 - Values 32 to 63: A standards enumerated reason for the 743 warning. 744 - Values -33 to -64: A non-standard reason for the warning. 746 Contraindicated: The Verifier asserts the Attester is explicitly 747 untrustworthy in regard to this aspect. 748 - Values 64 to 127: A standards enumerated reason for the 749 contraindication. 750 - Values -65 to -128: A non-standard reason for the 751 contraindication. 753 None: The Verifier makes no assertions about this Trustworthiness 754 Claim. The following values are reserved with the following 755 meanings across all instances of trustworthiness-claim. 756 - Value 0: Note: this should always be always treated 757 equivalently by the Relying Party as no claim being made. 758 I.e., the RP's Appraisal Policy for Attestation Results 759 SHOULD NOT make any distinction between a Trustworthiness 760 Claim with enumeration '0', and no Trustworthiness Claim 761 being provided. 762 - Value 1: The Evidence received contains unexpected elements 763 which the Verifier is unable to parse. An example might be 764 that the wrong type of Evidence has been delivered. 765 - Value -1: An unexpected error occurred during the Verifier's 766 appraisal processing. Note: while no claim is being made, the 767 Relying Party MAY make a distinction between a 768 Trustworthiness Claim with enumeration '-1', and no 769 Trustworthiness Claim being provided."; 770 } 772 typedef hardware { 773 type trustworthiness-claim; 774 description 775 "A Verifier has appraised any Attester hardware and firmware 776 which are able to expose fingerprints of their identity and 777 running code. 779 The following are specific reserved values of hardware and 780 the meanings of these reserved values: 782 0: No assertion 784 1: The Verifer cannot parse unexpected Evidence 786 -1:Verifier malfunction 788 2: An Attester has passed its hardware and/or firmware 789 verifications needed to demonstrate that these are 790 genuine/supported. 792 32:An Attester contains only genuine/supported hardware and/or 793 firmware, but there are known security vulnerabilities. 795 96:Attester hardware and/or firmware is recognized, but its 796 trustworthiness is contraindicated. 798 97:A Verifier does not recognize an Attester's hardware or 799 firmware, but it should be recognized."; 800 } 801 typedef instance-identity { 802 type trustworthiness-claim; 803 description 804 "A Verifier has appraised an Attesting Environment's unique 805 identity based upon private key signed Evidence which can be 806 correlated to a unique instantiated instance of the Attester. 807 (Note: this Trustworthiness Claim should only be generated if 808 the Verifier actually expects to recognize the unique identity 809 of the Attester.) 811 The following are specific reserved values of instance-identity 812 and the meanings of these reserved values: 814 0: No assertion 816 1: The Verifer cannot parse unexpected Evidence 818 -1:Verifier malfunction 820 2: The Attesting Environment is recognized, and the associated 821 instance of the Attester is not known to be compromised. 823 96:The Attesting Environment is recognized, and but its unique 824 private key indicates a device which is not trustworthy. 826 97:The Attesting Environment is not recognized; however the 827 Verifier believes it should be."; 828 } 830 typedef executables { 831 type trustworthiness-claim; 832 description 833 "A Verifier has appraised and evaluated relevant runtime files, 834 scripts, and/or other objects which have been loaded into the 835 Target environment's memory. 837 The following are specific reserved values of executables and 838 the meanings of these reserved values: 840 0: No assertion 842 1: The Verifer cannot parse unexpected Evidence 844 -1:Verifier malfunction 846 2: Only a recognized genuine set of approved executables, 847 scripts, files, and/or objects have been loaded during 848 and after the boot process. 850 3: Only a recognized genuine set of approved executables have 851 been loaded during the boot process. 853 32:Only a recognized genuine set of executables, scripts, files, 854 and/or objects have been loaded. However the Verifier cannot 855 vouch for a subset of these due to known bugs or other known 856 vulnerabilities. 858 33:Runtime memory includes executables, scripts, files, and/or 859 objects which are not recognized. 861 96:Runtime memory includes executables, scripts, files, and/or 862 object which are contraindicated. 864 99:Cryptographic validation of the Evidence has failed."; 865 } 867 typedef configuration { 868 type trustworthiness-claim; 869 description 870 "A Verifier has appraised an Attester's configuration, and is 871 able to make conclusions regarding the exposure of known 872 vulnerabilities. 874 The following are specific reserved values of configuration and 875 the meanings of these reserved values: 877 0: No assertion 879 1: The Verifer cannot parse unexpected Evidence 881 -1:Verifier malfunction 883 2: The configuration is a known and approved config 885 3: The configuration includes or exposes no known vulnerabilities 887 32:The configuration includes or exposes known vulnerabilities 889 64:The configuration is unsupportable as it exposes unacceptable 890 security vulnerabilities."; 891 } 893 /* 894 * GROUPINGS 895 */ 897 grouping trustworthiness-vector { 898 description 899 "Allows the inclusion of a Trustworthiness Vector into 900 other constructs."; 901 container trustworthiness-vector { 902 description 903 "One or more Trustworthiness Claims assigned which expose the 904 Verifiers evaluation of the Evidence associated with the 905 AIK which signed as associated TPM Quote."; 906 leaf hardware { 907 type hardware; 908 description 909 "An 8 bit signed integter encoded per the typedef."; 910 } 911 leaf instance-identity { 912 type instance-identity; 913 description 914 "An 8 bit signed integter encoded per the typedef."; 915 } 916 leaf executables { 917 type executables; 918 description 919 "An 8 bit signed integter encoded per the typedef."; 920 } 921 leaf configuration { 922 type configuration; 923 description 924 "An 8 bit signed integter encoded per the typedef."; 925 } 926 } 927 } 929 grouping verifier-evidence { 930 description 931 "Evidence generated by the Verifier."; 932 leaf appraisal-timestamp { 933 type yang:date-and-time; 934 mandatory true; 935 description 936 "The timestamp of the Verifier's appraisal. This can be used 937 by a Relying Party to determine the freshness of the 938 attestation results."; 939 } 940 leaf verifier-algorithm-type { 941 type identityref { 942 base taa:asymmetric; 943 } 944 mandatory true; 945 description 946 "Platform asymmetric algorithm used in the Verifier signature 947 process."; 948 } 949 leaf verifier-signature { 950 type binary; 951 mandatory true; 952 description 953 "Signature of the Verifier across all the current objects in 954 the attestation-results container except for 'verifier- 955 signature' and 'verifier-certificate-keystore-ref'. 956 This assumes CDDL encoding of the objects in the current 957 order of this YANG model."; 958 } 959 leaf verifier-certificate-keystore-ref { 960 type tpm:certificate-name-ref; 961 mandatory true; 962 description 963 "A reference to a specific certificate to an asymmetric key 964 in the Keystore for the Verifier which can be used to validate 965 the 'verifier-signature'. Note that the 966 'name' reference must be globally unique so that it can be 967 read by the Relying Party in a way which identifies a 968 specific Verifier."; 969 } 970 } 972 grouping tpm20-cddl-attestation-results { 973 description 974 "Elements combined into a CDDL representation for TPM2.0."; 975 uses trustworthiness-vector; 976 list tpm20-pcr-selection { 977 key "tpm20-hash-algo"; 978 description 979 "Specifies the list of PCRs and Hash Algorithms used by the 980 Verifier."; 981 reference 982 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 983 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.9.7"; 984 uses tpm:tpm20-hash-algo; 985 leaf-list pcr-index { 986 type tpm:pcr; 987 description 988 "The numbers of the PCRs associated with the TPM2B_DIGEST."; 989 } 990 } 991 leaf TPM2B_DIGEST { 992 mandatory true; 993 type binary; 994 description 995 "A hash of the latest PCR values (and the hash algorithm used) 996 which have been returned from a Verifier for the selected PCRs 997 identified within TPML_PCR_SELECTION."; 998 reference 999 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 1000 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.12.1"; 1001 } 1002 leaf clock { 1003 mandatory true; 1004 type uint64; 1005 description 1006 "Clock is a monotonically increasing counter that advances 1007 whenever power is applied to a TPM2. The value of Clock is 1008 incremented each millisecond."; 1009 reference 1010 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 1011 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.2"; 1012 } 1013 leaf reset-counter { 1014 mandatory true; 1015 type uint32; 1016 description 1017 "This counter increments on each TPM Reset. The most common 1018 TPM Reset would be due to a hardware power cycle."; 1019 reference 1020 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 1021 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.3"; 1022 } 1023 leaf restart-counter { 1024 mandatory true; 1025 type uint32; 1026 description 1027 "This counter shall increment by one for each TPM Restart or 1028 TPM Resume. The restartCount shall be reset to zero on a TPM 1029 Reset."; 1030 reference 1031 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 1032 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.4"; 1033 } 1034 leaf safe { 1035 mandatory true; 1036 type boolean; 1037 description 1038 "This parameter is set to YES when the value reported in Clock 1039 is guaranteed to be unique for the current Owner. It is set to 1040 NO when the value of Clock may have been reported in a previous 1041 attestation or access."; 1042 reference 1043 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 1044 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.5"; 1045 } 1046 leaf attester-certificate-name { 1047 mandatory true; 1048 description 1049 "The Attester is associated with these results."; 1050 type tpm:certificate-name-ref; 1051 } 1052 uses verifier-evidence; 1053 } 1055 grouping tpm12-cddl-attestation-results { 1056 description 1057 "Elements combined into a CDDL representation for TPM1.2."; 1058 uses trustworthiness-vector; 1059 uses tpm:tpm12-pcr-selection; 1060 leaf-list tpm12-pcr-value { 1061 type binary; 1062 description 1063 "The list of TPM_PCRVALUEs from each PCR selected in sequence 1064 of tpm12-pcr-selection."; 1065 reference 1066 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 1067 TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf 1068 Section 10.9.7"; 1069 } 1070 uses tpm:tpm12-hash-algo { 1071 refine "tpm12-hash-algo" { 1072 mandatory true; 1073 } 1074 } 1075 leaf TPM12-quote-timestamp { 1076 type yang:date-and-time; 1077 mandatory true; 1078 description 1079 "The timestamp for when the indicator of freshness (such as a 1080 nonce) was generated. This is the indicator of freshness 1081 which was used in the generation of the TPM1.2 quote. This 1082 timestamp can be used by a Relying Party to determine the 1083 freshness of the attestation results."; 1084 } 1085 leaf attester-certificate-name { 1086 mandatory true; 1087 description 1088 "The Attester is associated with these results."; 1090 type tpm:certificate-name-ref; 1091 } 1092 uses verifier-evidence; 1093 } 1095 /* 1096 * NOTIFICATIONS 1097 */ 1099 notification tpm20-stamped-passport { 1100 description 1101 "The augmentation of the most recent Attestation Results 1102 delivered from a Verifier with a TPM2.0 Quote."; 1103 container attestation-results { 1104 description 1105 "The latest Verifier delivered Attestation Results."; 1106 uses tpm20-cddl-attestation-results; 1107 } 1108 container tpm20-quote { 1109 description 1110 "The TPM2.0 quote delivered in response to a connectivity 1111 request."; 1112 leaf TPMS_QUOTE_INFO { 1113 type binary; 1114 mandatory true; 1115 description 1116 "A hash of the latest PCR values (and the hash algorithm 1117 used) which have been returned from a Verifier for the 1118 selected PCRs and Hash Algorithms."; 1119 reference 1120 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 1121 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.12.1"; 1122 } 1123 leaf quote-signature { 1124 type binary; 1125 mandatory true; 1126 description 1127 "Quote signature returned by TPM Quote. The signature was 1128 generated using the key associated with the 1129 certificate 'name'."; 1130 reference 1131 "https://www.trustedcomputinggroup.org/wp-content/uploads/ 1132 TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 11.2.1"; 1133 } 1134 } 1135 } 1137 notification tpm12-stamped-passport { 1138 description 1139 "The augmentation of the most recent Attestation Results 1140 delivered from a Verifier with a TPM1.2 Quote."; 1141 container attestation-results { 1142 description 1143 "The latest Verifier delivered Attestation Results."; 1144 uses tpm12-cddl-attestation-results; 1145 } 1146 container tpm12-quote { 1147 description 1148 "The TPM1.2 quote delivered in response to a connectivity 1149 request."; 1150 leaf TPM_QUOTE2 { 1151 type binary; 1152 description 1153 "Result of a TPM1.2 Quote2 operation. This includes PCRs, 1154 signatures, locality, the provided nonce and other data which 1155 can be further parsed to appraise the Attester."; 1156 reference 1157 "TPM1.2 commands rev116 July 2007, Section 16.5"; 1158 } 1159 } 1160 } 1162 /* 1163 * DATA NODES 1164 */ 1166 container attestation-results { 1167 presence 1168 "Indicates that Verifier has appraised the security posture of 1169 the Attester, and returned the results within this container."; 1170 description 1171 "Retains the most recent Attestation Results for this Attester. 1172 It must only be written by a Verfier which is to be trusted by a 1173 Relying Party."; 1175 choice tpm-specification-version { 1176 description 1177 "Identifies the cryptoprocessor API set which drove the 1178 Attestation Results."; 1179 case tpm20-attestation-results-cddl { 1180 if-feature "taa:tpm20"; 1181 description 1182 "Attestation Results which are returned from the 1183 evaluation of Evidence which includes a TPM2 quote."; 1184 container tpm20-attestation-results-cddl { 1185 description 1186 "Attestation Results which are returned from the 1187 evaluation of Evidence which includes a TPM2 quote."; 1188 uses tpm20-cddl-attestation-results; 1189 } 1190 } 1191 case tpm12-attestation-results-cddl { 1192 if-feature "taa:tpm12"; 1193 description 1194 "Attestation Results which are returned from the 1195 evaluation of Evidence which includes a TPM1.2 quote."; 1196 container tpm12-attestation-results-cddl { 1197 description 1198 "Attestation Results which are returned from the 1199 evaluation of Evidence which includes a TPM1.2 quote."; 1200 uses tpm12-cddl-attestation-results; 1201 } 1202 } 1203 } 1204 } 1205 } 1206 1208 6. Security Considerations 1210 Verifiers are limited to the Evidence available for appraisal from a 1211 Router. Although the state of the art is improving, some exploits 1212 may not be visible via Evidence. 1214 Only security measurements which are placed into PCRs are capable of 1215 being exposed via TPM Quote at time(EG'). 1217 Successful attacks on an Verifier have the potential of affecting 1218 traffic on the Trusted Topology. 1220 For Trusted Path Routing, links which are part of the FlexAlgo are 1221 visible across the entire IGP domain. Therefore a compromised device 1222 will know when it is being bypassed. 1224 Access control for the objects in Figure 4 should be tightly 1225 controlled so that it becomes difficult for the Stamped Passport to 1226 become a denial of service vector. 1228 7. References 1230 7.1. Normative References 1232 [attestation-results] 1233 "Attestation Results for Connectivity", 2 December 2021, 1234 . 1236 [crypto-types] 1237 "Common YANG Data Types for Cryptography", 17 December 1238 2021, . 1241 [RATS-Arch] 1242 "Remote Attestation Procedures Architecture", 8 February 1243 2022, . 1246 [RATS-YANG] 1247 "A YANG Data Model for Challenge-Response-based Remote 1248 Attestation Procedures using TPMs", 28 February 2022, 1249 . 1252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1253 Requirement Levels", BCP 14, RFC 2119, 1254 DOI 10.17487/RFC2119, March 1997, 1255 . 1257 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 1258 RFC 6021, DOI 10.17487/RFC6021, October 2010, 1259 . 1261 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1262 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1263 May 2017, . 1265 [TPM1.2] TCG, "TPM 1.2 Main Specification", 2 October 2003, 1266 . 1269 [TPM2.0] TCG, "TPM 2.0 Library Specification", 15 March 2013, 1270 . 1273 7.2. Informative References 1275 [I-D.ietf-lsr-flex-algo] 1276 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1277 A. Gulko, "IGP Flexible Algorithm", Work in Progress, 1278 Internet-Draft, draft-ietf-lsr-flex-algo-18, 25 October 1279 2021, . 1282 [IEEE-802.1X] 1283 Parsons, G., "802.1AE: MAC Security (MACsec)", 1 January 1284 2020, 1285 . 1287 [MACSEC] Seaman, M., "802.1AE: MAC Security (MACsec)", 1 January 1288 2006, . 1290 [RATS-Device] 1291 "Network Device Remote Integrity Verification", n.d., 1292 . 1295 [RATS-Interactions] 1296 "Reference Interaction Models for Remote Attestation 1297 Procedures", 26 January 2022, 1298 . 1301 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1302 Levkowetz, Ed., "Extensible Authentication Protocol 1303 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1304 . 1306 [stream-subscription] 1307 "Attestation Event Stream Subscription", 16 October 2021, 1308 . 1311 Appendix A. Acknowledgements 1313 Peter Psenak, Shwetha Bhandari, Adwaith Gautham, Annu Singh, Sujal 1314 Sheth, Nancy Cam Winget, and Ned Smith. 1316 Appendix B. Change Log 1318 [THIS SECTION TO BE REMOVED BY THE RFC EDITOR.] 1320 v04-v05 1322 * Tweaks to text 1323 * Added text which was morphed from that provided by Meiling 1325 v03-v04 1327 * YANG model updated in concert with draft-voit-rats-attestation- 1328 results as Trustworthiness Claim values are added. 1330 v03-v04 1332 * Moved in concert with draft-voit-rats-attestation-results as 1333 Trustworthiness Claims became 8 bit signed integers. 1335 v02-v03 1337 * Integrated [attestation-results] as prerequisite context. 1339 * Totally rearranged content. But there were not meaningful process 1340 changes. 1342 * Redid YANG model, and highlighted CDDL needs. 1344 v01-v02 1346 * Minor tweaks such as renaming and removal of a few 1347 trustworthiness-claims 1349 v00-v01 1351 * Minor tweaks 1353 v02-v00 of draft-voit-rats-trustworthy-path-routing-00 1355 * file rename was due to an IETF tool submission glitch 1357 * The Attester's AIK is included within the Stamped Passport. This 1358 eliminates the need to provision to AIK certificate on the Relying 1359 Party. 1361 * Removed Centralized variant 1363 * Added timing diagram, and moved content around to match 1365 v01-v02 of draft-voit-rats-trusted-path-routing 1367 * Extracted the attestation stream, and placed into draft-birkholz- 1368 rats-network-device-subscription 1370 * Introduced the Trustworthiness Vector 1371 v00-v01 of draft-voit-rats-trusted-path-routing 1373 * Move all FlexAlgo terminology to allow passport definition to be 1374 more generic. 1376 * Edited Figure 1 so that (4) points to the egress router. 1378 * Added text freshness mechanisms, and articulated configured 1379 subscription support. 1381 * Minor YANG model clarifications. 1383 * Added a few open questions which Frank thinks interesting to work. 1385 Appendix C. Open Questions 1387 (1) When there is no available Trusted Topology? 1389 Do we need functional requirements on how to handle traffic to/from 1390 Sensitive Subnets when no Trusted Topology exists between IGP edges? 1391 The network typically can make this unnecessary. For example it is 1392 possible to construct a local IPSec tunnel to make untrusted devices 1393 appear as Transparently-Transited Devices. This way Secure Subnets 1394 could be tunneled between FlexAlgo nodes where an end-to-end path 1395 doesn't currently exist. However there still is a corner case where 1396 all IGP egress points are not considered sufficiently trustworthy. 1398 (2) Extension of the Stamped Passport? 1400 Format of the reference to the 'verifier-certificate-name' based on 1401 WG desire to include more information in the Stamped Passport. Also 1402 we need to make sure that the keystore referenced names are globally 1403 unique, else we will need to include a node name in the object set. 1405 (3) Encoding of objects in CDDL. A Verifier will want to sign 1406 encoded objects rather than YANG structures. It is most efficient to 1407 encode the Attestation Results once on the Verifier, and push these 1408 down via a YANG model to the Attester. 1410 Authors' Addresses 1412 Eric Voit 1413 Cisco Systems, Inc. 1414 8135 Maple Lawn Blvd 1415 Fulton, Maryland 20759 1416 United States of America 1417 Email: evoit@cisco.com 1418 Chennakesava Reddy Gaddam 1419 Cisco Systems, Inc. 1420 Cessna Business Park, Kadubeesanahalli 1421 Bangalore 560103 1422 Karnataka 1423 India 1424 Email: chgaddam@cisco.com 1426 Guy C. Fedorkow 1427 Juniper Networks 1428 10 Technology Park Drive 1429 Westford, Massachusetts 01886 1430 United States of America 1431 Email: gfedorkow@juniper.net 1433 Henk Birkholz 1434 Fraunhofer SIT 1435 Rheinstrasse 75 1436 64295 Darmstadt 1437 Germany 1438 Email: henk.birkholz@sit.fraunhofer.de 1440 Meiling Chen 1441 China Mobile 1442 Email: chenmeiling@chinamobile.com