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

[Henk Birkholz <[e-mail]>]

Hi Wei,

thanks for the review!

Please see comments in-line. All assertions are from me as an 
individual. The authors will discuss your input as soon as possible, but 
I also have pulled in some editorial fixes already as is visible here:

> https://ietf-rats.github.io/draft-birkholz-rats-uccs/draft-birkholz-rats-uccs.html


On 03.06.20 13:19, Panwei (William) wrote:
> 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’.

Using just one sentence here might have been a tad bit too concise for 
the sake of readability. Yes, there are situations, where only one of 
the two peers is authenticated and the secure channel characteristics 
work only "one way". This can be due to design or due to a channel not 
been set up completely yet.

We probably need more text to elaborate on this. Maybe not in the Intro 
though.

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

fixed

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

fixed

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

As UCCSs does not really flow from the tongue, I tweaked the definition 
text a bit. It now reads: "Unprotected CWT Claims Set(s); CBOR map(s) of 
Claims [...]". While that fixes the problem for now, there might be more 
elegant solutions here.

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

fixed

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

This text implies the characteristics of a signature 
(authenticity/integrity). As part of the secure channel characteristics, 
the fact that an UCCS is conveyed via the secure channel by an 
authenticated peer (that created the secure channel) basically is the 
substitute of the "authenticity part of the signature characteristic". 
What remains to be provided is then the "integrity part of the signature 
characteristic". For this the secure channel must provide integrity 
protection for the UCCS.

This probably also needs more elaboration and clear wording. Thanks!

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

Yes, while the UCCS is not encrypted itself, a secure channel that 
encrypts messages for conveyance is probably the most likely solution here.

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

This would imply that the creator of UCCS would also be able to create 
CWT, which I think is not always the case. In general, the key semantics 
are vital here. If there is a separation of duty here with different 
sets of keys for different applications, using keys for multiple 
purposes might not be possible.

But maybe I am also missing something here that you tried to highlight.

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

Yes! I can see how this is also very compact text. Brevity for the sake 
of readability does not always makes it easier to understand, too. 
Analogously, we might need more text here, too.

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

That would be the upper-level EAT. If we want that to be more 
fine-grained, we'd need more text. But here simplicity is an enabler of 
security and I would like to abstain from that and go with "closest 
signature to the UCCS wins".

> 
> Section 5
> 
>     {#secchan} discusses security considerations for Secure Channels, in
> 
>     which UCCS might be used.
> 
> Nit: the reference to {#secchan} is missing.

fixed

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

This touches a re-occurring topic that we also find, for example, with 
"re-encoding XML renders the original signature invalid". It also 
touches on the topic of canonical decomposition and composition. I think 
that is basically a third option of "where do the signature 
characteristics go":

1.) signature
2.) secure channel
3.) signature value in UCCS

I think that could be a worthwhile addition to the use of UCCS and we 
will discuss this and come back to that topic!

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

That is actually an approach that we use in TUDA already. TUDA is not 
using maps but arrays to be even more concise than CWT, but the 
principle is the same - like I-Frames and P-Frames. Omitting "already 
shared/known" information in the context of a secure channel could be an 
interesting topic, too. We have to be careful about scope creep, but I 
am certain we will come back to this topic.

> 
> Regards & Thanks!
> 
> Wei Pan

Big thanks for comments and thoughts on content. Please expect another 
reply in.. some future :-)


Viele Grüße,

Henk

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