idnits 2.17.1 draft-yang-i2nsf-trust-enhanced-i2nsf-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 : ---------------------------------------------------------------------------- ** There are 31 instances of too long lines in the document, the longest one being 25 characters in excess of 72. ** The abstract seems to contain references ([TCGRoT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 331 has weird spacing: '...-number uin...' == Line 371 has weird spacing: '...-number uin...' == Line 432 has weird spacing: '...te-name cer...' == Line 444 has weird spacing: '...r-index pcr...' == Line 470 has weird spacing: '...-number uin...' == (3 more instances...) -- The document date (December 2021) is 863 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-12 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-13 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-11 == Outdated reference: A later version (-14) exists of draft-ietf-rats-tpm-based-network-device-attest-09 == Outdated reference: A later version (-22) exists of draft-ietf-rats-yang-tpm-charra-11 Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group P.Y. Yang, Ed. 3 Internet-Draft M.C. Chen, Ed. 4 Intended status: Informational L.S. Su, Ed. 5 Expires: 4 June 2022 China Mobile 6 December 2021 8 Trust Enhanced I2NSF 9 draft-yang-i2nsf-trust-enhanced-i2nsf-00 11 Abstract 13 This document describes the architecture of Trust Enhanced I2NSF. In 14 this architecture, technologies like TPM [tpm12][tpm20] and [TCGRoT] 15 will act as RoT (root of trust), integrity measurement and remote 16 attestation will be used to enhance the trustworthiness of NSF. 17 Relevant interfaces of Trust Enhanced I2NSF will also be illustrated 18 in this document. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 4 June 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Revised BSD License text as 48 described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Revised BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 3. Scope and Motivation . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Information Model . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Architecture of Trust Enhanced I2NSF . . . . . . . . . . 4 62 4.2. Root of Trust . . . . . . . . . . . . . . . . . . . . . . 6 63 4.3. Verifier/Relying Party . . . . . . . . . . . . . . . . . 6 64 4.4. Reference Value Provider . . . . . . . . . . . . . . . . 6 65 4.5. Endorser . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Data Model of Trust Enhanced I2NSF . . . . . . . . . . . . . 7 67 5.1. Trust Enhanced NSF Monitoring interface . . . . . . . . . 7 68 5.1.1. Yang Tree Diagram of Trust Enhanced NSF Monitoring 69 Interface . . . . . . . . . . . . . . . . . . . . . . 7 70 5.1.2. Yang Data Model of Trust Enhanced NSF Monitoring 71 Interface . . . . . . . . . . . . . . . . . . . . . . 13 72 5.2. Trust Enhanced Registration interface . . . . . . . . . . 19 73 5.2.1. Yang Tree Diagram of Trust Enhanced Registration 74 interface . . . . . . . . . . . . . . . . . . . . . . 19 75 5.2.2. Yang Data Model of Trust Enhanced Registration 76 interface . . . . . . . . . . . . . . . . . . . . . . 21 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 80 8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 23 81 8.2. Informative Reference . . . . . . . . . . . . . . . . . . 25 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 84 1. Introduction 86 NSF is always used in remote scenarios, in which it is hard to 87 guarantee the deployment environment is security and the NSF is 88 properly deployed. If the deployment environment or the NSF is 89 compromised, the behavior and the feedback of NSF cannot be trusted. 91 Trusted computing technology like TPM, TEE[TEE] could provide a root 92 of trust based on hardware in deployment environment. Trusted 93 computing hardware usually retains a pair of root key, which could be 94 used to sign signature for the measurement of development environment 95 and the NSF image. Then the signed result will be sent to the NSF 96 manager to estimate if the NSF is well deployed. 98 The RATs architecture[I-D.ietf-rats-architecture] has defined this 99 remote attestation process which could be introduced to I2NSF. Since 100 the RATs architecture is a general architecture, specific interface 101 and implementation still need to be determined in I2NSF. This draft 102 aims to create a unified trust enhanced I2NSF architecture to promote 103 the security of NSF 105 2. Terminology 107 2.1. Terms 109 RATs: Remote Attestation Procedure 111 RoT: Root of Trust 113 TPM: Trusted platform module 115 TEE: Trust Execution Environment 117 2.2. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 3. Scope and Motivation 125 3.1. Scope 127 The scope of this draft mainly focuses on the expanded interfaces of 128 trust enhanced I2NSF. The specific of how to implement measurement 129 or how to make remote attestation evidence is out of scope. 131 3.2. Motivation 133 The architecture of I2NSF [RFC8329] aims to provide network security 134 functions to network users. Often, the users are in remote 135 environment, and the platform to deploy these network security 136 functions may not be trusted. As a consequence, this will bring 137 several severe threats to the NSF. The first one is malfunction of 138 NSF. The inappropriate deployment of NSF or the defective platform 139 will affect the process of NSF directly. The second threat is the 140 leak of policy rules and core asset of security knowledge. If there 141 has malware in the remote environment, it will be hard to prevent the 142 leakage. The third threat is the potential spoofing attack to the 143 NSF architecture. Adversary could use the compromised NSF to 144 feedback spoofing information or other attacking information to 145 attack or penetrate the NSF architecture. 147 The solution of these threats is also straight, which is using remote 148 attestation to make sure the remote platform is trusted and the NSF 149 is well deployed. The RATs group in IETF defines architecture and 150 some specifications of remote attestation procedure. However brings 151 the RATs in I2NSF still needs some work. First, need to define the 152 trsut enhanced architecture. Second, need to refer the appropriate 153 specifications defined in RATs to create trust enhanced NSF 154 interfaces. Third, need to cover the heterogeneous architecture of 155 specific trust architecture like TPM and TEE. 157 4. Information Model 159 4.1. Architecture of Trust Enhanced I2NSF 160 +--------------+ +--------------+ 161 | | | | 162 | NSF User | +-------------+ Endorser | 163 | | | | | 164 +------+-------+ | +--------------+ 165 | | 166 | | 167 +-------------------+ 168 | 169 | 170 +------+-------+ +--------------+ 171 | | | | 172 | Security +-------------------------+ Developer's | 173 | Controller | | Mgnt System | 174 +-+----------+-+ +-+----------+-+ 175 | Verifier/| | Reference| 176 | Relying | | Value | 177 | Party | | Provider | 178 +----+-----+ +----------+ 179 | 180 | 181 +-------------------+---------------------+ 182 | | | 183 +------+-------+ +------+-------+ +------+-------+ 184 | | | | | | 185 | NSF1 + | NSF2 | | NSFn | 186 | | | | | | 187 +--+--------+--+ +--+--------+--+ +--+--------+--+ 188 | RoT | | RoT | | RoT | 189 | | | | | | 190 +--------+ +--------+ +--------+ 192 Figure 1: architecture of Trust Enhanced I2NSF 194 As shown in figure one is the trust enhanced I2NSF architecture. In 195 this architecture, several new components are introduced to NSF. The 196 first component is RoT which is deployed in the hardware platform of 197 NSF. The second component is Verifier/Relying Party, which is 198 deployed as part of Security Controller. This component is in charge 199 of verifying if the attestation value is complied with the reference 200 value. The third component is the Reference Value Provider, which 201 will bring the reference value of NSF image and deployment 202 environment to Security Controller. The fourth component is 203 Endorser, which will provie the endorsement of RoT. And the verifier 204 could use Endorser to verify the endorsement status of RoT. 206 4.2. Root of Trust 208 Root of Trust is a hardware-based component that could provide 209 information and certain function that cannot be stolen, tampered, or 210 repudiation. RoT MUST be deployed in the NSF hardware platform. The 211 NSF with RoT composes the rule of attester. 213 The architecture of specific RoT is out of scope of this document. 214 But in order to clarify RoT more clearly, the following segment uses 215 TPM as an example to illustrate. TPM keeps EK(Endorsement Key ) to 216 identify its identity. EK is an asymmetric key pair, which will 217 never expose its secret key to public. TPM also derives certain 218 AIKs(Attestation Identity Key) from EK to avoid the exposure of TPM's 219 real identity(EK). Meanwhile, TPM contains a reference Hash value of 220 the boot component of platform. When launching a remote attestation 221 procedure, the TPM will first measure the boot component of platform. 222 Based on the trust policy the TPM will choose if trust the boot 223 component and transfer the system control to the boot component. The 224 boot component then will measure the operating system kernel and 225 compare it to the reference value, and so on. During this trusted 226 measurement process, the TPM will record the measurement Hash result 227 in a series of registers called PCRs. If a remote attestation 228 procedure is initiated, the measurement Hash result will be signed by 229 AIK. In the end, remote attestation procedure will send this signed 230 Hash result and measurement result to the verifier. The specific 231 procedure could refer 232 to[I-D.ietf-rats-tpm-based-network-device-attest], which illustrates 233 how integrity verification works inside a device. 235 4.3. Verifier/Relying Party 237 The Verifier/Relying Party is deployed in Security Controller. In 238 the original architecture of RATs, Verifier and Relying Party could 239 be different components. Verifier is in charge of verifying the 240 remote attestation results from attester. The Relying Party is in 241 charge of appraising the verification result from Verifier. This 242 means that the Relying Party does not have to know the detail of 243 remote attestation result and could only focus on the final 244 verification result and make policies. While in NSF, both the role 245 of Verifier and Relying Party will be included in Security Controller 246 to reduce the complexity. 248 4.4. Reference Value Provider 250 The Developer's Mgnt System is in charge of providing reference value 251 of NSF and the deployment platform. The reference value will be 252 conveyed to Security Controller as the benchmark when verifying 253 remote attestation value from attester. 255 4.5. Endorser 257 The Endorser is in charge of providing endorsement to RoT, both EK 258 and AIK are related to Endorser. The communication between RoT and 259 Endorser is out of scope of this document, but the Security 260 Controller needs to communicate with Endorser to verify remote 261 attestation message. 263 5. Data Model of Trust Enhanced I2NSF 265 Two interfaces are involved in trust enhanced I2NSF, Trust Enhanced 266 NSF Monitoring Interface and Trust Enhanced Registration Interface. 268 5.1. Trust Enhanced NSF Monitoring interface 270 The TENMI (Trust Enhanced NSF Monitoring Interface) focuses on the 271 remote attestation procedure between NSF and security controller. 272 This interface will be an extended feature of NSF Monitoring 273 Interface and will fully comply with NSF Monitoring 274 Interface[I-D.ietf-i2nsf-nsf-monitoring-data-model]. Based on the 275 information transmission type, the TENMI has three Yang types: system 276 events, system logs and RPC. The system event is responsible for the 277 NSF event that will trigger the remote attestation of NSF. And the 278 event could be platform booting, measurement result change, NSF 279 deploy, etc. The system logs is responsible for the periodic remote 280 attestation. The third type is RPC in where the Verifier (Security 281 Controller) will challenge the attester (NSF) for its trustworthiness 282 initiatively. 284 At present, the RoT type now are split in two category, one is TPM- 285 based and the other is general TEE-based like Trust Zone. It can be 286 expected that other trsuted computing architectures like Intel SGX 287 [SGX] may also be involved in the near future. And also the TPM- 288 based RoT is split in TPM12 and TPM20 versions respectively. When 289 design this interface with TPM-based RoT, this document tries to 290 refer to the existing document[I-D.ietf-rats-yang-tpm-charra] as much 291 as possible to avoid unnecessary alignment work. And about the 292 general TEE-based RoT, this document refers to the EAT 293 document[I-D.ietf-rats-eat] and uses string type to express 294 JWT[RFC7519]or CWT [RFC8392]. 296 5.1.1. Yang Tree Diagram of Trust Enhanced NSF Monitoring Interface 298 The Yang tree of Trust Enhanced NSF Monitoring Interface is shown 299 below. 301 module: ietf-i2nsf-nsf-trust-enhanced-monitoring 302 rpcs: 303 +---x nsf-challenge-response-attestation 304 +---w input 305 | +---w (RoT-type)? 306 | +--:(TPM12) 307 | | +---w tpm12-rpc 308 | | +---w pcr-index* pcr 309 | | +---w nonce-value binary 310 | | +---w certificate-name* tpm:certificate-name-ref {tpm:tpms}? 311 | +--:(TPM20) 312 | | +---w tpm20-pcr 313 | | +---w nonce-value binary 314 | | +---w tpm20-pcr-selection* [] 315 | | | +---w tpm20-hash-algo? identityref 316 | | | +---w pcr-index* pcr 317 | | +---w certificate-name* tpm:certificate-name-ref {tpm:tpms}? 318 | +--:(TEE-general) 319 | +---w nonce? binary 320 | +---w certificate-name? string 321 +--ro output 322 +--ro (RoT-type)? 323 +--:(TPM12) 324 | +--ro tpm12-log 325 | +--ro name? string 326 | +--ro up-time? uint32 327 | +--ro (attested_event_log_type) 328 | +--:(bios) {bios}? 329 | | +--ro bios-event-logs 330 | | +--ro bios-event-entry* [event-number] 331 | | +--ro event-number uint32 332 | | +--ro event-type? uint32 333 | | +--ro pcr-index? pcr 334 | | +--ro digest-list* [hash-alog] 335 | | | +--ro hash-algo? identityref 336 | | | +--ro digest* binary 337 | | +--ro event-size? uint32 338 | | +--ro event-data* uint8 339 | +--:(ima) {ima}? 340 | | +--ro ima-event-logs 341 | | +--ro ima-event-entry* [event-number] 342 | | +--ro event-number uint64 343 | | +--ro ima-template? string 344 | | +--ro filename-hint? string 345 | | +--ro filedata-hash? binary 346 | | +--ro filedata-hash-algorithm? string 347 | | +--ro template-hash-algorithm? string 348 | | +--ro template-hash? binary 349 | | +--ro pcr-index? pcr 350 | | +--ro signature? binary 351 | +--:(netequip_boot) {netequip_boot}? 352 | +--ro boot-event-logs 353 | +--ro boot-event-entry* [event-number] 354 | +--ro event-number uint64 355 | +--ro ima-template? string 356 | +--ro filename-hint? string 357 | +--ro filedata-hash? binary 358 | +--ro filedata-hash-algorithm? string 359 | +--ro template-hash-algorithm? string 360 | +--ro template-hash? binary 361 | +--ro pcr-index? pcr 362 | +--ro signature? binary 363 +--:(TPM20) 364 | +--ro tpm20-log 365 | +--ro name? string 366 | +--ro up-time? uint32 367 | +--ro (attested_event_log_type) 368 | +--:(bios) {bios}? 369 | | +--ro bios-event-logs 370 | | +--ro bios-event-entry* [event-number] 371 | | +--ro event-number uint32 372 | | +--ro event-type? uint32 373 | | +--ro pcr-index? pcr 374 | | +--ro digest-list* [hash-alog] 375 | | | +--ro hash-algo? identityref 376 | | | +--ro digest* binary 377 | | +--ro event-size? uint32 378 | | +--ro event-data* uint8 379 | +--:(ima) {ima}? 380 | | +--ro ima-event-logs 381 | | +--ro ima-event-entry* [event-number] 382 | | +--ro event-number uint64 383 | | +--ro ima-template? string 384 | | +--ro filename-hint? string 385 | | +--ro filedata-hash? binary 386 | | +--ro filedata-hash-algorithm? string 387 | | +--ro template-hash-algorithm? string 388 | | +--ro template-hash? binary 389 | | +--ro pcr-index? pcr 390 | | +--ro signature? binary 391 | +--:(netequip_boot) {netequip_boot}? 392 | +--ro boot-event-logs 393 | +--ro boot-event-entry* [event-number] 394 | +--ro event-number uint64 395 | +--ro ima-template? string 396 | +--ro filename-hint? string 397 | +--ro filedata-hash? binary 398 | +--ro filedata-hash-algorithm? string 399 | +--ro template-hash-algorithm? string 400 | +--ro template-hash? binary 401 | +--ro pcr-index? pcr 402 | +--ro signature? binary 403 +--:(TEE-general) 404 +--ro (token-type)? 405 +--:(cwt) 406 | +--ro eat-header-cwt? string 407 | +--ro eat-payload-cwt? string 408 | +--ro eat-signature-cwt? string 409 +--:(jwt) 410 +--ro eat-header-jwt? string 411 +--ro eat-payload-jwt? string 412 +--ro eat-signature-jwt? string 414 notifications: 415 +---n i2nsf-trust-enhanced-event 416 | +--ro hardware-type string 417 | +--ro operating-system-type string 418 | +--ro acquisition-method? identityref 419 | +--ro emission-type? identityref 420 | +--ro dampening-type? identityref 421 | +--ro user string 422 | +--ro group* string 423 | +--ro ip-address inet:ip-address 424 | +--ro authentication? identityref 425 | +--ro message? string 426 | +--ro vendor-name? string 427 | +--ro nsf-name? union 428 | +--ro severity? severity 429 | +--ro (RoT-type)? 430 | +--:(TPM12) 431 | | +--ro tpm12-nsf-rats {taa:tpm12}? 432 | | +--ro certificate-name certificate-name-ref 433 | | +--ro up-time? uint32 434 | | +--ro TPM_QUOTE2? binary 435 | +--:(TPM20) 436 | | +--ro tpm20-nsf-rats {taa:tpm20}? 437 | | +--ro certificate-name certificate-name-ref 438 | | +--ro TPMS_QUOTE_INFO binary 439 | | +--ro quote-signature? binary 440 | | +--ro up-time? uint32 441 | | +--ro unsigned-pcr-values* [] 442 | | +--ro tpm20-hash-algo? identityref 443 | | +--ro pcr-values* [pcr-index] 444 | | +--ro pcr-index pcr 445 | | +--ro pcr-value? binary 446 | +--:(TEE-general) 447 | +--ro (token-type)? 448 | +--:(cwt) 449 | | +--ro eat-header-cwt? string 450 | | +--ro eat-payload-cwt? string 451 | | +--ro eat-signature-cwt? string 452 | +--:(jwt) 453 | +--ro eat-header-jwt? string 454 | +--ro eat-payload-jwt? string 455 | +--ro eat-signature-jwt? string 456 +---n i2nsf-trsut-enhanced-log 457 +--ro message? string 458 +--ro vendor-name? string 459 +--ro nsf-name? union 460 +--ro severity? severity 461 +--ro (RoT-type)? 462 +--:(TPM12) 463 | +--ro tpm12-log 464 | +--ro name? string 465 | +--ro up-time? uint32 466 | +--ro (attested_event_log_type) 467 | +--:(bios) {bios}? 468 | | +--ro bios-event-logs 469 | | +--ro bios-event-entry* [event-number] 470 | | +--ro event-number uint32 471 | | +--ro event-type? uint32 472 | | +--ro pcr-index? pcr 473 | | +--ro digest-list* [hash-alog] 474 | | | +--ro hash-algo? identityref 475 | | | +--ro digest* binary 476 | | +--ro event-size? uint32 477 | | +--ro event-data* uint8 478 | +--:(ima) {ima}? 479 | | +--ro ima-event-logs 480 | | +--ro ima-event-entry* [event-number] 481 | | +--ro event-number uint64 482 | | +--ro ima-template? string 483 | | +--ro filename-hint? string 484 | | +--ro filedata-hash? binary 485 | | +--ro filedata-hash-algorithm? string 486 | | +--ro template-hash-algorithm? string 487 | | +--ro template-hash? binary 488 | | +--ro pcr-index? pcr 489 | | +--ro signature? binary 490 | +--:(netequip_boot) {netequip_boot}? 491 | +--ro boot-event-logs 492 | +--ro boot-event-entry* [event-number] 493 | +--ro event-number uint64 494 | +--ro ima-template? string 495 | +--ro filename-hint? string 496 | +--ro filedata-hash? binary 497 | +--ro filedata-hash-algorithm? string 498 | +--ro template-hash-algorithm? string 499 | +--ro template-hash? binary 500 | +--ro pcr-index? pcr 501 | +--ro signature? binary 502 +--:(TPM20) 503 | +--ro tpm20-log 504 | +--ro name? string 505 | +--ro up-time? uint32 506 | +--ro (attested_event_log_type) 507 | +--:(bios) {bios}? 508 | | +--ro bios-event-logs 509 | | +--ro bios-event-entry* [event-number] 510 | | +--ro event-number uint32 511 | | +--ro event-type? uint32 512 | | +--ro pcr-index? pcr 513 | | +--ro digest-list* [hash-alog] 514 | | | +--ro hash-algo? identityref 515 | | | +--ro digest* binary 516 | | +--ro event-size? uint32 517 | | +--ro event-data* uint8 518 | +--:(ima) {ima}? 519 | | +--ro ima-event-logs 520 | | +--ro ima-event-entry* [event-number] 521 | | +--ro event-number uint64 522 | | +--ro ima-template? string 523 | | +--ro filename-hint? string 524 | | +--ro filedata-hash? binary 525 | | +--ro filedata-hash-algorithm? string 526 | | +--ro template-hash-algorithm? string 527 | | +--ro template-hash? binary 528 | | +--ro pcr-index? pcr 529 | | +--ro signature? binary 530 | +--:(netequip_boot) {netequip_boot}? 531 | +--ro boot-event-logs 532 | +--ro boot-event-entry* [event-number] 533 | +--ro event-number uint64 534 | +--ro ima-template? string 535 | +--ro filename-hint? string 536 | +--ro filedata-hash? binary 537 | +--ro filedata-hash-algorithm? string 538 | +--ro template-hash-algorithm? string 539 | +--ro template-hash? binary 540 | +--ro pcr-index? pcr 541 | +--ro signature? binary 542 +--:(TEE-general) 543 +--ro (token-type)? 544 +--:(cwt) 545 | +--ro eat-header-cwt? string 546 | +--ro eat-payload-cwt? string 547 | +--ro eat-signature-cwt? string 548 +--:(jwt) 549 +--ro eat-header-jwt? string 550 +--ro eat-payload-jwt? string 551 +--ro eat-signature-jwt? string 553 5.1.2. Yang Data Model of Trust Enhanced NSF Monitoring Interface 555 The Yang Model of Trust Enhanced NSF Monitoring Interface is shown 556 below. 558 module ietf-i2nsf-nsf-trust-enhanced-monitoring { 559 yang-version 1.1; 560 namespace 561 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-trust-enhanced-monitoring"; 562 prefix 563 nsftemi; 564 import ietf-i2nsf-nsf-monitoring{ 565 prefix nsfmi; 566 reference 567 "reference of nsf monitoring interface"; 568 } 569 import ietf-tcg-algs{ 570 prefix taa; 571 } 572 import ietf-tpm-remote-attestation{ 573 prefix tpm; 574 } 575 organization 576 "IETF I2NSF (Interface to Network Security Functions) Working Group"; 577 contact 578 "WG Web: 579 WG List: 581 Editor: Penglin Yang 582 "; 584 description 585 "This module is a YANG module for I2NSF NSF Trust Enhanced Monitoring."; 587 identity RoT-type{ 588 description 589 "RoT have different types, like TPM, TEE, SGX, etc."; 590 } 591 identity certificate-name-ref{ 592 description 593 "refer to tpm"; 594 } 595 identity TPM12{ 596 description 597 "RoT type is TPM1.2"; 598 } 599 identity TPM20{ 600 description 601 "RoT type is TPM2.0"; 602 } 603 identity TEE-general{ 604 description 605 "RoT type is TEE general"; 606 } 607 identity cwt{ 608 description 609 "cbor web token for remote attestation"; 610 } 611 identity jwt{ 612 description 613 "json web token for remote attestation"; 614 } 616 grouping nsf-remote-attestation{ 617 choice RoT-type{ 618 case TPM12{ 619 container tpm12-nsf-rats{ 620 if-feature "taa:tpm12"; 621 description 622 "since this message was triggered by event, so there is no input 623 from RPC. The pcr value is provided by device automatically, the 624 nonce value NEED to be replaced by the event time"; 625 uses tpm:certificate-name-ref; 626 uses tpm:tpm12-attestation; 627 } 628 } 629 case TPM20{ 630 container tpm20-nsf-rats{ 631 if-feature "taa:tpm20"; 632 description 633 "since this message was triggered by event, so there is no input 634 from RPC. The pcr value is provided by device automatically, the 635 nonce value NEED to be repalced by the event time"; 636 uses tpm:certificate-name-ref; 637 uses tpm:tpm20-attestation; 638 } 639 } 640 case TEE-general{ 641 description 642 "if the RoT is not TPM, or not specify the detail format, then uses 643 EAT as the reference of the attestation result at present. The 644 information includes: token-id; time-stamp; nonce; hardware-version; 645 software-description-version; security-level-claim; secure-boot-claim; 646 including-keys; location-claim; uptime-claim; boot-seed-claim; 647 intended-use-claim; profile-claim; software-manifest-claim; 648 software-evidence-claim"; 649 //how describe cwt or jwt in Yang, string? 650 choice token-type{ 651 case cwt{ 652 leaf eat-header-cwt{ 653 type string; 654 } 655 leaf eat-payload-cwt{ 656 type string; 657 } 658 leaf eat-signature-cwt{ 659 type string; 660 } 661 } 662 case jwt{ 663 leaf eat-header-jwt{ 664 type string; 665 } 666 leaf eat-payload-jwt{ 667 type string; 668 } 669 leaf eat-signature-jwt{ 670 type string; 671 } 672 } 673 } 674 } 675 } 676 } 677 grouping TEE-general-log{ 678 description 679 "describe the TEE general log."; 680 choice token-type{ 681 case cwt{ 682 leaf eat-header-cwt{ 683 type string; 684 } 685 leaf eat-payload-cwt{ 686 type string; 687 } 688 leaf eat-signature-cwt{ 689 type string; 690 } 691 } 692 case jwt{ 693 leaf eat-header-jwt{ 694 type string; 695 } 696 leaf eat-payload-jwt{ 697 type string; 698 } 699 leaf eat-signature-jwt{ 700 type string; 701 } 702 } 703 } 704 } 706 grouping remote-attestation-log{ 707 description 708 "describe different kind of log"; 709 choice RoT-type{ 710 case TPM12{ 711 description 712 "log recorded under the rule of TPM12"; 713 container tpm12-log{ 714 uses tpm:tpm-name; 715 uses tpm:node-uptime; 716 uses tpm:event-logs; 717 } 718 } 719 case TPM20{ 720 description 721 "log recorded under the rule of TPM20"; 722 container tpm20-log{ 723 uses tpm:tpm-name; 724 uses tpm:node-uptime; 725 uses tpm:event-logs; 726 } 727 } 728 case TEE-general{ 729 description 730 "log recorded under the rule of EAT"; 731 uses TEE-general-log; 732 } 734 } 735 } 737 notification i2nsf-trust-enhanced-event{ 738 description 739 "Notification for I2NSF trust enhanced Event."; 741 leaf hardware-type{ 742 mandatory true; 743 type string; 744 } 745 leaf operating-system-type{ 746 mandatory true; 747 type string; 748 } 749 uses nsfmi:characteristics; 750 uses nsfmi:i2nsf-system-event-type-content; 751 uses nsfmi:common-monitoring-data; 752 uses nsftemi:nsf-remote-attestation; 753 } 755 notification i2nsf-trsut-enhanced-log{ 756 description 757 "This notification is for integrity measurement log, 758 which does not have to be responsed immediately"; 759 uses nsfmi:common-monitoring-data; 760 uses remote-attestation-log; 761 } 763 rpc nsf-challenge-response-attestation{ 764 description 765 "this is the unified rpc for trust enhanced nsf"; 766 input{ 767 choice RoT-type{ 768 case TPM12{ 769 container tpm12-rpc{ 770 uses tpm:tpm12-pcr-selection; 771 uses tpm:nonce; 772 leaf-list certificate-name { 773 if-feature "tpm:tpms"; 774 type tpm:certificate-name-ref; 775 must "/tpm:rats-support-structures/tpm:tpms" 776 + "/tpm:tpm[tpm:firmware-version='taa:tpm12']" 777 + "/tpm:certificates/" 778 + "/tpm:certificate[name=current()]" { 779 error-message "Not an available TPM1.2 AIK certificate."; 780 } 781 description 782 "When populated, the RPC will only get a Quote for the 783 TPMs associated with these certificate(s)."; 784 } 785 } 786 } 787 case TPM20{ 788 container tpm20-pcr{ 789 uses tpm:nonce; 790 uses tpm:tpm20-pcr-selection; 791 leaf-list certificate-name { 792 if-feature "tpm:tpms"; 793 type tpm:certificate-name-ref; 794 must "/tpm:rats-support-structures/tpm:tpms" 795 + "/tpm:tpm[tpm:firmware-version='taa:tpm20']" 796 + "/tpm:certificates/" 797 + "/tpm:certificate[name=current()]" { 798 error-message "Not an available TPM2.0 AIK certificate."; 799 } 800 description 801 "When populated, the RPC will only get a Quote for the 802 TPMs associated with the certificates."; 803 } 804 } 805 } 806 case TEE-general{ 807 description 808 "there is no standard to reference"; 809 leaf nonce{ 810 type binary; 811 } 812 leaf certificate-name{ 813 type string; 814 } 815 } 816 } 817 } 818 output{ 819 uses remote-attestation-log; 820 } 821 } 822 } 823 5.2. Trust Enhanced Registration interface 825 The reference value of a NSF needs to be conveyed by trust enhanced 826 registration interface. The interface works between Security 827 Controller and Developer's Management System. (One trivial thing 828 needs to point out is that when refer to event-logs in ietf-tpm- 829 remote-attestation in data node, the list of "digest-list" needs to 830 define a key value. This condition determines future alignment with 831 [I-D.ietf-rats-yang-tpm-charra]. ) 833 5.2.1. Yang Tree Diagram of Trust Enhanced Registration interface 835 module: ietf-i2nsf-nsf-trust-enhanced-registration-interface 836 +--rw reference-value-register 837 +--rw nsf-name string 838 +--rw hardware-type string 839 +--rw operating-system-type string 840 +--rw (RoT-type)? 841 +--:(TPM12) 842 | +--rw tpm12-ref 843 | +--rw (attested_event_log_type) 844 | +--:(bios) {bios}? 845 | | +--rw bios-event-logs 846 | | +--rw bios-event-entry* [event-number] 847 | | +--rw event-number uint32 848 | | +--rw event-type? uint32 849 | | +--rw pcr-index? pcr 850 | | +--rw digest-list* [hash-alog] 851 | | | +--rw hash-algo? identityref 852 | | | +--rw digest* binary 853 | | +--rw event-size? uint32 854 | | +--rw event-data* uint8 855 | +--:(ima) {ima}? 856 | | +--rw ima-event-logs 857 | | +--rw ima-event-entry* [event-number] 858 | | +--rw event-number uint64 859 | | +--rw ima-template? string 860 | | +--rw filename-hint? string 861 | | +--rw filedata-hash? binary 862 | | +--rw filedata-hash-algorithm? string 863 | | +--rw template-hash-algorithm? string 864 | | +--rw template-hash? binary 865 | | +--rw pcr-index? pcr 866 | | +--rw signature? binary 867 | +--:(netequip_boot) {netequip_boot}? 868 | +--rw boot-event-logs 869 | +--rw boot-event-entry* [event-number] 870 | +--rw event-number uint64 871 | +--rw ima-template? string 872 | +--rw filename-hint? string 873 | +--rw filedata-hash? binary 874 | +--rw filedata-hash-algorithm? string 875 | +--rw template-hash-algorithm? string 876 | +--rw template-hash? binary 877 | +--rw pcr-index? pcr 878 | +--rw signature? binary 879 +--:(TPM20) 880 | +--rw tpm20-ref 881 | +--rw (attested_event_log_type) 882 | +--:(bios) {bios}? 883 | | +--rw bios-event-logs 884 | | +--rw bios-event-entry* [event-number] 885 | | +--rw event-number uint32 886 | | +--rw event-type? uint32 887 | | +--rw pcr-index? pcr 888 | | +--rw digest-list* [hash-alog] 889 | | | +--rw hash-algo? identityref 890 | | | +--rw digest* binary 891 | | +--rw event-size? uint32 892 | | +--rw event-data* uint8 893 | +--:(ima) {ima}? 894 | | +--rw ima-event-logs 895 | | +--rw ima-event-entry* [event-number] 896 | | +--rw event-number uint64 897 | | +--rw ima-template? string 898 | | +--rw filename-hint? string 899 | | +--rw filedata-hash? binary 900 | | +--rw filedata-hash-algorithm? string 901 | | +--rw template-hash-algorithm? string 902 | | +--rw template-hash? binary 903 | | +--rw pcr-index? pcr 904 | | +--rw signature? binary 905 | +--:(netequip_boot) {netequip_boot}? 906 | +--rw boot-event-logs 907 | +--rw boot-event-entry* [event-number] 908 | +--rw event-number uint64 909 | +--rw ima-template? string 910 | +--rw filename-hint? string 911 | +--rw filedata-hash? binary 912 | +--rw filedata-hash-algorithm? string 913 | +--rw template-hash-algorithm? string 914 | +--rw template-hash? binary 915 | +--rw pcr-index? pcr 916 | +--rw signature? binary 917 +--:(TEE-generic) 918 +--rw (token-type)? 919 +--:(cwt) 920 | +--rw eat-header-cwt? string 921 | +--rw eat-payload-cwt? string 922 | +--rw eat-signature-cwt? string 923 +--:(jwt) 924 +--rw eat-header-jwt? string 925 +--rw eat-payload-jwt? string 926 +--rw eat-signature-jwt? string 928 5.2.2. Yang Data Model of Trust Enhanced Registration interface 930 The Yang Model of Trust Enhanced Registration Interface is shown 931 below. 933 module ietf-i2nsf-nsf-trust-enhanced-registration-interface { 934 yang-version 1.1; 935 namespace 936 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-trust-enhanced-registration-interface"; 937 prefix 938 nsfteri; 940 import ietf-tpm-remote-attestation{ 941 prefix tpm; 942 } 943 import ietf-i2nsf-nsf-trust-enhanced-monitoring{ 944 prefix nsftemi; 945 } 946 organization 947 "IETF I2NSF (Interface to Network Security Functions) Working Group"; 948 contact 949 "WG Web: 950 WG List: 952 Editor: Penglin Yang 953 "; 955 description 956 "This module is a YANG module for I2NSF NSF Trust Enhanced Registration Interface."; 958 container reference-value-register{ 959 description 960 "the reference value is for nsf"; 961 leaf nsf-name{ 962 type string; 963 mandatory true; 964 description 965 "The name of nsf"; 966 } 967 leaf hardware-type{ 968 mandatory true; 969 type string; 970 } 971 leaf operating-system-type{ 972 mandatory true; 973 type string; 974 } 975 choice RoT-type{ 976 case TPM12{ 977 container tpm12-ref{ 978 uses tpm:event-logs; 979 } 980 } 981 case TPM20{ 982 container tpm20-ref{ 983 uses tpm:event-logs; 984 } 985 } 986 case TEE-generic{ 987 uses nsftemi:TEE-general-log; 988 } 989 } 990 } 991 } 993 6. IANA Considerations 995 This document requests IANA to register the following URI in the 996 "IETF XML Registry" RFC 3688 [RFC3688]: 998 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-trust-enhanced- 999 monitoring-interface Registrant Contact: The IESG. 1001 XML: N/A; the requested URI is an XML namespace. 1003 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-trust-enhanced- 1004 registration-interface Registrant Contact: The IESG. 1006 XML: N/A; the requested URI is an XML namespace. 1008 This document requests IANA to register the following YANG module in 1009 the "YANG Module Names" registry RFC 7950 [RFC7950] RFC 8525 1010 [RFC8525]: 1012 Name: ietf-i2nsf-trsut-enhanced-monitoring-interface 1013 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-trust-enhanced- 1014 monitoring-interface 1016 Prefix: nsftemi 1018 Reference: RFC XXXX 1020 Name: ietf-i2nsf-trsut-enhanced-registration-interface 1022 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-trust-enhanced- 1023 registration-interface 1025 Prefix: nsfteri 1027 Reference: RFC XXXX 1029 7. Security Considerations 1031 This document introduces the basic architecture of trust enhanced 1032 I2NSF and designs related interfaces. Different RoT architectures 1033 have different trust ability, and the Security Controller will 1034 determine if it will trust these remote attestation results by policy 1035 rules. These policy rules are out of scope of this document. The 1036 trust enhanced interfaces need to be protected by secure channel when 1037 transmission occurs. Meanwhile, the remote attestation results in 1038 trust enhanced interfaces are protected by their own mechanisms like 1039 TPM signature or token. 1041 8. References 1043 8.1. Normative Reference 1045 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 1046 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 1047 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 1048 Model", Work in Progress, Internet-Draft, draft-ietf- 1049 i2nsf-nsf-monitoring-data-model-12, 17 November 2021, 1050 . 1053 [I-D.ietf-rats-architecture] 1054 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 1055 W. Pan, "Remote Attestation Procedures Architecture", Work 1056 in Progress, Internet-Draft, draft-ietf-rats-architecture- 1057 13, 8 November 2021, . 1060 [I-D.ietf-rats-eat] 1061 Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity 1062 Attestation Token (EAT)", Work in Progress, Internet- 1063 Draft, draft-ietf-rats-eat-11, 24 October 2021, 1064 . 1067 [I-D.ietf-rats-tpm-based-network-device-attest] 1068 Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- 1069 based Network Device Remote Integrity Verification", Work 1070 in Progress, Internet-Draft, draft-ietf-rats-tpm-based- 1071 network-device-attest-09, 18 November 2021, 1072 . 1075 [I-D.ietf-rats-yang-tpm-charra] 1076 Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen, 1077 B., (Frank), L. X., Laffey, T., and G. C. Fedorkow, "A 1078 YANG Data Model for Challenge-Response-based Remote 1079 Attestation Procedures using TPMs", Work in Progress, 1080 Internet-Draft, draft-ietf-rats-yang-tpm-charra-11, 26 1081 August 2021, . 1084 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1085 Requirement Levels", BCP 14, RFC 2119, 1086 DOI 10.17487/RFC2119, March 1997, 1087 . 1089 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1090 DOI 10.17487/RFC3688, January 2004, 1091 . 1093 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1094 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1095 . 1097 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1098 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1099 . 1101 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1102 Kumar, "Framework for Interface to Network Security 1103 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 1104 . 1106 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1107 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1108 May 2018, . 1110 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 1111 and R. Wilton, "YANG Library", RFC 8525, 1112 DOI 10.17487/RFC8525, March 2019, 1113 . 1115 8.2. Informative Reference 1117 [SGX] Intel, "Overview of Intel Software Guard Extension", June 1118 2016, 1119 . 1122 [TCGRoT] Trust Computing Group, "DRAFT: TCG Roots of Trust 1123 Specification", October 2018, 1124 . 1127 [TEE] Global Platform Technology, "Global Platform Technology 1128 TEE System Architecture Version 1.2", December 2018, 1129 . 1132 [tpm12] Trusted Computing Group, "TPM Main Specification Level 2 1133 Version 1.2, Revision 116", March 2011, 1134 . 1137 [tpm20] Trusted Computing Group, "Trusted Platform Module Library 1138 Specification, Family "2.0", Level 00, Revision 01.59", 1139 November 2019, 1140 . 1143 Authors' Addresses 1145 Penglin Yang (editor) 1146 China Mobile 1147 32 Xuanwumen West Street, Xicheng District 1148 Beijing 1149 100053 1150 China 1152 Email: yangpenglin@chinamobile.com 1153 Meilin Chen (editor) 1154 China Mobile 1155 32 Xuanwumen West Street, Xicheng District 1156 Beijing 1157 100053 1158 China 1160 Email: chenmeiling@chinamobile.com 1162 Li Su (editor) 1163 China Mobile 1164 32 Xuanwumen West Street, Xicheng District 1165 Beijing 1166 100053 1167 China 1169 Email: suli@chinamobile.com