--- 1/draft-ietf-rats-yang-tpm-charra-17.txt 2022-03-20 01:13:10.056760470 -0700 +++ 2/draft-ietf-rats-yang-tpm-charra-18.txt 2022-03-20 01:13:10.164763176 -0700 @@ -1,30 +1,30 @@ RATS Working Group H. Birkholz Internet-Draft M. Eckel Intended status: Standards Track Fraunhofer SIT -Expires: 17 September 2022 S. Bhandari +Expires: 21 September 2022 S. Bhandari ThoughtSpot E. Voit B. Sulzen Cisco L. Xia Huawei T. Laffey HPE G. Fedorkow Juniper - 16 March 2022 + 20 March 2022 A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs - draft-ietf-rats-yang-tpm-charra-17 + draft-ietf-rats-yang-tpm-charra-18 Abstract This document defines YANG RPCs and a few 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 @@ -42,35 +42,35 @@ 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 17 September 2022. + This Internet-Draft will expire on 21 September 2022. Copyright Notice Copyright (c) 2022 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. + 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 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. The YANG Module for Basic Remote Attestation Procedures . . . 3 2.1. YANG Modules . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. 'ietf-tpm-remote-attestation' . . . . . . . . . . . . 4 2.1.2. 'ietf-tcg-algs' . . . . . . . . . . . . . . . . . . . 33 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 @@ -90,21 +90,21 @@ 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 TPM, or multiple TPMs in the case of a Composite Device, are required in order to use the YANG module defined in this document. Each TPM is used as a root of trust for storage (RTS) in order to store system security measurement Evidence. And each TPM is used as a root of trust for reporting (RTR) in order to retrieve attestation Evidence. This is done by using a YANG RPC - to request a quote which exposes a rolling hash the security + to request a quote which exposes a rolling hash of the security measurements held internally within the TPM. 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), Attestation Identity Key (AIK), Local Attestation Key (LAK). 1.1. Requirements notation @@ -137,38 +137,38 @@ In this section the several YANG modules are defined. 2.1.1. 'ietf-tpm-remote-attestation' This YANG module imports modules from [RFC6991] with prefix 'yang', [RFC8348] with prefix 'hw', [I-D.ietf-netconf-keystore] with prefix 'ks', and 'ietf-tcg-algs.yang' Section 2.1.2.3 with prefix 'taa'. Additionally, references are made to [RFC8032], [RFC8017], [RFC6933], [TPM1.2-Commands], [TPM2.0-Arch], [TPM2.0-Structures], [TPM2.0-Key], - [TPM1.2-Structures], [bios-log], [ima-log], [BIOS-Log-Event-Type], as - well as Appendix A and Appendix B. + [TPM1.2-Structures], [bios-log], [BIOS-Log-Event-Type], as well as + Appendix A and Appendix B. 2.1.1.1. Features This module supports the following features: * 'mtpm': Indicates that multiple TPMs on the device can support remote attestation. For example, this feature could be used in cases where multiple line cards are present, each with its own TPM. * 'bios': Indicates that the device supports the retrieval of BIOS/ UEFI event logs. [bios-log] * 'ima': Indicates that the device supports the retrieval of event - logs from the Linux Integrity Measurement Architecture (IMA - [ima-log]). Also see Appendix A. + logs from the Linux Integrity Measurement Architecture (IMA, see + Appendix A). * 'netequip_boot': Indicates that the device supports the retrieval of netequip boot event logs. See Appendix A and Appendix B. 2.1.1.2. Identities This module supports the following types of attestation event logs: 'bios', 'ima', and 'netequip_boot'. 2.1.1.3. Remote Procedure Calls (RPCs) @@ -376,24 +376,24 @@ | +--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 {ks:asymmetric-keys}? +--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. + algorithms are available for use on the Attesting platform. An + operator will use this information 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 @@ -402,20 +402,21 @@ +--rw compute-nodes {tpm:mtpm}? +--ro compute-node* [node-id] +--ro node-id string +--ro node-physical-index? int32 {hw:entity-mib}? +--ro node-name? string +--ro node-location? string 2.1.1.6. YANG Module file "ietf-tpm-remote-attestation@2022-03-15.yang" module ietf-tpm-remote-attestation { + yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation"; prefix tpm; import ietf-yang-types { prefix yang; } import ietf-hardware { prefix hw; } import ietf-keystore { @@ -456,21 +457,21 @@ 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 2022-03-15 { + revision 2022-03-18 { description "Initial version"; reference "RFC XXXX: A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs"; } /*****************/ /* Features */ /*****************/ @@ -494,48 +495,50 @@ feature ima { description "The device supports Integrity Measurement Architecture logs. Many variants of IMA logs exist in the deployment. Each encodes the log entry contents as the specific measurements which get hashed into a PCRs as Evidence. See the reference below for one example of such an encoding."; reference "ima-log: https://www.trustedcomputinggroup.org/wp-content/uploads/ - TCG_IWG_CEL_v1_r0p41_pub.pdf Section 4.3"; + TCG_IWG_CEL_v1_r0p41_pub.pdf Section 5.1.6"; + } + feature netequip_boot { description "The device supports the netequip_boot logs."; reference "netequip-boot-log: - https://www.kernel.org/doc/Documentation/ABI/testing/ima_policy"; + RFC AAAA Appendix B"; } /*****************/ /* Typedefs */ /*****************/ typedef pcr { type uint8 { range "0..31"; } description "Valid index number for a PCR. A {{TPM2.0}} compliant PCR index extends from 0-31. At this time a typical TPM would have no more than 32 PCRS."; } typedef compute-node-ref { type leafref { path "/tpm:rats-support-structures/tpm:compute-nodes" - + "/tpm:compute-node/tpm:node-name"; + + "/tpm:compute-node/tpm:node-id"; } description "This type is used to reference a hardware node. Note that an implementer might include an alternative leafref pointing to a different YANG module node specifying hardware structures."; } typedef certificate-name-ref { type leafref { path "/tpm:rats-support-structures/tpm:tpms/tpm:tpm" @@ -578,22 +580,22 @@ /*****************/ grouping tpm20-hash-algo { description "The cryptographic algorithm used to hash the TPM2 PCRs. This must be from the list of platform supported options."; leaf tpm20-hash-algo { type identityref { base taa:hash; } - must '/tpm:rats-support-structures/tpm:attester-supported-algos' - + '/tpm:tpm20-hash' { + must '. = /tpm:rats-support-structures' + + '/tpm:attester-supported-algos/tpm:tpm20-hash' { error-message "This platform does not support tpm20-hash-algo"; } default "taa:TPM_ALG_SHA256"; description "The hash scheme that is used to hash a TPM2.0 PCR. This must be one of those supported by a platform."; } } grouping tpm12-hash-algo { @@ -592,27 +594,26 @@ default "taa:TPM_ALG_SHA256"; description "The hash scheme that is used to hash a TPM2.0 PCR. This must be one of those supported by a platform."; } } grouping tpm12-hash-algo { description "The cryptographic algorithm used to hash the TPM1.2 PCRs."; - leaf tpm12-hash-algo { type identityref { base taa:hash; } - must '/tpm:rats-support-structures/tpm:attester-supported-algos' - + '/tpm:tpm12-hash' { + must '. = /tpm:rats-support-structures' + + '/tpm:attester-supported-algos/tpm:tpm12-hash' { error-message "This platform does not support tpm12-hash-algo"; } default "taa:TPM_ALG_SHA1"; description "The hash scheme that is used to hash a TPM1.2 PCR. This MUST be one of those supported by a platform."; } } grouping nonce { @@ -666,22 +667,21 @@ "Specifies the list of PCRs and Hash Algorithms that can be returned within a TPM2B_DIGEST."; reference "TPM2.0-Structures: https://www.trustedcomputinggroup.org/wp-content/uploads/ TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.9.7"; uses tpm20-hash-algo; leaf-list pcr-index { type pcr; must '/tpm:rats-support-structures/tpm:tpms' - + '/tpm:tpm[name = current()] and ' - + '/tpm:rats-support-structures/tpm:tpms/tpm:tpm' + + '/tpm:tpm[name = current()]' + '/tpm:tpm20-pcr-bank[pcr-index = current()]' { error-message "Acquiring this PCR index is not supported"; } description "The numbers of the PCRs that which are being tracked with a hash based on the tpm20-hash-algo. In addition, any selection of PCRs MUST verify that the set of PCRs requested are a subset the set of PCR indexes exposed within /tpm:rats-support-structures/tpm:tpms /tpm:tpm[name=current()]/tpm:tpm20-pcr-bank @@ -829,23 +830,24 @@ grouping boot-event-log { description "Defines a specific instance of an event log entry and corresponding to the information used to extend the PCR"; leaf event-number { type uint32; description "Unique event number of this event which monotonically - increases. The maximum event number should not be - reached, nor is wrapping back to an earlier number - supported."; + increases within a given event log. The maximum event + number should not be reached, nor is wrapping back to + an earlier number supported."; + } leaf event-type { type uint32; description "BIOS Log Event Type: https://trustedcomputinggroup.org/wp-content/uploads/ TCG_PCClient_PFP_r1p05_v23_pub.pdf Section 10.4.1"; } leaf pcr-index { type pcr; @@ -1123,29 +1126,32 @@ rpc log-retrieval { description "Logs Entries are either identified via indices or via providing the last line received. The number of lines returned can be limited. The type of log is a choice that can be augmented."; input { uses log-identifier; list log-selector { description - "Only log entries which meet all the selection criteria provided - are to be returned by the RPC output."; + "Only log entries which meet all the selection criteria + provided are to be returned by the RPC output."; leaf-list name { type string; description - "Name of one or more unique TPMs on a device. If this object - exists, a selection should pull only the objects related to - these TPM(s). If it does not exist, all qualifying TPMs that - are 'hardware-based' equals true on the device are selected."; + "Name of one or more unique TPMs on a device. If this + object exists, a selection should pull only the objects + related to these TPM(s). If it does not exist, all + qualifying TPMs that are 'hardware-based' equals true + on the device are selected. When this selection + criteria is provided, it will be considered as a logical + AND with any other selection criteria provided."; } choice index-type { description "Last log entry received, log index number, or timestamp."; case last-entry { description "The last entry of the log already retrieved."; leaf last-entry-value { type binary; description @@ -1314,36 +1320,38 @@ type identityref { base taa:cryptoprocessor; } mandatory true; description "Identifies the cryptoprocessor API set supported. This is automatically configured by the device and should not be changed."; } uses tpm12-hash-algo { - when "firmware-version = 'taa:tpm12'"; + when "derived-from-or-self(firmware-version, 'taa:tpm12')"; refine "tpm12-hash-algo" { description "The hash algorithm overwrites the default used for PCRs on this TPM1.2 compliant cryptoprocessor."; } } leaf-list tpm12-pcrs { - when "../firmware-version = 'taa:tpm12'"; + when + "derived-from-or-self(../firmware-version, 'taa:tpm12')"; type pcr; description "The PCRs which may be extracted from this TPM1.2 compliant cryptoprocessor."; } list tpm20-pcr-bank { - when "../firmware-version = 'taa:tpm20'"; + when + "derived-from-or-self(../firmware-version, 'taa:tpm20')"; key "tpm20-hash-algo"; description "Specifies the list of PCRs that may be extracted for a specific Hash Algorithm on this TPM2 compliant cryptoprocessor. A bank is a set of PCRs which are extended using a particular hash algorithm."; reference "TPM2.0-Structures: https://www.trustedcomputinggroup.org/wp-content/uploads/ TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.9.7"; @@ -1514,22 +1521,22 @@ 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. Specific references to [RFC2104], [RFC8017], [ISO-IEC-9797-1], [ISO-IEC-9797-2], [ISO-IEC-10116], [ISO-IEC-10118-3], [ISO-IEC-14888-3], [ISO-IEC-15946-1], [ISO-IEC-18033-3], [IEEE-Std-1363-2000], [IEEE-Std-1363a-2004], [NIST-PUB-FIPS-202], [NIST-SP800-38C], [NIST-SP800-38D], [NIST-SP800-38F], - [NIST-SP800-56A], [NIST-SP800-108], [bios-log], [ima-log], as well as - Appendix A and Appendix B exist within the YANG Model. + [NIST-SP800-56A], [NIST-SP800-108], [bios-log], as well as Appendix A + and Appendix B exist within the YANG Model. 2.1.2.1. Features 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. 2.1.2.2. Identities @@ -2250,21 +2257,21 @@ description "Edwards-curve Digital Signature Algorithm (PureEdDSA)"; reference "TCG-Algos:TCG Algorithm Registry Rev1.32 Table 3 and RFC 8032. ALG_ID: 0x0060"; } } Note that not all cryptographic functions are required for use by - "ietf-tpm-remote-attestation.yang". However the full definition of + ietf-tpm-remote-attestation.yang. However the full definition of Table 3 of [TCG-Algos] will allow use by additional YANG specifications. 3. IANA Considerations This document registers the following namespace URIs in the [xml-registry] as per [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation @@ -2375,20 +2382,24 @@ Section 9.4.5.2", n.d., . [BIOS-Log-Event-Type] "TCG PC Client Platform Firmware Profile Specification", n.d., . + [cel] "Canonical Event Log Format, Section 4.3", n.d., + . + [I-D.ietf-netconf-keystore] Watsen, K., "A YANG Data Model for a Keystore", Work in Progress, Internet-Draft, draft-ietf-netconf-keystore-24, 7 March 2022, . [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- @@ -2406,24 +2417,20 @@ [IEEE-Std-1363-2000] "IEEE 1363-2000 - IEEE Standard Specifications for Public- Key Cryptography", n.d., . [IEEE-Std-1363a-2004] "1363a-2004 - IEEE Standard Specifications for Public-Key Cryptography - Amendment 1: Additional Techniques", n.d., . - [ima-log] "Canonical Event Log Format, Section 4.3", n.d., - . - [ISO-IEC-10116] "ISO/IEC 10116:2017 - Information technology", n.d., . [ISO-IEC-10118-3] "Dedicated hash-functions - ISO/IEC 10118-3:2018", n.d., . [ISO-IEC-14888-3] "ISO/IEC 14888-3:2018 - Digital signatures with appendix", @@ -2650,122 +2657,122 @@ extended file attributes. In support of the appraisal of Evidence, IMA maintains an ordered list of measurements in kernel-space, the Stored Measurement Log (SML), for all files that have been measured before execution since the operating system was started. Although IMA can be used without a TPM, it is typically used in conjunction with a TPM to anchor the integrity of the SML in a hardware-protected secure storage location, i.e., Platform Configuration Registers (PCRs) provided by TPMs. IMA provides the SML in both binary and ASCII representations in the - Linux security file system _securityfs_ ("/sys/kernel/security/ - ima/"). + Linux security file system _securityfs_ (/sys/kernel/security/ima/). IMA templates define the format of the SML, i.e., which fields are included in a log record. Examples are file path, file hash, user ID, group ID, file signature, and extended file attributes. IMA comes with a set of predefined template formats and also allows a custom format, i.e., a format consisting of template fields supported by IMA. Template usage is typically determined by boot arguments passed to the kernel. Alternatively, the format can also be hard- - compiled into custom kernels. IMA templates and fields are - extensible in the kernel source code. As a result, more template - fields can be added in the future. + coded into custom kernels. IMA templates and fields are extensible + in the kernel source code. As a result, more template fields can be + added in the future. IMA policies define which files are measured using the IMA policy language. Built-in policies can be passed as boot arguments to the kernel. Custom IMA policies can be defined once during runtime or be - hard-compiled into a custom kernel. If no policy is defined, no + hard-coded into a custom kernel. If no policy is defined, no measurements are taken and IMA is effectively disabled. + A comprehensive description of the content fields ins in native Linux + IMA TLV format can be found in Table 16 of the Canonical Event Log + (CEL) specification [cel]. The CEL specification also illustrates + the use of templates to enable extended or customized IMA TLV formats + in Section 5.1.6. + Appendix B. IMA for Network Equipment Boot Logs Network equipment can generally implement similar IMA-protected functions to generate measurements (Claims) about the boot process of a device and enable corresponding remote attestation. Network Equipment Boot Logs combine the measurement and logging of boot components and operating system components (executables and files) - into a single log file in identical IMA format. + into a single log file in a format identical to the IMA format. Note + that the format used for logging measurement of boot components in + this scheme differs from the boot logging strategy described + elsewhere in this document. During the boot process of the network device, i.e., from BIOS to the - end of the operating system and user-space, all files executed during - this process can be measured and logged in the order of their - execution. When the Verifier initiates a remote attestation process - (e.g., challenge-response remote attestation as defined in this - document), the network equipment takes on the role of an Attester and - can convey to the Verifier Claims that comprise the measurement log - as well as the corresponding PCR values (Evidence) of a TPM. + end of the operating system and user-space, all files executed can be + measured and logged in the order of their execution. When the + Verifier initiates a remote attestation process (e.g., challenge- + response remote attestation as defined in this document), the network + equipment takes on the role of an Attester and can convey to the + Verifier Claims that comprise the measurement log as well as the + corresponding PCR values (Evidence) of a TPM. The verifier can appraise the integrity (compliance with the Reference Values) of each executed file by comparing its measured value with the Reference Value. Based on the execution order, the Verifier can compute a PCR reference value (by replaying the log) and compare it to the Measurement Log Claims obtained in conjunction with the PCR Evidence to assess their trustworthiness with respect to an intended operational state. - Not only during the operating system loading phase, even during the - BIOS boot phase, network equipment usually executes multiple - components. With this measurement log mechanism, network equipment - can take on the role of an Attester, proving to the Verifier the - trustworthiness of its boot process. Using the measurement log, - Verifiers can precisely identify mismatching log entries to infer - potentially tampered components. + Network equipment usually executes multiple components in parallel. + This holds not only during the operating system loading phase, but + also even during the BIOS boot phase. With this measurement log + mechanism, network equipment can take on the role of an Attester, + proving to the Verifier the trustworthiness of its boot process. + Using the measurement log, Verifiers can precisely identify + mismatching log entries to infer potentially tampered components. This mechanism also supports scenarios that modify files on the - Attester and are executed during the boot phase (e.g., updating/ - patching) by simply updating the appropriate Reference Values in - Reference Integrity Manifests that inform Verifiers about how an - Attester is composed. + Attester that are subsequently executed during the boot phase (e.g., + updating/patching) by simply updating the appropriate Reference + Values in Reference Integrity Manifests that inform Verifiers about + how an Attester is composed. Authors' Addresses Henk Birkholz Fraunhofer SIT Rheinstrasse 75 64295 Darmstadt Germany - Email: henk.birkholz@sit.fraunhofer.de Michael Eckel Fraunhofer SIT Rheinstrasse 75 64295 Darmstadt Germany - Email: michael.eckel@sit.fraunhofer.de - Shwetha Bhandari ThoughtSpot - Email: shwetha.bhandari@thoughtspot.com + Eric Voit Cisco Systems - Email: evoit@cisco.com Bill Sulzen Cisco Systems - Email: bsulzen@cisco.com Liang Xia (Frank) Huawei Technologies 101 Software Avenue, Yuhuatai District Nanjing Jiangsu, 210012 China - Email: Frank.Xialiang@huawei.com Tom Laffey Hewlett Packard Enterprise - Email: tom.laffey@hpe.com Guy C. Fedorkow Juniper Networks 10 Technology Park Drive Westford - Email: gfedorkow@juniper.net