[Rats] AD review of draft-ietf-rats-tpm-based-network-device-attest-08

[Roman Danyliw <[e-mail]>]

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?

** 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/
-- We might want to quickly define what "authentic" means (i.e., build/configured as intended by the manufacturer?)
-- Would there be any other users beyond an administrator relevant here?  Say an auditor?

** 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"?

** 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.

** 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?

** Section 1.7.1.  Editorial. Please provide a citation for Linux IMA on first use.

** 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?

** 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

** 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?

** 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://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8423794), isn't this the "subject" field (lower case)?

** 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.

** Section 2.1. The last paragraph starts using the term PCR without definition it.

** 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.

** 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"?

** Section 2.1.2.  Typo. s/paricular/particular.

** 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?

** Section 2.2.  Typo.  s/Subject Alt Name/subjectAltName/

** 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?

** Section 2.2. Typo.  s/certifcate/certificate/

** 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?

** 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.

-- How do things interoperate if one chooses not to use the prescribed standards such as the "SHOULD" flexibility in #4?

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

** 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.

** 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)

-- 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].

** 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?

-- 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)

-- 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.

** 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?

** 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?

** 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],

(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.

(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.

** 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?

** 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.

** 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?

** 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.

** 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: ..."

-- 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."

** 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.

** 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

-- 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?

** 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.

** Section 3.2.  How is error handling signaled from the Verifier back to the Attester?

** Section 3.2.  Step 5.  Should a reference to the procedures to get the reference values be included in one of the sub-steps?

** 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?

** 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 design 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.

** 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.

** 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.

** 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"?

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

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

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

** 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".

** 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?

Regards,
Roman