Subject: [Rats] Reviewing EAT for enterprise/cloud use cases

From: Yaron Sheffer <[email-masked]>
Date: Fri, 22 Nov 2019 13:57:41 +0800

I have read the EAT draft, specifically with a “cloud” use case in mind. To clarify, what I'm looking for is the capability:

- To attest to software components that are running inside VMs, containers (either on VMs or bare metal), and anonymous containers (function-as-a-service, such as AWS Lambda).

- Such components may be deployed in arbitrary hierarchies (VM-in-VM etc.).

- Attestation of running (as opposed to installed) components. For example, container code may be pulled from a remote repository shortly before it is run.

- To support diverse roots-of-trust, such that when a hardware root-of-trust is unavailable, we can have a hypervisor or an orchestration server (e.g. Kubernetes) as the RoT, even if that means a lower level of trust.

I think in general, EAT can be made to fit these use cases, given its recursive structure. But not surprisingly given its origins, the draft would need quite a few changes.

* 1.2 (and 3.12): why not spell out that a submodule can be either a hardware or software component?

* 1.2: why *dedicated* root of trust, what is it dedicated to? A RoT may have other functions; a system may in general have multiple RoTs. The word "dedicated" is not repeated anywhere else in the document, nor is it explained.

* 1.3 continues to only talk hardware, e.g. when defining the "manufacturer". Software has a manufacturer too.

* 3.3: the notion of UEID is fundamentally incompatible with some component types that we would wish to attest. For example, the lifetime of a function-as-a-service container may be less than a second, and even if it has an identity during its lifetime, there is no registry or persistent record of this identity. Is a UEID required in this scheme?

* 3.4: hey, finally some software!

I think we still don't have a handle on identifying running software, and CosWID may not be the whole answer. CosWID is more like traditional software inventorying, and we need something that will cover dynamic modern software.

Thanks,

                Yaron

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 22 Nov 2019 09:15:03 -0500

On Fri, Nov 22, 2019 at 12:57 AM Yaron Sheffer <[email-masked]>
wrote:

> I have read the EAT draft, specifically with a “cloud” use case in mind.
> To clarify, what I'm looking for is the capability:
>
>
>
> - To attest to software components that are running inside VMs, containers
> (either on VMs or bare metal), and anonymous containers
> (function-as-a-service, such as AWS Lambda).
>
> - Attestation of running (as opposed to installed) components. For
> example, container code may be pulled from a remote repository shortly
> before it is run.
>
> - To support diverse roots-of-trust, such that when a hardware
> root-of-trust is unavailable, we can have a hypervisor or an orchestration
> server (e.g. Kubernetes) as the RoT, even if that means a lower level of
> trust.
>
>
>
> I think in general, EAT can be made to fit these use cases, given its
> recursive structure. But not surprisingly given its origins, the draft
> would need quite a few changes.
>
>
>
> * 1.2: why *dedicated* root of trust, what is it dedicated to? A RoT may
> have other functions; a system may in general have multiple RoTs. The word
> "dedicated" is not repeated anywhere else in the document, nor is it
> explained.
>
> * 1.3 continues to only talk hardware, e.g. when defining the
> "manufacturer". Software has a manufacturer too.
>
> * 3.3: the notion of UEID is fundamentally incompatible with some
> component types that we would wish to attest. For example, the lifetime of
> a function-as-a-service container may be less than a second, and even if it
> has an identity during its lifetime, there is no registry or persistent
> record of this identity. Is a UEID required in this scheme?
>
> I think we still don't have a handle on identifying running software, and
> CosWID may not be the whole answer. CosWID is more like traditional
> software inventorying, and we need something that will cover dynamic modern
> software.
>

I'm going to write up some text for the CoSWID draft that would have a
CoSWID in an EAT (CWT).  If the entire CoSWID (or even SWID) were in a
claim, allowing you to add other claims, would this suffice for your use
case?

I think I'll write a draft specific to what CoSWID looks like in an EAT as
a follow up and would like coauthors.  I was thinking that might go into
SACM, referencing the EAT work.

Best regards,
Kathleen

>
> Thanks,
>
>                 Yaron
>
>
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

-- 

Best regards,
Kathleen

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 23 Nov 2019 08:53:54 -0800

Hi Yaron,

I don’t think there’s any philosophical or fundamental problem with changes to EAT so it can apply to VM’s / software. It is still an early draft and it has some biases from its origin, but we can adjust.

All claims are optional, so UEID is not required.

I would really hope that CoSWID can be the answer to all our SW Inventory and version needs. Maybe even including boot ROM and firmware versions. Agreed that SW has a manufacturer too.

LL

> On Nov 21, 2019, at 9:57 PM, Yaron Sheffer <[email-masked]> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>