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

[Giridhar Mandyam <[e-mail]>]

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]> On Behalf Of Hannes Tschofenig
Sent: Friday, March 12, 2021 2:17 AM
To: [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.