[Rats] revision -09 of RIV draft addressing AD comments

[Guy Fedorkow <[e-mail]>]

Roman,
  Thanks for such a careful review!  I've tried to address each of the comments in notes below and in corrections to the RIV document.
I've checked Revision 09 into datatracker
https://datatracker.ietf.org/doc/draft-ietf-rats-tpm-based-network-device-attest/

  Let me know if we've missed anything!
/guy

--------------------------




[External Email. Be cautious of content]

Nov 3, 2021

Hi!

I performed an AD review of draft-ietf-rats-tpm-based-network-device-attest-08.  Thanks for this document.  My comment are below.

There were quite a few normative TCG base specifications on which the document relies.  I tried my best to check them when possible, but due to the volume, it may be the case that I missed a few things and some of my feedback below is already answered in them.  If so, please just let me know.  It's probably too much work to do in all cases but providing section numbers to the TCG base specs when referring to specific behavior could help make the text even more approachable.

I appreciate that this document is both trying to describe the RIV use case and specify normative behavior.  There were a few places noted below where I ran into some trouble distinguishing between the narrative prose (informative) and the explicit normative behavior.  I also found a few places where normative language seemed repetitive and conflicting.  If possible, reducing this duplicate could simplify the document make it easier to adopt by implementers.

** Section 1.2.  What is the intent to define "attestation" generically and then in the context of TCG a few paragraphs down?
[guy] reworded as compatible steps in narrowing the scope from RATS to TPM to network devices

** Section 1.2.
   The goal of attestation is simply to assure an administrator that the
   device configuration and software that was launched when the device
   was last started is authentic and untampered-with.

-- Editorial.  s/is simply to assure/is to assure/  
[guy] I’d like to highlight the fact that in spite of reams of complexity, the goal is very straightforward, “has my router been hacked?”.
  
-- We might want to quickly define what "authentic" means (i.e., build/configured as intended by the manufacturer?) 
[guy] done
-- Would there be any other users beyond an administrator relevant here?  Say an auditor?  
[guy] Sure; done

** Section 1.2. Editorial
   Typically, the
   manufacturer of an embedded device would be accepted ...

As a matter of consistency, given that the text said earlier that RIV is focused on "network equipment" should this language be used instead of "embedded device"?  
[guy] fixed

** Section 1.4.  Editorial.  Recommend being clearer on the scope of configuration:

OLD
Verification of software and configuration of the
      device shows that the software that was authorized for
      installation by the administrator has actually been launched.

NEW
Verification that the software and associated configuration was authorized for installation by the administrator has actually been launched. 
[guy] ok

** Section 1.5.  Editorial. From the perspective of consistent terminology, Sections 1.2 and 1.4 use "administrator" as the party concerned about RIV.  This section seems to have adopted "network managers".  Is there a reason to use different terminology?  
[guy] Nope - fixed

** Section 1.7.1.  Editorial. Please provide a citation for Linux IMA on first use. 
[guy] ok

** Section 2.1.  In this section, the reader is told that RIV is a two-phase process.  In Section 1.5, the reader was informed that it was a four-step process.  What is the relationship between these two?  Why this distinction? 
 [guy] Add an xref to 2.1

** Section 2.1.  Per "Hashes are also extended, or cryptographically folded, into the TPM ...", what does it mean to "extend" or "fold" a hash?  There is later text that talks about "extending" with a TPM so an earlier explanation or a forward reference would help here  
[guy] added forward xref

** Section 2.1. "Once the device is running and has operational network      connectivity, a separate, trusted Verifier ...", what distinction is being made here by calling a Verifier "trusted"?  Are there "untrusted" ones?  
[guy] Changed to “a separate Verifier, running in its own trusted environment,”

** Section 2.1.
The result is that the Verifier can verify the device's identity by
   checking the Subject Field
Per Table 8-1 of 802.1AR-2018 (https://urldefense.com/v3/__https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8423794__;!!NEt6yMaO-gk!UNDiQXpCxaBT3PO-wpDMk2p5vVGjywG4k3TZ3aNUItvJ3s8-saAyFDgP0VH1A3B3MWE$ ), isn't this the "subject" field (lower case)?
[guy]   yes

** Does this document make a distinction between BIOS and UEFI?  The terms "BIOS", "UEFI" and "BIOS UEFI" are used throughout the document.

-- Uses "BIOS" = Sections 2.1, 2.1.2, 2.4.1
-- Uses "UEFI" = Section 2.1.2
-- Uses "UEFI BIOS" = Sections 2.1.1, 2.4.2
-- Uses "UEFI-compatible BIOS" = Section 2.4.1

If there is a distinction being drawn, please make that clear.  Otherwise, I would recommend consistent terminology and perhaps some up-front level setting on these terms.
[guy] I’m going with “UEFI BIOS”

** Section 2.1. The last paragraph starts using the term PCR without definition it. 
[guy]  eliminated

** Section 2.1.1 and 2.1.2.  I benefited from the background these sections provided to understand how TPMs work.  However, it wasn't clear to me what normative guidance an implementer should take from it (e.g., Figure 2).  If this is informative/out of scope can this be made clear.  
[guy] I added a clause saying there are no normative specs for other platforms.

** Section 2.1.1.
TPM attestation is strongly focused on Platform Configuration
   Registers (PCRs),
What does "strongly focused on" mean?  Is that equivalent to saying "depends upon"?  
[guy] fixed

** Section 2.1.2.  Typo. s/paricular/particular. 
[guy] fixed

** Section 2.2.  Which optional part of Section 5.4 of IEEE-802-1AR apply to RIV?  This text here appears to be making item 5.4.b mandatory.  Any thing else?   I amended RIV to explicitly say Serial Number is mandatory in RIV, even if not in AR

** Section 2.2.  Typo.  s/Subject Alt Name/subjectAltName/  
[guy] fixed

** Section 2.2.  subjectAltName (SAN) is mentioned for the first time here.
-- What is the expected value for it?  Is it following the optional guidance of 5.4.g of 802.1AR (i.e., to be the hardware module name)?

-- What role does the SAN play in validation?  Section 2.1 said that only the subject field is checked ("The result is that the Verifier can verify the device's identity by checking the Subject Field and signature of certificate  containing the TPM's attestation public key").  Is the SAN considered too?  
[guy] I’ve changed it to mark it as optional

** Section 2.2. Typo.  s/certifcate/certificate/  
[guy] ok

** Section 2.3.  Thanks for these definitions.  There appears to be a bit of mismatch and redundancy for me based on previous sections.  Section 1.2 explicitly said that Attester, Verifier, Relying Party, etc are terms from draft-ietf-rats-architecture.  That document has definitions for these terms (in Section 4.1) and defines them as roles.  This section appears to provide fairly complimentary definitions and also frames them as components (rather than roles).  Is there a RIV-specific need to redefine these terms?
[guy] I made the reference to rats-arch as the defining doc more prominent.

** Section 2.3.
   To achieve interoperability, the following standards components
   SHOULD be used:

The introductory sentence noted above says "the following ... components SHOULD be used".

-- The subsequent bullets contain a mix of statements that contain MUSTs and SHOULDs.  What does a "SHOULD on a MUST mean"?  For example, "3.  Device Identity MUST be managed ...".  Is it really optional?  Section 2.4 and 3.1.1 repeats that using IEEE-802-1AR is a MUST.
 [guy]  I tightened up the MUSTs

-- How do things interoperate if one chooses not to use the prescribed standards such as the "SHOULD" flexibility in #4? 
[guy]  I tightened up the MUSTs


** Section 2.3. Given the normative guidance here, [IMA] has to be a normative reference. 
[guy] Yes; done

** Section 2.3. Item #5
       While the TAP IM gives a protocol-
       independent description of the data elements involved, it's
       important to note that quotes from the TPM are signed inside the
       TPM, so MUST be retrieved in a way that does not invalidate the
       signature, as specified in [I-D.ietf-rats-yang-tpm-charra], to
       preserve the trust model.
This sentence doesn't parse.
[guy] I tweaked.


** Section 2.3. Item #6

Reference Values SHOULD be encoded as SWID or CoSWID tags, as
       defined in the TCG RIM document [RIM], compatible with NIST IR
       8060 [NIST-IR-8060] and the IETF CoSWID draft
       [I-D.ietf-sacm-coswid].  See Section 2.4.1.

-- Item #4 of Appendix A of [RIM] already says that SWID and CoSWID "SHOULD be used" and also references NIST-IR-8060.  The text here is restating normatively what the underlying reference already has.  Saying that "Reference Values SHOULD be encoded in [RIM]" seems like an equivalent statement (and makes clear what new constraints are being placed by this document)
[guy] Re-worded

-- Section 3.1.3 seems conflict with this weaker SHOULD noted above because it seems to repeat the same text but with a  MUST:
Reference Values MUST
   be encoded as SWID or CoSWID tags, signed by the device manufacturer,
   as defined in the TCG RIM document [RIM], compatible with NIST IR
   8060 [NIST-IR-8060] or the IETF CoSWID draft [I-D.ietf-sacm-coswid].
[guy] Avoided repeated phrase


** Section 2.4. Many of these "simplifying assumptions" appear to be duplicates.  It might be clearer to described the mandatory requirements in one place.
-- Per bullet #1, how much of this is unsaid per the language in Section 2.2 on IEEE.802.1AR?
[guy]    I added serial number as a MUST, noted that everything else that’s optional in .1AR stays optional

-- Per bullet #2, using TAP is listed as a MUST here, but Section 2.4 #5 already said it's a SHOULD (or something more, see editorial note above)
[guy]  I’m not sure I see the SHOULD causing the problem…  can you be more specific?

-- Per bullet #3, The section appears to be a duplicate.  Section 2.3 item #6, already said that RIM/SWID/CoSWID SHOULD be used.  Section 3.1.3 says RIMS MUST use SWID/CoSWID.
[guy] I shortened the sentence; #6 says how to encode RIMs, this bullet says the manufacturer has provide them.

** Section 2.4.1.
TCG has also published the PC Client Reference Integrity Measurement specification [PC-Client-RIM], which focuses on a SWID-compatible format suitable for expressing expected measurement values in the specific case of a UEFI-compatible BIOS ...

How is a developer intended to action this reference to [PC-Client-RIM] given the RIV use case specified in this document?  Can [PC-Client-RIM] be used instead of [RIM]? Is this guidance complimentary?
[guy] They’re complimentary; one cannot replace the other.  I’ve tweaked the wording.



** Section 2.4.2.  There appears to be a duplication of the acceptable log formats with different normative requirements.

(a) Section 2.3 said:
   4.  Attestation logs SHOULD be formatted according to the Canonical
       Event Log format [Canonical-Event-Log], although other
       specialized formats may be used.  UEFI-based systems MAY use the
       TCG UEFI BIOS event log [EFI-TPM].

(b) Here the text says
   There are multiple event log formats which may be supported as viable
   formats of Evidence between the Attester and Verifier:

   *  IMA Event log file exports [IMA]

   *  TCG UEFI BIOS event log (TCG EFI Platform Specification for TPM
      Family 1.1 or 1.2, Section 7) [EFI-TPM]

   *  TCG Canonical Event Log [Canonical-Event-Log]

Does it need to be said twice?  With different normative text?

[guy] I focused the text on two formats as a Simplifying Assumption, and removed the duplicative statements.

** Section 3.1.1.  This appears to be duplicate text.  Use of [IEEE-802-1AR] has already been stated a few times already.
(a) Section 1.5
   1.  Identity: Device identity MUST be based on IEEE 802.1AR Device
       Identity (DevID) [IEEE-802-1AR],
[guy] I removed the normative language

(b) Section 2.2.
RIV specifies the
      use of an IEEE 802.1AR Device Identity (DevID) [IEEE-802-1AR],
      signed by the device manufacturer, containing the device serial
      number.
[guy] This one is about the serial number extension.  I added an xref to where I say that more explicitly.

(c) Section 2.3
   3.  Device Identity MUST be managed as specified in IEEE 802.1AR
       Device Identity certificates [IEEE-802-1AR], with keys protected
       by TPMs.

(d) Section 2.4

The product to be attested MUST be shipped with an IEEE 802.1AR
      Device Identity and an Initial Attestation Key (IAK) with
      certificate.
[guy] This one is about requiring “both” IAK and IDevID, i.e. a requirement beyond the scope of 802.1AR

** Section 3.1.2.
   The Attester's TPM Keys MUST be associated with the DevID on the
   Verifier (see [Platform-DevID-TPM-2.0] and Section 5 Security
   Considerations, below).

Can a more specific section in [Platform-DevId-TPM-2.0] be provided?  The relevant guidance on how to do that association didn't easily jump out for me.  Should the TPM 2.0 association guidance also be followed even if using TPM 1.2?
[guy] I xref’d the section that says to use the same Subject Name in the two certs, and eliminated the TCG reference here.
The sentence was poorly worded anyway – it’s the Verifier that needs to be able to tell if the two keys are from the same TPM

** Section 3.1.3.
   The Verifier MUST obtain trustworthy Reference Values (encoded as
   SWID or CoSWID tags [I-D.ietf-sacm-coswid].

-- Should SWID also get a reference if CoSWID gets one?


-- What's the difference in the guidance in this sentence and the last paragraph of the section "In either case the Reference Values must be ..."?


** Section 3.1.3.  Recommend being clearer on scope.
OLD
   This document does not specify the format or contents for the
   Appraisal Policy for Evidence, but Reference Values may be acquired
   in one of two ways:

NEW
This document does not specify the format, contents, or mechanism to convey the Appraisal Policy for Evidence ...


** Section 3.1.3.  Per "... but Reference Values may be acquired in one of two ways: ...", is what is said next already described in bullet #4, Section 2.3?

** Section 3.1.3
   In either case, the Verifier Owner MUST select the source of trusted
   Reference Values through the Appraisal Policy for Evidence.

What does it mean to "select ... _through_ the Appraisal Policy of Evidence"?  Does it mean that the policy is going to specify the appropriate location/source of Reference Values?  If that is the case, that contradicts the language in the earlier paragraph that "This document does not specify the format or contents of the Appraisal Policy ..." because how a normative statement is being made about what this policy should contain (i.e., the content).

** Figure 4.  Editorial. I'm not sure if it was intentional.  This figure and Figure 3 seem to show the same nodes in the RIV architecture, but use slightly different names.

[guy] Thank You!  I’ve deleted most of 3.1.3 and returned the focus to appraisal policy

** Section 3.1.3
   In either case the Reference Values must be generated, acquired and
   delivered in a secure way, including reference measurements of
   firmware and bootable modules taken according to TCG PC Client
   [PC-Client-BIOS-TPM-2.0] and Linux IMA [IMA].

Section 2.3, #2 says:
For devices using UEFI and Linux, measurements of firmware and
       bootable modules SHOULD be taken according to TCG PC Client
       [PC-Client-BIOS-TPM-1.2] or [PC-Client-BIOS-TPM-2.0], and Linux
       IMA [IMA]

-- This section uses a lower case "must" but Section 2.3 uses "SHOULD".  Is there reason for this discrepancy?

-- Would [PC-Client-BIOS-TPM-1.2] be equally acceptable?
[guy] I’ve removed the paragraph in 3.1.3.  But I think the SHOULD is appropriate in 2.3 #2; mapping the idealized measurement paradigm to real machines is very tough to do, and different approaches can legitimately tweak the balance between security and brittleness.  Adjusting what is measured does affect security coverage, but I don’t think impacts interoperability.
Let me know if this thought should go into the doc somewhere; it’s a bit subtle.

** Section 3.1.3
Reference Values MUST
   be encoded as SWID or CoSWID tags, signed by the device manufacturer,
   as defined in the TCG RIM document [RIM], compatible with NIST IR
   8060 [NIST-IR-8060] or the IETF CoSWID draft [I-D.ietf-sacm-coswid].

This is nearly identical normative guidance to Section 2.3 which uses a weaker "SHOULD"?  What's the motivation for the mismatch and saying this twice?  See:
Reference Values SHOULD be encoded as SWID or CoSWID tags, as
       defined in the TCG RIM document [RIM], compatible with NIST IR
       8060 [NIST-IR-8060] and the IETF CoSWID draft
       [I-D.ietf-sacm-coswid].  See Section 2.4.1.
[guy] The text has been removed from 3.1.3

** Section 3.2.  This section seems to suggest that YANG  interface must be used as the basis for the exchange between the attester and relying party/verifier.  Specifically, "For interoperability, this MUST be       accomplished via a YANG [RFC7950] interface".  However:

-- Section 1.5 doesn't mention it in the bulleted list following "All implementations supporting this RIV specification require the support of the following three technologies:"

-- Section 2.3 doesn't mention it in "To achieve interoperability, the following standards components    SHOULD be used: ..."
[guy] I made 2.3 more MUSTy wrt to charra.  I don’t think section 1.5 is about normative language

-- Section 3.2.1 says something weaker than a MUST - "Network Management systems may retrieve signed PCR based Evidence as shown in Figure 5, and can be accomplished via NETCONF or RESTCONF,    with XML, JSON, or CBOR encoded Evidence."
[guy] changed to focus on encrypted transport; dropped reference to xml/cbor, as that’s not relevant here.  

** Figure 5.
   evidenceGeneration(nonce, PcrSelection, collectedClaims)       |
        | => SignedPcrEvidence(nonce, PcrSelection)               |
        | => LogEvidence(collectedClaims)

The figure notation of evidenceGeneration() vs. => SignedPcrEvidence() and => LogEvidence() would have benefited from explanatory text.  Could the notation of "=> something(param1, param2)" be explained.
[guy] ok, I’ve updated the figure and added a sentence on format.

** Section 3.2.
Step 2 (time(NS)): The Verifier generates a unique random nonce
      ("number used once"), and makes a request attestation data for one
      or more PCRs from an Attester.  For interoperability, this MUST be
      accomplished via a YANG [RFC7950] interface that implements the
      TCG TAP model (e.g., YANG Module for Basic Challenge-Response-
      based Remote Attestation Procedures
      [I-D.ietf-rats-yang-tpm-charra]).

-- Please make TCG TAP model a reference
[guy] OK

-- Is there any normative guidance to provide on constructing the nonce beyond the data formats provides in Section 4.9 of TAPS and draft-ietf-rats-yang-tpm-charra?
I added xrefs to the TPM specs for nonces
TPM2 – Nonce is the same size as a digest, i.e. no more than 256 bits
-	– Section 10.4.4
-	https://trustedcomputinggroup.org/resource/tpm-library-specification/
-	https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-Library-Family-2.0-Level-00-Revision-1.59_pub.zip
TPM1.2 – it’s 160 bits
TPM Main, Part 2 TPM Structures, Specification version 1.2, Level 2 Revision 116, 1 March 2011
Section 5.5 TPM_NONCE


** Section 3.2.  Step 3.  Where can the procedure for serializing and signing the quote by the AK found?  I'm assuming it's somewhere in a TCG reference.

[guy] TPM2 Quote structure: 
Trusted Platform Module Library, Part 3: Commands, Family “2.0”, Level 00 Revision 01.16, October 30, 2014
Section 18.4.2

TPM1.2 Quote Structure
TPM Main Part 3 Commands, Specification Version 1.2, Level 2 Revision 116, 1 March 2011
Section 16.5 TPM_QUOTE2

[guy] I added cross references to TPM quote commands in the “Using TPM” appendix, and added a note to the xref in Step 3

** Section 3.2.  How is error handling signaled from the Verifier back to the Attester?
[guy] while the Verifier may have lots of things to check as it reviews evidence, the YANG model has no option to signal an application-level error.


** Section 3.2.  Step 5.  Should a reference to the procedures to get the reference values be included in one of the sub-steps?
[guy] I don’t think there is a specified procedure for getting reference values.

** Section 3.2.1  This section explicitly says that draft-ietf-rates-yang-tpm-charra SHOULD be used of retrieval of log evidence.  However, 3.2 says something stronger but is vaguer:
For interoperability, this MUST be
      accomplished via a YANG [RFC7950] interface that implements the
      TCG TAP model (e.g., YANG Module for Basic Challenge-Response-
      based Remote Attestation Procedures
      [I-D.ietf-rats-yang-tpm-charra]).

Why frame the guidance differently - here as charra being a SHOULD, and the TCG TAP model a MUST (of which charra is an example) in in the earlier text?
[guy] I converted the 3.2.1 SHOULD into a MUST

** Section 4.  (Editorial commentary that does not need to be actioned - the WG wanted this text) I appreciate the well written text on the how network equipment contributes to security in this section.  Personally, it seems a bit of a stretch to me to link this to "guarding the privacy of individuals using the network user privacy" and those prescribed behaviors seem removed from the substance of the RIV use case.  The second bullet point about routing information seem a bit distant from end-user privacy and the reliable encryption of the third bullet could be as much a VPN to enable privacy as forced middle-box proxying traffic.  Bottom line for me is that those network devices are there to implement and enforce the policies of the entity operating the network and little ensures that in the general case those privacy goals or expectations line up with the desires/expectations of the "end user".  Much of this text feels like motivation for the RIV use case rather than calling out de  sign or operational considerations related to the use case.

** Section 4.
   RIV specifically addresses the collection of information from
   enterprise network devices by authorized agents of the enterprise.
   As such, privacy is a fundamental concern for those deploying this
   solution, given EU GDPR, California CCPA, and many other privacy
   regulations.

I wish this was true. However, this seems like too strong of a statement - that those fielding and operating enterprise network devices (irrespective of RIV since the rest of the text is silent on normative privacy behavior) are in fact concerned about privacy.  Also, not every jurisdiction or set of users is subject to EU GDPR or CCPA.
[guy] TCG is particularly sensitive to criticism that TPMs work against privacy, so I usually go out of my way to show that, while that may be true on a PC, the equation is flipped in an enterprise device like a router.
However, I think the paragraph on GDPR is out of scope for the doc; I’ll delete it.  As you say, it’s not actionable anyway in this context

** Section 4 or 5.  The language recently added to Section 10 (Privacy Considerations) of draft-ieft-sacm-coswid-17 seems to apply here too - (1) collected information about an endpoint's software load could be used to identify vulnerable software for attack; and (2) (the opposite of what coswid said) generally a collection of endpoint software information of a system could give hints about its users, this document is focused only on networking devices which are unlikely to have to have this issue - that is, to establish that the attestation information is not likely to be privacy sensitive since the use cases is not focused on end-user devices.
[guy] I added a paragraph on keeping attestation records confidential

** Section 4.
The enterprise SHOULD implement and enforce their duty of care.

No disagree with the sentiment.  However, unless the text is going to be specific on "duty of care", then then a normative "SHOULD" should not be used.
[guy] I removed it

** Section 5.
   *  Man-in-the-middle attacks may be used by a counterfeit device to
      attempt to deliver responses that originate in an actual authentic
      device.

-- The bullet prior to this one (#2) outlines an attack where the counterfeit device tries to impersonate an authentic device.  Bullet #4 describes a replay attack by a compromised device.  I'm trying to distinguish this bullet from the #2 and 4 and getting confused by the "... to deliver responses that originate in an actual authentic device" language.  This reads to me like the counterfeit device is doing a replay attack already described in #4 (since #4 is silent on whether it is on-path or not to have observed the response).  Are we talking about a compromised sub-component of an "authentic device"?
[guy] The PITM attack is described in 5.2, and resulted (long ago) from a TCG oversight in not linking the attestation key and device identifier key closely enough (that in turn resulting from a complicated response to a privacy challenge not applicable to routers).  So this section justifies the keying requirements.  
The replay paragraph I think is more generic security hygiene, where the most obvious case is that a compromised device replays a response known to be good.  In CHARRA, the nonce is wired right in from the start, but for TUDA, unidirectional attestation, “freshness” is a continuous source of vexation.
Let me know if you think something needs to change in the RIV doc.


-- In the spirit of inclusive language, please used alternative language to "Man-in-the-Middle". 
[guy] ok

-- (Editorial?) What is the distinction being made with "actual authentic device" as opposed to just "authentic device"  
[guy]- none - corrected

** Section 5.2.  Please consider using a more inclusive term than "Man-in-the-Middle". 
[guy] Ok

** Section 5.5.
Consequently, RIV implementations SHOULD use
      TPM2.0.

How does this square with the Section 2.3. and Section 3.1.2 guidance that TPM1.2 MUST be used?  It seems odd to mix "MUST use TPM1.2 or TPM2.0" and then to end here would "SHOULD use TPM2.0".
[guy] I’m trying to say that you MUST use a TPM, and you SHOULD use TPM2

** Section 9.4
It should be noted that, while the YANG model is RECOMMENDED
   for attestation, this table identifies an optional SNMP MIB as well,
   [Attest-MIB].

How does this text reconcile with Section 3.2, Step 2 which says "[f]or interoperability, this MUST be accomplished via a YANG [RFC7950] interface that implements the TCG TAP model ..."?  Is the thinking to be passing an SNMP-MIB over YANG?
[guy] I removed references to the TCG MIB

Regards,
Roman



Nov 4, 2021
Hi!

When I performed my AD review on draft-ietf-rats-tpm-based-network-device-attest (https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/rats/RuBQhogqh3EuleeyDY13eiSfiAU/__;!!NEt6yMaO-gk!VeJYwBI5Y8LbjV3rt3fa_YNVGCXXqAqLSRsYMwltFM-v1Yv0yQBrcWfHaAIAvhnvoHY$ ), I had only selectively read draft-ietf-rats-yang-tpm-charra.  With the benefit of detailed read, I have the following additional comments on draft-ietf-rats-tpm-based-network-device-attest-08

Given that Section 3.2.1 says, "Retrieval of Log Evidence SHOULD be done via log interfaces specified in [I-D.ietf-rats-yang-tpm-charra]", should the two documents be aligned as described below?

** Per the specific aligned text above, what kind of solution would not conform to the log interfaces in charra and how would this lead to an interoperable RIV solution?  Should this say MUST?
[guy] I changed it to MUST

** Section 2.3

   2.  For devices using UEFI and Linux, measurements of firmware and
       bootable modules SHOULD be taken according to TCG PC Client
       [PC-Client-BIOS-TPM-1.2] or [PC-Client-BIOS-TPM-2.0], and Linux
       IMA [IMA]

-- should references here line up exactly with the references used in charra BIOS and IMA features?
[guy] looks like we were both xref’ing out of date versions of the same BIOS doc; newest is 1.05, May 2021.  New template, no doc history ☹
I’ve updated my xref to IMA CEL, although it’s still draft

** Section 2.4.2

   There are multiple event log formats which may be supported as viable
   formats of Evidence between the Attester and Verifier:

   *  IMA Event log file exports [IMA]

   *  TCG UEFI BIOS event log (TCG EFI Platform Specification for TPM
      Family 1.1 or 1.2, Section 7) [EFI-TPM]

   *  TCG Canonical Event Log [Canonical-Event-Log]
[guy] I’ve eliminated the old IMA log, but added the TPM2 log.  You’re right there’s a dependency in CHARRA I hadn’t kept up with; I’ve fixed the statement.

   Attesters which use UEFI BIOS and Linux SHOULD use TCG Canonical
   Event Log [Canonical-Event-Log] and TCG UEFI BIOS event log
   [EFI-TPM], although the CHARRA YANG model
   [I-D.ietf-rats-yang-tpm-charra] has no dependence on the format of
   the log.

-- Is saying that charra has no dependence on the format of the log accurate.  It appears that charra is particular about what log formats it will accept.  From [e-mail], it appears to be only:

(1) feature bios ==> "https://urldefense.com/v3/__https://trustedcomputinggroup.org/wp-content/uploads/PC-ClientSpecific_Platform_Profile_for_TPM_2p0_Systems_v51.pdf__;!!NEt6yMaO-gk!VeJYwBI5Y8LbjV3rt3fa_YNVGCXXqAqLSRsYMwltFM-v1Yv0yQBrcWfHaAIAEFTvXvQ$ ,           Section 9.4.5.2";

(2) feature ima ==> "https://urldefense.com/v3/__https://www.trustedcomputinggroup.org/wp-content/uploads/TCG_IWG_CEL_v1_r0p30_13feb2021.pdf__;!!NEt6yMaO-gk!VeJYwBI5Y8LbjV3rt3fa_YNVGCXXqAqLSRsYMwltFM-v1Yv0yQBrcWfHaAIAE0uJTgU$   Section 4.3";

-- Is there a mismatch between how this document thinks of the UEFI BIOS event logs and that of the charra draft?

Here [EFI-TPM] is:

   [EFI-TPM]  Trusted Computing Group, "TCG EFI Platform Specification
              for TPM Family 1.1 or 1.2, Specification Version 1.22,
              Revision 15", January 2014,
              <https://urldefense.com/v3/__https://trustedcomputinggroup.org/resource/tcg-efi-__;!!NEt6yMaO-gk!VeJYwBI5Y8LbjV3rt3fa_YNVGCXXqAqLSRsYMwltFM-v1Yv0yQBrcWfHaAIAeBSwue0$
              platform-specification/>.

draft-ietf-rats-yang-tpm-charra defines it as:

https://urldefense.com/v3/__https://trustedcomputinggroup.org/wp-content/uploads/PC-ClientSpecific_Platform_Profile_for_TPM_2p0_Systems_v51.pdf__;!!NEt6yMaO-gk!VeJYwBI5Y8LbjV3rt3fa_YNVGCXXqAqLSRsYMwltFM-v1Yv0yQBrcWfHaAIAEFTvXvQ$ , Section 9.4.5.2

[guy] RIV cites both the TPM1.2 log and the TPM2.0 log.  I deleted references to the pre-EFI ‘legacy’ BIOS, as it was removed from RIV a while ago.  There were a couple places where I cited the 2.0 version, and failed to cite the 1.2 version; those were fixed.


-- Is it a problem that this document is seems to generically support [Canonical-Event-Log] but draft-ietf-rats-yang-tpm-charra seems to restrict its support to only Section 4.3 of that reference (around IMA)?
[guy] I don’t think charra intends to be restrictive.

-- Are IMA log file exports compatible with [Canonical-Event-Log]?
[guy] nope.  I’m removing the native IMA log format.  CEL was designed with the IMA developers to be uniform structure going forward.

-- The [IMA] reference definition seems to have a typo in it.
[guy]; I fixed the source file to make the authors’ names visible.


Regards,
Roman

_______________________________________________
RATS mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/rats__;!!NEt6yMaO-gk!VeJYwBI5Y8LbjV3rt3fa_YNVGCXXqAqLSRsYMwltFM-v1Yv0yQBrcWfHaAIAOP_34Kk$



From Eric Voit
> Here there is:
> https://trustedcomputinggroup.org/wp-content/uploads/PC-ClientSpecific_Platform_Profile_for_TPM_2p0_Systems_v51.pdf ,  Section 9.4.5.2
>
> draft-ietf-rats-tpm-based-network-device-attest uses:
>    [EFI-TPM]  Trusted Computing Group, "TCG EFI Platform Specification
>               for TPM Family 1.1 or 1.2, Specification Version 1.22,
>               Revision 15", January 2014,
>               <https://trustedcomputinggroup.org/resource/tcg-efi-
>               platform-specification/>.
> 
> Are these complimentary?  Should they be the same?

**Henk  **Guy, do you accept my assertion below?
I don't think this is an issue.  The
draft-ietf-rats-tpm-based-network-device-attest (RIV) talks about the
overall mechanisms and references for BIOS logs.  This link eventually above
resolves to: 
https://trustedcomputinggroup.org/wp-content/uploads/TCG_EFI_Platform_1_22_Final_-v15.pdf


The Charra model points to the specific object definitions in the log within
the PC platform profile containing the measurement object which goes into
the PCR.  This profile is 
https://trustedcomputinggroup.org/wp-content/uploads/PC-ClientSpecific_Platf
orm_Profile_for_TPM_2p0_Systems_v51.pdf,  Section 9.4.5.2

The delivered objects should be the same. It is an internal Verifier issue
of how the delivered log measurement object is extracted from the referenced
log and used in PCR hash verification.

Side note I learned during the comparison...  The charra model references a
newer version of that log than RIV.  **Guy, perhaps update the RIV
reference?
[guy] fixed

---------


 




Juniper Business Use Only