Re: [EAT] [Rats] Introduction

[Henk Birkholz <[e-mail]>]

Hello all,

wow. A lot more activity on the list :) That is very nice to see.

First of all, thank you for all the feedback and comments.

As Ned already addressed some of the topics and RATS related context was 
reposted by Carsten, I will reply wrt the general scope and goals of 
RATS, first. This became a rather long reply, so there is a tl;dr down 
below, after which references to current drafts are illustrated. :)


Tackling the scope of RATS:

RATS is not a single document, but the ongoing process to create a 
hardware-agnostic WG wrt remote attestation and related procedures in 
the IETF. RATS is also about providing proofs (Attestation Evidence) 
that a system is a trusted system - meaning it is doing what is intended 
to do - and nothing else. There can be several other types of proofs, 
but this is the scope we intend to starting with at the moment.

There is a big range of things that can make use of these procedures and 
solutions ranging from managed user-devices, to critical infrastructure, 
to constrained-node environments. There is a similar divers set of 
stakeholders that has a demand for solutions to establish trust in the 
trustworthiness of a communication partner that go beyond Proof of 
Possession.

There is a slide set that we presented in an informal meeting (a "Bar 
BoF" on-site at the 102 meeting) to get a initial round of feedback 
about the interest in this domain. And there was a lot of valuable input 
from about 50 attendees. This deck gives a general overview about RATS 
that is currently in the process of refactoring and that provided the 
basis for the ongoing work.

> https://github.com/ietf-rats/resources/blob/master/RATS-BoF_Intro.pdf


tl;dr Below follow existing documents and ongoing activities.

We are focusing on a Attestation Terminology document at the moment, to 
enable every interested party, stakeholder - i.e. everyone participating 
in the IETF (or, in fact, any SDO) to address a (sub-)type of 
attestation, while also enabling semantic interoperability between 
solutions.

> https://github.com/ietf-rats/draft-birkholz-attestation-terminology

We are disentangling the concept of Remote Attestation a bit by 
introducing roles next to Attestation Claimant and Relying Party: 
Attestor & Verifier. Also by differentiating the type of information 
that is conveyed: Attestation Claims (Implicit Attestation) and 
Attestation Evidence (Explicit Attestation).

The term TPM came up a lot.

RATS is not about a specific hardware solution, such as a TPM. But - as 
running code is often the basis for drafts - a TPM in many cases is the 
hardware an implementor can easily start with. It is simple to add to 
existing systems.

As Andreas pointed out, it is also important to highlight that a TPM can 
be used - and that is a tad bit simplified, but in essence - as a RoT 
for Reporting (Attestation Evidence), Storage, Privacy, etc. in contrast 
to the measurements (Attestation Claims) that can be created by any kind 
of Attestation Claimant in any kind of Computing Context (including a 
TEE, for example) using the TPM 2.0 Trusted Software Stack (TSS) or an 
Attestation Claimant running in a TEE, for example. In fact, there are 
usage scenarios, in which other Computing Contexts that provide an 
appropriate RoT for Reporting can take on the role of an Attestor - 
depending on the requirements addressed.

RATS is about providing the basis for semantic interoperability of 
solutions in the remote attestation domain - and creating corresponding 
solutions in the IETF and elsewhere.

We are in the progress of finalizing a document that highlights the 
Background, Goals, and Scope of RATS in the IETF.

Right now, incubator documents next to the terminology exist:

> https://datatracker.ietf.org/doc/draft-birkholz-reference-ra-interaction-model/

The interaction model document is about protocol flows and information 
elements that will compose more complex attestation 
workflows/procedures. We anticipate that not always all roles 
(Attestation Claimant, Attestor, Verifier, Relying Party), will be 
located on separate entities and also the chaining of these entities 
will have several compositions according to a usage scenario. E.g. 
sometimes Attestation Evidence will not be send to a Verifier but to a 
Relying Party that is then discovering or using an appropriate Verifier 
to get a trustworthy appraisal of the Attestation Evidence to get the 
required Attestation Results.

> https://datatracker.ietf.org/doc/draft-birkholz-yang-basic-remote-attestation/

This document illustrates a specific binding of the challenge-response 
interaction model using a YANG RPC. As this model is a combined effort 
of network vendors, this document uses the TCG Terminology as identifier 
names as basis - yet already is also including the generalized terms 
consolidated in the Attestation Terminology Document.

References to a set of other attestation-related document can be found 
in detail in the slide deck PDF referenced in the first URL in this email.

I will compose more replies, in the following days and will address more 
specific topics that came up on the list. We really appreciate the 
interest! :)

Viele Grüße,

Henk



On 09/10/2018 10:57 PM, Laurence Lundblade wrote:
> Thanks for all that Andre,
> 
> The intention of EAT is try to span both the TCG, TrustZone and other 
> technologies involved with attestation.  We haven't added text for 
> measurement claims to the EAT draft yet, but some of us were planning on 
> it and have some first drafts.
> 
> I say “try to” is because you can’t quite implement EAT using a standard 
> TPM today. TPMs only sign certain data in a particular way, and it is 
> not the CBOR/COSE format used by EAT or CWT (or JWT). The FIDO folks 
> however have a way to use TPMs to sign FIDO attestations 
> <https://fidoalliance.org/specs/fido-v2.0-ps-20150904/fido-key-attestation-v2.0-ps-20150904.html#tpm-attestation>. 
> We may be able to do something similar.  We may also just define a way 
> to tag and carry pure TPM remote attestations. Maybe there are 2-3 
> attestation variants for this.
> 
> I think the work here should be inclusive of TPM and non-TPM 
> attestations, similar to what FIDO did for similar reasons. TPMs are 
> very broadly deployed and used and there is deep experience with them. 
>   Similarly TrustZone and similar technologies are in a billion plus 
> smart phones and should to be included.
> 
> This is one of the reasons for forming a working group, rather than just 
> defining some additional CWT / JWT claims. (I also think defining those 
> claims in a universal way is interesting work).
> 
> 
> I have a few other comments on measurement.
> 
> My understanding is that the TPM measurements taken are boot are still 
> quite good even though the TPM doesn’t make them. This is because it is 
> done in stages. First some very trusted and very small code starts when 
> the CPU comes out of reset. It’s only job is to load the next junk of 
> code and measure it. It stores the measurement in the TPM. The next 
> stage is similar but does more. In this scheme, no code ever measures 
> itself and all code is measured before it starts running.
> 
> TrustZone-based devices are not so standardized in how they boot and 
> they haven’t done so much with measurement. However TrustZone is more 
> capable than a TPM and can perform measurements of the non-secure world 
> at any time. It doesn’t have to be at boot. This would allow some of the 
> periodic configuration confirmation attestations that the router and 
> network secure functions folks are talking about.
> 
> LL
> 
> 
> 
> 
> 
>> On Sep 10, 2018, at 3:21 AM, AndreRein <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> 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] 
>> <mailto:swillden=[e-mail]>>
>> *Cc:*[e-mail] <mailto:[e-mail]>; Carsten Bormann 
>> <[e-mail] <mailto:[e-mail]>>;[e-mail] <mailto:[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
>>
>> _______________________________________________
>> EAT mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/eat
> 
> 
> 
> _______________________________________________
> EAT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/eat
>