Hi Olaf, Thank you for the quick update!
Please, see my replies inline (trimming the solved points) On 2022-02-18 13:42, Olaf Bergmann wrote:
Hi Marco, thanks for the thorough review. I have done most of the suggested updates (see Editor's copy [1]). Just a few comments and questions inline. [1] https://ace-wg.github.io/ace-extend-dtls-authorize/draft-ietf-ace-extend-dtls-authorize.html On 2022-02-18, Marco Tiloca <[email protected]> wrote:[Section 1] * For consistency with draft-ietf-ace-dtls-authorize , I think here it would be better to refer to RFC 6347 when mentioning DTLS. The original profile only mentions DTLS 1.3 as a possible later version, without pointing to the specification.Done. DTLS1.3 now is not referenced anymore. Do you think a normative dependency for DTLS1.3 is required?
==>MTI think you can remove the DTLS 1.3 entry from the list of normative references. That reference is not present among those in draft-ietf-ace-dtls-authorize either (where DTLS 1.3 is at least named once), so it feels even more unnecessary here.
<==
* "The same access rights are valid in case transport layer security is either DTLS or TLS, and the same access token can be used." This implies that the "ace_profile" claim in the access token and the corresponding "ace_profile" parameter in the AS-to-Client response still indicate the profile name "coap_dtls", even though TLS might be used between C and RS. I think it's better to highlight it.Yes, good point. I have added the following sentence at the end: Therefore, the value `coap_dtls` in the `ace_profile` parameter of an AS-to-Client response or in the `ace_profile` claim of an access token indicates that either DTLS or TLS can be used for transport layer security.
==>MT Looks good. <==
* Building on the previous point, there's probably something more worth clarifying. Let's say that the client receives an AS-to-Client response specifying "ace_profile" with value "coap_dtls". Presumably, the following applies:- The client can feel free to go ahead with TLS or DTLS as itsees fit, if it does not know in advance which the RS prefers or exclusively supports.- Then, if the RS does not show support for DTLS (TLS), theclient may want to try again with TLS (DTLS) if supporting it.On the other hand, a client or RS that has been registered tothe AS as supporting the "coap_dtls" profile is supposed to support at least one among TLS or DTLS.You are raising an interesting point. It might happen that the client supports either DTLS or TLS, and the resource server has only support for the other transport layer security, they might not be able to talk to each other at all. The same might happen for other values of 'ace_profile' but for different profiles, the AS-to-clientn response would make this transparent. Do you feel that we should elaborate on the case where ace_profile: coap_dtls is returned in the AS-to-Client response but client and resource server still will not be able to setup a (D)TLS connection?
==>MTYes, it would help to elaborate on that. As you say, there is a possibility of no commonly supported transport security protocol, although within the commonly supported profile.
In that case, and assuming that neither of the two parties can be (promptly) updated to broaden its support, the client would just have to give up after failing to establish a channel with the only transport security protocol it supports.
Thanks, /Marco <==
Done 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_0xEE2664B40E58DA43.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
