Re: [Rats] Collection binding (was Re: New RATS)

[Simon Frost <[e-mail]>]

The clear intent of collections is part 3 below. The definition of the collection says that they have “some internally defined relationship through which the integrity of the whole collection can be determined”. I can introduce normative language that makes that clearer if necessary. Typically the mechanism is that within one signed element claim set, there is a claim which can be used to demonstrate a cryptographic binding to another element, for example a hash of their signer public key or a hash of the whole token. Binding between elements will be established as part of verification.

Reworking a typical collection to be a recursive encapsulation inside the terminal element is possible, but adds processing overhead and is inelegant and inflexible which isn’t the approach I see elsewhere in EAT.

Thanks
Simon
From: Laurence Lundblade <[e-mail]>
Sent: 03 June 2022 19:16
To: Simon Frost <[e-mail]>
Cc: [e-mail]; Thomas Fossati <[e-mail]>
Subject: Collection binding (was Re: [Rats] New RATS)

This is one of two comments I have on collections.

Without any cryptographic binding between tokens in the collection, an attacker can easily substitute a good attestation from another device for one that is not good. This is very large vulnerability in my view. So what to do?

1) One option is to write some very large security considerations. They would probably recommend strongly the use of TLS to provide the binding. They would look a lot like all the text in UCCS.

2) Another option is to abandon the draft for submods that does provide that. The top-level signer could be a weaker attester whose job is just to provide the binding. It would be kind of similar in security characteristics as using TLS (where TLS is not implemented in a root of trust).

3) There could be some other cryptographic binding. Perhaps a hash of one is COSE aad for another. There is allusion to cryptographic binding in the draft, but nothing specific. That other binding could be left up to the implementer and not standardized in which a big recommendation in security considerations is needed. It could also be standardized by describing what it is in this draft.  Can you describe what you were thinking about?

I don’t have a strong opinion of which option should be used, but I think one (or more) is needed.

LL




On May 30, 2022, at 4:33 AM, Simon Frost <[e-mail]<mailto:[e-mail]>> wrote:

FYI. I’ve just submitted a new draft for a proposed extension to the top level object in EAT.

There’s a full justification in the doc, but as a quick summary, there are difficulties in creating a top level ‘envelope’ object for a multi-token system while remaining compatible with EAT. Given the recent move to fix the list of top level objects but embrace extensions, this approach seems to be an appropriate proposal.

See: https://datatracker.ietf.org/doc/draft-frost-rats-eat-collection/ & https://github.com/SimonFrost-Arm/draft-frost-rats-eat-collection

Thanks
Simon

Simon Frost
Senior Principal Systems Solution Architect, ATG, Arm
Mob: [phone]

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.