Re: [Ace] DTLS profile - Open points

[Marco Tiloca <[e-mail]>]

Hi Olaf,

Thanks for the feeback and additional input; it looks clearer and better 
now.

Please, see inline.

Best,
/Marco

On 2021-05-21 15:21, Olaf Bergmann wrote:
> Hi Göran, Marco,
>
> (Adding the COSE mailing list for potential comments.)
>
> please see inline for my thoughts on this.
>
> On 2021-05-21, Göran Selander <[e-mail]> wrote:
>
>> Hello co-authors,
>>
>> (cc: Marco and ACE co-chairs)
>>
>> Returning to the subject in our recent mail thread I asked Marco to
>> summarize what he thinks remain to be addressed, see below. I think
>> these are valid points that each merit at least a note in the
>> specification. Do you agree?
>>
>> Should we ask Marco to repeat this on the ACE mailing list or is it
>> enough that we resolve them for the next version of the draft?
>>
>> Thanks
>> Göran
>>
>>
>> On 2021-05-20, 17:48, "Marco Tiloca" <[e-mail]> wrote:
>>
>>      Please find below a summary of the four open points.
>>
>>      All of them refer to Section 3.3.2 "DTLS Channel Setup Between Client
>>      and Resource Server", and specifically to the paragraph before
>> and the
>>      paragraph after Figure 9.
>>
>>      The original mail thread has subject "Conversion of access token to
>>      psk_identity".
>>
>>      Best,
>>      /Marco
>>
>>
>>      a) Clarify that the elements of the structure in Figure 9 of Section
>>      3.3.2 have to follow that exact order. This ensures that the
>> result and
>>      its following encoding are deterministic. This can't be taken for
>>      granted from a CBOR implementation building a CBOR map.
> I do not see why we would need to mandate this order. Although this
> could help with optimized parsers, it violates Postel's theorem and
> therefore should be avoided IMO.
>
> (That we indeed might have to say in the document is whether duplicate
> keys are allowed. As we are just using data represenations from other
> sources such as COSE and the CBOR-OAuth mappings, I would expect these
> specs to define the restrictions on the deterministic CBOR; I did not
> check that, though.)

==>MT
I initially interpreted that, by using the elements retrieved from the 
received Token, the RS had to rebuild and store exactly the same 
serialization that the client will have later built and sent on the wire 
as "psk_identity".

That would have required C and RS to agree on a canonical format of the 
CBOR map in Figure 9, to be sure that the "psk_identity" in 
ClientKeyExchange can match with the same "psk_identity" that the RS 
rebuilt and stored after receiving the Token.

Now my RS is storing as local lookup-label only the "kid" (rather than 
the whole "psk_identity" to expect on the wire). If the RS does so and 
actually relies on the "kid" only as a local lookup-label, I agree it's 
not necessary to have a fixed order of "kty" and "kid" into "COSE_Key".

When working on this, I managed to make also the following protected 
resource access work, so addressing also the last point (d), at least in 
Californium --- more on that below.
<==

>
>>      b) In Section 3.3.2, refer to RFC 7925 not only for the case where
>>      psk_identity is the token (see the paragraph following Figure 9), but
>>      also for the case when psk_identity is the structure in Figure 9
>> of the
>>      DTLS profile (see the paragraph before Figure 9).
> No, the uploading case is different because the client itself constructs
> the cnf structure shown in Figure 9.

==>MT
Ok, meaning it's not "opaque data" like in the case where "psk_identity" 
is the Token. Thanks.
<==

>
>>      c) In Section 3.3.2, the text before Figure 9 says: "This
>> structure then
>>      is included as the only element in the "cnf" structure that is
>> used as
>>      value for "psk_identity" as shown in Figure 9."
>>
>>          I think it should be clarified what "is used" actually
>> means. This
>>      can be either:
> Commit be8ac2c now clarifies that the serialized CBOR structure is put
> into the psk_identity (option i).

==>MT
I thought the CBOR serialization should refer to the most outer 
structure as the one used as value of "psk_identity", i.e. the map 
including the "cnf" element, also called "cnf structure".

Then, still following the same functional approach of option (i), I 
think the text should actually say:

OLD:
The CBOR serialization of this structure then is included ...

NEW:
This structure then is included as the only element in the `cnf` 
structure, whose CBOR serialization is used as value for `psk_identity` 
as shown in ...


Correct? To be even more clear, it would help to include after Figure 9 
also the actual serialization used in "psk_identity" for that, which 
should be:

0xA1 08 A1 01 A2 01 04 02 48 3D027833FC6267CE

<==

>
>>          i) using the binary serialization of the structure "as is"
>> with no
>>      re-coding, just like for the case when psk_identity is the token (see
>>      the paragraph after Figure 9); or
>>
>>          ii) saying that the specific way of "using" it for
>> psk_identity is
>>      up to the C and RS to pre-agree somehow, while still giving a
>>      recommendation like the one above; or
>>
>>          iii) see next item (d), trying to address implementations without
>>      "full support" for binary psk_identity.
>>
>>      d) Regarding psk_identity, RFC 7925 has the intent to *not require* a
>>      UTF-8 character string, which remains in general possible to use as
>>      valid opaque byte string. The ultimate goal is to tell to TLS
>>      implementations "don't try to parse" that string, since it may not be
>>      UTF-8 compliant.
> Yes.
>
>>      So, character strings are not *required* but they may
>>      still *be used*.
> I am not sure what this sentence means. Is this about sequences of
> multibyte characters such as UCS-2?

==>MT
It's just a rephrased summary of the text before that :-)

See "RFC 7925 has the intent to *not require* a UTF-8 character string, 
which remains in general possible to use as valid opaque byte string."
<==

>
>>      If so, they just have to be treated as opaque bytes
>>      anyway by DTLS.
>>
>>          As in point (c) above, the profile currently says that: if
>>      psk_identity is the token, its binary serialization is used; if
>>      psk_identity is not the token, the "cnf" structure of Figure 9 "is
>>      used", without further details.
>>
>>          It seems that implementations (e.g., Californium) don't fully
>>      support non-UTF-8 psk_identity values all the way up to an application
>>      needing to retrieve it, like in the case of an ACE RS.
>>
>>          In Californium, DTLS itself works with a non UTF-8 psk_identity
>>      (through a discouraged workaround), but the server eventually stores
>>      that identity to be accessible for the application as a UTF-8 character
>>      string anyway, thus making the original binary identity not available to
>>      the application. This results, in this case, in failed access to
>>      resources. A detailed explanation of this issue in Californium is in the
>>      mail I sent on 2021-05-07, at 12:55 CEST.
>>
>>          An admittedly arguable change in the profile to address both points
>>      (c) and (d) can be:
>>
>>             - When the token is used as psk_identity, then psk_identity is
>>      the base64 serialization of the token, which results in a UTF-8
>>      compliant string.
>>
>>             - When the "cnf" structure is used as psk_identity, then
>>      psk_identity is the base64 serialization of the binary encoding of the
>>      "cnf" structure, which results in a UTF-8 compliant string.
>>
>>             - The above can be the recommended option, unless otherwise
>>      pre-agreed by the Client and Resource Server.
> There has been a longer discussion about this (including my note that
> you could use UTF-8 for serialization to possibly save some bytes
> compared to the more expensive base64.)
>
> However: The major question is if we take this as an opportunity to fix
> the non-compliant Cf rather than specifying an IoT-protocol that wastes
> bytes on the wire although there is a clear recommendation in RFC 7925
> that psk_identity is not be parsed as UTF-8?

==>MT
I think I've solved this, although it was not straightforward.

Now my RS locally forces a convenient DTLS peer identity in its DTLS key 
store, rather than using the "psk_identity" verbatim from the wire 
(which would be easier and more convenient, but it breaks things later 
on as we discussed).

Californium actually provides a method for this manual identity 
"normalization" [1], as available to use in a DTLS Key Store --- in this 
case, basically in the middle of the handshake.

That locally overridden identity is what would be made available to the 
application to retrieve, from messages protected with the DTLS session 
in question. In particular, that identity can locally be set to be a 
character string (e.g., by base64 re-encoding), that the DTLS layer 
would thus make available to the application as usual, for matching with 
the peer identity paired with the stored Token, and ultimately making 
access control checks work as expected.

So, it would still be better that the peer identity was possible for the 
application to retrieve also when a non-character-string, but it seems 
anyway possible in Californium to be compliant with the spec through 
this additional manual normalization.

Thanks,
/Marco


[1] 
https://github.com/eclipse/californium/blob/df967c316fd6a4809f2f23ec10102e8d6a1bf73a/scandium-core/src/main/java/org/eclipse/californium/scandium/dtls/PskPublicInformation.java#L122
<==

>
> Grüße
> Olaf

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www.ri.se

Phone: [phone]
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)