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

[Dave Thaler <[e-mail]>]

Answers to clarifying questions…

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

Clarifying questions and comments.

Where did this table come from?

I created it based on my interpretation of statements made in draft-birkholz-rats-basic-yang-module and
draft-fedorkow-rats-network-device-attestation-01 (and based on Guy’s responses on this list to confirm/correct my understanding).
Of course since there seems to be some confusion about what YANG is, my statement about the applicability of the yang draft
may or may not be correct.   I will say I believe it is correct when the YANG module is used by any pull-based protocol like
netconf or restconf, which is the model draft-fedorkow-rats-network-device-attestation discusses as I understand it.
If you can encapsulate the YANG information inside some existing in-band protocol like 802.1x then it would be more aligned
with what I’m arguing since that would be usable both with and without the presence of a host firewall.

Is a firewall here a typical IP-level thing that filter Internet traffic? (If so, why is that relevant?). Or is it memory protection between the attestation host (e.g. RoT) and the other parts of the system? Something else?

Yes it’s a typical IP-level thing.  (See RFC 7288 for lots of IAB discussion on that term.)
It’s relevant because if the only way for a Relying Party to get attestation information is to separately ask the attester
via a different protocol that the attester has to accept unsolicited inbound communication for, then a host firewall whose
job it is to prevent unsolicited inbound communication will of course prevent that solution from working at all.
Whereas a mechanism that passes attestation information in a protocol the Attester initiates anyway, such as 802.1x
or any similar network authentication protocol, such conveyance will work with or without a firewall, and so be far more
broadly usable for network authentication, and be usable both by routers and non-routers, with a single common solution,
rather than having a bunch of point solutions.

What is privacy here? Is it the untrackability of attestations because they use ECDAA, shared keys or such? That is privacy in the web browser / GDPR sense.

Ask Guy, it’s from his draft ☺
But my own interpretation is that privacy means the network cannot tell that the specific device now is Bob’s or Alice’s device,
and cannot tell that the specific device is the same device it saw yesterday.
See section 5 of RFC 6973.

Various solutions at various layers may or may not provide this property.
For example, MAC address randomization is an example of a technique to try to provide this property, and
draft-ietf-dnssd-prireq is an example of IETF work on providing this for DNS service discovery.
Intel’s EPID arguably addresses this for their scenarios, the general point being that
It is possible to attest to the trustworthiness of a device without revealing a unique device identifier.
Whether that’s a requirement or not depends on the use case, the administrator, the device, etc.
But draft-fedorkow-rats-network-device-attestation is constrained only to cases that don’t need privacy,
and my reading (perhaps incorrect) is that draft-birkholz-rats-basic-yang-module
also has that scope, in that it reveals some device identifier.   If it is changed so that is optional,
then its applicability widens.  I am just arguing for broad solutions, not narrow ones.

One of them is not like the other: Firmware. It typically isn’t isolated and doesn’t have a CPU.

ALL of them are not like the others.   Every one is unique in some way.  But people want attestation in all of these scenarios.
They don’t provide the same degree of strength, but that doesn’t mean you can’t have common protocols/techniques/claim formats/etc.

There are other isolating execution environment approaches such as separate CPUs and virtualization, particularly Microsoft VBS.

Agree, there are more RoT types in general, and I argue for solutions that can easily be extended to more of them.
(By “Firmware” I meant what you call “virtualization”, not just Microsoft VBS in particular, but just the notion that a hypervisor or firmware
provides some level of attestation guarantees for higher layer components.)

I didn’t mention AMD in the table either, and AMD has things like AMD-SEV and the recently announced<https://www.youtube.com/watch?v=yr56SaJ_0QI&list=PLbzoR-pLrL6rF8E5yyknJzrVQaHeYszTR&index=16&t=0s> SEV-SNP,
and for RISC-V there’s Hex-Five’s MultiZone.  Etc.

Dave

LL



On Nov 11, 2019, at 5:43 PM, Dave Thaler <dthaler=[e-mail]<mailto:dthaler=[e-mail]>> wrote:

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