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

[Hannes Tschofenig <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> 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:


“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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Hannes Tschofenig
Sent: Friday, March 12, 2021 2:17 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [Rats] draft-birkholz-rats-uccs

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.
_______________________________________________
RATS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rats

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.