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

[Laurence Lundblade <[e-mail]>]

> On Mar 12, 2021, at 10:29 AM, Hannes Tschofenig <[e-mail]> wrote:
> 
> Hi Laurence, 
>  
> Could you clarify a few things? 
>  
> > The horse is pretty dead, but one more comment. 
>  
> What does this mean?

Micheal covered this one well. :-)

>  
> > 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. 

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.

>  
> > 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.

It will also be used between the Verifier and RP.


> > 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

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.

>  
> > 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.

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