Subject: [Rats] Use the term "attester" instead of root of trust

From: Laurence Lundblade <[email-masked]>
Date: Fri, 16 Aug 2019 12:23:52 -0700

I propose we use the term “attester” instead of root of trust in RATS/EAT. We say something like this about an attester:

While it is not required, for many implementations the attester will involve a root of trust. It is also quite reasonable for profile specifications for specific use cases to require a root of trust.

This not a big divergence from the current definition of attester in draft-birkholz-rats-architecture-01 <https://tools.ietf.org/html/draft-birkholz-rats-architecture-01>.

To go on with some more comments on the current definition of attester

>    Attester:  The producer of attestation evidence that has a root of
>       trust for reporting (RTR)
As above, RTR should be optional

>  and implements a conveyance protocol,
Conveyance protocol should be outside the attester so the token/evidence can be put into extensions in existing protocols, HTTP headers …

> authenticates using an attestation credential,

>  consumes assertions about itself
I’m not sure where people think the attester boundary is. I think it is OK for the attester to take in claims from lots of different places, even those less-secure than the attestation signing keys as long as they are labeled as such. For example, the Qualcomm implementation runs in the TEE, but takes in claims from the Android app that requests the attestation.

I think we want to accommodate something running in the cloud that checks reference values and knows about implicit claims. It might be a middle man between chip makers and relying parties so that every relying party doesn’t have to know about every chip maker. It may output signed EATs. If we call this an attester, the assertions are not about itself.

>  and presents it to a consumer of evidence (e.g. a
>       relying party or a verifier).  

> Every output of an attester can be appraised via reference values.
This should not be required. Location, for example can’t compare to a reference value.

> 4.1.1 <https://tools.ietf.org/html/draft-birkholz-rats-architecture-01#section-4.1.1>.  Attester Duties
> 
>    o  Acquisition or collection of assertions about itself
Same comment as above related to “itself”.

> 
>    o  Provide or create proof that an assertion is bound to the Attester
> 
>    o  Create Evidence from assertion bundles via roots-of-trust

Same comment as above related to root of trust.

LL

---

From: "Oliver, Ian (Nokia - FI/Espoo)" <[email-masked]>
Date: Sun, 18 Aug 2019 10:36:57 +0000

--

Dr. Ian Oliver

Cybersecurity Research

Distinguished Member of Technical Staff

Nokia Bell Labs

+358 50 483 6237

---

From: "Oliver, Ian (Nokia - FI/Espoo)" <[email-masked]>
Date: Sun, 18 Aug 2019 10:58:34 +0000

I'm just trying to put this into some more familiar architectural terms that we have implemented. So for example, we have an attestation server (AS) that can connect to a daemon running on, say, some servers/IoT devices/elements with TPMs.

Do I understand that the elements above are claimants and that the AS takes the roles of attester, verifier and authentication checker, while the daemon interpreting and responding to requests from the AS is the relaying party?

The data returned from the element (the claimant via the daemon) is, ostensibly an EAT, though in our case is a body of data that contains the TPMS_ATTEST structure + meta-data.

Further, do I understand that the attester may have itself a root-of-trust, thus becoming in the case where it does, a claimant in its own right?

t.

Ian

--

Dr. Ian Oliver

Cybersecurity Research

Nokia Bell Labs

+358 50 483 6237

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 18 Aug 2019 11:16:52 -0700

Here’s much of what I think defines an “attester":

1) It has some private / secret key material it uses to sign claims. Usually this is an ECDSA private key, but it could be a symmetric key used with a MAC. The RATS architecture document refers to this as an “attestation credential” and to the process of signing as "Provide or create proof that an assertion is bound to the Attester” (by my understanding).

2) It outputs evidence. An EAT is evidence. Evidence is claims / assertions that are signed so their authenticity can be checked by the verifier. 
The RATS architecture document doesn’t formally define evidence (it really needs to), but usually depicts it as what goes from the attester to the verifier. Also, everyone I have talked to personally seems to use the term evidence in this way.

3) It is an implementation of EAT or some other attestation token format. It is not a legal entity like a chip manufacturer or service operator. 

4) There is a notion of a boundary around the attester. The boundary might the TEE boundary, a user mode / kernel mode boundary, inside a TPM vs outside a TPM chip or simply the bounds of an Android app. The key material and signing implementation are inside this boundary. (IMO most definitions of root of trust seem to lack this concept). 

5) For most implementations, the claims originate inside the boundary, but that is not required.

I don’t understand the term claimant yet, so I’m going avoid it.

> On Aug 18, 2019, at 3:58 AM, Oliver, Ian (Nokia - FI/Espoo) <[email-masked]> wrote:
> 

If I’m understanding right, your “AS" is actually the RATS verifier and/or RATS relying party. Your “daemon" is the RATS attester.

It is the server/IoT devices/elements that you are trying to evaluate for trustworthiness. The claims and assertions are about these, right? They are the ones that have the secret signing keys, right?

There is a signed data structure that goes from the server/IoT devices/elements to the AS. That is the evidence. 

The AS receives the evidence and has public key material to evaluate the signature.

(Pardon if I’ve gone on too long, just trying to be clear)

LL

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

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 19 Aug 2019 18:58:13 +0000

See inline [nms]

On 8/18/19, 11:17 AM, "RATS on behalf of Laurence Lundblade" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

I don’t understand the term claimant yet, so I’m going avoid it.
[nms] Claimant is synonymous with ‘asserter’ in the most recently presented architecture slides. I believe fixing the term in the arch draft is on the issues list. A simple definition is the Asserter (Claimant) is a supply chain entity that conveys reference values to a Verifier so that the Verifier can compare ‘reference’ claims with actual claims aka ‘evidence’.

On Aug 18, 2019, at 3:58 AM, Oliver, Ian (Nokia - FI/Espoo) <[email-masked]<mailto:[email-masked]>> wrote:

LL

t.

Ian

--
Dr. Ian Oliver
Cybersecurity Research
Distinguished Member of Technical Staff
Nokia Bell Labs
+358 50 483 6237
_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 22 Aug 2019 11:23:35 -0700

Below

> On Aug 19, 2019, at 11:58 AM, Smith, Ned <[email-masked]> wrote:
> 
> See inline [nms]
>  
> On 8/18/19, 11:17 AM, "RATS on behalf of Laurence Lundblade" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
>  
> [nms] Claimant is synonymous with ‘asserter’ in the most recently presented architecture slides. I believe fixing the term in the arch draft is on the issues list. A simple definition is the Asserter (Claimant) is a supply chain entity that conveys reference values to a Verifier so that the Verifier can compare ‘reference’ claims with actual claims aka ‘evidence’

I few emails ago, I described how trust is fundamentally established out of band. Some how the verifier/relying party must get the public key to verify the signature on the token. This is also how they implicitly know some of the main security characteristics of the entity being attested to, like how well the private key is protected. Someone has to publish this public key and the implicit characteristics associated with it.

That has to be a role in the RATS architecture. 

It seems like claimant is closest to that role.

I don’t think it is always the case that the role publishing the reference values is the same as the role publishing the public key used to verify. For example, a TPM or TPM-like subsystem might exist and have the signing keys. It is made by one manufacturer. It has some inputs for measurements and claims and is tasked with measuring the HLOS. It can even be used with many different HLOS’s. The reference values don't come from this vendor. Instead they come from the various HLOS vendors.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 23 Aug 2019 01:05:09 +0000

See inline [nms]

On 8/22/19, 11:24 AM, "Laurence Lundblade" <[email-masked]<mailto:[email-masked]>> wrote:

Below

On Aug 19, 2019, at 11:58 AM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

See inline [nms]

That has to be a role in the RATS architecture.
[nms] It is clearly a dependency – if not on a RATS role directly then on something else outside of the architecture.

It seems like claimant is closest to that role.
[nms] Asserter (claimant) and Verifier have the challenge of somehow introducing themselves. Given there are existing authentication frameworks and protocols that address authentication and trusted 3rd parties. Maybe it is OK for the Asserter role to be described as having such a dependency?

I don’t think it is always the case that the role publishing the reference values is the same as the role publishing the public key used to verify.
[nms] agree. These could be different mechanisms. However, the Asserter and the introduction of the Asserter to the Verifier do not necessarily require another architectural role. They could simply agree to meet physically and exchange public keys (PGP key party).
For example, a TPM or TPM-like subsystem might exist and have the signing keys. It is made by one manufacturer. It has some inputs for measurements and claims and is tasked with measuring the HLOS. It can even be used with many different HLOS’s. The reference values don't come from this vendor. Instead they come from the various HLOS vendors.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 22 Aug 2019 18:35:22 -0700

> On Aug 22, 2019, at 6:05 PM, Smith, Ned <[email-masked]> wrote:
> 
> See inline [nms]
>  
> On 8/22/19, 11:24 AM, "Laurence Lundblade" <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Below
> 
> 
>> On Aug 19, 2019, at 11:58 AM, Smith, Ned <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> See inline [nms].
>>  

I think it should be in the architecture document because it is crucial.  We don’t have to define a protocol or info model or anything for it, but we should talk about it and generally frame it up. 

> [nms] Asserter (claimant) and Verifier have the challenge of somehow introducing themselves. Given there are existing authentication frameworks and protocols that address authentication and trusted…

Seems OK to me to describe the service needed at a very high level and leave it open as to the mechanism.

As you say, it can be a physical meeting to exchange PGP keys. Or maybe there are new businesses that step in to aggregate the way CA’s work for TLS. Lots of different solutions are likely in between.

I think the out-of-band trust role is much more important than the reference-value-supplying role. You can have real attestation without reference values. For example, most claims can be implicit. The entity has secure boot and can be assumed to perform correctly. Maybe the only claim is location.

If you don’t have the out-of-band trust, the measurements are worthless, so the architecture is incomplete if it just has a role that provides reference values.

I hope we can get to a clear architecture with all of this laid out. I think it will help cut through a lot of confused conversations.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 23 Aug 2019 19:53:40 +0000

[snip]

I think the out-of-band trust role is much more important than the reference-value-supplying role.
[nms] I may not understand what you mean by these terms “out-of-band trust role” and “reference-value-supplying role”. Generally, they appear to fit in the “Asserter role” side of the diagram Henk displayed at 105 session #2.

You can have real attestation without reference values. For example, most claims can be implicit. The entity has secure boot and can be assumed to perform correctly. Maybe the only claim is location.
[nms] I agree the Verifier role needs to somehow know which claims / assertions of trustworthiness apply to the Attester and that not all claims must be conveyed as Evidence. A definition of implicit attestation might suggest all assertions of trustworthiness could be conveyed via an out-of-band channel (where out-of-band refers to a conveyance that isn’t the one carrying Evidence). Recall, that the RATS WG deemed definition of Asserter / Assertions out of scope for now. Of course the architecture can talk about them. Hence, it is in scope to say that Evidence could be as simple as a Nonce claim and a Verifier could conclude that the Nonce + OOB claims = effective claim set. More concretely, the Evidence claims set (E) + (union) the Assertions claims set (A) = effectiVe claims set (V).
I’m not sure if you are also suggesting that implicit could mean something other than explicitly described Assertions. For example, Asserter and Verifier could meet at a coffee shop and agree that whenever a certificate path resolves to the trust anchor for the Asserter that claims set (S) also can be inferred. Hence, V = (S + A + E). The charter limitation implies we can define drafts that define E for the Attester and Verifier roles and S and A for the Verifier role only and not how Verifier obtains (S, A).

If you don’t have the [1] out-of-band trust, the measurements are worthless, so the architecture is incomplete if it just has a role that provides reference values.
                                [nms] Right. The architecture should assume that role entities have valid credentials (e.g. certificates + private key) and that the Verifier can resolve that it trusts the role entities’ credentials (somehow). If ‘out-of-band’ [1] means Asserter(s) then their Assertions (measurements) are expected to be their “provable assertions”; where provable means signed by the Asserter’s credential key.
[nms] We might want to qualify “Assertions” as “Provable Assertions” in the architecture to make it clear that there is a way for the Verifier to accept them without blindly trusting an assertion given to it. This would also qualify it in terms of an ISO/IEC terminology that defines Assertion as ‘a statement that is not necessarily provable’.
                                [nms] We could have a discussion about the veracity of Asserter(s)’ credentials. But I think it ends up being a recursion of the RATS architecture. This isn’t an interesting rat hole (pun intended), except for being convinced that the recursion terminates. For example, with some sort of trust anchor provisioning protocol or manual process (see [snip]).

[nms] +1

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 30 Aug 2019 12:36:01 -0700

Changed the subject as I want to reorient the discussion a bit. Apologies if this is all obvious to you. 

When measurements are being performed there is the subsystem that is doing the reporting / measuring and the subsystem that is being measured. 

I think the attester is the subsystem that is doing the reporting. It generates and formats the claims, has the signing key and does the signing.

I am calling the subsystem that is being measured the measurement target. I am proposing that the attester measures the measurement target in RATS architecture.

For the measurement to be of best value, there must be isolation between the attester and the measurement target. For example the attester doing the measurement should be a TEE, TPM or such. The measurement target is usually the HLOS like Linux or Windows.

The point of measurement is so that attacks against the measurement target can be detected. If there is no isolation, the attacker that succeeds against the measurement target is likely to be go on to affect the attester and then the evidence (e.g. measurement claims in an EAT token) can be manipulated.

In some architectures the manufacturer of the attester will be different than the manufacturer of the measurement target. For example a TPM is made by a TPM chip vendor. A TEE is made by a SoC vendor. These are different than the HLOS vendor, the vendor of Windows, Linux or the router’s OS.

The verifier role primarily needs two thing to successfully verify measurement evidence. 

1) They need the public key to verify the signature generated by the attester and to know that the key is trusted and probably some implied claims.

2) They need the reference values for what is being measured. For example, the expected values for Linux kernel 5.x on x86 or such.

I think 1) and 2) are likely to come from different manufacturers and thereby might be depicted as separate roles in the architecture.

1) requires the out-of-band trust role. A RATS system without 1) is not very secure and not something we want to put in our architecture.

2) requires the reference-value supplier role. Some RATS systems will have 2) and some will not. You can have a RATS system without 2). Android Key Store and FIDO’s use of attestation are examples.

The verifier has to have a trust relationship with both the manufacturer of the attester and the manufacture of the HLOS. Or perhaps I should call these two the attestion asserter and the reference-value asserter. (I prefer manufacturer because “asserter” is too close to “attester”, is fairly abstract and has some confusion around it for me).

LL

> On Aug 23, 2019, at 12:53 PM, Smith, Ned <[email-masked]> wrote:
> 
> [snip]
>

---

From: Giridhar Mandyam <[email-masked]>
Date: Fri, 30 Aug 2019 19:57:53 +0000

I am not sure why we are trying to re-define terms that have already been defined in the literature.  In my review on the -01 version of the architecture doc [1], I cited a couple of papers where terminology had been addressed [2]-[3].  I wonder if the RATS architecture editors did a complete literature review prior to the creation of this document, and if so whether they can provide a justification as to why they rejected previous approaches to defining attestation terminology and architecture.

In particular, [2] has the following text:

“Terminology. An appraiser is a party, generally a computer on a network, making a decision about some other party or parties. A target is a party about which an appraiser needs to make such a decision.”

“Terminology. Attestation is the activity of making a claim to an appraiser about the properties of a target by supplying evidence which supports that claim. An attester is a party performing this activity. An appraiser's decision-making process based on attested information is appraisal.”

“Terminology. To measure a target means to collect evidence about it through direct and local observation of it.”

[1] https://mailarchive.ietf.org/arch/msg/rats/9iIrnD9YixKCuwOGKtvGZIzd_bU.

[2] Coker, George et al.  "Principles of Remote Attestation."  International Journal on Information Security.  Vol. 10.  No .2.  2011.  pp. 63-81.  Available at http://web.cs.wpi.edu/~guttman/pubs/remote_attest.pdf.

[3] J. Guttman et al.  ""Attestation:  Evidence and Trust".  MITRE Technical Report MTR080072.  March 2008. https://www.mitre.org/sites/default/files/pdf/07_0186.pdf.

-Giri Mandyam

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Friday, August 30, 2019 12:36 PM
To: Smith, Ned <[email-masked]>
Cc: [email-masked]
Subject: [Rats] attester vs measurement target (was Re: Use the term "attester" instead of root of trust)

CAUTION: This email originated from outside of the organization.
Changed the subject as I want to reorient the discussion a bit. Apologies if this is all obvious to you.

LL

On Aug 23, 2019, at 12:53 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

[snip]

LL

---

From: Ira McDonald <[email-masked]>
Date: Fri, 30 Aug 2019 17:21:35 -0400

Hi,

+1 to Girii's comments and suggestions.  Reinventing terminology
(the curse of the computer industry) leads to automatic cognitive
disconnects and confusion and benefits no one.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
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]
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, Aug 30, 2019 at 3:58 PM Giridhar Mandyam <[email-masked]>
wrote:

> I am not sure why we are trying to re-define terms that have already been
> defined in the literature.  In my review on the -01 version of the
> architecture doc [1], I cited a couple of papers where terminology had been
> addressed [2]-[3].  I wonder if the RATS architecture editors did a
> complete literature review prior to the creation of this document, and if
> so whether they can provide a justification as to why they rejected
> previous approaches to defining attestation terminology and architecture.
>
>
>
> “*Terminology*. *An appraiser is a party, generally a computer on a
> network, making a decision about some other party or parties. A target is a
> party about which an appraiser needs to make such a decision*.”
>
>
>
> “*Terminology*. *Attestation** is the activity of making a claim to an
> appraiser about the properties of a target by supplying evidence which
> supports that claim. An attester is a party performing this activity. An
> appraiser's decision-making process based on attested information is
> appraisal*.”
>
>
>
> “*Terminology*. *To measure a target means to collect evidence about it
> through direct and local observation of it*.”
>
>
>
> *From:* RATS <[email-masked]> *On Behalf Of * Laurence Lundblade
> *Sent:* Friday, August 30, 2019 12:36 PM
> *To:* Smith, Ned <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* [Rats] attester vs measurement target (was Re: Use the term
> "attester" instead of root of trust)
>
>
>
> *CAUTION*: This email originated from outside of the organization.
>
> When measurements are being performed there is the subsystem that is doing
> the reporting / measuring and the subsystem that is being measured.
>
>
>
> I think the *attester* is the subsystem that is doing the reporting. It
> generates and formats the claims, has the signing key and does the signing.
>
>
>
> I am calling the subsystem that is being measured the *measurement
> target. *I am proposing that the attester *measures* the measurement
> target in RATS architecture.
>
>
>
> For the measurement to be of best value, there must be isolation between
> the attester and the measurement target. For example the attester doing the
> measurement should be a TEE, TPM or such. The measurement target is usually
> the HLOS like Linux or Windows.
>
>
>
> The point of measurement is so that attacks against the measurement target
> can be detected. If there is no isolation, the attacker that succeeds
> against the measurement target is likely to be go on to affect the attester
> and then the evidence (e.g. measurement claims in an EAT token) can be
> manipulated.
>
>
>
> In some architectures the manufacturer of the attester will be different
> than the manufacturer of the measurement target. For example a TPM is made
> by a TPM chip vendor. A TEE is made by a SoC vendor. These are different
> than the HLOS vendor, the vendor of Windows, Linux or the router’s OS.
>
>
>
> 1) They need the public key to verify the signature generated by the
> attester and to know that the key is trusted and probably some implied
> claims.
>
>
>
> 2) They need the reference values for what is being measured. For example,
> the expected values for Linux kernel 5.x on x86 or such.
>
>
>
> I think 1) and 2) are likely to come from different manufacturers and
> thereby might be depicted as separate roles in the architecture.
>
>
>
> 1) requires the out-of-band trust role. A RATS system without 1) is not
> very secure and not something we want to put in our architecture.
>
>
>
> 2) requires the reference-value supplier role. Some RATS systems will have
> 2) and some will not. You can have a RATS system without 2). Android Key
> Store and FIDO’s use of attestation are examples.
>
>
>
> The verifier has to have a trust relationship with both the manufacturer
> of the attester and the manufacture of the HLOS. Or perhaps I should call
> these two the attestion asserter and the reference-value asserter. (I
> prefer manufacturer because “asserter” is too close to “attester”, is
> fairly abstract and has some confusion around it for me).
>
>
>
> LL
>
>
>
>
>
>
>
> [nms] I may not understand what you mean by these terms “out-of-band trust
> role” and “reference-value-supplying role”. Generally, they appear to fit
> in the “Asserter role” side of the diagram Henk displayed at 105 session #2.
>
>
>
>
> You can have real attestation without reference values. For example, most
> claims can be implicit. The entity has secure boot and can be assumed to
> perform correctly. Maybe the only claim is location.
>
> [nms] I agree the Verifier role needs to somehow know which claims /
> assertions of trustworthiness apply to the Attester and that not all claims
> must be conveyed as Evidence. A definition of implicit attestation might
> suggest all assertions of trustworthiness could be conveyed via an
> out-of-band channel (where out-of-band refers to a conveyance that isn’t
> the one carrying Evidence). Recall, that the RATS WG deemed definition of
> Asserter / Assertions out of scope for now. Of course the architecture can
> talk about them. Hence, it is in scope to say that Evidence could be as
> simple as a Nonce claim and a Verifier could conclude that the Nonce + OOB
> claims = effective claim set. More concretely, the Evidence claims set (E)
> + (union) the Assertions claims set (A) = effectiVe claims set (V).
>
> I’m not sure if you are also suggesting that implicit could mean something
> other than explicitly described Assertions. For example, Asserter and
> Verifier could meet at a coffee shop and agree that whenever a certificate
> path resolves to the trust anchor for the Asserter that claims set (S) also
> can be inferred. Hence, V = (S + A + E). The charter limitation implies we
> can define drafts that define E for the Attester and Verifier roles and S
> and A for the Verifier role only and not how Verifier obtains (S, A).
>
>
>
> If you don’t have the [1] out-of-band trust, the measurements are
> worthless, so the architecture is incomplete if it just has a role that
> provides reference values.
>
>                                 [nms] Right. The architecture should
> assume that role entities have valid credentials (e.g. certificates +
> private key) and that the Verifier can resolve that it trusts the role
> entities’ credentials (somehow). If ‘out-of-band’ [1] means Asserter(s)
> then their Assertions (measurements) are expected to be their “provable
> assertions”; where provable means signed by the Asserter’s credential key.
>
> [nms] We might want to qualify “Assertions” as “Provable Assertions” in
> the architecture to make it clear that there is a way for the Verifier to
> accept them without blindly trusting an assertion given to it. This would
> also qualify it in terms of an ISO/IEC terminology that defines Assertion
> as ‘a statement that is not necessarily provable’.
>
>                                 [nms] We could have a discussion about the
>  *veracity* of Asserter(s)’ credentials. But I think it ends up being a
> recursion of the RATS architecture. This isn’t an interesting rat hole (pun
> intended), except for being convinced that the recursion terminates. For
> example, with some sort of trust anchor provisioning protocol or manual
> process (see [snip]).
>
>
>
> I hope we can get to a clear architecture with all of this laid out. I
> think it will help cut through a lot of confused conversations.
>
> [nms] +1
>
>
>
> LL
>
>
> [email-masked]

---

From: "Smith, Ned" <[email-masked]>
Date: Sun, 1 Sep 2019 01:02:07 +0000

I recommend reading Practical Principles for Computer Security, Butler Lampson, Microsoft Research, January, 2007 [4]
This is very relevant to attestation and introduces useful terminology, much of which aligns with the goals of attestation architecture.
It predates some of the references given below.
At some point consistency is a hobgoblin. The most important objective of terminology for RATS WG (IMHO) is to be able to not talk past one another. After that, we can agree on whatever industry term is most appropriate.

Specific responses to Laurence’s remarks are inline below prefaced with [nms].
-Ned
[4] https://www.microsoft.com/en-us/research/publication/practical-principles-for-computer-security/
On 8/30/19, 14:21 PM, "Ira McDonald" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Cheers,
- Ira

mailto: [email-masked]<mailto:[email-masked]>

On Fri, Aug 30, 2019 at 3:58 PM Giridhar Mandyam <[email-masked]<mailto:[email-masked]>> wrote:

-Giri Mandyam
From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Laurence Lundblade
Sent: Friday, August 30, 2019 12:36 PM
To: Smith, Ned <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Rats] attester vs measurement target (was Re: Use the term "attester" instead of root of trust)

CAUTION: This email originated from outside of the organization.
Changed the subject as I want to reorient the discussion a bit. Apologies if this is all obvious to you.
When measurements are being performed there is the subsystem that is doing the reporting / measuring and the subsystem that is being measured. [nms] +1
I think the attester is the subsystem that is doing the reporting. It generates and formats the claims, has the signing key and does the signing. [nms] +1
I am calling the subsystem that is being measured the measurement target. I am proposing that the attester measures the measurement target in RATS architecture.
[nms] The semantics of ‘attester measures the measurement target’ seems correct to me. Based on the definitions I’ve seen for “entity” it seems correct to say a ‘measurement target’ is an entity. It seems correct to say the ‘attester is an entity’ too. But they are different entities. Since an entity can be lots of things and we need to disambiguate what is relevant to attestation, the architecture introduced the idea of role names. We chose ‘attester’, ‘verifier’, ‘relying party’ and ‘asserter’. There are many possible alternative synonymous or nearly synonymous choices to be found in an English dictionary and in computer security literature. The role names are just place holder names for now, IMO. If RATS WG prefers using different strings then these then some alternatives can be proposed. I’m OK using these for now as place holders that allow the group to discuss RATS roles semantics.
Going back to measurement target, I don’t think ‘measurement target’ conceptually would be a RATS role since it is being acted upon rather than doing something.
Note: Butler Lampson’s paper [4] uses ‘Principal’ to name entities that can ‘say’ something  (e.g. “X”) or can ‘speak-for’ another Principal. Using Lampson’s terminology, the semantic is “the Principal named ‘Attester’ measures the Object named ‘Measurement target’.” Since the goal of the architecture is to provide a meta model for attestation behavior, it makes sense to use place holder names ‘Attester’ and ‘Measurement Target’ rather than actual instance names. BTW: Lampson clarifies that Objects are also Principals because of the identity property. This allows anything to say what it is. I.e. X says X. Ultimately ‘measurement target’ is just a placeholder name for an Object that is “the target of a measurement operation”. Maybe the RATS WG is happier with a different string than “measurement target”, but we should have some alternative suggestions first (so long as they don’t change intended semantics).
For the measurement to be of best value, there must be isolation between the attester and the measurement target. For example the attester doing the measurement should be a TEE, TPM or such. The measurement target is usually the HLOS like Linux or Windows.
[nms] +1. I think it is obvious that the Attester, though isolated from the Measurement Target (MT) is nevertheless able to observe it.
The point of measurement is so that attacks against the measurement target can be detected. If there is no isolation, the attacker that succeeds against the measurement target is likely to be go on to affect the attester and then the evidence (e.g. measurement claims in an EAT token) can be manipulated.
[nms] +1
In some architectures the manufacturer of the attester will be different than the manufacturer of the measurement target. For example a TPM is made by a TPM chip vendor. A TEE is made by a SoC vendor. These are different than the HLOS vendor, the vendor of Windows, Linux or the router’s OS.
[nms] +1
The verifier role primarily needs two thing to successfully verify measurement evidence.

1)      They need the public key to verify the signature generated by the attester and to know that the key is trusted and probably some implied claims.
[nms] Verifier needs to trust Attester. The trust path can be modeled using Lampson. See Figure 4 in [4] as it seems pretty close to describing how this works for your example involving both keys and implied claims.

  1.  They need the reference values for what is being measured. For example, the expected values for Linux kernel 5.x on x86 or such.
[nms] Verifier also needs to trust that “Asserters” who claim that their assertions are ‘golden’ or ‘known good’ or ‘reference’ values. This is another conversation the Verifier has that needs a trust path as exemplified in [4], figurer 4.
I think 1) and 2) are likely to come from different manufacturers and thereby might be depicted as separate roles in the architecture.
[nms] I disagree that RATS roles need to change because the entities performing the role differs. It is a case of multiple entities performing the same function (that produces the same class of output).

1)      requires the out-of-band trust role. A RATS system without 1) (above?) is not very secure and not something we want to put in our architecture.
[nms] The idea that ‘an entity is more secure than X’ is actually a determination a Relying Party should make. Attestation should supply it with information that allows the evaluation to take place.

  1.  requires the reference-value supplier role. Some RATS systems will have 2) (above?) and some will not. You can have a RATS system without 2). Android Key Store and FIDO’s use of attestation are examples.
[nms] Currently, the RATS architecture is using ‘Asserter’. Though in past revisions it was ‘Claimant’. Neither of these seem perfect. Although, it seems the majority of cases where Assertions from Asserters will be supply chain entities, there are cases (e.g. virtualized environments) where non-supply-chain entities take on the Asserter role. It would be great if RATS WG could find single word role names as this makes talking about them easier and reduces the need for acronyms.
The verifier has to have a trust relationship with both the manufacturer of the attester and the manufacture of the HLOS.
[nms] I don’t recall what HLOS means (expands to).
Or perhaps I should call these two the attestion asserter and the reference-value asserter. (I prefer manufacturer because “asserter” is too close to “attester”, is fairly abstract and has some confusion around it for me).
[nms] Are you suggesting ‘Supplier’? Some have suggested ‘Endorser’.
LL

[snip]

LL