Re: [Rats] Call for adoption (after draft rename) for Yang module draft

[Guy Fedorkow <[e-mail]>]

  I know I’m responding to a message from the ancient past, but I’d like to try to clarify a couple of the characterizations of RIV.
  It’s true that I asked Dave whether the relying party was required to shuttle information between the attester and the verifier, as shown in the Background Check model.  If the two are processes on the same network management machine, such a requirement seems odd.  But if they have different network reachability due to separate machines and firewalls and all, then of course the relying party can proxy information to the Verifier.  We specifically avoided distinguishing the two roles in the RIV draft, but I don’t think that can be taken to mean that the solution cannot work with firewalls.  But let me know if there was some other restriction that motivated the table entry
  The non-privacy clause in the RIV draft is also coincidental.  The TPM has a wide range of mechanisms to deal with degrees of privacy expectations, all of which relate to key provisioning.  For routers, we haven’t seen a need for complex measures to hide identity, and in fact I think most operators would not want routers with a secret identity on their network.  But if someone does want preservation of privacy, they can change to Local DevID keys and coordinate those keys between device and verifier using whatever approach they want.  I don’t think it has any impact on the RIV workflow.
  But I should probably say more explicitly somewhere in the draft that we’d want to the solution to work with zero touch provisioning, such as RFC 8572.  That’s not ‘required’ for RIV, but may help explain two things:

  *   sZTP assumes the device can identify itself.  Hence the non-privacy-preserving statement, and the request that manufacturers pre-provision identity and attestation keys.
  *   sZTP requires that the device announce itself so that it can be configured.  By the time it would be possible to do attestation, the device has already revealed its presence.  And indeed one might link the two – I don’t think it’s part of anyone’s spec, but a ZTP provisioning system might well want to run software integrity attestation once it’s figured out what the device is and whether it has a plausible to reason to want to connect.  But again, that seems out of scope to the draft.
  Finally, I don’t see YANG as the exclusive protocol for TPM-based attestation; it happens to be the one that’s already there for routers, and it’s a lot easier to get someone to add a YANG model to their router for network management, than to convince them to bring in a new protocol suite.
  But for other applications, YANG wouldn’t be the right thing…  Industrial IoT probably would ask for attestation via a protocol I’ve never heard of 😊  And I think there would be different protocols more suitable to end user computing, such as laptops and servers.  Glad to talk it over if someone wants to extend the scope.

  Thanks for reading a long response…  Let me know if this is clarifying or muddying!
/guy




Juniper Business Use Only
From: RATS <[e-mail]> On Behalf Of Dave Thaler
Sent: Monday, November 11, 2019 8:43 PM
To: Smith, Ned <[e-mail]>; Oliver, Ian (Nokia - FI/Espoo) <[e-mail]>; Laurence Lundblade <[e-mail]>; Nancy Cam-Winget (ncamwing) <[e-mail]>
Cc: [e-mail]; Henk Birkholz <[e-mail]>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

As far as I can understand from draft-birkholz-rats-basic-yang-module-01 and
draft-fedorkow-rats-network-device-attestation-01, they break down the use case
space as follows:

                        Requirements?
         +--------------+---------------+---------++---------------
         |  RoT         | Host Firewall | Privacy ||   Solution
         |  Type        |   Enabled     | Needed  ||    Pieces
         +--------------+---------------+---------++---------------
      1  |  SGX         | No            | No      ||
      2  |  SGX         | No            | Yes     ||
      3  |  SGX         | Yes           | No      ||
      4  |  SGX         | Yes           | Yes     ||
      5  |  TrustZone   | No            | No      ||
      6  |  TrustZone   | No            | Yes     ||
      7  |  TrustZone   | Yes           | No      ||
      8  |  TrustZone   | Yes           | Yes     ||
      9  |  TPM         | No            | No      || draft-birkholz-rats-basic-yang-module-01
     10  |  TPM         | No            | Yes     ||
     11  |  TPM         | Yes           | No      ||
     12  |  TPM         | Yes           | Yes     ||
     13  |SecureElement | No            | No      ||
     14  |SecureElement | No            | Yes     ||
     15  |SecureElement | Yes           | No      ||
     16  |SecureElement | Yes           | Yes     ||
     17  | Firmware     | No            | No      ||
     18  | Firmware     | No            | Yes     ||
     19  | Firmware     | Yes           | No      ||
     20  | Firmware     | Yes           | Yes     ||
     ... |   ...        |               |         ||

And draft-fedorkow-rats-network-device-attestation-01 further scopes itself down
by only being applicable to cases with "embedded" apps only = Yes, and where
the security policy is only an Exact match against reference values = Yes.
I believe that the yang draft doesn't have those two restrictions, from my reading.
However, the point is that both drafts are VERY narrow, and in the table shown above,
only address 1 out of 20 possibilies in that space.

In contrast, the TEEP WG decided that it was not interested in narrow scopings
(specifically something Global Platform specific), but instead wanted one general solution.

If the RATS WG spends effort on something that only addresses a single row out of 20+ rows,
then do we expect 19+ other solutions to also be done in the WG?  Or could we work on things
that are broader and happen to also work for row 9?

I've seen others commenting on the fact that the YANG module only supports TPMs and not
other things (EATs etc), which would just add support for a couple more rows, but still not
be general.

Personally, I would much rather see the WG spend effort on things that really are generic,
i.e., work with or without host firewalls, work with multiple RoT/TEE types, etc., rather
than seeing an explosion of point solutions.

Dave