draft-ietf-rats-yang-tpm-charra-04.txt   draft-ietf-rats-yang-tpm-charra-05.txt 
RATS Working Group H. Birkholz RATS Working Group H. Birkholz
Internet-Draft M. Eckel Internet-Draft M. Eckel
Intended status: Standards Track Fraunhofer SIT Intended status: Standards Track Fraunhofer SIT
Expires: June 19, 2021 S. Bhandari Expires: July 18, 2021 S. Bhandari
ThoughtSpot ThoughtSpot
E. Voit E. Voit
B. Sulzen B. Sulzen
Cisco Cisco
L. Xia L. Xia
Huawei Huawei
T. Laffey T. Laffey
HPE HPE
G. Fedorkow G. Fedorkow
Juniper Juniper
December 16, 2020 January 14, 2021
A YANG Data Model for Challenge-Response-based Remote Attestation A YANG Data Model for Challenge-Response-based Remote Attestation
Procedures using TPMs Procedures using TPMs
draft-ietf-rats-yang-tpm-charra-04 draft-ietf-rats-yang-tpm-charra-05
Abstract Abstract
This document defines a YANG RPC and a minimal datastore required to This document defines a YANG RPC and a minimal datastore required to
retrieve attestation evidence about integrity measurements from a retrieve attestation evidence about integrity measurements from a
device following the operational context defined in device following the operational context defined in TPM-based Network
[I-D.ietf-rats-tpm-based-network-device-attest]. Complementary Device Remote Integrity Verification. Complementary measurement logs
measurement logs are also provided by the YANG RPC originating from are also provided by the YANG RPC originating from one or more roots
one or more roots of trust of measurement. The module defined of trust of measurement. The module defined requires at least one
requires at least one TPM 1.2 or TPM 2.0 and corresponding Trusted TPM 1.2 or TPM 2.0 and corresponding Trusted Software Stack included
Software Stack included in the device components of the composite in the device components of the composite device the YANG server is
device the YANG server is running on. running on.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 19, 2021. This Internet-Draft will expire on July 18, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. The YANG Module for Basic Remote Attestation Procedures . . . 3 2. The YANG Module for Basic Remote Attestation Procedures . . . 3
2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3 2.1. YANG Modules . . . . . . . . . . . . . . . . . . . . . . 3
2.2. YANG Modules . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. ietf-tpm-remote-attestation . . . . . . . . . . . . . 3
2.2.1. ietf-tpm-remote-attestation . . . . . . . . . . . . . 6 2.1.2. ietf-tcg-algs . . . . . . . . . . . . . . . . . . . . 32
2.2.2. ietf-tcg-algs . . . . . . . . . . . . . . . . . . . . 30 3. IANA considerations . . . . . . . . . . . . . . . . . . . . . 48
3. IANA considerations . . . . . . . . . . . . . . . . . . . . . 46 4. Security Considerations . . . . . . . . . . . . . . . . . . . 48
4. Security Considerations . . . . . . . . . . . . . . . . . . . 46 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 49
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 47 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 7.1. Normative References . . . . . . . . . . . . . . . . . . 51
7.1. Normative References . . . . . . . . . . . . . . . . . . 49 7.2. Informative References . . . . . . . . . . . . . . . . . 52
7.2. Informative References . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
This document is based on the terminology defined in the This document is based on the terminology defined in the
[I-D.ietf-rats-architecture] and uses the operational context defined [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 in [I-D.ietf-rats-tpm-based-network-device-attest] as well as the
interaction model and information elements defined in interaction model and information elements defined in
[I-D.ietf-rats-reference-interaction-models]. The currently [I-D.ietf-rats-reference-interaction-models]. The currently
supported hardware security modules (HWM) are the Trusted Platform supported hardware security modules (HWM) are the Trusted Platform
Module (TPM) [TPM1.2] and [TPM2.0] specified by the Trusted Computing Module (TPM) [TPM1.2] and [TPM2.0] specified by the Trusted Computing
skipping to change at page 3, line 34 skipping to change at page 3, line 33
accordance with the Remote Attestation Procedures (RATS) architecture accordance with the Remote Attestation Procedures (RATS) architecture
[I-D.ietf-rats-architecture] and the corresponding challenge-response [I-D.ietf-rats-architecture] and the corresponding challenge-response
interaction model defined in the interaction model defined in the
[I-D.ietf-rats-reference-interaction-models] document. A fresh nonce [I-D.ietf-rats-reference-interaction-models] document. A fresh nonce
with an appropriate amount of entropy MUST be supplied by the YANG 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 client in order to enable a proof-of-freshness with respect to the
attestation evidence provided by the attester running the YANG attestation evidence provided by the attester running the YANG
datastore. The functions of this YANG module are restricted to 0-1 datastore. The functions of this YANG module are restricted to 0-1
TPMs per hardware component. TPMs per hardware component.
2.1. Tree Diagram 2.1. YANG Modules
module: ietf-tpm-remote-attestation 2.1.1. ietf-tpm-remote-attestation
+--rw rats-support-structures
+--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
+--rw tpms
| +--rw tpm* [tpm-name]
| +--rw tpm-name string
| +--ro hardware-based? boolean
| +--ro tpm-physical-index? int32 {ietfhw:entity-mib}?
| +--ro tpm-path? string
| +--ro compute-node compute-node-ref {tpm:TPMs}?
| +--ro tpm-manufacturer? string
| +--rw tpm-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 tpm-status enumeration
| +--rw certificates
| +--rw certificate* [certificate-name]
| +--rw certificate-name string
| +--rw certificate-keystore-ref? leafref
| +--rw certificate-type? enumeration
+--rw attester-supported-algos
+--rw tpm12-asymmetric-signing* identityref {taa:TPM12}?
+--rw tpm12-hash* identityref {taa:TPM12}?
+--rw tpm20-asymmetric-signing* identityref {taa:TPM20}?
+--rw tpm20-hash* identityref {taa:TPM20}?
rpcs: This YANG module imports modules from [RFC6991], [RFC8348],
+---x tpm12-challenge-response-attestation {taa:TPM12}? [I-D.ietf-netconf-keystore], ietf-tcg-algs.yang Section 2.1.2.3.
| +---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
+---x tpm20-challenge-response-attestation {taa:TPM20}?
| +---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
+---x log-retrieval
+---w input
| +---w log-selector* []
| | +---w tpm-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 tpm-name? string
+--ro up-time? uint32
+--ro log-result
+--ro (attested_event_log_type)
+--:(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)
| +--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)
+--ro boot-event-logs
+--ro boot-event-entry* [event-number]
+--ro event-number uint64
+--ro filename-hint? string
+--ro filedata-hash? binary
+--ro filedata-hash-algorithm? string
+--ro file-version? string
+--ro file-type? string
+--ro pcr-index? pcr
2.2. YANG Modules 2.1.1.1. Features
2.2.1. ietf-tpm-remote-attestation This module supports the following features:
This YANG module imports modules from [RFC6991], [RFC8348], <TPMs> - Indicates that multiple TPMs on the device can support
[I-D.ietf-netconf-keystore], ietf-tcg-algs.yang. remote attestation, This feature is applicable in cases where
multiple line cards, each with its own TPM.
2.2.1.1. Identities <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.
2.1.1.2. Identities
This module supports the following types of attestation event logs: This module supports the following types of attestation event logs:
<ima>, <bios>, and <netequip_boot>. <ima>, <bios>, and <netequip_boot>.
2.2.1.2. RPCs 2.1.1.3. RPCs
<tpm12-challenge-response-attestation> - Allows a Verifier to request 2.1.1.3.1. <tpm20-challenge-response-attestation>
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 This RPC allows a Verifier to request a quote of PCRs from a TPM2.0
a quote of PCRs from a TPM2.0 compliant cryptoprocessor. When one or compliant cryptoprocessor. Where the feature <TPMs> is active, and
more <certificate-name> is not provided, all TPM2.0 compliant one or more <certificate-name> is not provided, all TPM2.0 compliant
cryptoprocessors will respond. cryptoprocessors will respond. A YANG tree diagram of this RPC is as
follows:
<log-retrieval> - Allows a Verifier to acquire the evidence which was +---x tpm20-challenge-response-attestation {taa:TPM20}?
extended into specific PCRs. +---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
2.2.1.3. Data Nodes An example of an RPC challenge requesting PCRs 0-7 from a SHA256 bank
could look like the following:
container <rats-support-structures> - This exists when there are more <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
than one TPM for a particular Attester. This allows each specific <tpm20-challenge-response-attestation>
TPM to identify on which <compute-node> it belongs. xmlns="urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation">
<nonce>110101010110011011111001010010100</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>
and a successful response might be formated as follows:
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<tpm12-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>
<TPMS_QUOTE_INFO>
(raw information from the TPM Quote, this includes a digest
across the requested PCRs, the nonce, TPM2 time counters.)
</TPMS_QUOTE_INFO>
<quote-signature>
(signature across TPMS_QUOTE_INFO)
</quote-signature>
</tpm12-attestation-response>
</rpc-reply>
2.1.1.4. <tpm12-challenge-response-attestation>
This RPC allows a Verifier to request a quote of PCRs from a TPM1.2
compliant cryptoprocessor. Where the feature <TPMs> is active, and
one or more <certificate-name> is not provided, all TPM1.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
2.1.1.5. <log-retrieval>
This RPC allows a Verifier to acquire the evidence which was extended
into specific PCRs. A YANG tree diagram of this RPC is as follows:
+---x log-retrieval
+---w input
| +---w log-selector* []
| | +---w tpm-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 tpm-name? string
+--ro up-time? uint32
+--ro log-result
+--ro (attested_event_log_type)
+--:(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)
| +--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)
+--ro boot-event-logs
+--ro boot-event-entry* [event-number]
+--ro event-number uint64
+--ro filename-hint? string
+--ro filedata-hash? binary
+--ro filedata-hash-algorithm? string
+--ro file-version? string
+--ro file-type? string
+--ro pcr-index? pcr
2.1.1.6. Data Nodes
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
Section 2.1.1.7.
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 container <tpms> - Provides configuration and operational details for
each supported TPM, including the tpm-firmware-version, PCRs which each supported TPM, including the tpm-firmware-version, PCRs which
may be quoted, certificates which are associated with that TPM, and may be quoted, certificates which are associated with that TPM, and
the current operational status. Of note is the certificates which the current operational status. Of note is the certificates which
are associated with that TPM. As a certificate is associated with a are associated with that TPM. As a certificate is associated with a
single Attestation key, knowledge of the certificate allows a single Attestation key, knowledge of the certificate allows a
specific TPM to be identified. specific TPM to be identified.
+--rw tpms
+--rw tpm* [tpm-name]
+--rw tpm-name string
+--ro hardware-based? boolean
+--ro tpm-physical-index? int32 {ietfhw:entity-mib}?
+--ro tpm-path? string
+--ro compute-node compute-node-ref {tpm:TPMs}?
+--ro tpm-manufacturer? string
+--rw tpm-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 tpm-status enumeration
+--rw certificates
+--rw certificate* [certificate-name]
+--rw certificate-name string
+--rw certificate-keystore-ref? -> /ks:keystore/asymmetric-keys/asymmetric-key/certificates/certificate/name
+--rw certificate-type? enumeration
container <attester-supported-algos> - Identifies which TCG container <attester-supported-algos> - Identifies which TCG
algorithms are available for use the Attesting platform. This allows algorithms are available for use the Attesting platform. This allows
an operator to limit algorithms available for use by RPCs to just a an operator to limit algorithms available for use by RPCs to just a
desired set from the universe of all allowed by TCG. desired set from the universe of all allowed by TCG.
2.2.1.4. YANG Module +--rw attester-supported-algos
+--rw tpm12-asymmetric-signing* identityref {taa:TPM12}?
+--rw tpm12-hash* identityref {taa:TPM12}?
+--rw tpm20-asymmetric-signing* identityref {taa:TPM20}?
+--rw tpm20-hash* identityref {taa:TPM20}?
<CODE BEGINS> file ietf-tpm-remote-attestation@2020-12-09.yang 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.
+--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
2.1.1.7. YANG Module
<CODE BEGINS> file ietf-tpm-remote-attestation@2020-12-17.yang
module ietf-tpm-remote-attestation { module ietf-tpm-remote-attestation {
namespace "urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation"; namespace "urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation";
prefix "tpm"; prefix "tpm";
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
} }
import ietf-hardware { import ietf-hardware {
prefix ietfhw; prefix ietfhw;
} }
skipping to change at page 30, line 21 skipping to change at page 32, line 14
base taa:hash; base taa:hash;
} }
description description
"Platform supported TPM20 hash algorithms."; "Platform supported TPM20 hash algorithms.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
2.2.2. ietf-tcg-algs 2.1.2. ietf-tcg-algs
Cryptographic algorithm types were initially included within -v14 Cryptographic algorithm types were initially included within -v14
NETCONF's iana-crypto-types.yang. Unfortunately all this content NETCONF's iana-crypto-types.yang. Unfortunately all this content
including the algorithms needed here failed to make the -v15 used including the algorithms needed here failed to make the -v15 used
WGLC. As a result this document has encoded the TCG Algorithm WGLC. As a result this document has encoded the TCG Algorithm
definitions of [TCG-Algos], revision 1.32. By including this full definitions of [TCG-Algos], revision 1.32. By including this full
table as a separate YANG file within this document, it is possible table as a separate YANG file within this document, it is possible
for other YANG models to leverage the contents of this model. for other YANG models to leverage the contents of this model.
2.2.2.1. Features 2.1.2.1. Features
There are two types of features supported <TPM12> and <TPM20>. There are two types of features supported <TPM12> and <TPM20>.
Support for either of these features indicates that a cryptoprocessor Support for either of these features indicates that a cryptoprocessor
supporting the corresponding type of TCG API is present on an supporting the corresponding type of TCG API is present on an
Attester. Most commonly, only one type of cryptoprocessor will be Attester. Most commonly, only one type of cryptoprocessor will be
available on an Attester. available on an Attester.
2.2.2.2. Identities 2.1.2.2. Identities
There are three types of identities in this model. There are three types of identities in this model.
The first are the cryptographic functions supportable by a TPM The first are the cryptographic functions supportable by a TPM
algorithm, these include: <asymmetric>, <symmetric>, <hash>, algorithm, these include: <asymmetric>, <symmetric>, <hash>,
<signing>, <anonymous_signing>, <encryption_mode>, <method>, and <signing>, <anonymous_signing>, <encryption_mode>, <method>, and
<object_type>. The definitions of each of these are in Table 2 of <object_type>. The definitions of each of these are in Table 2 of
[TCG-Algos]. [TCG-Algos].
The second are API specifications for tpms: <tpm12> and <tpm2>. The second are API specifications for tpms: <tpm12> and <tpm2>.
The third are specific algorithm types. Each algorithm type defines The third are specific algorithm types. Each algorithm type defines
what cryptographic functions may be supported, and on which type of what cryptographic functions may be supported, and on which type of
API specification. It is not required that an implementation of a API specification. It is not required that an implementation of a
specific TPM will support all algorithm types. The contents of each specific TPM will support all algorithm types. The contents of each
specific algorithm mirrors what is in Table 3 of [TCG-Algos]. specific algorithm mirrors what is in Table 3 of [TCG-Algos].
2.2.2.3. YANG Module 2.1.2.3. YANG Module
<CODE BEGINS> ietf-tcg-algs@2020-09-18.yang <CODE BEGINS> ietf-tcg-algs@2020-09-18.yang
module ietf-tcg-algs { module ietf-tcg-algs {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-tcg-algs"; namespace "urn:ietf:params:xml:ns:yang:ietf-tcg-algs";
prefix taa; prefix taa;
organization organization
"IETF RATS Working Group"; "IETF RATS Working Group";
skipping to change at page 47, line 5 skipping to change at page 48, line 47
will be necessary. will be necessary.
4. Security Considerations 4. Security Considerations
The YANG module specified in this document defines a schema for data The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC5246]. [RFC8446].
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
Container: </rats-support-structures/attester-supported-algos> Container: </rats-support-structures/attester-supported-algos>
skipping to change at page 47, line 49 skipping to change at page 49, line 42
RPC: <log-retrieval> - Pulling lots of logs can chew up system RPC: <log-retrieval> - Pulling lots of logs can chew up system
resources. resources.
5. Acknowledgements 5. Acknowledgements
Not yet. Not yet.
6. Change Log 6. Change Log
Changes from version 04 to version 05:
o YANG Dr comments covered
Changes from version 03 to version 04: Changes from version 03 to version 04:
o TPM1.2 Quote1 eliminated o TPM1.2 Quote1 eliminated
o YANG model simplifications so redundant info isn't exposed
o YANG model simplifications so redundant info isn't exposed
Changes from version 02 to version 03: Changes from version 02 to version 03:
o moved to tcg-algs o moved to tcg-algs
o cleaned up model to eliminate sources of errors o cleaned up model to eliminate sources of errors
o removed key establishment RPC o removed key establishment RPC
o added lots of XPATH which must all be scrubbed still o added lots of XPATH which must all be scrubbed still
skipping to change at page 50, line 15 skipping to change at page 52, line 15
[TPM1.2] TCG, ., "TPM 1.2 Main Specification", October 2003, [TPM1.2] TCG, ., "TPM 1.2 Main Specification", October 2003,
<https://trustedcomputinggroup.org/resource/tpm-main- <https://trustedcomputinggroup.org/resource/tpm-main-
specification/>. specification/>.
[TPM2.0] TCG, ., "TPM 2.0 Library Specification", March 2013, [TPM2.0] TCG, ., "TPM 2.0 Library Specification", March 2013,
<https://trustedcomputinggroup.org/resource/tpm-library- <https://trustedcomputinggroup.org/resource/tpm-library-
specification/>. specification/>.
7.2. Informative References 7.2. Informative References
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
Authors' Addresses Authors' Addresses
Henk Birkholz Henk Birkholz
Fraunhofer SIT Fraunhofer SIT
Rheinstrasse 75 Rheinstrasse 75
Darmstadt 64295 Darmstadt 64295
Germany Germany
Email: henk.birkholz@sit.fraunhofer.de Email: henk.birkholz@sit.fraunhofer.de
 End of changes. 33 change blocks. 
177 lines changed or deleted 254 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/