Re: [Rats] Comments on draft-fedorkow-rats-network-device-attestation-00

[Guy Fedorkow <[e-mail]>]

Hi Dave,
  I'd like to respond to two points in your original message.

  I think you asked (indirectly) why RIV calls for separate keys for attestation and identity.  That's due to a particular TPM anti-spoofing security principal...
  Attestation evidence is collected entirely inside the TPM.  In the conventional Measured Boot flow, the rot of trust measures the first mutable component, which then measures the second, and so on in a chain.  Each time a measurement is taken, the TPM "extends" the value into a TPM PCR.  Net result is that the measurement showing that a section of code is out of whack is taken before that code is run, i.e., the hack doesn't have a chance to manipulate the end result, because it's measured by something trusted first.
  To preserve that property, the "quote" that reports the accumulated PCRs must be signed inside the TPM, so that the attesting system must transfer the result to the verifier without modification.  Net result is that, even if the attesting system is hacked, it can't pretend to be unmodified by cleaning up the quote before it goes to the verifier.
  But for that to be true, it must be impossible for the attesting system to forge a valid quote.  And for that to be true, it must be impossible for the attesting system to make up a quote from nothing, and convince the TPM to sign it with the attestation key.
  And identity key, on the other hand, must sign whatever it's asked to sign.  The Identity Key signature doesn't say anything about what it was that got signed, its purpose is to prove that, what ever it was, it got signed by the specific TPM.  So there's nothing to prevent an attesting system from making up a quote, and having it signed by an identity key.  So that leads to a desire for separate keys.
  But  you still have to prove that the quote comes from the same device as the identity (the so-called Asokan man in the middle attack).  The TPM has a mechanism to prove that two keys are resident in the same TPM, but RIV takes a simpler approach, but asking whoever provisions the keys (the manufacturer by default) to make the attestation key and identity keys at the same time, and put the same identity information into the corresponding two certificates.  So the verifier can look at the identity certificate and the attestation certificate, check that they are both valid signatures from the appropriate authority (e.g. the manufacturer), check that they have the same model and device serial number, and from there, know that the attestation result originated on the box that they're trying to attest.

  There is a secondary detail that makes the issue a bit less black-and-white.  For TPM1.2, the roles of attestation and identity keys simply must be separate, end of story.  In TPM2.0, it's possible to use one key for both, with a tiny probability of something going wrong...  that is, an attestation key can sign an external object, as long as it doesn't appear to spoof a quote.  But cryptographers usually then argue that good key management should use separate keys for separate functions, and we note that some Identity protocols require keys capable of encryption as well as signing, and so to simplify the cases, we ended up simply keeping them separate.

  Apologies for the long-winded response, but I hope that helps clarify the oblique reference in the RIV doc to two keys for anti-spoofing".  I can update the doc.

  There was also a question about scope of the doc.  There is actually a reason that it's been left a bit ambiguous at TCG.  The doc is currently focused on YANG as the external interface for attestation.  That's clearly aimed at networking gear - I don't think anyone else uses YANG.  Other applications, such as attesting the state of large embedded controllers in industrial gear, would follow the same workflow, but would undoubtedly want some other protocol.  It would be a simple job to extend the doc to those use cases by adding additional protocols, although there are none specifically in the pipeline that I know of.
  The other focus for the doc is TPM.  Of course there are other roots of trust that might be able to fill the same role, and might use the same workflow.  That's a tougher job to estimate, so we declared it out-of-scope for now.
  Oh, and the third restriction, "things that don't sleep"... this is definitely not fundamental.  The TPM clearly can be used in PCs that sleep, but getting in and out of sleep and hibernate states is complicated.  Large embedded devices typically have no application for sleep and hibernate, so we declared it out of scope for RIV.  If someone wants to add it back in, there are no fundamental limitations.

  For the RATS context, I'm fine with revising the doc to make the scope clearer.

  Let me know if this addresses your questions...

  And Henk, Ned, let me know if I'm misrepresenting keying policies!
Thanks
/guy







Juniper Business Use Only
From: Guy Fedorkow
Sent: Friday, November 8, 2019 11:10 AM
To: Dave Thaler <dthaler=[e-mail]>
Cc: [e-mail]; Thomas Hardjono <[e-mail]>; Smith, Ned <[e-mail]>; Henk Birkholz <[e-mail]>; Jessica Fitzgerald-McKay <[e-mail]>
Subject: RE: Comments on draft-fedorkow-rats-network-device-attestation-00

Hi Dave,
  I'll look at the title and scope again.  Within TCG, we'd left it a bit ambiguous, as there are a number of applications that it would fit without too much work.  But for RATS, I'm fine with being more careful to delineate where the work as written fits.
  We'll think of a more-formal way to say this, but as Jessica said, the actual scope of the doc is "things with a TPM that use YANG, and don't do sleep/wake cycles".
  I assume this can't be changed now given that the IETF106 deadline has passed, but there will be another revision one way or another in which I can address your other comments.
  Thanks
/guy






Juniper Business Use Only
From: Dave Thaler <dthaler=[e-mail]<mailto:dthaler=[e-mail]>>
Sent: Wednesday, November 6, 2019 8:18 PM
To: Guy Fedorkow <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Thomas Hardjono <[e-mail]<mailto:[e-mail]>>; Smith, Ned <[e-mail]<mailto:[e-mail]>>; Henk Birkholz <[e-mail]<mailto:[e-mail]>>; Jessica Fitzgerald-McKay <[e-mail]<mailto:[e-mail]>>
Subject: RE: Comments on draft-fedorkow-rats-network-device-attestation-00

And a couple of additional comments on -01 (the subject had -00 in it and probably shouldn't have)


  *   Since section 1 scopes the definition of RIV to certain types of network equipment, I find the term RIV to be

overly broad, since it has a name that implies it is remote attestation for all purposes, which it's apparently not.

I would recommend that, like the title of the doc, the term RIV be narrowed significantly by adding words

to indicate its narrow scope.



  *   Section 4 says:

In light of these
   requirements for protecting the privacy of users of the network, the
   Network Equipment must identify itself, and its boot configuration
   and measured device state (for example, PCR values), to the
   Equipment's Administrator, so there's no uncertainty as to what
   function each device and configuration is configured to carry out .



RIV specifically addresses the collection information from enterprise
   network devices by an enterprise network.

               However, those two sentences appear to be contradictory.   The first one talks about
               the "Equipment's Administrator" whereas the second one talks about "an enterprise network".
               Unless you further narrow the scope in section 1.5 to only cases where those are the same,
               you should not assume that the "Equipment's Administrator" and the "enterprise network"
               are the same organization.


  *   Another point on the same text in section 4 is that it talks about "boot" configuration and then says
"there's no uncertainty as to what function each device and configuration is configured to carry out".

In order to have "no uncertainty" you either have to remove the word "boot", so that it's not just

"boot" configuration, but configuration in general, or else constrain your definition of "embedded"

to cases where all configuration and functionality is fixed at boot time.  That's common in embedded,

but not universal, depending on your definition of embedded.  Currently you only define "embedded"

as "where the device manufacturer ships the software image for the device"

but that by itself doesn't mean all functionality is fixed at boot time.  E.g., the configuration might be

separate from the software image, and might even be obtained after boot, unless you scope down your

definition of "embedded".



  *   Section 5 says

"TPM practices require that these keys be different, as a way of
   ensuring that a general-purpose signing key cannot be used to spoof
   an attestation quote."

and

"To prevent spoofing, the quote generated inside the TPM must by
   signed by a key that's different from the DevID, called an
   Attestation Key (AK)."



The claim that a split is necessary to prevent spoofing is non-obvious (I know I didn't follow it).  I would recommend either

  1.  Delete the text about spoofing and just say that's how TPM works, or
  2.  Provide an explanation, or
  3.  Reference a publically accessible document that has the explanation.

Dave

From: RATS <[e-mail]<mailto:[e-mail]>> On Behalf Of Dave Thaler
Sent: Wednesday, November 6, 2019 4:26 PM
To: Guy Fedorkow <gfedorkow=[e-mail]<mailto:gfedorkow=[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Thomas Hardjono <[e-mail]<mailto:[e-mail]>>; Smith, Ned <[e-mail]<mailto:[e-mail]>>; Henk Birkholz <[e-mail]<mailto:[e-mail]>>; Jessica Fitzgerald-McKay <[e-mail]<mailto:[e-mail]>>
Subject: [Rats] Comments on draft-fedorkow-rats-network-device-attestation-00

[updated subject line]

Here's some comments on draft-fedorkow-rats-network-device-attestation-00, in addition to the one in the thread copied at bottom...

Section 1.2:

?  o  Platform Identity, the mechanism providing trusted identity, can

  *   reassure network managers that the specific devices they ordered
  *   from authorized manufacturers for attachment to their network are
  *   those that were installed, and that they continue to be present in
  *   their network.  As part of the mechanism for Platform Identity,
  *   cryptographic proof of the identity of the manufacturer is also
  *   provided.

Above is somewhat ambiguous.   When it says "the specific devices", is it talking about device instances
(in the exact serial number or key pair sense), or the same models?   I.e., I ordered 3 widgets, and I got
three widgets (and not three oranges or something else).  Is this talking about verifying that they're
widgets, or that they're the precise 3 widgets you're expecting?   I suspect you mean the latter but it's not
clear.   Assuming you do mean instances, then knowing that they're the specific devices that were ordered
presumes some mechanism for learning the public keys of the devices ordered, prior to their arrival, and
this should be called out.

Section 2.1 discusses the model where the verifier communicates directly with the attested device.
However, it doesn't point out the problems with that model, which is that the attested device will see this
as unsolicited inbound communication, and hence and sort of host firewall-like behavior will prevent the
interrogation from succeeding.    Section 1.5 already constrains the scope to a very narrow scenario, but
it's not sufficient, it has to be constrained further to the scenario where unsolicited inbound communication
is permitted.   Allowing unsolicited inbound communication opens up other potential security and privacy
risks that should be discussed in sections 4 and 5.

Given the narrowness of the applicability, and the security and privacy risks inherent in the model where
the verifier communicates directly with the attested device, it's not obvious why this is a good direction
to pursue, especially if there might be alternatives that are both more broadly applicable, and more secure/private.

I have no objection if there are good reasons, but the draft doesn't yet provide sufficient justification
in my view.

Thanks,
Dave

From: Guy Fedorkow <gfedorkow=[e-mail]<mailto:gfedorkow=[e-mail]>>
Sent: Wednesday, November 6, 2019 12:57 PM
To: Dave Thaler <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Thomas Hardjono <[e-mail]<mailto:[e-mail]>>; Smith, Ned <[e-mail]<mailto:[e-mail]>>; Henk Birkholz <[e-mail]<mailto:[e-mail]>>; Jessica Fitzgerald-McKay <[e-mail]<mailto:[e-mail]>>
Subject: RE: RIV and the RATS architecture

Hi Dave,
  Ok, I suppose the model where the verifier communicates directly with the attested device is a kind of sub-contracted full-service background check.  That's ok with me, as long as no one interprets the diagram as meaning that the relying party must somehow insert itself into the exchange between Verifier and Attester.

  And I see what you mean about lining up the scope of RIV.  The draft has gone through a number of changes as we've tried to disentangle it from TCG tribal knowledge.
  I think the scope is set by a couple factors.
  The doc as written is clearly limited to TPM-based systems.  That's certainly not the only way to manage a root of trust, but it's the one that's available on a lot of gear already, and it's fairly stable and tightly spec'd.  From the TCG side, I'd expect there would be interest in extending the ideas to other TCG roots of trust such as DICE, but it seems that should be driven out of TCG.

  The limitation to Network Equipment is entirely a matter of expedience.  I think the approach would work easily in other embedded applications, although YANG is likely a fixation only relevant to networking guys.  Other domains would presumably need other domain-specific protocols.

  I'll connect with Jessica to see if we can figure out how to align the name and scope a bit better with the rest of the RATS world.

  Thanks
/guy




Juniper Business Use Only
From: Dave Thaler <dthaler=[e-mail]<mailto:dthaler=[e-mail]>>
Sent: Monday, November 4, 2019 3:56 PM
To: Guy Fedorkow <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Thomas Hardjono <[e-mail]<mailto:[e-mail]>>; Smith, Ned <[e-mail]<mailto:[e-mail]>>; Henk Birkholz <[e-mail]<mailto:[e-mail]>>; Jessica Fitzgerald-McKay <[e-mail]<mailto:[e-mail]>>
Subject: RE: RIV and the RATS architecture

Hi Guy, sorry for the delay, I was at a conference (Open Source Summit, Confidential Computing Consortium, and Linux Security Summit were all co-located) all last week and traveling there/back.

Responses inline below...

From: RATS <[e-mail]<mailto:[e-mail]>> On Behalf Of Guy Fedorkow
Sent: Thursday, October 31, 2019 12:27 PM
To: Dave Thaler <dthaler=[e-mail]<mailto:dthaler=[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Thomas Hardjono <[e-mail]<mailto:[e-mail]>>; Smith, Ned <[e-mail]<mailto:[e-mail]>>; Henk Birkholz <[e-mail]<mailto:[e-mail]>>; Jessica Fitzgerald-McKay <[e-mail]<mailto:[e-mail]>>
Subject: [Rats] RIV and the RATS architecture

Hi Dave,
  Thanks for your doc https://tools.ietf.org/html/draft-thaler-rats-architecture-00<https://urldefense.com/v3/__https:/nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fnam06.safelinks.protection.outlook...com*2F*3Furl*3Dhttps*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-thaler-rats-architecture-00*26data*3D02*7C01*7Cdthaler*40microsoft.com*7C520adf8cc884437d639508d75e385c4d*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637081468537546960*26sdata*3D20zFPTGCbLybPlTaNB2E6uSb3re0G2bYPGC8F9TNXis*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!Rpme4JKWETjOw_zisYJRdztjgIgNvTA_HZoPymMV_ggWZP8BkjOlbCzLuKc18WRBFIY*24&data=02*7C01*7Cdthaler*40microsoft..com*7C1bf26678bca14945d3bd08d763191133*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637086831671084329&sdata=Lo3rkbTEksxPZCDIB*2FuCj*2BszeMO4xQuHUxDkOF9DZBk*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqJSUqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJQ!8WoA6RjC81c!Xn2_O62Wg9lin7aRm0WrBgW70EydD8BZFq8Se5MIXVP-bsHRkuSwjYOdlg3eAgtRn20$>.
  Do you have a view as to how the TPM-based attestation described in RIV would fit with the proposed categorization?
https://tools.ietf.org/html/draft-fedorkow-rats-network-device-attestation-00<https://urldefense.com/v3/__https:/nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-fedorkow-rats-network-device-attestation-00*26data*3D02*7C01*7Cdthaler*40microsoft.com*7C520adf8cc884437d639508d75e385c4d*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637081468537556953*26sdata*3DVTByXHpjuEMkojKjjly0i0BbnvujhB4fIpQaqiPFDKA*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSU!8WoA6RjC81c!Rpme4JKWETjOw_zisYJRdztjgIgNvTA_HZoPymMV_ggWZP8BkjOlbCzLuKc1fEcZrRQ*24&data=02*7C01*7Cdthaler*40microsoft.com*7C1bf26678bca14945d3bd08d763191133*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637086831671084329&sdata=W95iVCu0BKi3ioryV7ZOngYQnALJEwEgF19Iw6sXTHg*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqJSUqKioqKioqKiUlKiUlJSUlJSUlJSUlJSU!8WoA6RjC81c!Xn2_O62Wg9lin7aRm0WrBgW70EydD8BZFq8Se5MIXVP-bsHRkuSwjYOdlg3eGnNGpPw$>

Great question. From my reading of draft-fedorkow-rats-network-device-attestation-00, it's a background check model, as section 2.3 of your doc explains:
>   3.  A Relying Party, which has access to the Verifier to request
>       attestation and to act on results.

That sentence above is by definition the background check model.
That is, the Attester talks to the Relying Party, the Relying Party then requests a background check by consulting a Verifier,
and will accept whatever answer the Verifier decides.
There are ways where you could use the passport model for network device attestation,
but your document only covers the background check model.

  It doesn't seem to be a passport, since the attester only provides raw evidence, not a pre-approved passport

Agreed, from my reading of your document.

  It doesn't seem to be a background check, as it's the verifier that collects and analyzes the evidence.

If I understand your point here, you're saying that the verifier talks directly to the attester (e.g., by querying the yang module), without going back through the relying party, and that that seemed to you to be different from a classic "background check" diagram.  Did I get your point correctly?

If so, then I see it as a variation of the background check model, as opposed to a separate model per se.

  I'm not sure it matters to RIV, as we haven't drawn much distinction between the relying party and the verifier...  As you say, if they're on the same machine, the distinction is almost moot.

Agree.

And if they're not, I think the communication is out of scope for RIV (if not for RATS).

I disagree that it's out of scope for RATS.

I have no opinion on whether it's out of scope for RIV, since I still have some confusion on the intended scope of RIV.
I note that your document constrains its scope (in section 1.5) to only TPM-based embedded devices, and not other
types of devices.   I couldn't tell if the scope of RIV and the scope of the draft (which does not have RIV in the name, or in
section 1.5) are similar or one is a subset of the other.   Indeed, the title of the document is far wider than just TPM-based
embedded devices, so in that sense the title doesn't match the scoping in section 1.5.   Just explaining why there's not
enough information for me to have an opinion on verifier-relying party communication in RIV.

There can be other network attestation solutions that look quite different from the flow in your draft
(and I have no skin in this game, so don't have a bias towards any solution in particular).   For example,
some other solution might involve a RADIUS server being a Verifier, so the verifier - relying party communication might
be RADIUS in that example.   There's many ways to construct solutions, and so I imagine there's probably multiple
solutions already out there, since the NEA problem is not new even in the IETF (https://tools....ietf.org/wg/nea/<https://urldefense.com/v3/__https:/nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Ftools.ietf.org*2Fwg*2Fnea*2F__*3B!8WoA6RjC81c!Rpme4JKWETjOw_zisYJRdztjgIgNvTA_HZoPymMV_ggWZP8BkjOlbCzLuKc1mSGm10I*24&data=02*7C01*7Cdthaler*40microsoft.com*7C1bf26678bca14945d3bd08d763191133*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637086831671094320&sdata=jzwLX8epRspaFxc1XVL61XMieibUdFECiPAD2860Dzg*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!8WoA6RjC81c!Xn2_O62Wg9lin7aRm0WrBgW70EydD8BZFq8Se5MIXVP-bsHRkuSwjYOdlg3eRfx7-V0$> has
pointers to RFCs for anyone reading this who's not already aware of it).

  But it would be good ensure the architecture and the applications of it actually do fit together...

Absolutely.

Dave

  Thanks
/guy






Juniper Business Use Only