Re: [Rats] regarding rats-network-device-attestation; michael's comments

[Guy Fedorkow <[e-mail]>]

Hi Michael,
  Thanks for the review comments.  I've addressed them in my copy, along with a bunch of other changes.  I hope to have the rest of the updates done soon so I can post a new rev.
  Enclosed are responses to your comments, marked by [guy]
/guy



-----Original Message-----
From: RATS <[e-mail]> On Behalf Of Michael Richardson
Sent: Tuesday, September 10, 2019 7:05 AM
To: [e-mail]
Subject: [Rats] regarding rats-network-device-attestation





I have read through this document, and it is now the publicly available reference on the TCG work for the use-case document.  I have sent some edits directly to the authors.

[guy] Yes, the original TCG version of this doc is posted on the TCG site.  We haven't gone back to push changes into the TCG version since the IETF draft got under way, so the pictures in the TCG version are nicer, but the words are more up to date in the IETF draft.



I like the use of the term "Remote Integrity Verification".

I'm not too crazy about "RIV" as a TLA in a field with way too many TLAs already though, but okay.



I found this text difficult:



         * Platform Identity refers to the mechanism assuring the

        attestation verifier (typically a network administrator)

        that the equipment on their network can be reliably identified,

        and that its manufacturer is certified by a trusted authority.



}        This certification provides the verifier with assurance that

}        the Root of Trust elements of the device were verified by the

}        manufacturer before the device was shipped.



I'm not sure if the device is actually identified to the verifier (network admin).

Or that there is a *meta* claim that the device could be identified.



Is this a claim that a claim was made, but the contents of the claim is not revealed for privacy reasons?  If that is the intent, then can we be more explicit?  (And that's actually a new use case).

If that's not the intent, then perhaps the passive language that is confusing could be changed.

[guy] no Meta Claim, just clumsy wording.  I've tried to simplify it





>   o  Processor Sleep Modes: Embedded equipment typically does not

>      "sleep", so sleep and hibernate modes are not considered.



why is this a consideration?

lots of embedded systems go into low power mode all the time.

[guy] I suppose.  I changed it to Network Equipment, which I don't think ever sleeps.  It's not that attestation can't be done after sleep mode, but it sure gets harder when the device is sort-of-but-not-quite rebooted.  TCG has various process flow charts for this, but for NetEq it's easier to leave it out.





re: 2.4.1: DevID Alternatives.



I don't find the use of LDevID to be a credible solution here.

It seems that LDevID have to get installed manually, via some privacy preserving mechanism.  Privacy preserving against who?  The person or entity that installs the LDevID surely gets to learn the identity

of the device.   I don't think we can do zero-touch provisioning

without the IDevID.



I would like this section to clarify the privacy threat here.

[guy] Hmm, I didn't mean to imply privacy-preserving.  I've revised the section a bit to try to say more clearly what they're for.  Short answer: it's like an asset tag placed by the owner of the device.  If the revised draft still implies 'privacy' let me know and I'll try again.



>   The TCG TPM 2.0 Keys

>   document [Platform-DevID-TPM-2.0] also outlines procedures for

>   creating Local Attestation Keys and Local Device IDs (LDevIDs) rooted

>   in the manufacturer's IDevID as a check to reduce the chances that

>   counterfeit devices are installed in the network.



[Platform-DevID-TPM-2.0] <-- seems to be a draft, and so probably not public?



[guy] Sadly yes, still a draft.



>   whether the measured hashes are "the right ones" or not.



up to now, you've carefully said "measurements", rather than measured hashes.

Do you want to stick with measurement, or was there a reason to change?

[guy] nope, sloppy language.  I've fixed it.



>   Quotes from a TPM can provide evidence of the state of a device at

>   the time the quote was requested, but to make sense of the quote in

>   most cases an event log of what software modules contributed which

>   values to the quote during startup must also be provided.  The log



As I understand it, the problem of the multi-process (and multi-processor) boot is that the hash values arrive in non-deterministic orders, and so would contribute to a straight sequential hash differently.

Why aren't the different contributions either just listed, or just filled

into a table with a canonical order?   I'm sure you have thought of this,

so there must be something I don't understand about why this solution can't work.

[guy] I think Ned would say that the log file *is* the primary record of which process started in what order, and the quote from the TPM is just a way of 'signing' the log.

   In the easy case, all the verifier has to do is to read the log from first to last entry, and compute the digest of all the hashes in the log.  The result should equal what's in the PCR.  If it doesn't, you should look for corruption in the log mechanism.  If it does, you can look at each entry in the log to see whether it's filename and path line up with the measured hash for that object.  If not, you've found the corrupted object.

  The harder case is when the log and the quote are out of sync, i.e., you ask for a quote in between the time that a digest was extended into a PCR and the corresponding log entry written out.  Careful ordering and maybe a second quote will fix the problem.



If one expects ten processes, A->J to be running, have a table that is ten items long.  If one needs to be sure that there are no other processes running, then some measurement of a canonicalized process table seems to be in order. That would omit the PID for instance, or canonicalize the PID into some abstract namespace if relationships between processes were also important.





Juniper Business Use Only