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

[Laurence Lundblade <[e-mail]>]

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