Internet DRAFT - draft-yang-i2nsf-trust-enhanced-i2nsf
draft-yang-i2nsf-trust-enhanced-i2nsf
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: <http://tools.ietf.org/wg/i2nsf>
WG List: <mailto:i2nsf@ietf.org>
Editor: Penglin Yang
<mailto:yangpenglin@chinamobile.com>";
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: <http://tools.ietf.org/wg/i2nsf>
WG List: <mailto:i2nsf@ietf.org>
Editor: Penglin Yang
<mailto:yangpenglin@chinamobile.com>";
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,
<https://www.ietf.org/archive/id/draft-ietf-i2nsf-nsf-
monitoring-data-model-12.txt>.
[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, <https://www.ietf.org/archive/id/
draft-ietf-rats-architecture-13.txt>.
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,
<https://www.ietf.org/archive/id/draft-ietf-rats-eat-
11.txt>.
[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,
<https://www.ietf.org/archive/id/draft-ietf-rats-tpm-
based-network-device-attest-09.txt>.
[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, <https://www.ietf.org/archive/id/draft-ietf-
rats-yang-tpm-charra-11.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[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,
<https://www.rfc-editor.org/info/rfc8329>.
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, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
and R. Wilton, "YANG Library", RFC 8525,
DOI 10.17487/RFC8525, March 2019,
<https://www.rfc-editor.org/info/rfc8525>.
8.2. Informative Reference
[SGX] Intel, "Overview of Intel Software Guard Extension", June
2016,
<https://www.intel.com/content/www/us/en/developer/tools/
software-guard-extensions/overview.html>.
[TCGRoT] Trust Computing Group, "DRAFT: TCG Roots of Trust
Specification", October 2018,
<https://trustedcomputinggroup.org/wp-content/uploads/
TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf>.
[TEE] Global Platform Technology, "Global Platform Technology
TEE System Architecture Version 1.2", December 2018,
<https://globalplatform.org/specs-library/tee-system-
architecture-v1-2/>.
[tpm12] Trusted Computing Group, "TPM Main Specification Level 2
Version 1.2, Revision 116", March 2011,
<https://trustedcomputinggroup.org/resource/tpm-main-
specification/>.
[tpm20] Trusted Computing Group, "Trusted Platform Module Library
Specification, Family "2.0", Level 00, Revision 01.59",
November 2019,
<https://trustedcomputinggroup.org/resource/tpm-library-
specification/>.
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]
