Draft: draft-ietf-rats-yang-tpm-charra

Commentary: Basically , this fixes typos ,  , and consistency . And , all above , the TPM 2.0 quote information , which was set to TPMSQUOTEINFO . Actually it is TPM2B_ATTEST . Further Issues to be created . 
 TPM 2.0 quote information ( attestation data ) is of type TPM2BATTEST , not TPMSQUOTEINFO .  is a sub element of the TPM2BATTEST . In a TPM2Quote operation , the TPM signs a hash of the TPM2BATTEST structure . The signature is of type TPMT_SIGNATURE ( just FYI ) .
This document defines a YANG RPC and a small number of configuration
node 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 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 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 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 are the Trusted Platform Module (TPM) TPM1.2 and
TPM2.0 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 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).
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).
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
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.  The functions of this YANG
module are restricted to 0-1 TPMs per hardware component.
This YANG module imports modules from RFC6991, RFC8348, I-D.ietf-
netconf-keystore, ietf-tcg-algs.yang ref-ietf-tcg-algs.
'TPMs' - Indicates that multiple TPMs on the device can support
remote attestation, This feature is applicable in cases where
multiple line cards, each with its own TPM.
'bios' - Indicates the device supports the retrieval of bios event
logs.
'ima' - Indicates the device supports the retrieval of Integrity
Measurement Architecture event logs.
'netequip_boot' - Indicates the device supports the retrieval of
netequip boot event logs.
This module supports the following types of attestation event logs:
'ima', 'bios', and 'netequip_boot'.
container 'rats-support-structures' - This houses the set of
information relating to a device's TPM(s).
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.
container 'compute-nodes' - When there is more than one TPM
supported, this container maintains the set of information related to
the compute associated with a specific TPM.  This allows each
specific TPM to identify on which 'compute-node' it belongs.
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 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
TCG-Algos.
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 TCG-Algos.
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.
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" ref-ietf-tcg-algs.
'TPMs': Indicates that multiple TPMs on the device can support
remote attestation.  This feature is applicable 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.
'ima': Indicates that the device supports the retrieval of event
logs from the Linux Integrity Measurement Architecture (IMA).
'netequip_boot': Indicates that the device supports the retrieval
of netequip boot event logs.
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 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.
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.
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.
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.
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.
To be defined yet.  But keeping up with changes to ietf-tcg-algs.yang
will be necessary.
To be defined yet.  But keeping up with changes to "ietf-tcg-
algs.yang" will be necessary.
'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.
'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 a Attestation Identity Key (AIK) within the
TPM.
RPC: 'tpm12-challenge-response-attestation' - Need to verify that the
certificate is provided is able to support Attestation on the
targeted TPM.
RPC: 'tpm20-challenge-response-attestation' - Need to verify that the
certificate is provided is able to support Attestation on the
targeted TPM.
RPC: 'log-retrieval' - Pulling lots of logs can chew up system
resources.
'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.