Re: [Rats] my comments on the mic line

Hi Hannes,

Thank you for the helpful feedback. It's good to know exactly what would
help in a new version.

On Wed, Nov 8, 2023 at 11:53 AM <hannes.tschofenig@gmx.net> wrote:

> Hi Kathleen,
>
> I have just re-read the draft myself and have similar questions.
> The architecture is not clear to me. A figure would help me.
>

Great, I'll work on a figure.

>
> I also believe there is a bit of a terminology mix-up. The RATS
> architecture already defines an extensive list of terms and you add even
> more (without defining them). I have challenges understanding many of the
> sentences.
>

Yes, I need to update on all the terms created over the last few years. I
used terms that were okay 3 years ago and that the general population might
understand. I'll work on this.

>
> There are also lots of references missing. Is it necessary to even talk
> about these specifications/technologies to get the idea across?
>

I think they can be removed. I ran out of time and had wanted to put in the
references. Part was that I wanted to make sure others understood that the
assessments using local or implicit attestation are in place already for
assurance of hardware, firmware, BIOS, and the host server (e.g. ESXi) in a
container environment. We've been working with a couple of these vendors.

> I believe a simplified example would help the reader understand.
>
> In general, there is also the question about what you are proposing. It
> seems that you propose the following:
>
> -  an architecture extension (in the style of how draft-ietf-rats-daa
> extends the RATS architecture)    , and
> - new claims for EAT.
>
> Is this correct?
>
Yes, that's correct. It's meant to be simple, to create a registry that
allows you to name a policy and level that is being communicated to a
posture management system as well as the posture assessment result. Once
all are collected, the posture management system can convey the status of a
cluster or Pod, full VM stack, etc.

> The document is somewhat incomplete. The claim definition is missing, the
> IANA consideration section for those claims is empty, the reference to RATS
> cannot be informative, the appendices should be removed, etc.

Yes, I did this intentionally as I'd like to make sure there is
collaboration, ideally in a WG, to reach consensus on what should be in the
EAT. Laurence has offered assistance on the claims for when we are ready
and Thomas has connected me to some key individuals who should have shared
interest in the work to develop it as it would be needed. It will be
important to have the input of implementers at both the point of assessment
as well as the posture management system receiving the result.

I hope that helps and your feedback was very helpful.

Thank you,
Kathleen

>
>
> Ciao
> Hannes
>
>
> -----Original Message-----
> From: RATS <rats-bounces@ietf.org> On Behalf Of Thomas Fossati
> Sent: Mittwoch, 8. November 2023 13:12
> To: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>; rats <
> rats@ietf.org>
> Subject: [Rats] my comments on the mic line
>
> Hi Kathleen,
>
> sorry you didn't feel good, I hope you'll recover soon!
>
> This is a copy of the comments I made on the mic line, feel free to
> address them whenever you feel better.
>
> First of all, for me, it is important to get a grasp of the system
> architecture you have in mind to understand whether this work is in the
> scope of RATS.
>
> IIUC, you have a composite device that produces complex, multi-layered
> evidence.  Then a (local) verifier appraises the evidence and produces an
> attestation result.  Then a relying party (i.e., some kind of
> governance/risk-compliance application) uses its application-specific
> appraisal policy to process the attestation result and create an
> “attestation” (= NIST definition #2, see [1]) using the claims you want to
> define/register.
>
> If that is the case, it'd seem to me that the claims set is outside of the
> RATS picture - they'd be a message coming out of the RP box in the bottom
> right-hand corner of the architecture picture.
>
> If that is not the case - apologies if I misconstrued your design :-)
> - and the claims set is part of the attestation result coming out of the
> verifier, then it's good to go for me because this would be semantics
> encoded in one of the RATS conceptual messages.
>
> In any case, RATS or not, this is very relevant work.
>
> cheers, thanks!
>
> [1] https://csrc.nist.gov/glossary/term/attestation
>
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>
>

-- 

Best regards,
Kathleen