Subject: [EAT] Introduction

From: Shawn Willden <[email-masked]>
Date: Thu, 6 Sep 2018 10:37:50 -0600

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 :-)

My name is Shawn Willden, and I lead the Android hardware-backed security
team at Google. I designed and implemented the Keystore attestation scheme
that's been present in Android since 7.0 (Nougat) and required for new
devices since 8.0 (Oreo). Laurence invited me to participate in the EAT
effort.

I'm very interested in standard attestation protocols.  Attestation in
Keystore began as a narrow solution to a narrow problem, but it has become
clear that there is massive demand for attestation in a wide variety of
contexts. I'm not particularly happy with Keystore attestation, but it's
hard to argue for changing it given that many people have implemented
solutions on it, warty as it is. Compliance with an IETF standard would
provide a perfect rationale for revising it -- assuming, of course, that
the standard actually meets all of Android's needs.

Since I doubt everyone is familiar with Android Keystore attestation [1],
let me give a brief overview.

Android Keystore provides a place for Android apps and system components to
store and use cryptographic key material (RSA, ECC, AES & HMAC) in a
trusted [2] environment. The goal is that key material should not be
compromised even by total compromise of the Android operating system, e.g.
kernel compromise.

Further, since 6.0 (Marshmallow), various usage constraints can be attached
to keys at key creation time, and most of these constraints are also
enforced by the trusted environment, limiting the use of the trusted
environment as an oracle for an attacker who has compromised Android. The
ways that keys can be used are expressed affirmatively as "authorizations";
keys may only be used in ways defined by the associated authorizations.
Perhaps the most obviously-useful of the authorizations is authentication
binding. Authentication-bound keys may only be used when the user
authenticates via password or fingerprint so an attacker who steals or
finds your phone cannot use the keys.

So Keystore provides a valuable tool to authors of apps that require strong
security. For example, for a key used to authenticate an account holder to
a banking system. But this tool is much less valuable if the bank's server
can't verify that the secret is managed in a trusted environment. Hence,
Keystore attestation, which allows the trusted environment to prove that it
secures the key material, and specifies the authorizations that define how
it may be used.

Some important constraints upon Keystore derive from the fact that it is an
implementation (some may say "subversion") of the Java Keystore API [3].  A
result of needing to fit attestation into the standard Java APIs was that
attestations must come in the form of an X.509 certificate chain. Given
that it would be necessary for users of Keystore attestations to parse the
ASN.1 DER-encoded X.509 certificate, I opted to implement attestation as an
ASN.1 DER-encoded certificate extension, so they didn't have to parse two
different sorts of encodings. To simplify implementation in
resource-constrained trusted environments, I opted to structure the schema
around the data structure that implementations already used to manage
authorizations, namely "authorization lists".

The schema has subsequently been extended to support device ID attestation
(attesting to various device identifiers -- though this functionality is
tightly restricted in the interest of user privacy), and attestation of
firmware versioning data. I expect more such extensions to come in each
release of Android, as more use cases are identified and implemented.

Within the Android scheme, attestation signing keys are injected into
devices during manufacturing and can never be rotated without returning the
device to the manufacturer. Signing keys are also not device-unique,
because we use standard RSA and ECDSA signatures, not a group scheme, and
we wished to avoid providing a strong unique device identifier, again for
user privacy reasons. Android compliance requirements specify that each
signing key must be injected into at least 100K devices, all of the same
model. Attestation key certificate chains are rooted in a Google-owned
certificate for Android devices with Google Play; manufacturers of non-Play
devices (e.g. Amazon) can provide their own root.

Because this is already long I won't go into the rationale behind the
decisions described in the last paragraph, but I'm happy to explain.

[1] https://source.android.com/security/keystore/attestation
[2] "Trusted" is always an interesting word. The actual security level of
the various Android trusted execution environments (TEEs) is largely
unknown. Based on what has happened every time security researchers looked
hard at them, I suspect they're not very good. However, they are isolated
from the main Android OS and the usage model generally means that it's
necessary to first compromise Android in order to even begin attacking the
TEE. Thus they provide a security benefit, though precisely how large is
unknown. With Android 9.0 (Pie) we've begun supporting Android Keystore
backed by hardware secure elements, which come with a culture of
certification testing which is presently lacking in the TEE world.
[3] https://docs.oracle.com/javase/7/docs/api/java/security/KeyStore.html

-- 
Shawn Willden | Staff Software Engineer | [email-masked] | 801-477-4296

---

From: Suresh Marisetty <[email-masked]>
Date: Fri, 7 Sep 2018 02:36:15 +0000

Hi Shawn,

Good overview.  Is there an action, take away or a proposal from your end on the ongoing EAT effort and the direction it is on?

Thanks
Suresh Marisetty

From: EAT <[email-masked]> On Behalf Of Shawn Willden
Sent: Thursday, September 6, 2018 10:08 PM
To: [email-masked]; [email-masked]
Subject: [EAT] Introduction

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 :-)

My name is Shawn Willden, and I lead the Android hardware-backed security team at Google. I designed and implemented the Keystore attestation scheme that's been present in Android since 7.0 (Nougat) and required for new devices since 8.0 (Oreo). Laurence invited me to participate in the EAT effort.

I'm very interested in standard attestation protocols.  Attestation in Keystore began as a narrow solution to a narrow problem, but it has become clear that there is massive demand for attestation in a wide variety of contexts. I'm not particularly happy with Keystore attestation, but it's hard to argue for changing it given that many people have implemented solutions on it, warty as it is. Compliance with an IETF standard would provide a perfect rationale for revising it -- assuming, of course, that the standard actually meets all of Android's needs.

Since I doubt everyone is familiar with Android Keystore attestation [1], let me give a brief overview.

Android Keystore provides a place for Android apps and system components to store and use cryptographic key material (RSA, ECC, AES & HMAC) in a trusted [2] environment. The goal is that key material should not be compromised even by total compromise of the Android operating system, e.g. kernel compromise.

Further, since 6.0 (Marshmallow), various usage constraints can be attached to keys at key creation time, and most of these constraints are also enforced by the trusted environment, limiting the use of the trusted environment as an oracle for an attacker who has compromised Android.. The ways that keys can be used are expressed affirmatively as "authorizations"; keys may only be used in ways defined by the associated authorizations. Perhaps the most obviously-useful of the authorizations is authentication binding. Authentication-bound keys may only be used when the user authenticates via password or fingerprint so an attacker who steals or finds your phone cannot use the keys.

So Keystore provides a valuable tool to authors of apps that require strong security. For example, for a key used to authenticate an account holder to a banking system. But this tool is much less valuable if the bank's server can't verify that the secret is managed in a trusted environment. Hence, Keystore attestation, which allows the trusted environment to prove that it secures the key material, and specifies the authorizations that define how it may be used.

Some important constraints upon Keystore derive from the fact that it is an implementation (some may say "subversion") of the Java Keystore API [3].  A result of needing to fit attestation into the standard Java APIs was that attestations must come in the form of an X.509 certificate chain. Given that it would be necessary for users of Keystore attestations to parse the ASN.1 DER-encoded X.509 certificate, I opted to implement attestation as an ASN.1 DER-encoded certificate extension, so they didn't have to parse two different sorts of encodings. To simplify implementation in resource-constrained trusted environments, I opted to structure the schema around the data structure that implementations already used to manage authorizations, namely "authorization lists".

The schema has subsequently been extended to support device ID attestation (attesting to various device identifiers -- though this functionality is tightly restricted in the interest of user privacy), and attestation of firmware versioning data. I expect more such extensions to come in each release of Android, as more use cases are identified and implemented.

Within the Android scheme, attestation signing keys are injected into devices during manufacturing and can never be rotated without returning the device to the manufacturer. Signing keys are also not device-unique, because we use standard RSA and ECDSA signatures, not a group scheme, and we wished to avoid providing a strong unique device identifier, again for user privacy reasons. Android compliance requirements specify that each signing key must be injected into at least 100K devices, all of the same model. Attestation key certificate chains are rooted in a Google-owned certificate for Android devices with Google Play; manufacturers of non-Play devices (e.g. Amazon) can provide their own root.

Because this is already long I won't go into the rationale behind the decisions described in the last paragraph, but I'm happy to explain.

[1] https://source.android.com/security/keystore/attestation
[2] "Trusted" is always an interesting word. The actual security level of the various Android trusted execution environments (TEEs) is largely unknown. Based on what has happened every time security researchers looked hard at them, I suspect they're not very good. However, they are isolated from the main Android OS and the usage model generally means that it's necessary to first compromise Android in order to even begin attacking the TEE. Thus they provide a security benefit, though precisely how large is unknown. With Android 9.0 (Pie) we've begun supporting Android Keystore backed by hardware secure elements, which come with a culture of certification testing which is presently lacking in the TEE world.
[3] https://docs.oracle.com/javase/7/docs/api/java/security/KeyStore.html

--
Shawn Willden | Staff Software Engineer | [email-masked]<mailto:[email-masked]> | 801-477-4296
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Shawn Willden <[email-masked]>
Date: Fri, 7 Sep 2018 05:48:43 -0600

The main action item at this point is on me, to understand the EAT draft
proposal and figure out in what ways it does or doesn't work for Keystore.
I wrote the overview so that other participants could understand my goals,
and possibly inform me if Keystore attestation is fundamentally different
from what EAT intends to accomplish. Based on Ned's reply, it sounds like
that's not the case.

On Thu, Sep 6, 2018 at 8:36 PM Suresh Marisetty <[email-masked]>
wrote:

> Hi Shawn,
>
>
>
> Good overview.  Is there an action, take away or a proposal from your end
> on the ongoing EAT effort and the direction it is on?
>
>
>
> Thanks
>
> Suresh Marisetty
>
>
>
>
>
> *From:* EAT <[email-masked]> *On Behalf Of * Shawn Willden
> *Sent:* Thursday, September 6, 2018 10:08 PM
> *To:* [email-masked]; [email-masked]
> *Subject:* [EAT] Introduction
>
>
>
> Android Keystore provides a place for Android apps and system components
> to store and use cryptographic key material (RSA, ECC, AES & HMAC) in a
> Further, since 6.0 (Marshmallow), various usage constraints can be
> attached to keys at key creation time, and most of these constraints are
> also enforced by the trusted environment, limiting the use of the trusted
> environment as an oracle for an attacker who has compromised Android.. The
> So Keystore provides a valuable tool to authors of apps that require
> strong security. For example, for a key used to authenticate an account
> holder to a banking system. But this tool is much less valuable if the
> bank's server can't verify that the secret is managed in a trusted
> environment. Hence, Keystore attestation, which allows the trusted
> environment to prove that it secures the key material, and specifies the
> authorizations that define how it may be used.
>
>
>
> Some important constraints upon Keystore derive from the fact that it is
> an implementation (some may say "subversion") of the Java Keystore API
> [3].  A result of needing to fit attestation into the standard Java APIs
> was that attestations must come in the form of an X.509 certificate chain.
> Given that it would be necessary for users of Keystore attestations to
> parse the ASN.1 DER-encoded X.509 certificate, I opted to implement
> attestation as an ASN.1 DER-encoded certificate extension, so they didn't
> have to parse two different sorts of encodings. To simplify implementation
> in resource-constrained trusted environments, I opted to structure the
> schema around the data structure that implementations already used to
> manage authorizations, namely "authorization lists".
>
>
>
> Shawn Willden | Staff Software Engineer | [email-masked] |
> 801-477-4296 <(801)%20477-4296>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 7 Sep 2018 14:29:33 +0200

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

---

From: Shawn Willden <[email-masked]>
Date: Fri, 7 Sep 2018 07:51:42 -0600

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 <[email-masked]> wrote:

> Indeed, as long as we are trying to find out what is what between eat@
> and rats@, cross-posting is the way to go.
>
> 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
>
> --

---

From: Ira McDonald <[email-masked]>
Date: Sat, 8 Sep 2018 10:07:24 -0400

Hi Shawn,

About RATS, there is Henk's excellent attestation terminology draft:

https://datatracker.ietf.org/doc/draft-birkholz-attestation-terminology/

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, Sep 7, 2018 at 9:52 AM Shawn Willden <swillden=
[email-masked]> wrote:

>  801-477-4296
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 9 Sep 2018 09:37:43 -0700

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=[email-masked]> wrote:
> 
> On Fri, Sep 7, 2018 at 6:29 AM Carsten Bormann <[email-masked] <mailto:[email-masked]>> wrote:
> On Sep 6, 2018, at 18:37, Shawn Willden <swillden=[email-masked] <mailto:[email-masked]>> wrote:
> > 
> Archived-At: ⁨<https://mailarchive.ietf.org/arch/msg/eat/G5WvKAAXc16ixn30MbcfErLmUQ4 <https://mailarchive.ietf.org/arch/msg/eat/G5WvKAAXc16ixn30MbcfErLmUQ4>>⁩
> Archived-At: ⁨<https://mailarchive.ietf.org/arch/msg/eat/DxM8NcxqPsR6HZXDS1q24lUqMg8 <https://mailarchive.ietf.org/arch/msg/eat/DxM8NcxqPsR6HZXDS1q24lUqMg8>>⁩
> Archived-At: ⁨<https://mailarchive.ietf.org/arch/msg/eat/61cWm6byj-9tItyjUIi3PyGsCJk <https://mailarchive.ietf.org/arch/msg/eat/61cWm6byj-9tItyjUIi3PyGsCJk>>⁩
> 
> Shawn Willden | Staff Software Engineer | [email-masked] <mailto:[email-masked]> | 801-477-4296
> EAT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eat

---

From: AndreRein <[email-masked]>
Date: Mon, 10 Sep 2018 10:21:31 +0000

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:[email-masked]] On Behalf Of Laurence Lundblade
Sent: Sonntag, 9. September 2018 18:38
To: Shawn Willden <swillden=[email-masked]>
Cc: [email-masked]; Carsten Bormann <[email-masked]>; [email-masked]
Subject: Re: [Rats] [EAT] Introduction

LL

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

On Fri, Sep 7, 2018 at 6:29 AM Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote:

Hi Shawn,

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

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 10 Sep 2018 13:57:03 -0700

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 <[email-masked]> wrote:
> 
> From: RATS [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Laurence Lundblade
> To: Shawn Willden <swillden=[email-masked] <mailto:swillden=[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; Carsten Bormann <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Sep 7, 2018, at 6:51 AM, Shawn Willden <swillden=[email-masked] <mailto:swillden=[email-masked]>> wrote:
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/eat <https://www.ietf.org/mailman/listinfo/eat>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/eat <https://www.ietf.org/mailman/listinfo/eat>

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 11 Sep 2018 10:16:50 +0200

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:
> 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).
> 
> 
> 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 <[email-masked] 
>> <mailto:[email-masked]>> 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:[email-masked]]*On Behalf Of*Laurence Lundblade
>> *Sent:*Sonntag, 9. September 2018 18:38
>> *To:*Shawn Willden <swillden=[email-masked] 
>> <mailto:swillden=[email-masked]>>
>> *Cc:[email-masked] <mailto:[email-masked]>; Carsten Bormann 
>> <[email-masked] <mailto:[email-masked]>>;[email-masked] <mailto:[email-masked]>
>> *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=[email-masked]
>>     <mailto:swillden=[email-masked]>> wrote:
>>         On Sep 6, 2018, at 18:37, Shawn Willden
>>         <swillden=[email-masked]
>>         <mailto:[email-masked]>> 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,
>>
>>         Indeed, as long as we are trying to find out what is what
>>         between eat@ and rats@, cross-posting is the way to go.
>>
>>         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 [email-masked]
>>     <mailto:[email-masked]> | 801-477-4296

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Sep 2018 13:25:49 -0400

Thank you for a great summary email.
It's very very useful to me.

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

I'm reading many fewer emails on eats, and I guess I shall subscribe to rats.
Probably should have one list.  Although I missed IETF102 and the Bar Bof,
I've been through the slides and some of your documents.

...
    > solutions in the IETF and elsewhere.

I do not feel sufficiently grounded in an actual use case that I feel that
we can really make progress.   I am having visions of X.500 here.

Who is going to write the running-code?

While I'm not a fan of pay-to-play "standards" groups, I continue to wonder
if TCG isn't a better place for this.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-