Internet-Draft | YANG-CHARRA for TPMs | August 2021 |
Birkholz, et al. | Expires 27 February 2022 | [Page] |
This document defines YANG RPCs and a small number of configuration nodes required to retrieve attestation evidence about integrity measurements from a device, following the operational context defined in TPM-based Network Device Remote Integrity Verification. Complementary measurement logs are also provided by the YANG RPCs, originating from one or more roots of trust for measurement (RTMs). The module defined requires at least one TPM 1.2 or TPM 2.0 as well as a corresponding TPM Software Stack (TSS), included in the device components of the composite device the YANG server is running on.¶
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 27 February 2022.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
This document is based on the general terminology defined in the [I-D.ietf-rats-architecture] and uses the operational context defined in [I-D.ietf-rats-tpm-based-network-device-attest] as well as the interaction model and information elements defined in [I-D.ietf-rats-reference-interaction-models]. The currently supported hardware security modules (HSMs) are the Trusted Platform Modules (TPMs) [TPM1.2] and [TPM2.0] as specified by the Trusted Computing Group (TCG). One or more TPMs embedded in the components of a Composite Device are required in order to use the YANG module defined in this document. A TPM is used as a root of trust for reporting (RTR) in order to retrieve attestation Evidence from a composite device (TPM Quote primitive operation). Additionally, it is used as a root of trust for storage (RTS) in order to retain shielded secrets and store system measurements using a folding hash function (TPM PCR Extend primitive operation).¶
Specific terms imported from [I-D.ietf-rats-architecture] and used in this document include: Attester, Composite Device, Evidence.¶
Specific terms imported from [TPM2.0-Key] and used in this document include: Endorsement Key (EK), Initial Attestation Key (IAK), Local Attestation Key (LAK).¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
One or more TPMs MUST be embedded in a Composite Device that provides attestation evidence via the YANG module defined in this document. The ietf-basic-remote-attestation YANG module enables a composite device to take on the role of an Attester, in accordance with the Remote Attestation Procedures (RATS) architecture [I-D.ietf-rats-architecture], and the corresponding challenge-response interaction model defined in the [I-D.ietf-rats-reference-interaction-models] document. A fresh nonce with an appropriate amount of entropy MUST be supplied by the YANG client in order to enable a proof-of-freshness with respect to the attestation Evidence provided by the Attester running the YANG datastore. Further, this nonce is used to prevent replay attacks. The functions of this YANG module are restricted to 0-1 TPMs per hardware component.¶
In this section the several YANG modules are defined.¶
This YANG module imports modules from [RFC6991], [RFC8348], [I-D.ietf-netconf-keystore], and ietf-tcg-algs.yang
Section 2.1.2.3.¶
This module supports the following features:¶
This module supports the following types of attestation event logs: 'bios', 'ima', and 'netequip_boot'.¶
In the following, RPCs for both TPM 1.2 and TPM 2.0 attestation procedures are defined.¶
This RPC allows a Verifier to request signed TPM PCRs (TPM Quote operation) from a TPM 1.2 compliant cryptoprocessor. Where the feature 'TPMs' is active, and one or more 'certificate-name' is not provided, all TPM 1.2 compliant cryptoprocessors will respond. A YANG tree diagram of this RPC is as follows:¶
+---x tpm12-challenge-response-attestation {taa:TPM12}? +---w input | +---w tpm12-attestation-challenge | +---w pcr-index* pcr | +---w nonce-value binary | +---w certificate-name* certificate-name-ref {tpm:TPMs}? +--ro output +--ro tpm12-attestation-response* [] +--ro certificate-name certificate-name-ref +--ro up-time? uint32 +--ro TPM_QUOTE2? binary¶
This RPC allows a Verifier to request signed TPM PCRs (TPM Quote operation) from a TPM 2.0 compliant cryptoprocessor. Where the feature 'TPMs' is active, and one or more 'certificate-name' is not provided, all TPM 2.0 compliant cryptoprocessors will respond. A YANG tree diagram of this RPC is as follows:¶
+---x tpm20-challenge-response-attestation {taa:tpm}? +---w input | +---w tpm20-attestation-challenge | +---w nonce-value binary | +---w tpm20-pcr-selection* [] | | +---w TPM20-hash-algo? identityref | | +---w pcr-index* tpm:pcr | +---w certificate-name* certificate-name-ref {tpm:TPMs}? +--ro output +--ro tpm20-attestation-response* [] +--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 +--ro pcr-value? binary¶
An example of an RPC challenge requesting PCRs 0-7 from a SHA-256 bank could look like the following:¶
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <tpm20-challenge-response-attestation> xmlns="urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation"> <certificate-name> (identifier of a TPM signature key with which the Verifier is supposed to sign the attestation data) </certificate-name> <nonce> 0xe041307208d9f78f5b1bbecd19e2d152ad49de2fc5a7d8dbf769f6b8ffdeab9 </nonce> <tpm20-pcr-selection> <tpm20-hash-algo xmlns:taa="urn:ietf:params:xml:ns:yang:ietf-tcg-algs"> taa:TPM_ALG_SHA256 </tpm20-hash-algo> <pcr-index>0</pcr-index> <pcr-index>1</pcr-index> <pcr-index>2</pcr-index> <pcr-index>3</pcr-index> <pcr-index>4</pcr-index> <pcr-index>5</pcr-index> <pcr-index>6</pcr-index> <pcr-index>7</pcr-index> </tpm20-pcr-selection> </tpm20-challenge-response-attestation> </rpc>¶
A successful response could be formatted as follows:¶
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <tpm20-attestation-response xmlns="urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation"> <certificate-name xmlns:ks=urn:ietf:params:xml:ns:yang:ietf-keystore> ks:(instance of Certificate name in the Keystore) </certificate-name> <attestation-data> (raw attestation data, i.e. the TPM quote; this includes a composite digest of requested PCRs, the nonce, and TPM 2.0 time information.) </attestation-data> <quote-signature> (signature over attestation-data using the TPM key identified by sig-key-id) </quote-signature> </tpm20-attestation-response> </rpc-reply>¶
This RPC allows a Verifier to acquire the evidence which was extended into specific TPM PCRs. A YANG tree diagram of this RPC is as follows:¶
+---x log-retrieval +---w input | +---w log-selector* [] | | +---w name* string | | +---w (index-type)? | | | +--:(last-entry) | | | | +---w last-entry-value? binary | | | +--:(index) | | | | +---w last-index-number? uint64 | | | +--:(timestamp) | | | +---w timestamp? yang:date-and-time | | +---w log-entry-quantity? uint16 | +---w log-type identityref +--ro output +--ro system-event-logs +--ro node-data* [] +--ro name? string +--ro up-time? uint32 +--ro log-result +--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* [] | | +--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 +--ro signature? binary¶
This section provides a high level description of the data nodes containing the configuration and operational objects with the YANG model. For more details, please see the YANG model itself in Figure 1.¶
This houses the set of information relating to a device's TPM(s).¶
Provides configuration and operational details for each supported TPM, including the tpm-firmware-version, PCRs which may be quoted, certificates which are associated with that TPM, and the current operational status. Of note are the certificates which are associated with that TPM. As a certificate is associated with a particular TPM attestation key, knowledge of the certificate allows a specific TPM to be identified.¶
+--rw tpms +--rw tpm* [name] +--rw name string +--ro hardware-based? boolean +--ro physical-index? int32 {ietfhw:entity-mib}? +--ro path? string +--ro compute-node compute-node-ref {tpm:tpms}? +--ro manufacturer? string +--rw firmware-version identityref +--rw tpm12-hash-algo? identityref +--rw tpm12-pcrs* pcr +--rw tpm20-pcr-bank* [tpm20-hash-algo] | +--rw tpm20-hash-algo identityref | +--rw pcr-index* tpm:pcr +--ro status enumeration +--rw certificates +--rw certificate* [name] +--rw name string +--rw keystore-ref? leafref +--rw type? enumeration¶
container 'attester-supported-algos' - Identifies which TCG hash algorithms are available for use on the Attesting platform. This allows an operator to limit algorithms available for use by RPCs to just a desired set from the universe of all allowed hash algorithms by the TCG.¶
+--rw attester-supported-algos +--rw tpm12-asymmetric-signing* identityref +--rw tpm12-hash* identityref +--rw tpm20-asymmetric-signing* identityref +--rw tpm20-hash* identityref¶
container 'compute-nodes' - When there is more than one TPM supported, this container maintains the set of information related to the compute node associated with a specific TPM. This allows each specific TPM to identify to which 'compute-node' it belongs.¶
+--rw compute-nodes {tpm:TPMs}? +--ro compute-node* [node-id] +--ro node-id string +--ro node-physical-index? int32 {ietfhw:entity-mib}? +--ro node-name? string +--ro node-location? string¶
Cryptographic algorithm types were initially included within -v14 NETCONF's iana-crypto-types.yang. Unfortunately, all this content including the algorithms needed here failed to make the -v15 used WGLC. As a result, this document has encoded the TCG Algorithm definitions of [TCG-Algos], revision 1.32. By including this full table as a separate YANG file within this document, it is possible for other YANG models to leverage the contents of this model.¶
There are two types of features supported: 'TPM12' and 'TPM20'. Support for either of these features indicates that a cryptoprocessor supporting the corresponding type of TCG TPM API is present on an Attester. Most commonly, only one type of cryptoprocessor will be available on an Attester.¶
There are three types of identities in this model:¶
<CODE BEGINS> file "ietf-tcg-algs@2021-05-11.yang" module ietf-tcg-algs { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-tcg-algs"; prefix taa; organization "IETF RATS Working Group"; contact "WG Web: <http://datatracker.ietf.org/wg/rats/> WG List: <mailto:rats@ietf.org> Author: Eric Voit <mailto:evoit@cisco.com>"; description "This module defines a identities for asymmetric algorithms. Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision 2021-05-11 { description "Initial version"; reference "RFC XXXX: tbd"; } /*****************/ /* Features */ /*****************/ feature tpm12 { description "This feature indicates algorithm support for the TPM 1.2 API as per TPM-main-1.2-Rev94-part-2, Section 4.8."; } feature tpm20 { description "This feature indicates algorithm support for the TPM 2.0 API as per TPM-Rev-2.0-Part-1-Architecture-01.38 Section 11.4."; } /*****************/ /* Identities */ /*****************/ /* There needs to be collasping/verification of some of the identity types between the various algorithm types listed below */ identity asymmetric { description "A TCG recognized asymmetric algorithm with a public and private key."; reference "http://trustedcomputinggroup.org/resource/tcg-algorithm-registry/ TCG_Algorithm_Registry_r1p32_pub Table 2"; } identity symmetric { description "A TCG recognized symmetric algorithm with only a private key."; reference "TCG_Algorithm_Registry_r1p32_pub Table 2"; } identity hash { description "A TCG recognized hash algorithm that compresses input data to a digest value or indicates a method that uses a hash."; reference "TCG_Algorithm_Registry_r1p32_pub Table 2"; } identity signing { description "A TCG recognized signing algorithm"; reference "TCG_Algorithm_Registry_r1p32_pub Table 2"; } identity anonymous_signing { description "A TCG recognized anonymous signing algorithm."; reference "TCG_Algorithm_Registry_r1p32_pub Table 2"; } identity encryption_mode { description "A TCG recognized encryption mode."; reference "TCG_Algorithm_Registry_r1p32_pub Table 2"; } identity method { description "A TCG recognized method such as a mask generation function."; reference "TCG_Algorithm_Registry_r1p32_pub Table 2"; } identity object_type { description "A TCG recognized object type."; reference "TCG_Algorithm_Registry_r1p32_pub Table 2"; } identity cryptoprocessor { description "Base identity identifying a crytoprocessor."; } identity tpm12 { if-feature "tpm12"; base cryptoprocessor; description "Supportable by a TPM1.2."; reference "TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf TPM_ALGORITHM_ID values, page 18"; } identity tpm20 { if-feature "tpm12"; base cryptoprocessor; description "Supportable by a TPM2."; reference "TPM-Rev-2.0-Part-2-Structures-01.38.pdf The TCG Algorithm Registry. Table 9"; } identity TPM_ALG_RSA { if-feature "tpm12 or tpm20"; base tpm12; base tpm20; base asymmetric; base object_type; description "RSA algorithm"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and RFC 8017. ALG_ID: 0x0001"; } identity TPM_ALG_TDES { if-feature "tpm12"; base tpm12; base symmetric; description "Block cipher with various key sizes (Triple Data Encryption Algorithm, commonly called Triple Data Encryption Standard) Note: was banned in TPM1.2 v94"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and ISO/IEC 18033-3. ALG_ID: 0x0003"; } identity TPM_ALG_SHA1 { if-feature "tpm12 or tpm20"; base hash; base tpm12; base tpm20; description "SHA1 algorithm - Deprecated due to insufficient cryptographic protection. However it is still useful for hash algorithms where protection is not required."; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and ISO/IEC 10118-3. ALG_ID: 0x0004"; } identity TPM_ALG_HMAC { if-feature "tpm12 or tpm20"; base tpm12; base tpm20; base hash; base signing; description "Hash Message Authentication Code (HMAC) algorithm"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3, ISO/IEC 9797-2 and RFC2014. ALG_ID: 0x0005"; } identity TPM_ALG_AES { if-feature "tpm12"; base tpm12; base symmetric; description "The AES algorithm with various key sizes"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and ISO/IEC 18033-3. ALG_ID: 0x0006"; } identity TPM_ALG_MGF1 { if-feature "tpm20"; base tpm20; base hash; base method; description "hash-based mask-generation function"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3, IEEE Std 1363-2000 and IEEE Std 1363a -2004. ALG_ID: 0x0007"; } identity TPM_ALG_KEYEDHASH { if-feature "tpm20"; base tpm20; base hash; base object_type; description "An encryption or signing algorithm using a keyed hash. These may use XOR for encryption or an HMAC for signing and may also refer to a data object that is neither signing nor encrypting."; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and TCG TPM 2.0 library specification. . ALG_ID: 0x0008"; } identity TPM_ALG_XOR { if-feature "tpm12 or tpm20"; base tpm12; base tpm20; base hash; base symmetric; description "The XOR encryption algorithm."; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and TCG TPM 2.0 library specification. ALG_ID: 0x000A"; } identity TPM_ALG_SHA256 { if-feature "tpm20"; base tpm20; base hash; description "The SHA 256 algorithm"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and ISO/IEC 10118-3. ALG_ID: 0x000B"; } identity TPM_ALG_SHA384 { if-feature "tpm20"; base tpm20; base hash; description "The SHA 384 algorithm"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and ISO/IEC 10118-3. ALG_ID: 0x000C"; } identity TPM_ALG_SHA512 { if-feature "tpm20"; base tpm20; base hash; description "The SHA 512 algorithm"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and ISO/IEC 10118-3. ALG_ID: 0x000D"; } identity TPM_ALG_NULL { if-feature "tpm20"; base tpm20; description "NULL algorithm"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and TCG TPM 2.0 library specification. ALG_ID: 0x0010"; } identity TPM_ALG_SM3_256 { if-feature "tpm20"; base tpm20; base hash; description "The SM3 hash algorithm."; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and GM/T 0004-2012 - SM3_256. ALG_ID: 0x0012"; } identity TPM_ALG_SM4 { if-feature "tpm20"; base tpm20; base symmetric; description "SM4 symmetric block cipher"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and GB/T 32907-2016. ALG_ID: 0x0013"; } identity TPM_ALG_RSASSA { if-feature "tpm20"; base tpm20; base asymmetric; base signing; description "Signature algorithm defined in section 8.2 (RSASSAPKCS1-v1_5)"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and RFC 8017. ALG_ID: 0x0014"; } identity TPM_ALG_RSAES { if-feature "tpm20"; base tpm20; base asymmetric; base encryption_mode; description "Signature algorithm defined in section 7.2 (RSAES-PKCS1-v1_5)"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and RFC 8017 ALG_ID: 0x0015"; } identity TPM_ALG_RSAPSS { if-feature "tpm20"; base tpm20; base asymmetric; base signing; description "Padding algorithm defined in section 8.1 (RSASSA PSS)"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and RFC 8017. ALG_ID: 0x0016"; } identity TPM_ALG_OAEP { if-feature "tpm20"; base tpm20; base asymmetric; base encryption_mode; description "Padding algorithm defined in section 7.1 (RSASSA OAEP)"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and RFC 8017. ALG_ID: 0x0017"; } identity TPM_ALG_ECDSA { if-feature "tpm20"; base tpm20; base asymmetric; base signing; description "Signature algorithm using elliptic curve cryptography (ECC)"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and ISO/IEC 14888-3. ALG_ID: 0x0018"; } identity TPM_ALG_ECDH { if-feature "tpm20"; base tpm20; base asymmetric; base method; description "Secret sharing using ECC"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and NIST SP800-56A and RFC 7748. ALG_ID: 0x0019"; } identity TPM_ALG_ECDAA { if-feature "tpm20"; base tpm20; base asymmetric; base signing; base anonymous_signing; description "Elliptic-curve based anonymous signing scheme"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and TCG TPM 2.0 library specification. ALG_ID: 0x001A"; } identity TPM_ALG_SM2 { if-feature "tpm20"; base tpm20; base asymmetric; base signing; base encryption_mode; base method; description "SM2 - depending on context, either an elliptic-curve based, signature algorithm, an encryption scheme, or a key exchange protocol"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and A GM/T 0003.1-2012, GM/T 0003.2-2012, GM/T 0003.3-2012, GM/T 0003.5-2012 SM2. ALG_ID: 0x001B"; } identity TPM_ALG_ECSCHNORR { if-feature "tpm20"; base tpm20; base asymmetric; base signing; description "Elliptic-curve based Schnorr signature"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and TCG TPM 2.0 library specification. ALG_ID: 0x001C"; } identity TPM_ALG_ECMQV { if-feature "tpm20"; base tpm20; base asymmetric; base method; description "Two-phase elliptic-curve key"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and NIST SP800-56A. ALG_ID: 0x001D"; } identity TPM_ALG_KDF1_SP800_56A { if-feature "tpm20"; base tpm20; base hash; base method; description "Concatenation key derivation function"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and NIST SP800-56A (approved alternative1) section 5.8.1. ALG_ID: 0x0020"; } identity TPM_ALG_KDF2 { if-feature "tpm20"; base tpm20; base hash; base method; description "Key derivation function"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and IEEE 1363a-2004 KDF2 section 13.2. ALG_ID: 0x0021"; } identity TPM_ALG_KDF1_SP800_108 { base TPM_ALG_KDF2; description "A key derivation method"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and NIST SP800-108 - Section 5.1 KDF. ALG_ID: 0x0022"; } identity TPM_ALG_ECC { if-feature "tpm20"; base tpm20; base asymmetric; base object_type; description "Prime field ECC"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and ISO/IEC 15946-1. ALG_ID: 0x0023"; } identity TPM_ALG_SYMCIPHER { if-feature "tpm20"; base tpm20; description "Object type for a symmetric block cipher"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and TCG TPM 2.0 library specification. ALG_ID: 0x0025"; } identity TPM_ALG_CAMELLIA { if-feature "tpm20"; base tpm20; base symmetric; description "The Camellia algorithm"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and ISO/IEC 18033-3. ALG_ID: 0x0026"; } identity TPM_ALG_SHA3_256 { if-feature "tpm20"; base tpm20; base hash; description "ISO/IEC 10118-3 - the SHA 256 algorithm"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and NIST PUB FIPS 202. ALG_ID: 0x0027"; } identity TPM_ALG_SHA3_384 { if-feature "tpm20"; base tpm20; base hash; description "The SHA 384 algorithm"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and NIST PUB FIPS 202. ALG_ID: 0x0028"; } identity TPM_ALG_SHA3_512 { if-feature "tpm20"; base tpm20; base hash; description "The SHA 512 algorithm"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and NIST PUB FIPS 202. ALG_ID: 0x0029"; } identity TPM_ALG_CMAC { if-feature "tpm20"; base tpm20; base symmetric; base signing; description "block Cipher-based Message Authentication Code (CMAC)"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and ISO/IEC 9797-1:2011 Algorithm 5. ALG_ID: 0x003F"; } identity TPM_ALG_CTR { if-feature "tpm20"; base tpm20; base symmetric; base encryption_mode; description "Counter mode"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and ISO/IEC 10116. ALG_ID: 0x0040"; } identity TPM_ALG_OFB { base tpm20; base symmetric; base encryption_mode; description "Output Feedback mode"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and ISO/IEC 10116. ALG_ID: 0x0041"; } identity TPM_ALG_CBC { if-feature "tpm20"; base tpm20; base symmetric; base encryption_mode; description "Cipher Block Chaining mode"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and ISO/IEC 10116. ALG_ID: 0x0042"; } identity TPM_ALG_CFB { if-feature "tpm20"; base tpm20; base symmetric; base encryption_mode; description "Cipher Feedback mode"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and ISO/IEC 10116. ALG_ID: 0x0043"; } identity TPM_ALG_ECB { if-feature "tpm20"; base tpm20; base symmetric; base encryption_mode; description "Electronic Codebook mode"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and ISO/IEC 10116. ALG_ID: 0x0044"; } identity TPM_ALG_CCM { if-feature "tpm20"; base tpm20; base symmetric; base signing; base encryption_mode; description "Counter with Cipher Block Chaining-Message Authentication Code (CCM)"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and NIST SP800-38C. ALG_ID: 0x0050"; } identity TPM_ALG_GCM { if-feature "tpm20"; base tpm20; base symmetric; base signing; base encryption_mode; description "Galois/Counter Mode (GCM)"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and NIST SP800-38D. ALG_ID: 0x0051"; } identity TPM_ALG_KW { if-feature "tpm20"; base tpm20; base symmetric; base signing; base encryption_mode; description "AES Key Wrap (KW)"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and NIST SP800-38F. ALG_ID: 0x0052"; } identity TPM_ALG_KWP { if-feature "tpm20"; base tpm20; base symmetric; base signing; base encryption_mode; description "AES Key Wrap with Padding (KWP)"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and NIST SP800-38F. ALG_ID: 0x0053"; } identity TPM_ALG_EAX { if-feature "tpm20"; base tpm20; base symmetric; base signing; base encryption_mode; description "Authenticated-Encryption Mode"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and NIST SP800-38F. ALG_ID: 0x0054"; } identity TPM_ALG_EDDSA { if-feature "tpm20"; base tpm20; base asymmetric; base signing; description "Edwards-curve Digital Signature Algorithm (PureEdDSA)"; reference "TCG_Algorithm_Registry_r1p32_pub Table 3 and RFC 8032. ALG_ID: 0x0060"; } } <CODE ENDS>¶
Note that not all cryptographic functions are required for use by ietf-tpm-remote-attestation.yang
. However the full definition of Table 3 of [TCG-Algos] will allow use by additional YANG specifications.¶
This document registers the following namespace URIs in the "ns" class of the IETF XML Registry [IANA.xml-registry] as per [RFC3688]:¶
urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation¶
urn:ietf:params:xml:ns:yang:ietf-tcg-algs¶
This document registers the following YANG modules in the "YANG Module Names" registry [IANA.yang-parameters] as per Section 14 of [RFC6020]:¶
The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].¶
There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes as well as their sensitivity/vulnerability:¶
'tpm12-asymmetric-signing', 'tpm12-hash', 'tpm20-asymmetric-signing', and 'tpm20-hash'. All could be populated with algorithms that are not supported by the underlying physical TPM installed by the equipment vendor.¶
'name': Although shown as 'rw', it is system generated. Therefore it should not be possible for an operator to add or remove a TPM from the configuration.¶
'tpm20-pcr-bank': It is possible to configure PCRs for extraction which are not being extended by system software. This could unnecessarily use TPM resources.¶
'certificates': It is possible to provision a certificate which does not correspond to an Attestation Identity Key (AIK) within the TPM 1.2, or an Attestation Key (AK) within the TPM 2.0 respectively.¶
It must be verified that the certificate is for an active AIK, i. e. the certificate provided is able to support Attestation on the targeted TPM 1.2.¶
It must be verified that the certificate is for an active AK, i. e. the certificate provided is able to support Attestation on the targeted TPM 2.0.¶
Pulling lots of logs can chew up system resources.¶
Changes from version 08 to version 09:¶
Changes from version 05 to version 06:¶
Changes from version 04 to version 05:¶
Changes from version 03 to version 04:¶
Changes from version 02 to version 03:¶
Changes from version 01 to version 02:¶
Changes from version 00 to version 01:¶