Subject: Re: [Rats] FW: New Version Notification for draft-shaw-rats-rear-00.txt

From: Henk Birkholz <[email-masked]>
Date: Thu, 2 Jul 2020 16:04:56 +0200

Hi Thomas,
hi authors,

please let me start with: I really like what this I-D is about; 
especially how everything is basically arranged around how to use 
timestamps and nonces in several specific interactions. The essence here 
is the qualified data conveyed via restful operations that are used to 
create Conceptual Messages, such as Evidence or Attestation Results.

The fact that all these different types of qualifying data are bound 
with each other via sequences of restful operations makes the 
relationship of the sequence diagrams rather complex and renders the use 
of the qualified data / handles hard to read. At the same time, I am 
uncertain how to avoid that, though.

You managed to get all the semantic relationships into the sequence 
diagrams themselves. I am quite impressed. But I could only decipher the 
notation while parsing them with the help of a little cheat sheet that I 
wrote down on a piece of paper.

This topic is intrinsically complex, so - as I already said - I am 
unable to provide an immediate proposal how to increase readability. The 
fact remains that this is a very useful -00 I-D. Suffice to say that I 
would rather have this content in this form than not at all!

Coincidentally, more generic versions of your diagrams with respect to 
the reference interaction models can be found in this editor's version:

> https://ietf-rats.github.io/draft-birkholz-rats-reference-interaction-model/draft-birkholz-rats-reference-interaction-model.html#name-interaction-models

These diagrams use simpler annotation, but therefore are also way more 
generic. They match with your more specific semantics, though, and I am 
very happy about that.

We also struggled a bit with the illustration of the processing of 
qualified data in TUDA and based on your new I-D we can now try to 
improve them.

Viele Grüße,

Henk

On 12.06.20 19:00, Thomas Fossati wrote:
> Hi, all,
> 
> We have just submitted a new draft "RESTful attested resources" (details
> below).
> 
> The main goal here is creating a mechanism to expose attested system
> state as RESTful resources (i.e., "things" that can be de-referenced by
> their URIs) together with a way to securely bind said system state with
> an EAT token.
> 
> We define two REST interfaces: one to the Attester and one to the
> Verifier, with timestamp- and nonce-based freshness.  We show how these
> can be composed into the usual "background check", "passport" and
> "time-based unidirectional" patterns.  HTTP and CoAP instantiations are
> provided, together with the associated MIME machinery.  A discovery
> method is also discussed based on the CoRE Resource Directory.
> 
> This proposal seems in scope with the RATS charter, in particular its
> "Standardize interoperable protocols to securely convey
> assertions/claims." bit.  We hope this provides a valid contribution on
> how the RATS architecture and basic protocol elements can be used in
> high level protocol(s), and would really appreciate any feedback with
> regards to its usefulness, correctness and completeness.
> 
> cheers, thanks!
> 
> On 12/06/2020, 17:48, "[email-masked]" <[email-masked]> wrote:
>> A new version of I-D, draft-shaw-rats-rear-00.txt
>> has been successfully submitted by Thomas Fossati and posted to the
>> IETF repository.
>>
>> Name:draft-shaw-rats-rear
>> Revision:00
>> Title:Restful Attested Resources
>> Document date:2020-06-12
>> Group:Individual Submission
>> Pages:23
>> URL:            https://www.ietf.org/internet-drafts/draft-shaw-rats-rear-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-shaw-rats-rear/
>> Htmlized:       https://tools.ietf.org/html/draft-shaw-rats-rear-00
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-shaw-rats-rear
>>
>>
>> Abstract:
>>     This memo describes a REST interface based on the RATS architecture
>>     that can be used to retrieve attested system state, for example the
>>     reading of a security critical sensor.  The objective is to present a
>>     common vocabulary of data formats and basic protocol transactions
>>     that can be pieced together into a cohesive interface that is capable
>>     of serving different attestation workflows.
> 
> 
> 
> 
> 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.
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 2 Jul 2020 16:06:18 +0000

Hi Henk,

On 02/07/2020, 15:05, "Henk Birkholz" <[email-masked]> wrote:
> timestamps and nonces in several specific interactions. The essence
> here is the qualified data conveyed via restful operations that are
> used to create Conceptual Messages, such as Evidence or Attestation
> Results.
>

Thank you for your taking the time to parse the document - and making
the cheat sheet!  Also glad you found the topic interesting.

Re: readability.  It seemed to us that it would be easier to use a
top-down approach, presenting the abstract protocol first and then
giving a number of possible instantiations.  Apparently it didn't work
as smoothly as expected.  Maybe to lower the barriers to entry we could
give a short primer at (one of) the next meeting(s)?

> generic. They match with your more specific semantics, though, and I am

Thanks for the pointer.  I like the more human-friendly notation.  I'll
have a look and see if I can make our diagrams look similar.  I'm also
going to swap our reference to TUDA with the more generic reference to
your section 7.2 (Uni-Directional Remote Attestation).  When are you
going to publish the new version?

cheers, thanks!

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 2 Jul 2020 18:40:44 +0200

Hi Thomas,

> give a short primer at (one of) the next meeting(s)?

Yes, please. I think with floating this document more, we might get some 
additional hints and tips and, of course, feedback on how this currently 
addresses the needs of implementers. I'd encourage to request a slot for 
the upcoming IETF 108 sessions.

> going to publish the new version?

That sounds great. With respect to submission... yes, we should do a 
submit soon and then another before the submission moratorium, if we are 
able to pull in the expected content about Direct Anonymous Attestation. 
Let me see, if I can do another pass on the relatively fresh and clumsy 
text around the diagrams in section 7, first.

Viele Grüße,

Henk

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Jul 2020 16:15:46 -0400

Hi, thank you for the draft.
(Please expect some pendantry on how to say this is a REST based interface.
I don't think it matters what you write, someone will say you wrote it wrong)

Some things that jumped out at me:
> strong authenticity.

I don't know what this means.  I think that we went to some lengths in the
architecture to say that we were evidence of trustworthiness.
The paragraph that follows, which deals with assurance, seems much better.
Maybe just omit the first paragraph :-)

"are the three RATS actors" <- we never use "actors" in the architecture.
Some said we should, but we didn't go there.
We used "roles"... which I agree are things that actors portray.

I suggest:
   The three RATS roles of the attester (A), the relying party (RP) and the verifier (V)
   are protrayed by three principal actors.

I scanned through the rest of the document.
I didn't check your math, as I would really need to be in implementation
mindset to do that.  I feel that there is perhaps some unexplained/implicit
knowledge around the if= that I might not have understood the first time.

In this thread you offered to do a tutorial/walkthrough.
I won't say no to that, but I want to say that if the document needs a
tutorial/walkthrough to be understood, then the document needs some changes.
So, do that walkthrough, but with the idea not of explaining things, but
of getting feedback on the explanation so that you can make the document
better.

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

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 3 Jul 2020 09:20:41 +0000

Hi Michael,

On 02/07/2020, 21:16, "Michael Richardson" <[email-masked]> wrote:
> Hi, thank you for the draft.  (Please expect some pendantry on how to
> say this is a REST based interface.  I don't think it matters what you
> write, someone will say you wrote it wrong)
>
> I don't know what this means.  I think that we went to some lengths in
> the architecture to say that we were evidence of trustworthiness.  The
> paragraph that follows, which deals with assurance, seems much better.
> "are the three RATS actors" <- we never use "actors" in the
> architecture.  Some said we should, but we didn't go there.  We used
> "roles"... which I agree are things that actors portray.
>
> I suggest: The three RATS roles of the attester (A), the relying party
> (RP) and the verifier (V) are protrayed by three principal actors.
>
> I scanned through the rest of the document.  I didn't check your math,
> as I would really need to be in implementation mindset to do that.  I
> feel that there is perhaps some unexplained/implicit knowledge around
> the if= that I might not have understood the first time.

Thanks for the comments, I've made tickets for them with a -01
milestone.

> In this thread you offered to do a tutorial/walkthrough.  I won't say
> no to that, but I want to say that if the document needs a
> So, do that walkthrough, but with the idea not of explaining
> things, but of getting feedback on the explanation so that you can
> make the document better.

We want to strike a balance between rigour and readability and the
signal we are not making a good job on the latter is loud and clear :)

I've looked into Henk's Reference Interaction Models doc and it looks
like we could take inspiration from that for reshaping the interaction
diagrams.  I'm going to give that a stab.

cheers!

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 6 Jul 2020 10:40:48 -0400

Thank you for your work on this document.  I read through it on a phone, so I don’t have detailed comments, but a few high level.

This sort of document was needed, good stuff!  Since we have a number of RESTful protocols in use to exchange formatted data, it would be good to explicitly state support for these protocols.  SCAPv2.0 has adopted ROLIE [RFC8322].  Since SCAP is how posture assessment is performed, it would be good to include this capability to enable a smooth transition to the use of remote attestation for simplified posture assessment as this work evolves.

Similarly, RedFish is in use for server management across several platforms.  I’ve been working with the DMTF to improve security of RedFish just in case it could be used.

There are likely other protocols that may be used, and leaving this open to accommodate various RESTful protocols may be the best approach towards enabling adoption.  This would also enable use for a shared purpose- configuration management in an IT application as well as security posture assessment.

Best regards,
Kathleen 

Sent from my mobile device

> On Jun 12, 2020, at 1:00 PM, Thomas Fossati <[email-masked]> wrote:
> 
> Hi, all,
>

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 8 Jul 2020 16:22:11 +0000

Hi Kathleen,

I hadn't come across SCAP before.  This looks interesting and certainly
relevant, so thanks for pointing out the potential relation with our
draft.

On 06/07/2020, 15:41, "Kathleen Moriarty" <[email-masked]> wrote:
> Since we have a number of RESTful protocols in use to exchange
> formatted data, it would be good to explicitly state support for these
> protocols.  SCAPv2.0 has adopted ROLIE [RFC8322].  Since SCAP is how
> posture assessment is performed, it would be good to include this
> capability to enable a smooth transition to the use of remote
> attestation for simplified posture assessment as this work evolves.

Clarifying question.  In principle, the mechanics specified in the draft
can be used to bind attestation data to *any* resource.  So, ROLIE feeds
are certainly in scope.  However, it seems to me that in the SCAP
architecture the "natural" attestors are the Endpoints.  And, on the
Endpoint, posture collection is pulled using one of NEA/SWIMA, or
NETCONF, or some other specific MDM protocol, depending on the
Endpoint's type/class.  So, wouldn't NETCONF be a more suitable target
than ROLIE in this case?

> Similarly, RedFish is in use for server management across several
> platforms.  I’ve been working with the DMTF to improve security of
> RedFish just in case it could be used.
>
> There are likely other protocols that may be used, and leaving this
> open to accommodate various RESTful protocols may be the best approach
> towards enabling adoption.

+1 -- Though I'm a bit unsure about what strategy would you suggest?

One of the base constructs provided in the draft, namely the way to bind
the resource representation with the attestation Evidence by hashing it
in to the nonce claim, is very broadly applicable.  So there's that.
However, the REST-y bits (verbs & content types) are slightly more
"rigid" in the sense that although the attested resource can be anything
you want it to be, the outer shell has a very precise format that is not
open to manipulation.

cheers, thanks!

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Jul 2020 17:03:28 -0400

> Endpoint's type/class.  So, wouldn't NETCONF be a more suitable target

However, we did do:

https://github.com/ietf-rats-wg/architecture/commit/87561f0cf9e65fcdda18291123367f6500c92ceb

 In this diagram, the protocol between Attester and a Relying Party
 can be any new or existing protocol (e.g., HTTP(S), COAP(S),
+ROLIE {{RFC8322}},
 802.1x, OPC UA, etc.), depending on the use case.  Such
 protocols typically already have mechanisms for passing security
 information for purposes of authentication and authorization.  Common