Re: [EAT] [Rats] Introduction

[AndreRein <[e-mail]>]

From my perspective you are right that the current discussions around (remote) attestation are very TCG shaped and in general a TPM is often regarded as _the_ security anchor. In a way this makes a lot of sense, because the TPM offers a secure identity (Root of Trust for Reporting (RTR)) and a tamper-proof storage (Root of Trust for Storage (RTS)), both of which are required for an attestation process (at least how it is generally understood today). However, it is important to note that the measurements themselves are not performed by the TPM; the TPM is only used for the secure recording and reporting of measured values during the attestation. Depending on which parts of the system are to be attested, the actual measurements are provided by other (secure) components, starting from an initial (trusted) measurement component (Root of Trust for Measurement (RTM)).

I don't want to go too much into the technical details here, but I think it makes sense for a general specification of an attestation (and a corresponding protocol) to detach itself from the TPM as a term (I'm not saying that we do this actually) and instead argue on the basis of the RoTs involved. A TPM is an excellent reference implementation that provides certain RoTs in a very secure way, but a TPM provides only one implementation possibility that realizes parts of what is necessary to report a system’s state for conducting a (remote) attestation procedure.

Best regards,

Andre

From: RATS [mailto:[e-mail]] On Behalf Of Laurence Lundblade
Sent: Sonntag, 9. September 2018 18:38
To: Shawn Willden <swillden=[e-mail]>
Cc: [e-mail]; Carsten Bormann <[e-mail]>; [e-mail]
Subject: Re: [Rats] [EAT] Introduction

My understanding from the RATS BoF and talking to Henk, Marty and others is that it is about sending the attestations created by TPMs to a remote entity. These  attestation messages contain the usual measurements of the running SW that TPMs do. It is very TCG oriented.

There is some possibility of defining a protocol to carry these attestations, but I don’t think anything has been written.

There was a lot of interest in this from the network infrastructure folks that want to make sure routers, firewalls and such were booted and still running correctly.

LL





On Sep 7, 2018, at 6:51 AM, Shawn Willden <swillden=[e-mail]<mailto:swillden=[e-mail]>> wrote:

Thanks. I need to get clear on what rats@ is about. Is there a draft?

On Fri, Sep 7, 2018 at 6:29 AM Carsten Bormann <[e-mail]<mailto:[e-mail]>> wrote:
On Sep 6, 2018, at 18:37, Shawn Willden <swillden=[e-mail]<mailto:[e-mail]>> wrote:
>
> Please excuse me if I'm violating some list etiquette with this introduction; it seemed like the best way to jump in. It appears that cross-posting between RATS and EAT is fairly common, so I think I'm good on that front :-)

Hi Shawn,

welcome to this discussion!

Indeed, as long as we are trying to find out what is what between eat@ and rats@, cross-posting is the way to go.

A thread of three of the messages triggered by your initial message went to eat@ only, though:

Archived-At: ⁨<https://mailarchive.ietf.org/arch/msg/eat/G5WvKAAXc16ixn30MbcfErLmUQ4>⁩
Archived-At: ⁨<https://mailarchive.ietf.org/arch/msg/eat/DxM8NcxqPsR6HZXDS1q24lUqMg8>⁩
Archived-At: ⁨<https://mailarchive.ietf.org/arch/msg/eat/61cWm6byj-9tItyjUIi3PyGsCJk>⁩

As these are essentially about rats@ content (proof of protection), it would be useful for rats@ people to read them, too (and then reply to both lists, please).

Grüße, Carsten
--
Shawn Willden | Staff Software Engineer | [e-mail]<mailto:[e-mail]> | 801-477-4296
_______________________________________________
EAT mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/eat