Subject: [Rats] CDDL for CWT, JWT, UCCS and UJCS

From: Laurence Lundblade <[email-masked]>
Date: Mon, 25 Oct 2021 10:20:56 -0700

Hi folks,

Sorry for the large cross-post, but wanted to be sure everyone is a little aware of this.

The latest EAT draft  <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-11> efines CDDL for a Claims-Set, the main collection of label-value pairs that is central to CWT and JWT. It is intended to work for both CBOR and JSON (and maybe other encodings). When you want to define a new claim for a CWT or JWT you can write it in CDDL and both the CBOR protocol implementer and JSON protocol implementer know what to do. Should even work with the CDDL validation tools. See here <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-11#section-8.4>.

There’s a few other things in this EAT draft:
The Claims-Set CDDL applies to UCCS
It defines UJCS (which is a one-liner in CDDL) in case you don’t want to use JWT NULL algorithm for something like EAT Attestation Results
It defines a way to put a CWT inside a JWT and vice versa since EAT needs nested tokens

A common format for signed/encrypted/unsecured collections of CBOR/JSON label-value pairs seems generally useful for more than just EAT. The common format could give some code re use too.

I’m not sure that this belongs in the EAT draft. I put it in EAT to get it published in a coherent way for the basis of discussion. I’m expecting discussion of this in the RATS sessions at IETF 112 (Chairs / ADs, maybe you have an opinion on where further discussion can happen).

LL

P.S. This turned up some issues around how CDDL for CBOR+JSON works and how to validate with the cddl validation tool:
Integer vs text labels
How to represent byte strings so they get b64 encoded and validate
An alternative to CBOR tags for JSON

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Oct 2021 13:20:01 -0400

Laurence, I took a look through eat-11 just now.

It's 70 pages to the appendix (17 pages of appendix), of which 28 pages (10
through 28) are about claims.

11 pages (section 8) is the CDDL.  So let's say, not really 70 but 59 pages
of content that requires human attention.
15 pages for privacy and security considerations.

Section 7 concerns me.  It's a profile for writing profiles.

I wonder if section 3 (Claims) shouldn't come after section 6, before 7.
section 6, which is about keys, maybe even should be earlier.

To me, the document looks done to me.
I think that there are wording fixes that would make it a little easier to
read, but it sure looks finished to me.

If there are still problems with some of the claims, maybe we could move those
claims to another document.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Oct 2021 11:25:27 -0400

> read, but it sure looks finished to me.

Is EAT core work for the RATS document set?
I thought it was.  But it does not seem like the document is actually that important.

If the document isn't done, then maybe it's not necessary.

---

From: Giridhar Mandyam <[email-masked]>
Date: Wed, 27 Oct 2021 15:44:48 +0000

This is the Last Call candidate.  I expect the chairs to initiate a call to the group using this doc.  I expect that there will be changes in the document as we progress through resolution of LC comments (and AD comments, IESG, IANA, etc.), but there is no reason not to go to LC now.

-Giri

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Michael Richardson
Sent: Wednesday, October 27, 2021 8:25 AM
To: rats <[email-masked]>
Subject: Re: [Rats] EAT document (was Re: CDDL for CWT, JWT, UCCS and UJCS)

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 27 Oct 2021 09:40:54 -0700

> I thought it was.  But it does not seem like the document is actually that important.

R in RATS is for “remote” which means there’s a protocol to convey Attestation Evidence.

If you want to do remote attestation that is not conveyed via YANG, would not EAT be the protocol?

What’s your vision of the protocols used in remote attestation that doesn’t need EAT?

LL

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 27 Oct 2021 19:38:15 +0200

Hi Laurence,

EAT is not a protocol, it is a data model for CWT (and I guess now also 
for JWT) to represent remote attestation evidence (where evidence is the 
conceptual message generated by an Attester and appraised by a Verifier).

The data model proposed can include information elements that are useful 
for protocols - most prominently, a nonce - but that does not render it 
a protocol, it probably makes it "convenient payload" that also "puts 
constraints on most protocols that want to use EAT".

Viele Grüße,

Henk

On 27.10.21 18:40, Laurence Lundblade wrote:
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 27 Oct 2021 11:53:14 -0700

Hi Henk,

Right. As a data model, the question seems mostly the same.  What will a person implementing RATS use if they are not using yang? 

Yang is not particularly suitable for small IoT devices, and those devices need attestation too, right? Claims in a UCCS sent over DTLS is EAT, right?

And maybe we should we be aligning EAT closer to all the stuff defined for yang?

LL

> On Oct 27, 2021, at 10:38 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> EAT is not a protocol, it is a data model for CWT (and I guess now also for JWT) to represent remote attestation evidence (where evidence is the conceptual message generated by an Attester and appraised by a Verifier).
> 
> The data model proposed can include information elements that are useful for protocols - most prominently, a nonce - but that does not render it a protocol, it probably makes it "convenient payload" that also "puts constraints on most protocols that want to use EAT".
> 
> Viele Grüße,
> 
> Henk
> 
> 
>

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 28 Oct 2021 00:14:40 +0200

Hi Laurence,

one step towards answering the question "what will a person implementing 
RATS use if they are not using yang?" is of course > 
draft-ietf-rats-reference-interaction-models

But of course that work does not provide you with a set of protocols 
(aka the complete answer), but only with a set of models to chose from 
in order to build the acutal protocol.

Now - I've been holding back on that one - TUDA is of course a very 
exact protocol how to convey evidence and that would be one candiate> 
draft-birkholz-rats-tuda

Alas, that protocol does not require EAT, as well as YANG TPM CHARRA 
does not. In consequence, I like the notion to align EAT more to TUDA or 
to YANG of course, but I am not certain that that is actually possible. 
I'd really appreciate proposals that illustrate how to do that.

EAT brings a lot of flexibility to the table, especially if the layout 
of an attesting environment is under your design control. Mix in some 
simple component hierarchy that is also under your direct control, such 
as with cell phones, and EAT is an excellent fit.

There are other evidence representations that are more difficult to fit 
into EAT (as we have learned here in RATS), because they already existed 
for a long time, have stable and intentionally (relatively "strict 
defined") interfaces, such as a TPM. That does not seem to be a bad 
thing, but simply is accepted as a different way how to phrase evidence, 
in the end.

In summary, today there are a few distinct ways how to represent 
evidence. Some representations are based on existing technology, some 
representations are based on the appraisal process (e.g. IMA logs in 
support of indeterministic user space environments), and some 
representations are tailored to match other conceptual message formats.

On the one hand, I think EAT should be the first goto candidate, if you 
want to implement RATS and are free to chose how to do it. On the other 
hand, I also think that EAT should not be an MTI or a mandatory data 
model to be incorporated in a protocol.

The most important thing EAT brings to the table - from my point of view 
- is actually the information model. The information elements defined 
(and registered as CWT Claim definitions in the end) are the real treat. 
No evidence format should conflict with these definitions! That would be 
really really bad for semantic interoperability and would be in conflict 
with the RATS WG's goals. If there is overlap, the WG process should 
identify that and address that (although I am not taking a stance on the 
"how", maybe sometimes a change to EAT might be warranted, but that case 
would have to be presented very thoroughly).

In general, I'd like to see EAT as "the first candidate in line", but 
also other options next to it next in line.

Viele Grüße,

Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 31 Oct 2021 12:08:06 -0700

Hey Henk,

Pretty much agree with all you say below. Completely understand that EAT doesn’t fit every use case. Thanks for taking the time write it out. :-)

As to Michael’s comment "it does not seem like the document is actually that important.”
- Henk provides some good reasons below
- EAT lines up well for big use case like FIDO and the Android Key Store 
- It works well with TEE’s. It is used by SUIT, is integrated into ARM’s Trusted Firmware and is a part of ARM’s PSA certified program
- If you can’t afford to solder a TPM into you IoT device and your device needs the most compact representation, doesn’t use YANG and such, EAT is a good candidate

Now that the core writing for EAT is done, I hope to spend more time seeing how it fits with other RATS work. Am open to changes in EAT, particularly improving the claims, to make it fit better.

LL

> On Oct 27, 2021, at 3:14 PM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> one step towards answering the question "what will a person implementing RATS use if they are not using yang?" is of course > draft-ietf-rats-reference-interaction-models
> 
> But of course that work does not provide you with a set of protocols (aka the complete answer), but only with a set of models to chose from in order to build the acutal protocol.
> 
> Now - I've been holding back on that one - TUDA is of course a very exact protocol how to convey evidence and that would be one candiate> draft-birkholz-rats-tuda
> 
> Alas, that protocol does not require EAT, as well as YANG TPM CHARRA does not. In consequence, I like the notion to align EAT more to TUDA or to YANG of course, but I am not certain that that is actually possible. I'd really appreciate proposals that illustrate how to do that.
> 
> EAT brings a lot of flexibility to the table, especially if the layout of an attesting environment is under your design control. Mix in some simple component hierarchy that is also under your direct control, such as with cell phones, and EAT is an excellent fit.
> 
> There are other evidence representations that are more difficult to fit into EAT (as we have learned here in RATS), because they already existed for a long time, have stable and intentionally (relatively "strict defined") interfaces, such as a TPM. That does not seem to be a bad thing, but simply is accepted as a different way how to phrase evidence, in the end.
> 
> In summary, today there are a few distinct ways how to represent evidence. Some representations are based on existing technology, some representations are based on the appraisal process (e.g. IMA logs in support of indeterministic user space environments), and some representations are tailored to match other conceptual message formats.
> 
> On the one hand, I think EAT should be the first goto candidate, if you want to implement RATS and are free to chose how to do it. On the other hand, I also think that EAT should not be an MTI or a mandatory data model to be incorporated in a protocol.
> 
> The most important thing EAT brings to the table - from my point of view - is actually the information model. The information elements defined (and registered as CWT Claim definitions in the end) are the real treat. No evidence format should conflict with these definitions! That would be really really bad for semantic interoperability and would be in conflict with the RATS WG's goals. If there is overlap, the WG process should identify that and address that (although I am not taking a stance on the "how", maybe sometimes a change to EAT might be warranted, but that case would have to be presented very thoroughly).
> 
> In general, I'd like to see EAT as "the first candidate in line", but also other options next to it next in line.
> 
> Viele Grüße,
> 
> Henk
> 
> 
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 31 Oct 2021 16:07:52 -0400

> As to Michael’s comment "it does not seem like the document is actually

My position: if it's important, then it should be done already and it's long
overdue for WGLC.   That this hasn't happened tells me that maybe the WG
(and/or WG chairs) don't think it's that important.

    > Now that the core writing for EAT is done, I hope to spend more time
    > seeing how it fits with other RATS work. Am open to changes in EAT,
    > particularly improving the claims, to make it fit better.

It needs a WGLC, area reviews and publication already.

---

From: Giridhar Mandyam <[email-masked]>
Date: Sun, 31 Oct 2021 20:10:01 +0000

Agree.  Chairs - please initiate LC.

-Giri