Subject: [Rats] New RATS Architecture document

From: Henk Birkholz <[email-masked]>
Date: Tue, 10 Sep 2019 15:12:32 +0200

Hi all,

we created a fully revised architecture document that maps and 
represents the state of the current discussion and the material 
presented at the last IETF meeting.

The current Editor's version can be found here:

> https://ietf-rats.github.io/draft-birkholz-rats-architecture/draft-birkholz-rats-architecture.html

We will submit a new version the day after the RATS virtual interim.

TL;DR
Below you can find a list of essential changes & a list of action items 
still to be addressed.

This version of the RATS Architecture document:

* does not define or uses the terms "root(s) of trust" (RoT) or "Trust 
Anchor" (TA) at the moment. (Note: It is a fact that the Asserter Role 
_is_ a TA for the Verifier Role and that an Attester Role _could_ rely 
on RoTs. But - this content will not go into the main body of this 
document),

* does define RATS Roles, Messages, and Principals formerly known as 
"Actors" (borrowing heavily from ABLP),

* provides an even more "base" interaction model diagram for the RATS 
Roles than presented in the last IETF meeting slide deck:

> https://datatracker.ietf.org/meeting/105/materials/slides-105-rats-sessb-rats-architecture-interaction-model-challange-response-yang-module-information-module-00.pdf

* introduces a framework for "level of confidence" in the 
trustworthiness of an Attester and the endorsement of the protection 
characteristics of its "Attesting Computing Context", allowing for other 
entities to use this framework and fill it with, e.g., openly defined 
levels of confidence metrics,

* is not based on the primitive of "trust" but the concept of 
"trustworthiness" as illustrated by the RATS charter,

* simplifies the definitions of Attester and Verifier that seemed to 
have caused some unfortunate confusion following the proposal of Giri 
and starting with commonly-accepted definitions and then justify why 
they may need to be modified,

* differentiates between the Attesting Computing Environment and the 
Attested Computing Environment better, which both are components of an 
Attester,

* uses the "Claim" concept as a building block to compose Evidence, 
Known-Good-Values and Endorsements. Conversely, the "Assertion" concept 
is dropped in this proposal (as initially suggested by Laurence, IIRC?). 
(Note: this was done to simplify the discussion about the information 
model. Please also note: Due to the {J|C}WT definition of "Claim", a 
key/value pair is implied, which is already a data model decision and 
not mandated by an information model), and

* analogously, now uses the term Known-Good-Values instead of 
Attestation Assertions.

For future versions the authors intent:

* to elaborate on the use of RATS Principals, including more exemplary 
diagrams of RATS Role composition and interaction between RATS 
Principals based on the use case document (and by that address a unified 
mapping to TEEP, RIV, and models that use EAT),

* to shift some of the focus on technical-trust as proposed by Thomas. 
(the Endorsements provided by an Asserter are a first step into that 
direction),

* still not to define the roots of trust terms nor invent new words for 
them :) But - start to reference them on a minimal level and define a 
base set of primitives they can provide in order to describe what they 
actually are and can do in the context of RATS as proposed by Ira, Simon 
and Thomas,

* to introduce and define a concise scope for layered attestation, 
addressing, e.g., the staging of Computing Environments and the 
(un-)availability of an Attesting Computing Environment at certain 
points of time, or, another example given, addressing the 
differentiation of an attested boot sequence of an Attester and an 
Attester running TEEs or rich systems for years,

* to address the change of Roles of a Principal over time as proposed by 
Ian,

* to move the remaining architectural sections in the EAT draft into the 
RATS Architecture draft, and

* to shift some of the focus on the out-of-band trust establishment in 
order to illustrate a coherent RATS ecosystem (e.g. the provisioning of 
key material is not include in the "base diagram" anymore for now - this 
will be more elaborated on in future section of the architecture).

Viele Grüße,

Henk

---

From: Giridhar Mandyam <[email-masked]>
Date: Tue, 10 Sep 2019 16:28:33 +0000

Henk and other editors of the architecture doc,

I appreciate the effort put into this latest revision, and I will review it with a fresh eye. 

I do have one overarching question:  why is this document listed as 'Standards Track' (as opposed to 'Informational')?  I had expressed my concerns about this in an earlier review of the doc:  https://mailarchive.ietf.org/arch/msg/rats/9iIrnD9YixKCuwOGKtvGZIzd_bU. 

Since the editors' team is composed of experienced IETF'ers, I assume that there are solid reasons for doing so.  If you all have stated them before, I hope you do not mind me requesting that you lay out your reasons again because I seemed to have missed it.

-Giri

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Henk Birkholz
Sent: Tuesday, September 10, 2019 6:13 AM
To: [email-masked]
Subject: [Rats] New RATS Architecture document

-------------------------------------------------------------------------
CAUTION: This email originated from outside of the organization.
-------------------------------------------------------------------------

Hi all,

we created a fully revised architecture document that maps and represents the state of the current discussion and the material presented at the last IETF meeting.

TL;DR
Below you can find a list of essential changes & a list of action items still to be addressed.

Viele Grüße,

Henk

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

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 15 Sep 2019 13:39:35 -0700

This new architecture doc is starting to work pretty well for me. There are still things to work on, but I support adoption of it.

I particularly like the definition of Attester, Verifier, Relying Party, Claim and Evidence.

I’m fine with moving the architecture parts in EAT to this document.

LL

> On Sep 10, 2019, at 6:12 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi all,
> 
> * does not define or uses the terms "root(s) of trust" (RoT) or "Trust Anchor" (TA) at the moment. (Note: It is a fact that the Asserter Role _is_ a TA for the Verifier Role and that an Attester Role _could_ rely on RoTs. But - this content will not go into the main body of this document),
> 
> * does define RATS Roles, Messages, and Principals formerly known as "Actors" (borrowing heavily from ABLP),
> 
> * provides an even more "base" interaction model diagram for the RATS Roles than presented in the last IETF meeting slide deck:
> 
> * introduces a framework for "level of confidence" in the trustworthiness of an Attester and the endorsement of the protection characteristics of its "Attesting Computing Context", allowing for other entities to use this framework and fill it with, e.g., openly defined levels of confidence metrics,
> 
> * is not based on the primitive of "trust" but the concept of "trustworthiness" as illustrated by the RATS charter,
> 
> * simplifies the definitions of Attester and Verifier that seemed to have caused some unfortunate confusion following the proposal of Giri and starting with commonly-accepted definitions and then justify why they may need to be modified,
> 
> * differentiates between the Attesting Computing Environment and the Attested Computing Environment better, which both are components of an Attester,
> 
> * uses the "Claim" concept as a building block to compose Evidence, Known-Good-Values and Endorsements. Conversely, the "Assertion" concept is dropped in this proposal (as initially suggested by Laurence, IIRC?). (Note: this was done to simplify the discussion about the information model. Please also note: Due to the {J|C}WT definition of "Claim", a key/value pair is implied, which is already a data model decision and not mandated by an information model), and
> 
> * analogously, now uses the term Known-Good-Values instead of Attestation Assertions.
> 
> 
> * to elaborate on the use of RATS Principals, including more exemplary diagrams of RATS Role composition and interaction between RATS Principals based on the use case document (and by that address a unified mapping to TEEP, RIV, and models that use EAT),
> 
> * to shift some of the focus on technical-trust as proposed by Thomas. (the Endorsements provided by an Asserter are a first step into that direction),
> 
> * still not to define the roots of trust terms nor invent new words for them :) But - start to reference them on a minimal level and define a base set of primitives they can provide in order to describe what they actually are and can do in the context of RATS as proposed by Ira, Simon and Thomas,
> 
> * to introduce and define a concise scope for layered attestation, addressing, e.g., the staging of Computing Environments and the (un-)availability of an Attesting Computing Environment at certain points of time, or, another example given, addressing the differentiation of an attested boot sequence of an Attester and an Attester running TEEs or rich systems for years,
> 
> * to address the change of Roles of a Principal over time as proposed by Ian,
> 
> * to move the remaining architectural sections in the EAT draft into the RATS Architecture draft, and
> 
> * to shift some of the focus on the out-of-band trust establishment in order to illustrate a coherent RATS ecosystem (e.g. the provisioning of key material is not include in the "base diagram" anymore for now - this will be more elaborated on in future section of the architecture).
> 
> 
> Viele Grüße,
> 
> Henk
> 
> 
> 
> 
> 
>

---

From: Simon Frost <[email-masked]>
Date: Mon, 16 Sep 2019 17:08:11 +0000

At a first pass through this, I'm concerned that the interaction model (Fig 1 etc) has been restricted to a single pattern, the 'passport' model to use the terminology from the TEEP/RATS  slides. I don't recall this restriction being discussed. Also allowing the 'background check' model allows the relying party to have much greater flexibility on selecting an appropriate verifier. While the origins of Attester and Known Good Values are going to have close alignment, multiple verifiers may exist. A relying party may choose an alternative verifier based upon the approach to appraisal, to the form that the attestation results are presented or due to business model.

Thanks
Simon

-----Original Message-----
From: Henk Birkholz <[email-masked]>
Sent: 10 September 2019 14:13
To: [email-masked]
Subject: [Rats] New RATS Architecture document

Hi all,

TL;DR

Viele Grüße,

Henk

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: Henk Birkholz <[email-masked]>
Date: Tue, 17 Sep 2019 11:12:39 +0200

Hello Simon,

TL;DR
It's just a simplified first example diagram. There is no intent to 
artificially exclude compositions, such as the 'background check' 
composition. Corresponding diagrams will be added again.

We simplified the initial figure to... reduce the risk to overwhelm the 
reader with all the potential composition option and called it "base" 
interaction model diagram.

That said, we will "reintroduce" other and also more complex 
compositions again in future versions - especially the 'background 
model' and the 'multiple relying parties' variant. This is not intended 
to become an artificial exclusion.

The "upper level bureaucracy" in this model (Asserter & Verifier) are 
intended to be "1..n" as depicted in the meeting slide decks about the 
architecture. This was also not included in the base diagram to keep it 
simple, but maybe we should highlight that there are a lot of other ways 
to compose the roles - when we add other composition diagrams.

The goal of this refactoring of the RATS Arch I-D was to clean it up & 
out, so we have an uncluttered starting point to add content via a 
structured process.

The authors will try to update the I-D with additional role composition 
diagrams before the next virtual interim (again, the obvious ones align 
with teep).

Viele Grüße,

Henk

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Tue, 17 Sep 2019 10:16:17 +0000

Hi Henk, other draft authors,
Thanks for the efforts for largely simplifying this new version, which looks much more clear and understandable.

I have reviewed the draft through and have some comments as below:
Section 1.1
1. should "message digest" be "MAC"?
2. nit. s/A corresponding attestation provisioning workflow uses trustworthiness Claims/ A corresponding attestation provisioning workflow uses Reference Claims/
3. the Endorsements definition in Section 4.3.2 seems to be more correct than the one in this section, but still be a little abstract. Is my understanding right: an example of Endorsements is manufacturer's CA?
4. In general, the overlapping exists for the RATS messages' definition in this section and section 4.3.2. Please combine them into one.

Section 3
The last sentence emphasis on the "change". Can you clarify what kind of change it is? The change of the Evidence with time or the change between Evidence and KGV? The former seems to be too narrow, the latter is better.

Section 3.2
Although I can understand, but some contents in it are not straightforward, like: " recursive trustworthiness properties and the need for termination. " and others. I suggest to re-write them using other well-known text such as: trust chain, root of trust, etc.

Section 4.2
1. Freshness is only for replay attack? No any time freshness meaning?
2. for the principle of Identity, do you consider the privacy protection issue: run remote attestation without revealing the device's identity?
3. Some confusing terminologies: does Provenance equal to source authentication? does Veracity equal to integrity protection? Validity seems to be like Freshness, right?

Section 5
I don't get your point why the last four bytes of a challenge nonce are replaced by the IPv4 address-value of the Attester in its response. Can you clarify?

B.R.
Frank

-----邮件原件-----
发件人: RATS [mailto:[email-masked]] 代表 Henk Birkholz
发送时间: 2019年9月10日 21:13
收件人: [email-masked]
主题: [Rats] New RATS Architecture document

Hi all,

TL;DR

Viele Grüße,

Henk

---

From: Simon Frost <[email-masked]>
Date: Wed, 18 Sep 2019 14:40:14 +0000

Henk,

Thank you for the reassurance. My concern was not just with the diagram, but the descriptions used in the Roles section could be seen as proscriptive to a single solution when accompanied by just that diagram. A modification to note that multiple composition methods are possible should avoid that perception.

Regards
Simon

-----Original Message-----
From: Henk Birkholz <[email-masked]>
Sent: 17 September 2019 10:13
To: Simon Frost <[email-masked]>; [email-masked]
Subject: Re: [Rats] New RATS Architecture document

Hello Simon,

TL;DR
It's just a simplified first example diagram. There is no intent to artificially exclude compositions, such as the 'background check'
composition. Corresponding diagrams will be added again.

Viele Grüße,

Henk