ietf-rats-wg / basic-yang-module Goto Github PK

Details are in Pull Request 24.

Must be better than "log event type"

During the charra presentation at IETF 108, we said we were going to ask the following question to the list: "Should the algorithm set defined in YANG be reduced to just those asymmetric algorithms currently exposed in the current TPM 1.2 and 2 specifications?"

This is reflected seen in https://www.ietf.org/proceedings/108/slides/slides-108-rats-sessb-charra-update-00, Slide 7.

The proposal I would like to make is as follows:

The TCG tracked algorithms supportable by a TPM should be the only ones included in a charra maintained list of YANG identities.

• This identity set needs to be extendable to new algorithms for any YANG models which augment charra.

TCG Algorithm Registry Revision 01.32, Table 3 at https://trustedcomputinggroup.org/wp-content/uploads/TCG-_Algorithm_Registry_r1p32_pub.pdf contains the algorithms we should encode.

• There are other types of information within this table, and we might as well encode the full table within a YANG model. That way we can explicitly make the scope of a "ietf-tcg-algs.yang" model the contents this TCG table encoded in YANG.

• The YANG model will indicate what TCG algorithms are deprecated by the IETF. However identities for these deprecated algorithms from the TCG table will be assigned. (e.g., SHA-1)

This issues tries to capture the remaining issue about the difference between the log features "ima" and "netequip_boot":

The difference between the two log types is the scope of events represented in the most expressive way possible. While ima changes the formats during layered attestation ending up using the "richest format" when the kernel becomes the Attesting Environment, netequip_boot uses the "rich kernel format" from the very start.
Neteq therefore can reuse the ima-event grouping and can use "https://www.trustedcomputinggroup.org/wp-content/uploads/TCG_IWG_CEL_v1_r0p30_13feb2021.pdf Section 4.3" as the reference in "feature netequip_boot". But it seems to me that it somehow still should be its own feature, as there is a difference in the semantics how the format in that grouping is used.

Here I am trying to capture what I think of as the most straight forward options right now:

Should a "feature driven" optional statement be added to "ima-event" that acts as a flag that exists based on the netequip_boot feature (which I think would be more verbose where logs are already verbose) and ima and netequip_boot feature are merged into ima?

or

Should netequip_boot feature remain a separate statement that also uses ima-event, but has the extended scope of ima expressiveness described in its feature description?

Please add obvious options that elude me right now.

TPM 2.0 quote information (attestation data) is of type TPM2B_ATTEST, not TPMS_QUOTE_INFO. TPMS_QUOTE_INFO is a sub element of the TPM2B_ATTEST. In a TPM2_Quote operation, the TPM signs a hash of the TPM2B_ATTEST structure. The signature is of type TPMT_SIGNATURE (just FYI).

The description of COSE_Algorithm-value

There are several issues with the current YANG model. I am grouping them as one as I have a single YANG model pull request to cover all of these.

The issues I believe need to be addressed include:

(1) PCR numbers should be their own type, not a UINT8. PCRs should be limited to [0..31]

(2) We should use ENUMs instead of strings for TCG and IETF crypto algorithm types. Strings allow lots of errors to be introduced which we can protect using a larger, more detailed ENUM construct.

(3) Most devices do not have multiple line cards. Because of that, we should not have nested keys of [node id] [tpm name]. This adds unnecessary complexity for the vast majority of users. Instead the tpm should have a mandatory leafref back to node-id when compute-nodes is not null.

(4) The YANG doctors will not let us have a TPM-Name of "ALL". Instead of "ALL" we should be able to assume that an RPC means all hardware based TPMs if a specific TPM is not named in the RPC. Note that this means that we should not use TPM-name as a KEY in any RPC.

(5) We should add leaf for a unique TPM-Path. It might be claimed this is irrelevant with the existing key structure, but

• likely the YANG model itself will learn the TPM this way after boot.
• You could add/remove/migrate new virtual TPMs, more easily only re-allocating an existing path when the new vTPM is activated.

(6) We should have optional YANG features for TPM1.2 and TPM2.0 so that RPCs are not exposed when there are no such TPMs of that type are supported.

(7) We should great new grouping for the log algorithm types. These groupings can be reused for a Telemetry/Subscription feed of individual log entries. Other log types like those proposed for "netequip boot" by Bin Cao can then be merged.

See https://mailarchive.ietf.org/arch/msg/rats/25hOXIYNmUeXRIPdJknfM3kqmsk/

This is item (10) split out from issue #6

As ietf-tcg-algs.yang has to be updated over time, the question is how to facilitate that with the least growing pains. One option is $SUBJECT. We should have a clear understanding how this can work and how this should work in the end.

Please confirm that all changes made in ietf-rats/draft-birkholz-rats-basic-yang-module#17 are reflected here.