A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMsFraunhofer SITRheinstrasse 75Darmstadt64295Germanyhenk.birkholz@sit.fraunhofer.deFraunhofer SITRheinstrasse 75Darmstadt64295Germanymichael.eckel@sit.fraunhofer.deThoughtSpotshwetha.bhandari@thoughtspot.comCisco Systemsevoit@cisco.comCisco Systemsbsulzen@cisco.comHuawei Technologies101 Software Avenue, Yuhuatai DistrictNanjingJiangsu210012ChinaFrank.Xialiang@huawei.comHewlett Packard Enterprisetom.laffey@hpe.comJuniper Networks10 Technology Park DriveWestfordMassachusetts01886gfedorkow@juniper.net
Security
RATS Working GroupInternet-DraftThis document defines a YANG RPC and a minimal datastore required to retrieve attestation evidence about integrity measurements from a device following the operational context defined in . Complementary measurement logs are also provided by the YANG RPC originating from one or more roots of trust of measurement. The module defined requires at least one TPM 1.2 or TPM 2.0 and corresponding Trusted Software Stack included in the device components of the composite device the YANG server is running on.This document is based on the terminology defined in the and uses the operational context defined in as well as the interaction model and information elements defined in . The currently supported hardware security modules (HWM) are the Trusted Platform Module (TPM) and specified by the Trusted Computing Group (TCG). One ore more TPMs embedded in the components of a composite device - sometimes also referred to as an aggregate 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 (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 (extend primitive operation).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 when, and only when, they
appear in all capitals, as shown here.One or more TPMs MUST be embedded in the composite device that is providing 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 Claimant and Attester in accordance with the Remote Attestation Procedures (RATS) architecture and the corresponding challenge-response interaction model defined in the 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. The functions of this YANG module are restricted to 0-1 TPMs per hardware component.This YANG module imports modules from , , , ietf-tcg-algs.yang.This module supports the following types of attestation event logs: <ima>, <bios>, and <netequip_boot>.<tpm12-challenge-response-attestation> - Allows a Verifier to request a quote of PCRs from a TPM1.2 compliant cryptoprocessor. When one or more <certificate-name> is not provided, all TPM1.2 compliant cryptoprocessors will respond.<tpm20-challenge-response-attestation> - Allows a Verifier to request a quote of PCRs from a TPM2.0 compliant cryptoprocessor. When one or more <certificate-name> is not provided, all TPM2.0 compliant cryptoprocessors will respond.<log-retrieval> - Allows a Verifier to acquire the evidence which was extended into specific PCRs.container <rats-support-structures> - This exists when there are more than one TPM for a particular Attester. This allows each specific TPM to identify on which <compute-node> it belongs.container <tpms> - 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 is the certificates which are associated with that TPM. As a certificate is associated with a single Attestation key, knowledge of the certificate allows a specific TPM to be identified.container <attester-supported-algos> - Identifies which TCG algorithms are available for use 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 by TCG.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 , 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 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.The first are the cryptographic functions supportable by a TPM algorithm, these include: <asymmetric>, <symmetric>, <hash>, <signing>, <anonymous_signing>, <encryption_mode>, <method>, and <object_type>. The definitions of each of these are in Table 2 of .The second are API specifications for tpms: <tpm12> and <tpm2>.The third are specific algorithm types. Each algorithm type defines what cryptographic functions may be supported, and on which type of API specification. It is not required that an implementation of a specific TPM will support all algorithm types. The contents of each specific algorithm mirrors what is in Table 3 of .Note that not all cryptographic functions are required for use by ietf-tpm-remote-attestation.yang. However the full definition of Table 3 of will allow use by additional YANG specifications.This document will include requests to IANA:To be defined yet. But keeping up with changes to ietf-tcg-algs.yang will be necessary.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 or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS .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 and their sensitivity/vulnerability:Container: </rats-support-structures/attester-supported-algos><tpm12-asymmetric-signing>, <tpm12-hash>, <tpm20-asymmetric-signing>, and <tpm20-hash> all could be populated with algorithms which are not supported by the underlying physical TPM installed by the equipment vendor.Container: </rats-support-structures/tpms><tpm-name> - Although shown as ‘rw’, it is system generated<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 a Attestation Identity Key (AIK) within the TPM.RPC: <tpm12-challenge-response-attestation> - Need to verify that the certificate is for an active AIK.RPC: <tpm20-challenge-response-attestation> - Need to verify that the certificate is for an active AIK.RPC: <log-retrieval> - Pulling lots of logs can chew up system resources.Not yet.Changes from version 03 to version 04:TPM1.2 Quote1 eliminatedYANG model simplifications so redundant info isn’t exposedChanges from version 02 to version 03:moved to tcg-algscleaned up model to eliminate sources of errorsremoved key establishment RPCadded lots of XPATH which must all be scrubbed stillDescriptive text added on model contents.Changes from version 01 to version 02:Extracted Crypto-types into a separate YANG fileMades the algorithms explicit, not stringsHash Algo as key the selected TPM2 PCRsPCR numbers are their own typeEliminated nested keys for node-id plus tpm-nameEliminated TPM-Name of “ALL”Added TPM-PathChanges from version 00 to version 01:Addressed author’s commentsExtended complementary details about attestation-certificatesRelabeled chunk-size to log-entry-quantityRelabeled location with compute-node or tpm-name where appropriateAdded a valid entity-mib physical-index to compute-node and tpm-name to map it back to hardware inventoryRelabeled name to tpm_nameRemoved event-string in last-entryKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Common YANG Data TypesThis document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.A YANG Data Model for Hardware ManagementThis document defines a YANG data model for the management of hardware on a single server.A YANG Data Model for a KeystoreThis document defines a YANG 1.1 module called "ietf-keystore" that enables centralized configuration of both symmetric and asymmetric keys. The secret value for both key types may be encrypted or hidden. Asymmetric keys may be associated with certificates. Notifications are sent when certificates are about to expire. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types * "CCCC" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * "2020-08-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change LogReference Interaction Models for Remote Attestation ProceduresThis document describes interaction models for remote attestation procedures (RATS). Three conveying mechanisms - Challenge/Response, Uni-Directional, and Streaming Remote Attestation - are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. Privacy preserving conveyance of Evidence via Direct Anonymous Attestation is elaborated on in the context of the Attester, Endorser, and Verifier role.Remote Attestation Procedures ArchitectureIn network protocol exchanges it is often the case that one entity requires believable evidence about the operational state of a remote peer. Such evidence is typically conveyed as claims about the peer's software and hardware platform, and is subsequently appraised in order to assess the peer's trustworthiness. The process of generating and appraising this kind of evidence is known as remote attestation. This document describes an architecture for remote attestation procedures that generate, convey, and appraise evidence about a peer's operational state.TPM-based Network Device Remote Integrity VerificationThis document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules [TPM1.2], [TPM2.0], as defined by the Trusted Computing Group (TCG).TPM 1.2 Main SpecificationTPM 2.0 Library SpecificationTCG_Algorithm_Registry_r1p32_pubNetwork Configuration Protocol (NETCONF)The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]RESTCONF ProtocolThis document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).Using the NETCONF Protocol over Secure Shell (SSH)This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]The Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]