Re: [Rats] I-D Action: draft-birkholz-rats-uccs-01.txt

["Panwei (William)" <[e-mail]>]

Hi authors,



I've read this draft and have some comments below:



Section 1

   If a mutually Secured Channel is established between two remote peers, and
   if that Secure Channel provides the correct properties, it is
   possible to omit the protection provided by COSE, creating a use case
   for unprotected CWT Claims Sets.  Similarly, if there is one-way
   authentication, the party that did not authenticate may be in a
   position to send authentication information through this channel that
   allows the already authenticated party to authenticate the other
   party.



I'm confused about the 2nd sentence. Based on these two sentences, I think the 'this channel' in the 2nd sentence means the 'mutually Secured Channel' in the 1st sentence. If 'this channel' is secure, then the two parties should have already authenticated each other. In my understanding, maybe the 2nd sentence is talking about that the channel is half established and one-way authentication is finished, right? If yes, I think the meaning should be 'after one-way authentication of the channel is finished, the protection of the Claims sent from the already authenticated party to the other party that did not authenticate can be provided by this channel'.


   Consequently, in a well-defined
   scope, it might be acceptable to strip a CWT of its COSE container an
   replace the CWT Claims Set's CWT CBOR tag with a UCCS CBOR tag for
   further processing - or vice versa.



Nit: s/COSE container an/COSE container and/



Section 2


   Use cases involving the conveyance of claims, in particular, remote
   attestations [I-D.ietf-rats-architecture] require a standardized data
   schema and format that can be trasferred and transported using
   different communication channels.  As these are Claims, [RFC8392] are
   a suitable format but how these Claims are secured depends on the
   deployment, the security capabilities of the device, as well as their
   software stack.



Nits: s/trasferred/transferred/, s/[RFC8392] are/[RFC8392] is/



Section 3


   As UCCS were initially created for use in Remote ATtestation
   procedureS (RATS) Secure Channels, the following subsection provides
   a discussion of their use in these channels.



In the terminology section, the UCCS is short for "Unprotected CWT Claims Set", so I think it is a singular noun rather than a plural noun.



Section 3.1


   If only authenticity/integrity for a Claim is required, a Secure
   Channel MUST be established to, at minimum, provide integrity of the
   communication.  Further, the provider of the UCCS SHOULD be
   authenticated by the reciever to ensure the channel is truly secured
   and the sender is validated.  If confidentiality is also required,
   the receiving side SHOULD also be authenticated.



Nit: s/reciever/receiver/

About the first sentence, how the authenticity of a Claim is guaranteed when the Secure Channel only provide the integrity of the communication?

About the last sentence, I think the key point of providing confidentiality of a Claim isn't that the sender authenticates the receiver, but the Claim should be encrypted. In this UCCS case, the Secure Channel should provide the encryption mechanism.



   The extent to which a Secure Channel can provide assurances that UCCS

   originate from a trustworthy attesting environment depends on the

   characteristics of both the cryptographic mechanisms used to

   establish the channel and the characteristics of the attesting

   environment itself.  A Secure Channel established or maintained using

   weak cryptography may not provide the assurance required by a relying

   party of the authenticity and integrity of the UCCS.



I think if the keys used for signing and encrypting the Claims are also used for establishing the Secure Channel, then the authenticity can be easily guaranteed. But


   As with EATs nested in other EATs (Section 3.12.1.2 of
   [I-D.ietf-rats-eat]), the Secure Channel does not endorse fully
   formed CWTs transferred through it.  Effectively, the COSE envelope
   of a CWT shields the CWT Claims Set from the endorsement of the
   Secure Channel.  (Note that EAT might add a nested UCCS Claim, and
   this statement does not apply to UCCS nested into UCCS, only to fully
   formed CWTs)



This paragraph is really hard to understand. I guess the meaning is: when using the Secure Channel to transfer the EATs in which other EATs are nested, the nested EATs and upper-level EATs are endorsed/signed by using COSE and the Secure Channel has no direct relationship with these EATs. And when using the Secure Channel to transfer the UCCSs in which other UCCSs are nested, these UCCSs can be seen as signed by the sending party of the Secure Channel.

But when using the Secure Channel to transfer the EATs in which the UCCSs are nested, which one endorses the UCCSs, the upper-level EATs or the Secure Channel?



Section 5


   {#secchan} discusses security considerations for Secure Channels, in
   which UCCS might be used.



Nit: the reference to {#secchan} is missing.



Besides the use cases described in the current draft, I think there is another suitable use case for UCCS.

The Attester/sender can decompose existing signed structures, then put all the parts into UCCS claims, including the signature of the 'original' structure. And the Verifier/receiver can compose all the UCCS claims into the original structure canonically.

For example, assume the existing signed structure is {data1, data2, data3, signature-of-all-data}. After the sender decomposes the structure and puts all the parts into UCCS claims, the new structure is {UCCS(data1), UCCS(data2), UCCS(data3), UCCS(signature-of-all-data)}. The receiver can recompose the structure, which will be the original structure {data1, data2, data3, signature-of-all-data}.

The remote attestation can be done periodically or several times. The first set of claims has to be a complete set of all the values in the signed structure. But in the subsequent sets of claims, some of the values can be omitted, because they never change and in remote attestation they would always be transmitted redundantly. So the sender can most definitely only convey a subset and the receiver can rebuild the original structure. This can save the bytes.



Regards & Thanks!

Wei Pan



> -----Original Message-----

> From: I-D-Announce [mailto:[e-mail]] On Behalf

> Of [e-mail]

> Sent: Tuesday, June 2, 2020 2:46 AM

> To: [e-mail]

> Subject: I-D Action: draft-birkholz-rats-uccs-01.txt

>

>

> A New Internet-Draft is available from the on-line Internet-Drafts

> directories.

>

>

>         Title           : A CBOR Tag for Unprotected CWT Claims Sets

>         Authors         : Henk Birkholz

>                           Jeremy O'Donoghue

>                           Nancy Cam-Winget

>                           Carsten Bormann

>    Filename        : draft-birkholz-rats-uccs-01.txt

>    Pages           : 8

>    Date            : 2020-06-01

>

> Abstract:

>    CBOR Web Token (CWT, RFC 8392) Claims Sets sometimes do not need

> the

>    protection afforded by wrapping them into COSE, as is required for a

>    true CWT.  This specification defines a CBOR tag for such unprotected

>    CWT Claims Sets (UCCS) and discusses conditions for its proper use.

>

>

> The IETF datatracker status page for this draft is:

> https://datatracker.ietf.org/doc/draft-birkholz-rats-uccs/

>

> There are also htmlized versions available at:

> https://tools.ietf.org/html/draft-birkholz-rats-uccs-01

> https://datatracker.ietf.org/doc/html/draft-birkholz-rats-uccs-01

>

> A diff from the previous version is available at:

> https://www.ietf.org/rfcdiff?url2=draft-birkholz-rats-uccs-01

>

>

> Please note that it may take a couple of minutes from the time of

> submission until the htmlized version and diff are available at tools.ietf.org.

>

> Internet-Drafts are also available by anonymous FTP at:

> ftp://ftp.ietf.org/internet-drafts/

>

>

> _______________________________________________

> I-D-Announce mailing list

> [e-mail]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/i-d-announce

> Internet-Draft directories: http://www.ietf.org/shadow.html or

> ftp://ftp.ietf.org/ietf/1shadow-sites.txt