idnits 2.17.00 (12 Aug 2021) /tmp/idnits12647/draft-yang-i2nsf-remote-attestation-interface-dm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 416 has weird spacing: '...r-index pcr...' == Line 441 has weird spacing: '...-number uin...' == Line 463 has weird spacing: '...-number uin...' == Line 477 has weird spacing: '...r-index pcr...' == Line 495 has weird spacing: '...te-name cer...' == (10 more instances...) -- The document date (March 2022) is 60 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-15 ** Downref: Normative reference to an Informational draft: draft-ietf-rats-architecture (ref. 'I-D.ietf-rats-architecture') == Outdated reference: A later version (-14) exists of draft-ietf-rats-tpm-based-network-device-attest-13 ** Downref: Normative reference to an Informational draft: draft-ietf-rats-tpm-based-network-device-attest (ref. 'I-D.ietf-rats-tpm-based-network-device-attest') == Outdated reference: A later version (-19) exists of draft-ietf-rats-yang-tpm-charra-16 ** Downref: Normative reference to an Informational RFC: RFC 8329 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group P. Yang 3 Internet-Draft M. Chen 4 Intended status: Standards Track L. Su 5 Expires: 3 September 2022 China Mobile 6 D. Lopiz 7 Telefonica 8 J. Jeong 9 Sungkyunkwan University 10 L. Dunbar 11 Futurewei 12 March 2022 14 I2NSF Remote Attestation Interface YANG Data Model 15 draft-yang-i2nsf-remote-attestation-interface-dm-00 17 Abstract 19 This document describes the architecture and interfaces of remote 20 attestation in I2NSF. The architectures defines remote attestation 21 components which must comply with the original architectures of I2NSF 22 and RATs. The interfaces includes remote attestation interface of 23 I2NSF and reference value interface of I2NSF. 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 2 September 2022. 42 Copyright Notice 44 Copyright (c) 2022 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 (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 3. Scope and Motivation . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Information Model . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. Architecture of I2NSF Remote Attestation . . . . . . . . 4 67 4.2. Root of Trust . . . . . . . . . . . . . . . . . . . . . . 6 68 4.3. Verifier/Relying Party . . . . . . . . . . . . . . . . . 7 69 4.4. Reference Value Provider . . . . . . . . . . . . . . . . 7 70 4.5. Endorser . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5. Data Model of I2NSF Remote Attestation . . . . . . . . . . . 7 72 5.1. I2NSF Remote Attestation Interface . . . . . . . . . . . 8 73 5.1.1. Yang Tree Diagram of I2NSF Remote Attestation 74 Interface . . . . . . . . . . . . . . . . . . . . . . 9 75 5.1.2. Yang Data Model of I2NSF Remote Attestation 76 Interface . . . . . . . . . . . . . . . . . . . . . . 15 77 5.2. I2NSF Remote Attestation Reference Value Interface . . . 22 78 5.2.1. Yang Tree Diagram of I2NSF Remote Attestation Reference 79 Value Interface . . . . . . . . . . . . . . . . . . . 22 80 5.2.2. Yang Data Model of I2NSF Remote Attestation Reference 81 Value Interface . . . . . . . . . . . . . . . . . . . 23 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 85 8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 29 86 8.2. Informative Reference . . . . . . . . . . . . . . . . . . 31 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 89 1. Introduction 91 NSF system is always used in remote scenarios, in which it is hard to 92 guarantee if the deployment environment is secure and the NSF is 93 properly deployed. If the deploy environment or the NSF is 94 compromised, the behavior and the feedback of NSF cannot be trusted. 96 Remote attestation procedure [I-D.ietf-rats-architecture] provides an 97 efficient mechanism that a relying party like NSF security controller 98 could appraise if the NSF and the basic platform are trusted. The 99 general remote attestation procedure has been defined by RATs group, 100 however specific interfaces and implementation still need to be 101 determined in I2NSF. This draft aims to create a unified remote 102 attestation architecture of I2NSF to enable remote attestation and 103 promote the security of NSF. 105 This document will follow the definition of I2NSF [RFC8329] and and 106 will also keep align with RATs architecture. 108 2. Terminology 110 2.1. Terms 112 RATs: Remote Attestation Procedure 114 RoT: Root of Trust 116 TPM: Trusted platform module 118 TEE: Trust Execution Environment 120 RVP: Reference Value Provider 122 IRAI: I2NSF Remote Attestation Interface 124 IRARVI: I2NSF Remote Attestation Reference Value Interface 126 2.2. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 3. Scope and Motivation 134 3.1. Scope 136 The scope of this document mainly focuses on the architecture and 137 expanded interfaces of remote attestation in I2NSF. The details of 138 how to implement measurement or how to make remote attestation 139 evidence is out of scope. 141 3.2. Motivation 143 The architecture of I2NSF aims to provide network security functions 144 to network users. Usually the NSFs are in remote environment and the 145 platform to deploy these NSFs may not be trusted. As a consequence 146 this will bring several potential threats to the NSF, some examples 147 are shown in the follow . The first threat is malfunction of NSF. 148 The inappropriate deployment of NSF or the defective platform in 149 where runs NSF will affect the behaviour of NSF directly. The second 150 threat is the leak of digital asset like policy rules and security 151 intelligence, which is provided by the security controller. If the 152 remote environment is malicious, it will be hard to prevent the 153 leakage. Consider a secuiry company provides NSF in where contains 154 lots of policy rules such as DDoS prevention, traffic filter, AI 155 module, etc. If the platform who carrys the NSF is malicious, it 156 could steal this digital asset and provide to other rivals or 157 attackers. The third threat is the potential spoofing attack to the 158 NSF architecture. Adversary could use the compromised NSF to 159 feedback spoofing information or other attacking information to 160 attack or penetrate the NSF architecture. The attackers in platfom 161 could also disturb the action of NSF, and feedback the fake 162 notification or event to security controller. 164 The solution of these threats is also straight, which is using remote 165 attestation to make sure the remote platform is trusted and the NSF 166 is well deployed. While it is true that any environment is 167 vulnerable to malicious activity with full physical access (and this 168 is obviously beyond the scope of this document), the application of 169 attestation mechanisms raises the degree of physical control 170 necessary to perform an untraceable malicious modification of the 171 environment. 173 When designing remote attestation in I2NSF, three aspects need to be 174 considered. First, determine the remote attestation architecture of 175 I2NSF. Second, refer to the appropriate specifications defined in 176 RATs to create I2NSF remote attestation interfaces. Third, cover the 177 heterogeneity architecture of specific trust architecture like TPM 178 and TEE. 180 4. Information Model 182 4.1. Architecture of I2NSF Remote Attestation 183 +------------+ +------------+ 184 | | | | 185 | NSF User | +---------+ Endorser | 186 | | | | | 187 +---+--------+ | +------------+ 188 | | 189 | +---------+ 190 | | 191 +---+------+---+ +--------------+ 192 | | | | 193 | Security +--------------+ Developer's | 194 | Controller | | Mgmt System | 195 +-+----------+-+ +-+----------+-+ 196 | Verifier/| | Reference| 197 | Relying | | Value | 198 | Party | | Provider/| 199 +----+-----+ | Interface| 200 | +----------+ 201 +---------------------+ 202 | | 203 +------+-------+ +------+-------+ 204 | | | | 205 | NSF1 + | NSFn | 206 | | | | 207 +--+--------+--+ +--+--------+--+ 208 | RoT | | RoT | 209 +--------+ +--------+ 211 Figure 1: Architecture of Remote Attestation of I2NSF 213 As shown in figure one is the remote attestation architecture in 214 I2NSF. In this architecture, several new components are introduced 215 to NSF. The first component is RoT which is deployed in the basic 216 platform of NSF as a hardware. The second component is Verifier/ 217 Relying Party, which is deployed as part of Security Controller. 218 This component is in charge of verifying if the attestation evidence 219 is complied with the reference value. The third component is the 220 Reference Value Provider/Interface, which will bring the reference 221 value of NSF image and deployment environment to Security Controller. 222 In some conditions, the RVP could be some other venders like a 223 blockchain, a third party security provider. So the RVP component 224 may be an interface that receive RVP form the third party. Right now 225 this interface haven't beed defined by RATs or other group. The 226 fourth component is Endorser, which will provie the endorsement of 227 RoT. And the verifier could use Endorser to verify the endorsement 228 information of RoT. 230 Figure 2 is the granularity of remote attestation in I2NSF. One 231 platform could deploy multiple NSFs. In physical environment, NSFs 232 could exist as applications. In virtualization environment, NSFs 233 could exist as VMs. The remote attestation procedure in I2NSF could 234 challenge RoT, Platform and NSFs separately. 236 +------+ +------+ +------+ 237 | NSF1 | | NSF2 | | NSFn | 238 +--+---+ +--+---+ +--+---+ 239 | | | 240 +--+----------+----------+----+ 241 | Platform | 242 +-------------+---------------+ 243 | 244 +--+--+ 245 | RoT | 246 +-----+ 248 Figure 2: granularity of remote attestation in I2NSF 250 4.2. Root of Trust 252 Root of Trust is a hardware-based component that could provide 253 endorsement information and relevant functions that cannot be stolen, 254 tampered, or repudiated. RoT MUST be deployed in the basic hardware 255 platform of NSF. Technologies like [TCGRoT] and [TEE] could act as 256 RoT. 258 The architecture of specific RoT is out of scope of this document. 259 But in order to elaborate RoT more clearly, the following segment 260 uses TPM [tpm12][tpm20] as an example to explain how RoT works. TPM 261 keeps an EK(Endorsement Key) to identify its identity. EK is an 262 asymmetric root key pair, which will never expose its secret key to 263 public. TPM also derives certain AIKs(Attestation Identity Key) from 264 EK to avoid the exposure of TPM's real identity(EK) during remote 265 attestation. In the booting period, the TPM will record the Hash of 266 measurement of bootloader, OS kernel and applications to a series of 267 PCRs (Platform Configuration Registers), which cannot be tampered. 268 If a remote attestation procedure is initiated, the PCR value will be 269 signed by AIK and send to the verifier for appraising. The specific 270 procedures are based 271 on[I-D.ietf-rats-tpm-based-network-device-attest], which illustrates 272 how integrity verification works inside a network device. 274 4.3. Verifier/Relying Party 276 The Verifier/Relying Party is deployed in Security Controller. In 277 the original architecture of RATs, Verifier and Relying Party could 278 be different components. Verifier is in charge of verifying the 279 remote attestation evidence from attester. The Relying Party is in 280 charge of appraising the attestation result from Verifier. This 281 indicates that the Relying Party does not have to know the detail of 282 remote attestation evidence and could only focus on the final 283 attestation result and make policies. While in NSF, both the role of 284 Verifier and Relying Party will be included in Security Controller to 285 reduce the redundancy of system. 287 4.4. Reference Value Provider 289 The Developer's Mgmt System is in charge of providing reference value 290 of NSF and the deployment platform. The reference value will be 291 conveyed to Security Controller as the benchmark when verifying 292 remote attestation evidence from attester. When the reference value 293 needs to be collected by third party, the Reference Value Interface 294 or other out-of-band methods in Developer's Mgmt System will be used. 296 4.5. Endorser 298 The Endorser is in charge of providing endorsement to RoT. For 299 example, both EK and AIK in TPM are endorsed by Endorser. The 300 communication between RoT and Endorser is based on specific RoT 301 hardware, and usually has been setup during manufactureing. The 302 Security Controller also needs to communicate with Endorser to get 303 the endorsement of RoT before appraising attestation evidence. 305 5. Data Model of I2NSF Remote Attestation 307 The object of I2NSF remote attestation could be NSF, Platform and 308 RoT. In order to decouple the remote attestation result to 309 granularities, the following table shows the mapping between differnt 310 components. In the TPM based remote attestation, the PCRs are 311 arranged by specific purpose. PCR 0-10 are responsible for the 312 platform related remote attestation. PCR 11-32 are responsible for 313 the NSF remote attestation. If the platform is a virtual machine 314 architecture, PCR 11-32 will be responsible for each virtual 315 machines. And if the platform is a physical machines architecture, 316 PCR 11-32 will be responsible for each NSF functions. The EAT-based 317 row uses Token to realize remote attestation. EAT SYS Token and EAT 318 NSF TOKEN are responsible for platform and NSF respectively. 320 +--------+-------------+------------+ 321 | | TPM-based | EAT-based | 322 +------- +-------------+------------+ 323 | RoT | Device Name | Device ID | 324 | | TPM Name | | 325 +--------+-------------+------------+ 326 | | Boot event | | 327 | | log | EAT SYS | 328 |Platform|-------------| Token | 329 | | IMA-List | | 330 | | Sytem File | | 331 | | PCR 1-10 | | 332 +--------+-------------+------------+ 333 | | IMA-list | EAT NSF | 334 | NSF | NSF File | Token | 335 | | PCR 11-32 | | 336 +--------+-------------+------------+ 338 Figure 3: the mapping between different RoTs 340 Based on the remote attestation architecture, the relevant interfaces 341 are IRAI (I2NSF Remote Attestation Interface) and IRARVI (I2NSF 342 Remote Attestation Registration Interface). The following document 343 will depicit the Yang tree diagram and Yang data model of these two 344 interfaces. 346 5.1. I2NSF Remote Attestation Interface 348 IRAI focuses on the remote attestation information between NSF and 349 security controller. This interface will fully comply with existing 350 NSF Monitoring Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model] . 351 IRAI interface defined notification and RPC for RoT, platform and 352 NSFs. Security Controller could attest the NSF in different 353 granularities. 355 At present, the RoT type now have two categories, one is TPM-based 356 and the other is TEE-based like TrustZone. And the TPM-based RoT is 357 split into TPM12 and TPM20 versions. It can be expected that trusted 358 computing architectures like Intel SGX [SGX] or other architectures 359 may also be involved in the near future. When design this interface 360 with TPM-based RoT, this document refers to the existing 361 document[I-D.ietf-rats-yang-tpm-charra] as much as possible to avoid 362 unnecessary alignment work. And about the TEE-based RoT, this 363 document refers to the EAT document[I-D.ietf-rats-eat] and uses 364 binary format to express JWT[RFC7519]or CWT [RFC8392]. 366 5.1.1. Yang Tree Diagram of I2NSF Remote Attestation Interface 368 The Yang tree of i2nsf remote attestation interface is shown below. 370 module: ietf-i2nsf-remote-attestation 371 +--rw nsf-pcr-set {tpm:tpms}? 372 | +--rw nsf-name? nsf-name 373 | +--rw pcr-index? tpm:pcr 374 +--rw eat-set {TEE}? 375 +--rw algorithm? enumeration 376 +--rw cwt-uwt-choose? int32 378 rpcs: 379 +---x nsf-challenge-response 380 | +---w input 381 | | +---w nsf-name? nsf-name 382 | | +---w token? binary 383 | | +---w nonce? uint32 384 | +--ro output 385 | +--ro (RoT-type)? 386 | +--:(TPM12) {TPM12}? 387 | | +--ro tpm12-ra 388 | | +--ro event-number? uint64 389 | | +--ro ima-template? string 390 | | +--ro filename-hint? string 391 | | +--ro filedata-hash? binary 392 | | +--ro filedata-hash-algorithm? string 393 | | +--ro template-hash-algorithm? string 394 | | +--ro template-hash? binary 395 | | +--ro pcr-index? pcr 396 | | +--ro signature? binary 397 | | +--ro up-time? uint32 398 | | +--ro TPM_QUOTE2? binary 399 | +--:(TPM20) {TPM20}? 400 | | +--ro tpm20-ra 401 | | +--ro event-number? uint64 402 | | +--ro ima-template? string 403 | | +--ro filename-hint? string 404 | | +--ro filedata-hash? binary 405 | | +--ro filedata-hash-algorithm? string 406 | | +--ro template-hash-algorithm? string 407 | | +--ro template-hash? binary 408 | | +--ro pcr-index? pcr 409 | | +--ro signature? binary 410 | | +--ro TPMS_QUOTE_INFO binary 411 | | +--ro quote-signature? binary 412 | | +--ro up-time? uint32 413 | | +--ro unsigned-pcr-values* [] 414 | | +--ro tpm20-hash-algo? identityref 415 | | +--ro pcr-values* [pcr-index] 416 | | +--ro pcr-index pcr 417 | | +--ro pcr-value? binary 418 | +--:(TEE) 419 | +--ro header-NSF? binary 420 | +--ro payload-NSF? binary 421 | +--ro signature-NSF? binary 422 +---x platform-challenge-response 423 | +---w input 424 | | +---w token? binary 425 | | +---w nsf-name? nsf-name 426 | | +---w nonce? int32 427 | +--ro output 428 | +--ro (RoT-type)? 429 | +--:(TPM12) {TPM12}? 430 | | +--ro tpm12-pra 431 | | +--ro event-number? uint64 432 | | +--ro ima-template? string 433 | | +--ro filename-hint? string 434 | | +--ro filedata-hash? binary 435 | | +--ro filedata-hash-algorithm? string 436 | | +--ro template-hash-algorithm? string 437 | | +--ro template-hash? binary 438 | | +--ro pcr-index? pcr 439 | | +--ro signature? binary 440 | | +--ro bios-event-entry* [event-number] 441 | | | +--ro event-number uint32 442 | | | +--ro event-type? uint32 443 | | | +--ro pcr-index? pcr 444 | | | +--ro digest-list* [hash-alog] 445 | | | | +--ro hash-algo? identityref 446 | | | | +--ro digest* binary 447 | | | +--ro event-size? uint32 448 | | | +--ro event-data* uint8 449 | | +--ro up-time? uint32 450 | | +--ro TPM_QUOTE2? binary 451 | +--:(TPM20) {TPM20}? 452 | | +--ro tpm2-pra 453 | | +--ro event-number? uint64 454 | | +--ro ima-template? string 455 | | +--ro filename-hint? string 456 | | +--ro filedata-hash? binary 457 | | +--ro filedata-hash-algorithm? string 458 | | +--ro template-hash-algorithm? string 459 | | +--ro template-hash? binary 460 | | +--ro pcr-index? pcr 461 | | +--ro signature? binary 462 | | +--ro bios-event-entry* [event-number] 463 | | | +--ro event-number uint32 464 | | | +--ro event-type? uint32 465 | | | +--ro pcr-index? pcr 466 | | | +--ro digest-list* [hash-alog] 467 | | | | +--ro hash-algo? identityref 468 | | | | +--ro digest* binary 469 | | | +--ro event-size? uint32 470 | | | +--ro event-data* uint8 471 | | +--ro TPMS_QUOTE_INFO binary 472 | | +--ro quote-signature? binary 473 | | +--ro up-time? uint32 474 | | +--ro unsigned-pcr-values* [] 475 | | +--ro tpm20-hash-algo? identityref 476 | | +--ro pcr-values* [pcr-index] 477 | | +--ro pcr-index pcr 478 | | +--ro pcr-value? binary 479 | +--:(TEE) {TEE}? 480 | +--ro header-platform? binary 481 | +--ro payload-platform? binary 482 | +--ro signature-platform? binary 483 +---x RoT-challenge-response 484 +---w input 485 | +---w token? binary 486 | +---w nsf-name? nsf-name 487 | +---w nonce? int32 488 +--ro output 489 +--ro (RoT-type)? 490 +--:(TPM12) 491 | +--ro rot-tpm12 {TPM12}? 492 | +--ro rot-name? -> 493 /tpm:rats-support-structures/tpms/tpm/ 494 certificates/certificate/name 495 | +--ro certificate-name certificate-name-ref 496 | +--ro tpm12-hash-algo? identityref 497 +--:(TPM20) {TPM20}? 498 | +--ro rot-tpm20 499 | +--ro rot-name? -> 500 /tpm:rats-support-structures/tpms/tpm/ 501 certificates/certificate/name 502 | +--ro certificate-name certificate-name-ref 503 | +--ro tpm20-hash-algo? identityref 504 +--:(TEE-general) {TEE}? 505 +--ro TEE-UEID? binary 507 notifications: 508 +---n NSF-remote-attestation-event 509 | +--ro event-description? string 510 | +--ro acquisition-method? identityref 511 | +--ro emission-type? identityref 512 | +--ro dampening-type? identityref 513 | +--ro user string 514 | +--ro group* string 515 | +--ro ip-address inet:ip-address 516 | +--ro authentication? identityref 517 | +--ro message? string 518 | +--ro vendor-name? string 519 | +--ro nsf-name? union 520 | +--ro severity? severity 521 | +--ro (RoT-type)? 522 | +--:(TPM12) {TPM12}? 523 | | +--ro tpm12-ra 524 | | +--ro event-number? uint64 525 | | +--ro ima-template? string 526 | | +--ro filename-hint? string 527 | | +--ro filedata-hash? binary 528 | | +--ro filedata-hash-algorithm? string 529 | | +--ro template-hash-algorithm? string 530 | | +--ro template-hash? binary 531 | | +--ro pcr-index? pcr 532 | | +--ro signature? binary 533 | | +--ro up-time? uint32 534 | | +--ro TPM_QUOTE2? binary 535 | +--:(TPM20) {TPM20}? 536 | | +--ro tpm20-ra 537 | | +--ro event-number? uint64 538 | | +--ro ima-template? string 539 | | +--ro filename-hint? string 540 | | +--ro filedata-hash? binary 541 | | +--ro filedata-hash-algorithm? string 542 | | +--ro template-hash-algorithm? string 543 | | +--ro template-hash? binary 544 | | +--ro pcr-index? pcr 545 | | +--ro signature? binary 546 | | +--ro TPMS_QUOTE_INFO binary 547 | | +--ro quote-signature? binary 548 | | +--ro up-time? uint32 549 | | +--ro unsigned-pcr-values* [] 550 | | +--ro tpm20-hash-algo? identityref 551 | | +--ro pcr-values* [pcr-index] 552 | | +--ro pcr-index pcr 553 | | +--ro pcr-value? binary 554 | +--:(TEE) 555 | +--ro header-NSF? binary 556 | +--ro payload-NSF? binary 557 | +--ro signature-NSF? binary 558 +---n Platform-remote-attestation-event 559 | +--ro event-description? string 560 | +--ro acquisition-method? identityref 561 | +--ro emission-type? identityref 562 | +--ro dampening-type? identityref 563 | +--ro user string 564 | +--ro group* string 565 | +--ro ip-address inet:ip-address 566 | +--ro authentication? identityref 567 | +--ro message? string 568 | +--ro vendor-name? string 569 | +--ro nsf-name? union 570 | +--ro severity? severity 571 | +--ro (RoT-type)? 572 | +--:(TPM12) {TPM12}? 573 | | +--ro tpm12-pra 574 | | +--ro event-number? uint64 575 | | +--ro ima-template? string 576 | | +--ro filename-hint? string 577 | | +--ro filedata-hash? binary 578 | | +--ro filedata-hash-algorithm? string 579 | | +--ro template-hash-algorithm? string 580 | | +--ro template-hash? binary 581 | | +--ro pcr-index? pcr 582 | | +--ro signature? binary 583 | | +--ro bios-event-entry* [event-number] 584 | | | +--ro event-number uint32 585 | | | +--ro event-type? uint32 586 | | | +--ro pcr-index? pcr 587 | | | +--ro digest-list* [hash-alog] 588 | | | | +--ro hash-algo? identityref 589 | | | | +--ro digest* binary 590 | | | +--ro event-size? uint32 591 | | | +--ro event-data* uint8 592 | | +--ro up-time? uint32 593 | | +--ro TPM_QUOTE2? binary 594 | +--:(TPM20) {TPM20}? 595 | | +--ro tpm2-pra 596 | | +--ro event-number? uint64 597 | | +--ro ima-template? string 598 | | +--ro filename-hint? string 599 | | +--ro filedata-hash? binary 600 | | +--ro filedata-hash-algorithm? string 601 | | +--ro template-hash-algorithm? string 602 | | +--ro template-hash? binary 603 | | +--ro pcr-index? pcr 604 | | +--ro signature? binary 605 | | +--ro bios-event-entry* [event-number] 606 | | | +--ro event-number uint32 607 | | | +--ro event-type? uint32 608 | | | +--ro pcr-index? pcr 609 | | | +--ro digest-list* [hash-alog] 610 | | | | +--ro hash-algo? identityref 611 | | | | +--ro digest* binary 612 | | | +--ro event-size? uint32 613 | | | +--ro event-data* uint8 614 | | +--ro TPMS_QUOTE_INFO binary 615 | | +--ro quote-signature? binary 616 | | +--ro up-time? uint32 617 | | +--ro unsigned-pcr-values* [] 618 | | +--ro tpm20-hash-algo? identityref 619 | | +--ro pcr-values* [pcr-index] 620 | | +--ro pcr-index pcr 621 | | +--ro pcr-value? binary 622 | +--:(TEE) {TEE}? 623 | +--ro header-platform? binary 624 | +--ro payload-platform? binary 625 | +--ro signature-platform? binary 626 +---n RoT-remote-attestation-event 627 +--ro event-description? string 628 +--ro acquisition-method? identityref 629 +--ro emission-type? identityref 630 +--ro dampening-type? identityref 631 +--ro user string 632 +--ro group* string 633 +--ro ip-address inet:ip-address 634 +--ro authentication? identityref 635 +--ro message? string 636 +--ro vendor-name? string 637 +--ro nsf-name? union 638 +--ro severity? severity 639 +--ro (RoT-type)? 640 +--:(TPM12) 641 | +--ro rot-tpm12 {TPM12}? 642 | +--ro rot-name? -> 643 /tpm:rats-support-structures/tpms/tpm/ 644 certificates/certificate/name 645 | +--ro certificate-name certificate-name-ref 646 | +--ro tpm12-hash-algo? identityref 647 +--:(TPM20) {TPM20}? 648 | +--ro rot-tpm20 649 | +--ro rot-name? -> 650 /tpm:rats-support-structures/tpms/tpm/ 651 certificates/certificate/name 652 | +--ro certificate-name certificate-name-ref 653 | +--ro tpm20-hash-algo? identityref 654 +--:(TEE-general) {TEE}? 655 +--ro TEE-UEID? binary 657 5.1.2. Yang Data Model of I2NSF Remote Attestation Interface 659 The Yang Model of I2NSF Remote Attestation Interface is shown below. 661 module ietf-i2nsf-remote-attestation { 662 yang-version 1.1; 663 namespace 664 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-remote-attestation"; 665 prefix 666 nsfra; 667 import ietf-i2nsf-nsf-monitoring{ 668 prefix nsfmi; 669 reference 670 "Section 9 of draft-ietf-i2nsf-nsf-facing-interface"; 671 } 672 import ietf-tpm-remote-attestation{ 673 prefix tpm; 674 } 675 import ietf-inet-types{ 676 prefix inet; 677 reference 678 "section 4 of RFC 6991"; 679 } 680 organization 681 "IETF I2NSF (Interface to Network Security Functions) 682 Working Group"; 683 contact 684 "WG Web: 685 WG List: 687 Editor: Penglin Yang 688 "; 690 description 691 "This module is a YANG module for I2NSF Remote 692 Attestation Interface."; 693 feature TPM12{ 694 description 695 "This device is for TPM12 remote attestation"; 696 } 697 feature TPM20{ 698 description 699 "This device is for TPM20 remote attestation"; 700 } 701 feature TEE{ 702 description 703 "This device is for general TEE remote attestation"; 704 } 705 typedef nsf-name{ 706 type union{ 707 type string; 708 type inet:ip-address-no-zone; 709 } 710 description 711 "nsf-name for remote attestation"; 712 } 713 identity RoT-type{ 714 description 715 "RoT have different types, like TPM, TEE, etc."; 716 } 717 identity TPM12{ 718 base RoT-type; 719 description 720 "RoT type is TPM1.2"; 721 } 722 identity TPM20{ 723 base RoT-type; 724 description 725 "RoT type is TPM2.0"; 726 } 727 identity TEE{ 728 base RoT-type; 729 description 730 "RoT type is TEE"; 731 } 732 identity cwt{ 733 description 734 "cbor web token for remote attestation"; 735 } 736 identity jwt{ 737 description 738 "json web token for remote attestation"; 739 } 740 identity nsf-name{ 741 description 742 "nsf name"; 743 } 745 grouping nsf-remote-attestation{ 746 description 747 "This grouping is for certain nsf's remote attestation result."; 748 choice RoT-type{ 749 case TPM12{ 750 if-feature "TPM12"; 751 description 752 "The filename hint of IMA log item is NSF name. The range 753 of PCR index is defined as 11~32."; 754 container tpm12-ra{ 755 uses tpm:ima-event; 756 uses tpm:tpm12-attestation; 757 } 758 } 759 case TPM20{ 760 if-feature "TPM20"; 761 container tpm20-ra{ 762 uses tpm:ima-event; 763 uses tpm:tpm20-attestation; 764 } 765 } 766 case TEE{ 767 description 768 "EAT for NSF remote attestation"; 769 leaf header-NSF{ 770 type binary; 771 } 772 leaf payload-NSF{ 773 type binary; 774 } 775 leaf signature-NSF{ 776 type binary; 777 } 778 } 779 } 780 } 781 grouping platform-remote-attestation{ 782 description 783 "this item is for platform remote attestation"; 784 choice RoT-type{ 785 case TPM12{ 786 if-feature "TPM12"; 787 container tpm12-pra{ 788 uses tpm:ima-event; 789 uses tpm:bios-event-log; 790 uses tpm:tpm12-attestation; 791 } 792 } 793 case TPM20{ 794 if-feature "TPM20"; 795 container tpm20-pra{ 796 uses tpm:ima-event; 797 uses tpm:bios-event-log; 798 uses tpm:tpm20-attestation; 799 } 800 } 801 case TEE{ 802 if-feature "TEE"; 803 description 804 "EAT for Platform Remote Attestation"; 805 leaf header-platform{ 806 type binary; 807 } 808 leaf payload-platform{ 809 type binary; 810 } 811 leaf signature-platform{ 812 type binary; 813 } 814 } 815 } 816 } 817 grouping RoT-remote-attestation{ 818 description 819 "this item is for the identity of platform and RoT"; 820 choice RoT-type{ 821 case TPM12{ 822 container rot-tpm12{ 823 if-feature "TPM12"; 824 description 825 "the identity of TPM could be represented by 826 TPM-name and certificate"; 827 leaf rot-name{ 828 type leafref { 829 path "/tpm:rats-support-structures/tpm:tpms/tpm:tpm" 830 + "/tpm:certificates/tpm:certificate/tpm:name"; 831 } 832 } 833 uses tpm:certificate-name-ref; 834 uses tpm:tpm12-hash-algo; 835 } 836 } 837 case TPM20{ 838 if-feature "TPM20"; 839 description 840 "the identity of TPM could be represented 841 by TPM-name and certificate"; 842 container rot-tpm20{ 843 leaf rot-name{ 844 type leafref { 845 path "/tpm:rats-support-structures/tpm:tpms/tpm:tpm" 846 + "/tpm:certificates/tpm:certificate/tpm:name"; 847 } 848 } 849 uses tpm:certificate-name-ref; 850 uses tpm:tpm20-hash-algo; 851 } 852 } 853 case TEE-general{ 854 if-feature "TEE"; 855 leaf TEE-UEID{ 856 type binary; 857 } 858 } 859 } 860 } 861 notification NSF-remote-attestation-event{ 862 description 863 "Event that triggered the NSF remote attestation 864 will use this notification"; 865 leaf event-description{ 866 description 867 "describe the reason why notification was triggered"; 868 type string; 869 } 870 uses nsfmi:characteristics; 871 uses nsfmi:i2nsf-system-event-type-content; 872 uses nsfmi:common-monitoring-data; 873 uses nsf-remote-attestation; 874 } 875 notification Platform-remote-attestation-event{ 876 description 877 "Event that triggered the platform remote attestation 878 will use this notification "; 879 leaf event-description{ 880 description 881 "describe why this notification was triggered"; 882 type string; 883 } 884 uses nsfmi:characteristics; 885 uses nsfmi:i2nsf-system-event-type-content; 886 uses nsfmi:common-monitoring-data; 887 uses platform-remote-attestation; 888 } 889 notification RoT-remote-attestation-event{ 890 description 891 "Event that triggered the rot remote attestation 892 will use this notification"; 893 leaf event-description{ 894 description 895 "describe why this notification was triggered"; 896 type string; 897 } 898 uses nsfmi:characteristics; 899 uses nsfmi:i2nsf-system-event-type-content; 900 uses nsfmi:common-monitoring-data; 901 uses RoT-remote-attestation; 902 } 904 //token in RPC is for specify the identity of RPC caller. // 905 grouping token{ 906 description 907 "this token is for identify rpc caller. How to define 908 this token, oauth, JWT, or other? Or not necessary, TBD"; 909 leaf token{ 910 type binary; 911 } 912 } 913 rpc nsf-challenge-response{ 914 description 915 "this is the unified rpc for nsf remote attestation"; 916 input{ 917 leaf nsf-name{ 918 type nsf-name; 919 } 920 uses token; 921 leaf nonce{ 922 type uint32; 923 } 924 } 925 output{ 926 uses nsf-remote-attestation; 927 } 928 } 929 rpc platform-challenge-response{ 930 description 931 "this rpc is for platform challenge "; 932 input{ 933 uses token; 934 leaf nsf-name{ 935 type nsf-name; 936 } 937 leaf nonce{ 938 type int32; 939 } 940 } 941 output{ 942 uses platform-remote-attestation; 943 } 944 } 945 rpc RoT-challenge-response{ 946 input{ 947 uses token; 948 leaf nsf-name{ 949 type nsf-name; 950 } 951 leaf nonce{ 952 type int32; 953 } 954 } 955 output{ 956 uses RoT-remote-attestation; 957 } 958 } 960 //***********************************************// 961 // configuration about PCR and NSF set. // 962 //***********************************************// 963 container nsf-pcr-set{ 964 description 965 "this container is used for NSF-name, IMA log and 966 PCR index setting. NSF-name needs to be set as the 967 IMA item filename-hint, the pcr value need to be 968 set as the IMA pcr index."; 969 if-feature "tpm:tpms"; 970 leaf nsf-name{ 971 type nsf-name; 972 } 973 leaf pcr-index{ 974 type tpm:pcr; 975 } 976 } 978 //***********************************************// 979 // configuration about EAT set. // 980 //***********************************************// 981 container eat-set{ 982 description 983 "this container is for NSF-name set in EAT environment"; 984 if-feature "TEE"; 985 leaf algorithm{ 986 description 987 "set the signing algorithm for generating EAT"; 988 type enumeration{ 989 enum HS256;//hmac with sha256 990 enum RS256;//rsa with sha256 991 } 992 } 993 leaf cwt-uwt-choose{ 994 type int32; 995 description 996 "0 is cwt, 1 is uccs, 2 is jwt"; 997 } 998 } 999 } 1001 5.2. I2NSF Remote Attestation Reference Value Interface 1003 The reference value of a NSF needs to be conveyed by I2NSF Remote 1004 Attestation Reference Value Interface. The interface works between 1005 Security Controller and Developer's Management System. 1007 5.2.1. Yang Tree Diagram of I2NSF Remote Attestation Reference Value 1008 Interface 1010 module: ietf-i2nsf-remote-attestation-reference-value 1011 +--rw nsf-tpm-reference-value-registration 1012 | +--rw nsf-name nsf-name 1013 | +--rw ima-template? string 1014 | +--rw nsf-hash? binary 1015 | +--rw nsf-hash-algorithm? string 1016 | +--rw pcr-index? pcr 1017 +--rw nsf-tee-reference-value-registration 1018 | +--rw nsf-name nsf-name 1019 | +--rw header-NSF? binary 1020 | +--rw payload-NSF? binary 1021 | +--rw signature-NSF? binary 1022 +--rw rot-reference-value-registration 1023 | +--rw (RoT-type)? 1024 | +--:(TPM12) {TPM12}? 1025 | | +--rw rot-tm12 1026 | | +--rw rot-tpm12-name? string 1027 | | +--rw certificate-name certificate-name-ref 1028 | | +--rw tpm12-hash-algo? identityref 1029 | +--:(TPM20) {TPM20}? 1030 | | +--rw rot-tpm20 1031 | | +--rw rot-tpm20-name? string 1032 | | +--rw certificate-name certificate-name-ref 1033 | | +--rw tpm20-hash-algo? identityref 1034 | +--:(TEE) {TEE}? 1035 | +--rw TEE-UEID? binary 1036 +--rw platform-tpm-reference-value-registration 1037 | +--rw platform-name string 1038 | +--rw ima-template? string 1039 | +--rw nsf-hash? binary 1040 | +--rw nsf-hash-algorithm? string 1041 | +--rw pcr-index? pcr 1042 +--rw platform-tee-remote-attestation-reference-value 1043 +--rw platform-name nsf-name 1044 +--rw header-NSF? binary 1045 +--rw payload-NSF? binary 1046 +--rw signature-NSF? binary 1048 5.2.2. Yang Data Model of I2NSF Remote Attestation Reference Value 1049 Interface 1051 The Yang Model of I2NSF Remote Attestation Reference Value Interface 1052 is shown below. The registration information will refer to the 1053 measurement logs and algorithms of remote attestation. The log 1054 infomation contains all the information needed by Security Controller 1055 to apparaise attester's evidence. 1057 module ietf-i2nsf-remote-attestation-reference-value { 1058 yang-version 1.1; 1059 namespace 1060 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-remote- 1061 attestation-reference-value"; 1062 prefix 1063 nsfrarv; 1065 import ietf-tpm-remote-attestation{ 1066 prefix tpm; 1067 } 1068 import ietf-inet-types{ 1069 prefix inet; 1070 } 1071 organization 1072 "IETF I2NSF (Interface to Network Security Functions) 1073 Working Group"; 1074 contact 1075 "WG Web: 1076 WG List: 1077 Editor: Penglin Yang 1078 "; 1080 description 1081 "This module is a YANG module for I2NSF NSF remote 1082 attestation reference value."; 1084 identity RoT-type{ 1085 description 1086 "RoT have different types, like TPM, TEE, etc."; 1087 } 1089 identity TPM12{ 1090 base RoT-type; 1091 description 1092 "RoT type is TPM1.2"; 1093 } 1094 identity TPM20{ 1095 base RoT-type; 1096 description 1097 "RoT type is TPM2.0"; 1098 } 1099 identity TEE{ 1100 base RoT-type; 1101 description 1102 "RoT type is TEE general"; 1103 } 1104 feature TPM12{ 1105 description 1106 "tpm 1.2 version"; 1107 } 1108 feature TPM20{ 1109 description 1110 "tpm 2.0 version"; 1111 } 1112 feature TEE{ 1113 description 1114 "TEE version"; 1115 } 1116 typedef nsf-name{ 1117 type union{ 1118 type string; 1119 type inet:ip-address-no-zone; 1120 } 1121 description 1122 "nsf-name for regular expression"; 1123 } 1124 typedef pcr{ 1125 type uint8{ 1126 range "0..31"; 1127 } 1128 } 1130 container nsf-tpm-reference-value-registration{ 1131 description 1132 "the reference value is for nsf in tpm20 platform"; 1133 leaf nsf-name{ 1134 type nsf-name; 1135 mandatory true; 1136 description 1137 "The name of nsf"; 1138 } 1139 leaf ima-template { 1140 type string; 1141 description 1142 "Name of the template used for event logs 1143 for e.g. ima, ima-ng, ima-sig"; 1144 } 1145 leaf nsf-hash { 1146 type binary; 1147 description 1148 "Hash of nsf file/image"; 1149 } 1150 leaf nsf-hash-algorithm { 1151 type string; 1152 description 1153 "Algorithm used for filedata-hash"; 1154 } 1155 leaf pcr-index { 1156 type pcr; 1157 description 1158 "Defines the PCR index that stores this nsf"; 1159 } 1160 } 1161 container nsf-tee-reference-value-registration{ 1162 description 1163 "the reference value is for nsf in TEE platform"; 1164 leaf nsf-name{ 1165 type nsf-name; 1166 mandatory true; 1167 description 1168 "The name of nsf"; 1169 } 1170 leaf header-NSF{ 1171 type binary; 1172 } 1173 leaf payload-NSF{ 1174 type binary; 1175 } 1176 leaf signature-NSF{ 1177 type binary; 1178 } 1179 } 1180 container rot-reference-value-registration{ 1181 description 1182 "this container is for root of trust reference value"; 1183 choice RoT-type{ 1184 case TPM12{ 1185 if-feature "TPM12"; 1186 description 1187 "the identity of TPM could be represented by 1188 TPM-name and certificate"; 1189 container rot-tm12{ 1190 leaf rot-tpm12-name{ 1191 type string; 1192 } 1193 uses tpm:certificate-name-ref; 1194 uses tpm:tpm12-hash-algo; 1195 } 1196 } 1197 case TPM20{ 1198 if-feature "TPM20"; 1199 description 1200 "the identity of TPM could be represented by 1201 TPM-name and certificate"; 1202 container rot-tpm20{ 1203 leaf rot-tpm20-name{ 1204 type string; 1205 } 1206 uses tpm:certificate-name-ref; 1207 uses tpm:tpm20-hash-algo; 1208 } 1209 } 1210 case TEE{ 1211 if-feature "TEE"; 1212 leaf TEE-UEID{ 1213 //provide a UEID to identify TEE 1214 type binary; 1215 } 1216 } 1217 } 1218 } 1219 container platform-tpm-reference-value-registration{ 1220 description 1221 "this container is for platform reference value"; 1222 leaf platform-name{ 1223 type string; 1224 mandatory true; 1225 description 1226 "The name of nsf"; 1227 } 1228 leaf ima-template { 1229 type string; 1230 description 1231 "Name of the template used for event logs 1232 for e.g. ima, ima-ng, ima-sig"; 1233 } 1234 leaf nsf-hash { 1235 type binary; 1236 description 1237 "Hash of nsf file/image"; 1238 } 1239 leaf nsf-hash-algorithm { 1240 type string; 1241 description 1242 "Algorithm used for filedata-hash"; 1243 } 1244 leaf pcr-index { 1245 type pcr; 1246 description 1247 "Defines the PCR index that stores this nsf"; 1248 } 1250 } 1251 container platform-tee-remote-attestation-reference-value{ 1252 description 1253 "the reference value is for platform in TEE platform"; 1254 leaf platform-name{ 1255 type nsf-name; 1256 mandatory true; 1257 description 1258 "The name of nsf"; 1259 } 1260 leaf header-NSF{ 1261 type binary; 1262 } 1263 leaf payload-NSF{ 1264 type binary; 1265 } 1266 leaf signature-NSF{ 1267 type binary; 1268 } 1269 } 1270 } 1272 6. IANA Considerations 1274 This document requests IANA to register the following URI in the 1275 "IETF XML Registry" RFC 3688 [RFC3688]: 1277 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-remote-attestation 1278 Registrant Contact: The IESG. 1280 XML: N/A; the requested URI is an XML namespace. 1282 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-remote-attestation- 1283 reference-value Registrant Contact: The IESG. 1285 XML: N/A; the requested URI is an XML namespace. 1287 This document requests IANA to register the following YANG module in 1288 the "YANG Module Names" registry RFC 7950 [RFC7950] RFC 8525 1289 [RFC8525]: 1291 Name: ietf-i2nsf-remote-attestation-interface 1293 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-remote- 1294 attestation 1296 Prefix: nsfra 1297 Reference: RFC XXXX 1299 Name: ietf-i2nsf-remote-attestation-reference-value-interface 1301 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-remote- 1302 attestation-reference-value 1304 Prefix: nsfteri 1306 Reference: RFC XXXX 1308 7. Security Considerations 1310 This document introduces the architecture of I2NSF remote attestation 1311 and designs related interfaces. Different RoT architectures have 1312 different trust ability and different appearance. Security 1313 Controller will determine if it will trust these remote attestation 1314 results by customized policy rules. The I2NSF remote attestation 1315 interfaces need to be protected by secure channel when transmission 1316 occurs. Meanwhile, the remote attestation results in interfaces are 1317 protected by their own mechanisms like TPM signature or token. 1319 8. References 1321 8.1. Normative Reference 1323 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 1324 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 1325 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 1326 Model", Work in Progress, Internet-Draft, draft-ietf- 1327 i2nsf-nsf-monitoring-data-model-15, 15 February 2022, 1328 . 1331 [I-D.ietf-rats-architecture] 1332 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 1333 W. Pan, "Remote Attestation Procedures Architecture", Work 1334 in Progress, Internet-Draft, draft-ietf-rats-architecture- 1335 15, 8 February 2022, . 1338 [I-D.ietf-rats-eat] 1339 Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity 1340 Attestation Token (EAT)", Work in Progress, Internet- 1341 Draft, draft-ietf-rats-eat-12, 24 February 2022, 1342 . 1345 [I-D.ietf-rats-tpm-based-network-device-attest] 1346 Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- 1347 based Network Device Remote Integrity Verification", Work 1348 in Progress, Internet-Draft, draft-ietf-rats-tpm-based- 1349 network-device-attest-13, 1 March 2022, 1350 . 1353 [I-D.ietf-rats-yang-tpm-charra] 1354 Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen, 1355 B., (Frank), L. X., Laffey, T., and G. C. Fedorkow, "A 1356 YANG Data Model for Challenge-Response-based Remote 1357 Attestation Procedures using TPMs", Work in Progress, 1358 Internet-Draft, draft-ietf-rats-yang-tpm-charra-16, 2 1359 March 2022, . 1362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1363 Requirement Levels", BCP 14, RFC 2119, 1364 DOI 10.17487/RFC2119, March 1997, 1365 . 1367 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1368 DOI 10.17487/RFC3688, January 2004, 1369 . 1371 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1372 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1373 . 1375 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1376 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1377 . 1379 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1380 Kumar, "Framework for Interface to Network Security 1381 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 1382 . 1384 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1385 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1386 May 2018, . 1388 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 1389 and R. Wilton, "YANG Library", RFC 8525, 1390 DOI 10.17487/RFC8525, March 2019, 1391 . 1393 8.2. Informative Reference 1395 [SGX] Intel, "Overview of Intel Software Guard Extension", June 1396 2016, 1397 . 1400 [TCGRoT] Trust Computing Group, "DRAFT: TCG Roots of Trust 1401 Specification", October 2018, 1402 . 1405 [TEE] Global Platform Technology, "Global Platform Technology 1406 TEE System Architecture Version 1.2", December 2018, 1407 . 1410 [tpm12] Trusted Computing Group, "TPM Main Specification Level 2 1411 Version 1.2, Revision 116", March 2011, 1412 . 1415 [tpm20] Trusted Computing Group, "Trusted Platform Module Library 1416 Specification, Family "2.0", Level 00, Revision 01.59", 1417 November 2019, 1418 . 1421 Authors' Addresses 1423 Penglin Yang 1424 China Mobile 1425 32 Xuanwumen West Street, Xicheng District 1426 Beijing 1427 100053 1428 China 1429 Email: yangpenglin@chinamobile.com 1431 Meiling Chen 1432 China Mobile 1433 32 Xuanwumen West Street, Xicheng District 1434 Beijing 1435 100053 1436 China 1437 Email: chenmeiling@chinamobile.com 1438 Li Su 1439 China Mobile 1440 32 Xuanwumen West Street, Xicheng District 1441 Beijing 1442 100053 1443 China 1444 Email: suli@chinamobile.com 1446 Diego Lopiz 1447 Telefonica 1448 Email: diego.r.lopez@telefonica.com 1450 Jaehoon Paul Jeong 1451 Sungkyunkwan University 1452 Email: jaehoon.paul@gmail.com 1454 Linda Dunbar 1455 Futurewei 1456 Email: linda.dunbar@futurewei.com