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 <[email protected]> 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" <[email protected]> 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.)
==>MTI 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.
==>MTOk, 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).
==>MTI 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: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistagången 16 SE-164 40 Kista (Sweden)
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
