I2NSF Working Group P.Y. Yang, Ed. Internet-Draft M.C. Chen, Ed. Intended status: Informational L.S. Su, Ed. Expires: 4 June 2022 China Mobile December 2021 Trust Enhanced I2NSF draft-yang-i2nsf-trust-enhanced-i2nsf-00 Abstract This document describes the architecture of Trust Enhanced I2NSF. In this architecture, technologies like TPM [tpm12][tpm20] and [TCGRoT] will act as RoT (root of trust), integrity measurement and remote attestation will be used to enhance the trustworthiness of NSF. Relevant interfaces of Trust Enhanced I2NSF will also be illustrated in this document. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 June 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. Yang, et al. Expires 4 June 2022 [Page 1] Internet-Draft Abbreviated Title December 2021 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 3. Scope and Motivation . . . . . . . . . . . . . . . . . . . . 3 3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 4. Information Model . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Architecture of Trust Enhanced I2NSF . . . . . . . . . . 4 4.2. Root of Trust . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Verifier/Relying Party . . . . . . . . . . . . . . . . . 6 4.4. Reference Value Provider . . . . . . . . . . . . . . . . 6 4.5. Endorser . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Data Model of Trust Enhanced I2NSF . . . . . . . . . . . . . 7 5.1. Trust Enhanced NSF Monitoring interface . . . . . . . . . 7 5.1.1. Yang Tree Diagram of Trust Enhanced NSF Monitoring Interface . . . . . . . . . . . . . . . . . . . . . . 7 5.1.2. Yang Data Model of Trust Enhanced NSF Monitoring Interface . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Trust Enhanced Registration interface . . . . . . . . . . 19 5.2.1. Yang Tree Diagram of Trust Enhanced Registration interface . . . . . . . . . . . . . . . . . . . . . . 19 5.2.2. Yang Data Model of Trust Enhanced Registration interface . . . . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 23 8.2. Informative Reference . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction NSF is always used in remote scenarios, in which it is hard to guarantee the deployment environment is security and the NSF is properly deployed. If the deployment environment or the NSF is compromised, the behavior and the feedback of NSF cannot be trusted. Yang, et al. Expires 4 June 2022 [Page 2] Internet-Draft Abbreviated Title December 2021 Trusted computing technology like TPM, TEE[TEE] could provide a root of trust based on hardware in deployment environment. Trusted computing hardware usually retains a pair of root key, which could be used to sign signature for the measurement of development environment and the NSF image. Then the signed result will be sent to the NSF manager to estimate if the NSF is well deployed. The RATs architecture[I-D.ietf-rats-architecture] has defined this remote attestation process which could be introduced to I2NSF. Since the RATs architecture is a general architecture, specific interface and implementation still need to be determined in I2NSF. This draft aims to create a unified trust enhanced I2NSF architecture to promote the security of NSF 2. Terminology 2.1. Terms RATs: Remote Attestation Procedure RoT: Root of Trust TPM: Trusted platform module TEE: Trust Execution Environment 2.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Scope and Motivation 3.1. Scope The scope of this draft mainly focuses on the expanded interfaces of trust enhanced I2NSF. The specific of how to implement measurement or how to make remote attestation evidence is out of scope. 3.2. Motivation The architecture of I2NSF [RFC8329] aims to provide network security functions to network users. Often, the users are in remote environment, and the platform to deploy these network security functions may not be trusted. As a consequence, this will bring several severe threats to the NSF. The first one is malfunction of NSF. The inappropriate deployment of NSF or the defective platform Yang, et al. Expires 4 June 2022 [Page 3] Internet-Draft Abbreviated Title December 2021 will affect the process of NSF directly. The second threat is the leak of policy rules and core asset of security knowledge. If there has malware in the remote environment, it will be hard to prevent the leakage. The third threat is the potential spoofing attack to the NSF architecture. Adversary could use the compromised NSF to feedback spoofing information or other attacking information to attack or penetrate the NSF architecture. The solution of these threats is also straight, which is using remote attestation to make sure the remote platform is trusted and the NSF is well deployed. The RATs group in IETF defines architecture and some specifications of remote attestation procedure. However brings the RATs in I2NSF still needs some work. First, need to define the trsut enhanced architecture. Second, need to refer the appropriate specifications defined in RATs to create trust enhanced NSF interfaces. Third, need to cover the heterogeneous architecture of specific trust architecture like TPM and TEE. 4. Information Model 4.1. Architecture of Trust Enhanced I2NSF Yang, et al. Expires 4 June 2022 [Page 4] Internet-Draft Abbreviated Title December 2021 +--------------+ +--------------+ | | | | | NSF User | +-------------+ Endorser | | | | | | +------+-------+ | +--------------+ | | | | +-------------------+ | | +------+-------+ +--------------+ | | | | | Security +-------------------------+ Developer's | | Controller | | Mgnt System | +-+----------+-+ +-+----------+-+ | Verifier/| | Reference| | Relying | | Value | | Party | | Provider | +----+-----+ +----------+ | | +-------------------+---------------------+ | | | +------+-------+ +------+-------+ +------+-------+ | | | | | | | NSF1 + | NSF2 | | NSFn | | | | | | | +--+--------+--+ +--+--------+--+ +--+--------+--+ | RoT | | RoT | | RoT | | | | | | | +--------+ +--------+ +--------+ Figure 1: architecture of Trust Enhanced I2NSF As shown in figure one is the trust enhanced I2NSF architecture. In this architecture, several new components are introduced to NSF. The first component is RoT which is deployed in the hardware platform of NSF. The second component is Verifier/Relying Party, which is deployed as part of Security Controller. This component is in charge of verifying if the attestation value is complied with the reference value. The third component is the Reference Value Provider, which will bring the reference value of NSF image and deployment environment to Security Controller. The fourth component is Endorser, which will provie the endorsement of RoT. And the verifier could use Endorser to verify the endorsement status of RoT. Yang, et al. Expires 4 June 2022 [Page 5] Internet-Draft Abbreviated Title December 2021 4.2. Root of Trust Root of Trust is a hardware-based component that could provide information and certain function that cannot be stolen, tampered, or repudiation. RoT MUST be deployed in the NSF hardware platform. The NSF with RoT composes the rule of attester. The architecture of specific RoT is out of scope of this document. But in order to clarify RoT more clearly, the following segment uses TPM as an example to illustrate. TPM keeps EK(Endorsement Key ) to identify its identity. EK is an asymmetric key pair, which will never expose its secret key to public. TPM also derives certain AIKs(Attestation Identity Key) from EK to avoid the exposure of TPM's real identity(EK). Meanwhile, TPM contains a reference Hash value of the boot component of platform. When launching a remote attestation procedure, the TPM will first measure the boot component of platform. Based on the trust policy the TPM will choose if trust the boot component and transfer the system control to the boot component. The boot component then will measure the operating system kernel and compare it to the reference value, and so on. During this trusted measurement process, the TPM will record the measurement Hash result in a series of registers called PCRs. If a remote attestation procedure is initiated, the measurement Hash result will be signed by AIK. In the end, remote attestation procedure will send this signed Hash result and measurement result to the verifier. The specific procedure could refer to[I-D.ietf-rats-tpm-based-network-device-attest], which illustrates how integrity verification works inside a device. 4.3. Verifier/Relying Party The Verifier/Relying Party is deployed in Security Controller. In the original architecture of RATs, Verifier and Relying Party could be different components. Verifier is in charge of verifying the remote attestation results from attester. The Relying Party is in charge of appraising the verification result from Verifier. This means that the Relying Party does not have to know the detail of remote attestation result and could only focus on the final verification result and make policies. While in NSF, both the role of Verifier and Relying Party will be included in Security Controller to reduce the complexity. 4.4. Reference Value Provider The Developer's Mgnt System is in charge of providing reference value of NSF and the deployment platform. The reference value will be conveyed to Security Controller as the benchmark when verifying remote attestation value from attester. Yang, et al. Expires 4 June 2022 [Page 6] Internet-Draft Abbreviated Title December 2021 4.5. Endorser The Endorser is in charge of providing endorsement to RoT, both EK and AIK are related to Endorser. The communication between RoT and Endorser is out of scope of this document, but the Security Controller needs to communicate with Endorser to verify remote attestation message. 5. Data Model of Trust Enhanced I2NSF Two interfaces are involved in trust enhanced I2NSF, Trust Enhanced NSF Monitoring Interface and Trust Enhanced Registration Interface. 5.1. Trust Enhanced NSF Monitoring interface The TENMI (Trust Enhanced NSF Monitoring Interface) focuses on the remote attestation procedure between NSF and security controller. This interface will be an extended feature of NSF Monitoring Interface and will fully comply with NSF Monitoring Interface[I-D.ietf-i2nsf-nsf-monitoring-data-model]. Based on the information transmission type, the TENMI has three Yang types: system events, system logs and RPC. The system event is responsible for the NSF event that will trigger the remote attestation of NSF. And the event could be platform booting, measurement result change, NSF deploy, etc. The system logs is responsible for the periodic remote attestation. The third type is RPC in where the Verifier (Security Controller) will challenge the attester (NSF) for its trustworthiness initiatively. At present, the RoT type now are split in two category, one is TPM- based and the other is general TEE-based like Trust Zone. It can be expected that other trsuted computing architectures like Intel SGX [SGX] may also be involved in the near future. And also the TPM- based RoT is split in TPM12 and TPM20 versions respectively. When design this interface with TPM-based RoT, this document tries to refer to the existing document[I-D.ietf-rats-yang-tpm-charra] as much as possible to avoid unnecessary alignment work. And about the general TEE-based RoT, this document refers to the EAT document[I-D.ietf-rats-eat] and uses string type to express JWT[RFC7519]or CWT [RFC8392]. 5.1.1. Yang Tree Diagram of Trust Enhanced NSF Monitoring Interface The Yang tree of Trust Enhanced NSF Monitoring Interface is shown below. Yang, et al. Expires 4 June 2022 [Page 7] Internet-Draft Abbreviated Title December 2021 module: ietf-i2nsf-nsf-trust-enhanced-monitoring rpcs: +---x nsf-challenge-response-attestation +---w input | +---w (RoT-type)? | +--:(TPM12) | | +---w tpm12-rpc | | +---w pcr-index* pcr | | +---w nonce-value binary | | +---w certificate-name* tpm:certificate-name-ref {tpm:tpms}? | +--:(TPM20) | | +---w tpm20-pcr | | +---w nonce-value binary | | +---w tpm20-pcr-selection* [] | | | +---w tpm20-hash-algo? identityref | | | +---w pcr-index* pcr | | +---w certificate-name* tpm:certificate-name-ref {tpm:tpms}? | +--:(TEE-general) | +---w nonce? binary | +---w certificate-name? string +--ro output +--ro (RoT-type)? +--:(TPM12) | +--ro tpm12-log | +--ro name? string | +--ro up-time? uint32 | +--ro (attested_event_log_type) | +--:(bios) {bios}? | | +--ro bios-event-logs | | +--ro bios-event-entry* [event-number] | | +--ro event-number uint32 | | +--ro event-type? uint32 | | +--ro pcr-index? pcr | | +--ro digest-list* [hash-alog] | | | +--ro hash-algo? identityref | | | +--ro digest* binary | | +--ro event-size? uint32 | | +--ro event-data* uint8 | +--:(ima) {ima}? | | +--ro ima-event-logs | | +--ro ima-event-entry* [event-number] | | +--ro event-number uint64 | | +--ro ima-template? string | | +--ro filename-hint? string | | +--ro filedata-hash? binary | | +--ro filedata-hash-algorithm? string | | +--ro template-hash-algorithm? string | | +--ro template-hash? binary Yang, et al. Expires 4 June 2022 [Page 8] Internet-Draft Abbreviated Title December 2021 | | +--ro pcr-index? pcr | | +--ro signature? binary | +--:(netequip_boot) {netequip_boot}? | +--ro boot-event-logs | +--ro boot-event-entry* [event-number] | +--ro event-number uint64 | +--ro ima-template? string | +--ro filename-hint? string | +--ro filedata-hash? binary | +--ro filedata-hash-algorithm? string | +--ro template-hash-algorithm? string | +--ro template-hash? binary | +--ro pcr-index? pcr | +--ro signature? binary +--:(TPM20) | +--ro tpm20-log | +--ro name? string | +--ro up-time? uint32 | +--ro (attested_event_log_type) | +--:(bios) {bios}? | | +--ro bios-event-logs | | +--ro bios-event-entry* [event-number] | | +--ro event-number uint32 | | +--ro event-type? uint32 | | +--ro pcr-index? pcr | | +--ro digest-list* [hash-alog] | | | +--ro hash-algo? identityref | | | +--ro digest* binary | | +--ro event-size? uint32 | | +--ro event-data* uint8 | +--:(ima) {ima}? | | +--ro ima-event-logs | | +--ro ima-event-entry* [event-number] | | +--ro event-number uint64 | | +--ro ima-template? string | | +--ro filename-hint? string | | +--ro filedata-hash? binary | | +--ro filedata-hash-algorithm? string | | +--ro template-hash-algorithm? string | | +--ro template-hash? binary | | +--ro pcr-index? pcr | | +--ro signature? binary | +--:(netequip_boot) {netequip_boot}? | +--ro boot-event-logs | +--ro boot-event-entry* [event-number] | +--ro event-number uint64 | +--ro ima-template? string | +--ro filename-hint? string Yang, et al. Expires 4 June 2022 [Page 9] Internet-Draft Abbreviated Title December 2021 | +--ro filedata-hash? binary | +--ro filedata-hash-algorithm? string | +--ro template-hash-algorithm? string | +--ro template-hash? binary | +--ro pcr-index? pcr | +--ro signature? binary +--:(TEE-general) +--ro (token-type)? +--:(cwt) | +--ro eat-header-cwt? string | +--ro eat-payload-cwt? string | +--ro eat-signature-cwt? string +--:(jwt) +--ro eat-header-jwt? string +--ro eat-payload-jwt? string +--ro eat-signature-jwt? string notifications: +---n i2nsf-trust-enhanced-event | +--ro hardware-type string | +--ro operating-system-type string | +--ro acquisition-method? identityref | +--ro emission-type? identityref | +--ro dampening-type? identityref | +--ro user string | +--ro group* string | +--ro ip-address inet:ip-address | +--ro authentication? identityref | +--ro message? string | +--ro vendor-name? string | +--ro nsf-name? union | +--ro severity? severity | +--ro (RoT-type)? | +--:(TPM12) | | +--ro tpm12-nsf-rats {taa:tpm12}? | | +--ro certificate-name certificate-name-ref | | +--ro up-time? uint32 | | +--ro TPM_QUOTE2? binary | +--:(TPM20) | | +--ro tpm20-nsf-rats {taa:tpm20}? | | +--ro certificate-name certificate-name-ref | | +--ro TPMS_QUOTE_INFO binary | | +--ro quote-signature? binary | | +--ro up-time? uint32 | | +--ro unsigned-pcr-values* [] | | +--ro tpm20-hash-algo? identityref | | +--ro pcr-values* [pcr-index] | | +--ro pcr-index pcr Yang, et al. Expires 4 June 2022 [Page 10] Internet-Draft Abbreviated Title December 2021 | | +--ro pcr-value? binary | +--:(TEE-general) | +--ro (token-type)? | +--:(cwt) | | +--ro eat-header-cwt? string | | +--ro eat-payload-cwt? string | | +--ro eat-signature-cwt? string | +--:(jwt) | +--ro eat-header-jwt? string | +--ro eat-payload-jwt? string | +--ro eat-signature-jwt? string +---n i2nsf-trsut-enhanced-log +--ro message? string +--ro vendor-name? string +--ro nsf-name? union +--ro severity? severity +--ro (RoT-type)? +--:(TPM12) | +--ro tpm12-log | +--ro name? string | +--ro up-time? uint32 | +--ro (attested_event_log_type) | +--:(bios) {bios}? | | +--ro bios-event-logs | | +--ro bios-event-entry* [event-number] | | +--ro event-number uint32 | | +--ro event-type? uint32 | | +--ro pcr-index? pcr | | +--ro digest-list* [hash-alog] | | | +--ro hash-algo? identityref | | | +--ro digest* binary | | +--ro event-size? uint32 | | +--ro event-data* uint8 | +--:(ima) {ima}? | | +--ro ima-event-logs | | +--ro ima-event-entry* [event-number] | | +--ro event-number uint64 | | +--ro ima-template? string | | +--ro filename-hint? string | | +--ro filedata-hash? binary | | +--ro filedata-hash-algorithm? string | | +--ro template-hash-algorithm? string | | +--ro template-hash? binary | | +--ro pcr-index? pcr | | +--ro signature? binary | +--:(netequip_boot) {netequip_boot}? | +--ro boot-event-logs | +--ro boot-event-entry* [event-number] Yang, et al. Expires 4 June 2022 [Page 11] Internet-Draft Abbreviated Title December 2021 | +--ro event-number uint64 | +--ro ima-template? string | +--ro filename-hint? string | +--ro filedata-hash? binary | +--ro filedata-hash-algorithm? string | +--ro template-hash-algorithm? string | +--ro template-hash? binary | +--ro pcr-index? pcr | +--ro signature? binary +--:(TPM20) | +--ro tpm20-log | +--ro name? string | +--ro up-time? uint32 | +--ro (attested_event_log_type) | +--:(bios) {bios}? | | +--ro bios-event-logs | | +--ro bios-event-entry* [event-number] | | +--ro event-number uint32 | | +--ro event-type? uint32 | | +--ro pcr-index? pcr | | +--ro digest-list* [hash-alog] | | | +--ro hash-algo? identityref | | | +--ro digest* binary | | +--ro event-size? uint32 | | +--ro event-data* uint8 | +--:(ima) {ima}? | | +--ro ima-event-logs | | +--ro ima-event-entry* [event-number] | | +--ro event-number uint64 | | +--ro ima-template? string | | +--ro filename-hint? string | | +--ro filedata-hash? binary | | +--ro filedata-hash-algorithm? string | | +--ro template-hash-algorithm? string | | +--ro template-hash? binary | | +--ro pcr-index? pcr | | +--ro signature? binary | +--:(netequip_boot) {netequip_boot}? | +--ro boot-event-logs | +--ro boot-event-entry* [event-number] | +--ro event-number uint64 | +--ro ima-template? string | +--ro filename-hint? string | +--ro filedata-hash? binary | +--ro filedata-hash-algorithm? string | +--ro template-hash-algorithm? string | +--ro template-hash? binary | +--ro pcr-index? pcr Yang, et al. Expires 4 June 2022 [Page 12] Internet-Draft Abbreviated Title December 2021 | +--ro signature? binary +--:(TEE-general) +--ro (token-type)? +--:(cwt) | +--ro eat-header-cwt? string | +--ro eat-payload-cwt? string | +--ro eat-signature-cwt? string +--:(jwt) +--ro eat-header-jwt? string +--ro eat-payload-jwt? string +--ro eat-signature-jwt? string 5.1.2. Yang Data Model of Trust Enhanced NSF Monitoring Interface The Yang Model of Trust Enhanced NSF Monitoring Interface is shown below. module ietf-i2nsf-nsf-trust-enhanced-monitoring { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-trust-enhanced-monitoring"; prefix nsftemi; import ietf-i2nsf-nsf-monitoring{ prefix nsfmi; reference "reference of nsf monitoring interface"; } import ietf-tcg-algs{ prefix taa; } import ietf-tpm-remote-attestation{ prefix tpm; } organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; contact "WG Web: WG List: Editor: Penglin Yang "; description "This module is a YANG module for I2NSF NSF Trust Enhanced Monitoring."; identity RoT-type{ description Yang, et al. Expires 4 June 2022 [Page 13] Internet-Draft Abbreviated Title December 2021 "RoT have different types, like TPM, TEE, SGX, etc."; } identity certificate-name-ref{ description "refer to tpm"; } identity TPM12{ description "RoT type is TPM1.2"; } identity TPM20{ description "RoT type is TPM2.0"; } identity TEE-general{ description "RoT type is TEE general"; } identity cwt{ description "cbor web token for remote attestation"; } identity jwt{ description "json web token for remote attestation"; } grouping nsf-remote-attestation{ choice RoT-type{ case TPM12{ container tpm12-nsf-rats{ if-feature "taa:tpm12"; description "since this message was triggered by event, so there is no input from RPC. The pcr value is provided by device automatically, the nonce value NEED to be replaced by the event time"; uses tpm:certificate-name-ref; uses tpm:tpm12-attestation; } } case TPM20{ container tpm20-nsf-rats{ if-feature "taa:tpm20"; description "since this message was triggered by event, so there is no input from RPC. The pcr value is provided by device automatically, the nonce value NEED to be repalced by the event time"; uses tpm:certificate-name-ref; Yang, et al. Expires 4 June 2022 [Page 14] Internet-Draft Abbreviated Title December 2021 uses tpm:tpm20-attestation; } } case TEE-general{ description "if the RoT is not TPM, or not specify the detail format, then uses EAT as the reference of the attestation result at present. The information includes: token-id; time-stamp; nonce; hardware-version; software-description-version; security-level-claim; secure-boot-claim; including-keys; location-claim; uptime-claim; boot-seed-claim; intended-use-claim; profile-claim; software-manifest-claim; software-evidence-claim"; //how describe cwt or jwt in Yang, string? choice token-type{ case cwt{ leaf eat-header-cwt{ type string; } leaf eat-payload-cwt{ type string; } leaf eat-signature-cwt{ type string; } } case jwt{ leaf eat-header-jwt{ type string; } leaf eat-payload-jwt{ type string; } leaf eat-signature-jwt{ type string; } } } } } } grouping TEE-general-log{ description "describe the TEE general log."; choice token-type{ case cwt{ leaf eat-header-cwt{ type string; } Yang, et al. Expires 4 June 2022 [Page 15] Internet-Draft Abbreviated Title December 2021 leaf eat-payload-cwt{ type string; } leaf eat-signature-cwt{ type string; } } case jwt{ leaf eat-header-jwt{ type string; } leaf eat-payload-jwt{ type string; } leaf eat-signature-jwt{ type string; } } } } grouping remote-attestation-log{ description "describe different kind of log"; choice RoT-type{ case TPM12{ description "log recorded under the rule of TPM12"; container tpm12-log{ uses tpm:tpm-name; uses tpm:node-uptime; uses tpm:event-logs; } } case TPM20{ description "log recorded under the rule of TPM20"; container tpm20-log{ uses tpm:tpm-name; uses tpm:node-uptime; uses tpm:event-logs; } } case TEE-general{ description "log recorded under the rule of EAT"; uses TEE-general-log; } Yang, et al. Expires 4 June 2022 [Page 16] Internet-Draft Abbreviated Title December 2021 } } notification i2nsf-trust-enhanced-event{ description "Notification for I2NSF trust enhanced Event."; leaf hardware-type{ mandatory true; type string; } leaf operating-system-type{ mandatory true; type string; } uses nsfmi:characteristics; uses nsfmi:i2nsf-system-event-type-content; uses nsfmi:common-monitoring-data; uses nsftemi:nsf-remote-attestation; } notification i2nsf-trsut-enhanced-log{ description "This notification is for integrity measurement log, which does not have to be responsed immediately"; uses nsfmi:common-monitoring-data; uses remote-attestation-log; } rpc nsf-challenge-response-attestation{ description "this is the unified rpc for trust enhanced nsf"; input{ choice RoT-type{ case TPM12{ container tpm12-rpc{ uses tpm:tpm12-pcr-selection; uses tpm:nonce; leaf-list certificate-name { if-feature "tpm:tpms"; type tpm:certificate-name-ref; must "/tpm:rats-support-structures/tpm:tpms" + "/tpm:tpm[tpm:firmware-version='taa:tpm12']" + "/tpm:certificates/" + "/tpm:certificate[name=current()]" { error-message "Not an available TPM1.2 AIK certificate."; } description Yang, et al. Expires 4 June 2022 [Page 17] Internet-Draft Abbreviated Title December 2021 "When populated, the RPC will only get a Quote for the TPMs associated with these certificate(s)."; } } } case TPM20{ container tpm20-pcr{ uses tpm:nonce; uses tpm:tpm20-pcr-selection; leaf-list certificate-name { if-feature "tpm:tpms"; type tpm:certificate-name-ref; must "/tpm:rats-support-structures/tpm:tpms" + "/tpm:tpm[tpm:firmware-version='taa:tpm20']" + "/tpm:certificates/" + "/tpm:certificate[name=current()]" { error-message "Not an available TPM2.0 AIK certificate."; } description "When populated, the RPC will only get a Quote for the TPMs associated with the certificates."; } } } case TEE-general{ description "there is no standard to reference"; leaf nonce{ type binary; } leaf certificate-name{ type string; } } } } output{ uses remote-attestation-log; } } } Yang, et al. Expires 4 June 2022 [Page 18] Internet-Draft Abbreviated Title December 2021 5.2. Trust Enhanced Registration interface The reference value of a NSF needs to be conveyed by trust enhanced registration interface. The interface works between Security Controller and Developer's Management System. (One trivial thing needs to point out is that when refer to event-logs in ietf-tpm- remote-attestation in data node, the list of "digest-list" needs to define a key value. This condition determines future alignment with [I-D.ietf-rats-yang-tpm-charra]. ) 5.2.1. Yang Tree Diagram of Trust Enhanced Registration interface module: ietf-i2nsf-nsf-trust-enhanced-registration-interface +--rw reference-value-register +--rw nsf-name string +--rw hardware-type string +--rw operating-system-type string +--rw (RoT-type)? +--:(TPM12) | +--rw tpm12-ref | +--rw (attested_event_log_type) | +--:(bios) {bios}? | | +--rw bios-event-logs | | +--rw bios-event-entry* [event-number] | | +--rw event-number uint32 | | +--rw event-type? uint32 | | +--rw pcr-index? pcr | | +--rw digest-list* [hash-alog] | | | +--rw hash-algo? identityref | | | +--rw digest* binary | | +--rw event-size? uint32 | | +--rw event-data* uint8 | +--:(ima) {ima}? | | +--rw ima-event-logs | | +--rw ima-event-entry* [event-number] | | +--rw event-number uint64 | | +--rw ima-template? string | | +--rw filename-hint? string | | +--rw filedata-hash? binary | | +--rw filedata-hash-algorithm? string | | +--rw template-hash-algorithm? string | | +--rw template-hash? binary | | +--rw pcr-index? pcr | | +--rw signature? binary | +--:(netequip_boot) {netequip_boot}? | +--rw boot-event-logs | +--rw boot-event-entry* [event-number] | +--rw event-number uint64 Yang, et al. Expires 4 June 2022 [Page 19] Internet-Draft Abbreviated Title December 2021 | +--rw ima-template? string | +--rw filename-hint? string | +--rw filedata-hash? binary | +--rw filedata-hash-algorithm? string | +--rw template-hash-algorithm? string | +--rw template-hash? binary | +--rw pcr-index? pcr | +--rw signature? binary +--:(TPM20) | +--rw tpm20-ref | +--rw (attested_event_log_type) | +--:(bios) {bios}? | | +--rw bios-event-logs | | +--rw bios-event-entry* [event-number] | | +--rw event-number uint32 | | +--rw event-type? uint32 | | +--rw pcr-index? pcr | | +--rw digest-list* [hash-alog] | | | +--rw hash-algo? identityref | | | +--rw digest* binary | | +--rw event-size? uint32 | | +--rw event-data* uint8 | +--:(ima) {ima}? | | +--rw ima-event-logs | | +--rw ima-event-entry* [event-number] | | +--rw event-number uint64 | | +--rw ima-template? string | | +--rw filename-hint? string | | +--rw filedata-hash? binary | | +--rw filedata-hash-algorithm? string | | +--rw template-hash-algorithm? string | | +--rw template-hash? binary | | +--rw pcr-index? pcr | | +--rw signature? binary | +--:(netequip_boot) {netequip_boot}? | +--rw boot-event-logs | +--rw boot-event-entry* [event-number] | +--rw event-number uint64 | +--rw ima-template? string | +--rw filename-hint? string | +--rw filedata-hash? binary | +--rw filedata-hash-algorithm? string | +--rw template-hash-algorithm? string | +--rw template-hash? binary | +--rw pcr-index? pcr | +--rw signature? binary +--:(TEE-generic) +--rw (token-type)? Yang, et al. Expires 4 June 2022 [Page 20] Internet-Draft Abbreviated Title December 2021 +--:(cwt) | +--rw eat-header-cwt? string | +--rw eat-payload-cwt? string | +--rw eat-signature-cwt? string +--:(jwt) +--rw eat-header-jwt? string +--rw eat-payload-jwt? string +--rw eat-signature-jwt? string 5.2.2. Yang Data Model of Trust Enhanced Registration interface The Yang Model of Trust Enhanced Registration Interface is shown below. module ietf-i2nsf-nsf-trust-enhanced-registration-interface { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-trust-enhanced-registration-interface"; prefix nsfteri; import ietf-tpm-remote-attestation{ prefix tpm; } import ietf-i2nsf-nsf-trust-enhanced-monitoring{ prefix nsftemi; } organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; contact "WG Web: WG List: Editor: Penglin Yang "; description "This module is a YANG module for I2NSF NSF Trust Enhanced Registration Interface."; container reference-value-register{ description "the reference value is for nsf"; leaf nsf-name{ type string; mandatory true; description "The name of nsf"; } Yang, et al. Expires 4 June 2022 [Page 21] Internet-Draft Abbreviated Title December 2021 leaf hardware-type{ mandatory true; type string; } leaf operating-system-type{ mandatory true; type string; } choice RoT-type{ case TPM12{ container tpm12-ref{ uses tpm:event-logs; } } case TPM20{ container tpm20-ref{ uses tpm:event-logs; } } case TEE-generic{ uses nsftemi:TEE-general-log; } } } } 6. IANA Considerations This document requests IANA to register the following URI in the "IETF XML Registry" RFC 3688 [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-trust-enhanced- monitoring-interface Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-trust-enhanced- registration-interface Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document requests IANA to register the following YANG module in the "YANG Module Names" registry RFC 7950 [RFC7950] RFC 8525 [RFC8525]: Name: ietf-i2nsf-trsut-enhanced-monitoring-interface Yang, et al. Expires 4 June 2022 [Page 22] Internet-Draft Abbreviated Title December 2021 Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-trust-enhanced- monitoring-interface Prefix: nsftemi Reference: RFC XXXX Name: ietf-i2nsf-trsut-enhanced-registration-interface Namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-trust-enhanced- registration-interface Prefix: nsfteri Reference: RFC XXXX 7. Security Considerations This document introduces the basic architecture of trust enhanced I2NSF and designs related interfaces. Different RoT architectures have different trust ability, and the Security Controller will determine if it will trust these remote attestation results by policy rules. These policy rules are out of scope of this document. The trust enhanced interfaces need to be protected by secure channel when transmission occurs. Meanwhile, the remote attestation results in trust enhanced interfaces are protected by their own mechanisms like TPM signature or token. 8. References 8.1. Normative Reference [I-D.ietf-i2nsf-nsf-monitoring-data-model] Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. Birkholz, "I2NSF NSF Monitoring Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietf- i2nsf-nsf-monitoring-data-model-12, 17 November 2021, . [I-D.ietf-rats-architecture] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote Attestation Procedures Architecture", Work in Progress, Internet-Draft, draft-ietf-rats-architecture- 13, 8 November 2021, . Yang, et al. Expires 4 June 2022 [Page 23] Internet-Draft Abbreviated Title December 2021 [I-D.ietf-rats-eat] Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity Attestation Token (EAT)", Work in Progress, Internet- Draft, draft-ietf-rats-eat-11, 24 October 2021, . [I-D.ietf-rats-tpm-based-network-device-attest] Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- based Network Device Remote Integrity Verification", Work in Progress, Internet-Draft, draft-ietf-rats-tpm-based- network-device-attest-09, 18 November 2021, . [I-D.ietf-rats-yang-tpm-charra] Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen, B., (Frank), L. X., Laffey, T., and G. C. Fedorkow, "A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs", Work in Progress, Internet-Draft, draft-ietf-rats-yang-tpm-charra-11, 26 August 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, "Framework for Interface to Network Security Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, . Yang, et al. Expires 4 June 2022 [Page 24] Internet-Draft Abbreviated Title December 2021 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., and R. Wilton, "YANG Library", RFC 8525, DOI 10.17487/RFC8525, March 2019, . 8.2. Informative Reference [SGX] Intel, "Overview of Intel Software Guard Extension", June 2016, . [TCGRoT] Trust Computing Group, "DRAFT: TCG Roots of Trust Specification", October 2018, . [TEE] Global Platform Technology, "Global Platform Technology TEE System Architecture Version 1.2", December 2018, . [tpm12] Trusted Computing Group, "TPM Main Specification Level 2 Version 1.2, Revision 116", March 2011, . [tpm20] Trusted Computing Group, "Trusted Platform Module Library Specification, Family "2.0", Level 00, Revision 01.59", November 2019, . Authors' Addresses Penglin Yang (editor) China Mobile 32 Xuanwumen West Street, Xicheng District Beijing 100053 China Email: yangpenglin@chinamobile.com Yang, et al. Expires 4 June 2022 [Page 25] Internet-Draft Abbreviated Title December 2021 Meilin Chen (editor) China Mobile 32 Xuanwumen West Street, Xicheng District Beijing 100053 China Email: chenmeiling@chinamobile.com Li Su (editor) China Mobile 32 Xuanwumen West Street, Xicheng District Beijing 100053 China Email: suli@chinamobile.com Yang, et al. Expires 4 June 2022 [Page 26]