Subject: [Rats] draft-birkholz-rats-uccs

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 12 Mar 2021 10:17:21 +0000

Hi all

draft-birkholz-rats-uccs was discussed at the WG meeting this week and there was some controverse around its security protection.

Having looked at the draft again I believe the proposal is sound. In fact, I would even argue that it provides better security protection than the use of COSE.

Here are my thoughts.

Here is how some want to deploy EAT tokens:

   +-------------------------------------------+
   | Device                                    |
   |                          +--------+ Maybe TLS/Maybe not
   |    +-------------+       |        |-----------+  +-----------+
   |    | TEE/SE      |       | HTTP   |---------+ |  |           |
   |    | +--------+  |  +----| Client |       | | |  | Verifier  |
   |    | |Attester|  |  |    |        |       | | +->| ( HTTP )  |
   |    | |        |<----+    |        |       | |  +-| (Server)  |
   |    | +--------+  |       |        |       | +->| |           |
   |    |             |       +--------+       |    | +-----------+
   |    |             |                        |    |        |
   |    |             |                        |    +--------+
   |    |             |                        |
   |    |             |                        |
   |    +-------------+                        |
   +-------------------------------------------+

                              EAT protected by COSE
             |----------------------------------------------|

Here is how the UCCS protection looks like:

   +-------------------------------------------+
   | Device                                    |
   |                          +--------+  TLS not needed
   |    +-------------+       |        |-----------+  +-----------+
   |    | TEE/SE      |       | Broker |---------+ |  |           |
   |    | +--------+  |  +----|        |       | | |  | Verifier  |
   |    | |Attester|  |  |    |        |       | | +->| ( HTTP )  |
   |    | |        |<----+    |        |       | |  +-| (Server)  |
   |    | +--------+  |       |        |       | +->| |           |
   |    |             |       +--------+       |    | +-----------+
   |    |             |                        |    |        |
   |    |             |                        |    +--------+
   |    |             |                        |
   |    |             |                        |
   |    +-------------+                        |
   +-------------------------------------------+

                              EAT protected by TLS
             |----------------------------------------------|

If you compare the two, then you might realize that a TLS handshake run into the SE/TEE actually provides better security properties than a  COSE protected EAT (with a signature or MAC) provides.

My conclusion is: draft-birkholz-rats-uccs is good stuff. I would even go as far as recommending to use TLS into the SE/TEE rather than terminating it on the non-secure side.

Ciao
Hannes

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: Giridhar Mandyam <[email-masked]>
Date: Fri, 12 Mar 2021 16:55:39 +0000

Agree with Hannes.  I'll also add that current text in https://tools.ietf.org/html/draft-ietf-rats-architecture-10#section-12.2 states:

"The security protecting conveyed information may be applied at different layers, whether by a conveyance protocol, or an information encoding format.  This architecture expects attestation messages (i.e., Evidence, Attestation Results, Endorsements, Reference Values, and Policies) are end-to-end protected based on the role interaction context.  For example, if an Attester produces Evidence that is relayed through some other entity that doesn't implement the Attester or the intended Verifier roles, then the relaying entity should not expect to have access to the Evidence."

In other words, the first figure below actually shows a relaying entity (HTTP client outside of TEE/SE security boundary) that may have access to the evidence.

-Giri

From: RATS <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Friday, March 12, 2021 2:17 AM
To: [email-masked]
Subject: [Rats] draft-birkholz-rats-uccs

Hi all

Here are my thoughts.

                              EAT protected by COSE

                              EAT protected by TLS

Ciao
Hannes

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 12 Mar 2021 09:33:28 -0800

The horse is pretty dead, but one more comment. 

My thought is that UCCS over-specifies security. UCCS is a very general format for use inside rats and outside rats. It also will be used in several ways inside rats (Evidence and Results). A general document like UCCS can’t anticipate all the use cases and all the possible security issues and all the security solutions for all the use case so it should just have some general warnings that it provides no security. Would make the document very short and sweet.

The general security architecture and concerns for UCCS applied to rats should be in the rats architecture document.

That said, I’m OK with it as is.

LL

> On Mar 12, 2021, at 8:55 AM, Giridhar Mandyam <[email-masked]> wrote:
> 
> Agree with Hannes.  I’ll also add that current text in https://tools.ietf.org/html/draft-ietf-rats-architecture-10#section-12.2 <https://tools.ietf.org/html/draft-ietf-rats-architecture-10#section-12.2> states:
>  
> “The security protecting conveyed information may be applied at different layers, whether by a conveyance protocol, or an information encoding format.  This architecture expects attestation messages (i.e., Evidence, Attestation Results, Endorsements, Reference Values, and Policies) are end-to-end protected based on the role interaction context.  For example, if an Attester produces Evidence that is relayed through some other entity that doesn't implement the Attester or the intended Verifier roles, then the relaying entity should not expect to have access to the Evidence.”
>  
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 12 Mar 2021 18:29:57 +0000

Hi Laurence,

Could you clarify a few things?

> The horse is pretty dead, but one more comment.

What does this mean?

> My thought is that UCCS over-specifies security.

Could you explain what this means? My understanding is that the provide the protection just at a different layer. IMHO their approach has security advantages that are missing in a pure COSE-based security approach.

> UCCS is a very general format for use inside rats and outside rats.

Their document says not much more than: there are deployments where protection of EAT tokens are provided at a different layer. If you do that then it is not necessary to protect EAT tokens with COSE. I am not sure what “inside rats and outside rats” means.

> It also will be used in several ways inside rats (Evidence and Results).
My reading is that it will be used for the communication from the attester to the verifier.

> A general document like UCCS can’t anticipate all the use cases and all the possible security issues and all the security solutions for all the use case so it should just have some general warnings that it provides no security. Would make the document very short and sweet.

No document can anticipate all use cases. UCCS does not claim it does. It has a specific security model in mind, which is different from the one assumed by others. IMHO it is fine to use a format like EAT in different deployment contexts

> The general security architecture and concerns for UCCS applied to rats should be in the rats architecture document.
It might be good to discuss the security architecture in RATS.

>That said, I’m OK with it as is.
Cool!

Ciao
Hannes

LL

On Mar 12, 2021, at 8:55 AM, Giridhar Mandyam <[email-masked]<mailto:[email-masked]>> wrote:

Agree with Hannes.  I’ll also add that current text in https://tools.ietf.org/html/draft-ietf-rats-architecture-10#section-12.2 states:

-Giri

From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Hannes Tschofenig
Sent: Friday, March 12, 2021 2:17 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Rats] draft-birkholz-rats-uccs

Hi all

Here are my thoughts.

                              EAT protected by COSE

                              EAT protected by TLS

Ciao
Hannes

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]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

---

From: Michael Richardson <[email-masked]>
Date: Fri, 12 Mar 2021 16:41:50 -0500

> What does this mean?

The idiom is "beating a dead horse"
    https://en.wikipedia.org/wiki/Flogging_a_dead_horse
The reason to beat a live horse is to make it go faster.
(Does it really work?  Not relevant)
It being dead, beating it won't make it go faster.

So, LL means that he thinks that the argument is almost, but not completely
over.  (and that you won)

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

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 13 Mar 2021 11:05:52 -0800

> On Mar 12, 2021, at 10:29 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Laurence, 
>  

Micheal covered this one well. :-)

> Their document says not much more than: there are deployments where protection of EAT tokens are provided at a different layer. If you do that then it is not necessary to protect EAT tokens with CO…

Someone could use UCCS for some authentication-related protocol (that’s what CWT was made fo)r. Someone could use UCCS for some other non-attestation protocol that non of us have thought of yet. UCCS is a very general format useful way beyond EAT and rats. Its just a CBOR map of label-value pairs that can be put to use any time one wants such a map.

Security for this open-ended set of use cases is also open-ended. Maybe IPsec works. Maybe CMS is used. Maybe something else.

> My reading is that it will be used for the communication from the attester to the verifier.

It will also be used between the Verifier and RP.

> No document can anticipate all use cases. UCCS does not claim it does. It has a specific security model in mind, which is different from the one assumed by others. IMHO it is fine to use a format l…

To me putting all the security discussion in to the UCCS spec is like putting the TLS and IPsec standard into the HTML, JSON or XML standards. HTML, UCCS… just define data formats. The difference here is that CWT which has security built in and came first where as HTML, JSON and XML were invented first without security.

> It might be good to discuss the security architecture in RATS.

Expanding on this thought, let me ask where are the best places to lock down the security requirements for attestation in the ultimately published RFCs? This would need to cover the use of COSE, JOSE and TLS in ways specific to the attestation use cases. Is it sufficient for EAT to reference what’s in the rats architecture document now? 

I didn’t think of this before.  What about splitting UCCS into two standards?

1) Describe the UCCS format — very short sweet document that is not specific to rats

2) TLS-secured attestation evidence — how to secure rats attestation evidence with a transport protocol. Can be used for CBOR claims (UCCS) or JSON claims or XML claim… It is specific to rats.

LL

---

From: Thomas Fossati <[email-masked]>
Date: Sat, 13 Mar 2021 20:32:56 +0000

Hi Laurence, just a small note,

> To me putting all the security discussion in to the UCCS spec is like putting the TLS and IPsec standard into the HTML, JSON or XML standards. HTML, UCCS… just define data formats. The difference h…

I see this in a slightly different way: we take a data format that has
a "secure by default" label on it and we strip off the very thing that
makes it secure.  Since we are changing its commonly understood
semantics, it's probably wise that we simultaneously state why and
when this is acceptable, along with the assumed threat model.

cheers!
-- 
Thomas

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 13 Mar 2021 13:05:24 -0800

> On Mar 13, 2021, at 12:32 PM, Thomas Fossati <[email-masked]> wrote:
> 

Agree that something must be said for this reason.

Just don’t think it should go into the full set of security considerations or describing a designed solution because both vary by use case and problem domain. It is not possible to anticipate all the use cases and problem domains. 

We don’t have any standard that says how you should securely transfer particular data formats like HTTP, XML or JSON. There is no “Secure transfer of HTML” standard. Instead we have security protocols like TLS, COSE, JOSE and such which can be used to secure data in general.

As I mentioned before, I think it would be good to split the document in two, something I hadn’t thought of before.

But, I’m still OK with it as is. This is just a fun discussion :-)

LL

---

From: Thomas Fossati <[email-masked]>
Date: Sun, 14 Mar 2021 00:32:31 +0000

> Agree that something must be said for this reason.

cool

> As I mentioned before, I think it would be good to split the document in two, something I hadn’t thought of before.

IMHO it seems more natural to have that (minimalist) something you
mention above narrated alongside the description of the UCCS mechanics
rather than splitting the two.

> But, I’m still OK with it as is. This is just a fun discussion :-)

True, I also learned something new about sailors and horse latitudes!

cheers,
-- 
Thomas

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 15 Mar 2021 10:31:29 +0100

> when this is acceptable, along with the assumed threat model.

Well, we are defining a new thing, called

	Unprotected CWT Claims Set (UCCS)

What part of “unprotected” do you think will be hard to understand?

Grüße, Carsten

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 15 Mar 2021 10:16:01 +0000

Hi Carsten

> What part of “unprotected” do you think will be hard to understand?

The oxymoron between "Unprotected" and the COSE in "CWT" has the
potential of creating cognitive dissonance.

That IMHO deserves some discussion *in* the document.

cheers!

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 15 Mar 2021 11:26:21 +0100

> potential of creating cognitive dissonance.

It is not the CWT that is unprotected; the CWT claims set is.

> That IMHO deserves some discussion *in* the document.

Definitely.  But piling up security considerations for when you are carrying around unprotected information seems a bit on the motherhood and apple pie side.

Grüße, Carsten

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 15 Mar 2021 10:44:44 +0000

> It is not the CWT that is unprotected; the CWT claims set is.

I don't want to sound polemic, but if you take a CWT and you peel off
its security layer (i.e., you "unprotect" the CWT) what you are left
with is the CWT claims set :-)

> Definitely.  But piling up security considerations for when you are carrying around unprotected information seems a bit on the motherhood and apple pie side.

I don't think I have suggested piling up stuff - IIRC I even used
"minimalist" upthread - but something needs to be said to clarify what
are the assumptions that need to hold for this to be usable.

(I will review the draft and provide some more useful/actionable comments.)

-- 
Thomas

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 15 Mar 2021 11:48:53 +0100

> with is the CWT claims set :-)

Exactly.  
But it is not a CWT, just as the people sitting in a tank are not a tank.

> (I will review the draft and provide some more useful/actionable comments.)

I definitely appreciate that!

Grüße, Carsten

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 15 Mar 2021 15:39:21 +0000

Hi Carsten,

> But it is not a CWT, just as the people sitting in a tank are not a tank.

The analogy is correct but incomplete.  At least for the RATS context
(which I'm assuming is what we are interested here), you don't just
kick the people in the tank out and you're done with it: you need to
put them on a train and make absolutely sure that the train and the
tank came out of the same factory.  I.e., the requirement for UCCS is
that the signing key that identifies the secure transport endpoint is
- or can be linked to - the same key that would have signed the
attestation Evidence, were it encoded as "proper" CWT.

> I definitely appreciate that!

Will do shortly, cheers!
--
Thomas

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 15 Mar 2021 16:46:47 +0100

On 2021-03-15, at 16:39, Thomas Fossati <[email-masked]> wrote:
> you need to
> put them on a train

Whose train is that?

Grüße, Carsten

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 15 Mar 2021 18:25:30 +0000

> On 2021-03-15, at 16:39, Thomas Fossati <[email-masked]> wrote:

For a UCCS that carries Evidence claims, it's the attester's; for a
UCCS that carries Attestation Result claims, the verifier's.

-- 
Thomas