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

On Fri, Nov 22, 2019 at 12:57 AM Yaron Sheffer <yaronf.ietf@gmail.com>
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).
>
> - 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.
>

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
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>

-- 

Best regards,
Kathleen