Thanks for the review and fast response. Yours, Daniel
On Fri, Feb 18, 2022 at 7:42 AM Olaf Bergmann <bergm...@tzi.org> 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 <marco.tiloca=40ri...@dmarc.ietf.org> wrote: > > > [General] > > > > * In the document header, "Network Working Group" should be > > replaced by "ACE Working Group". > > Done > > > * Looking at the phrasing in Section 2 of > > draft-ietf-ace-dtls-authorize, it would be more consistent to use > > "Extension of the CoAP-DTLS Profile for ACE to TLS", as document > > title and in the abstract. > > Done > > > [Abstract] > > > > * Also as a feedback from the ID nit checker, the abstract should > > explicitly mention the updated document > > draft-ietf-ace-dtls-authorize. > > Done > > > [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? > > > * Please, add a reference to RFC 8446 for TLS. > > Done. > > > * "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. > > > * 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 it > > sees 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), the > > client may want to try again with TLS (DTLS) if supporting it. > > > > On the other hand, a client or RS that has been registered to > > the 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? > > > [Section 2] > > > > * Shouldn't this section update the IANA considerations from > > Section 9 of draft-ietf-ace-dtls-authorize ? The "Profile > > Description" column of the "coap_dtls" entry in the ACE OAuth > > Profile registry should become: > > > > "Profile for delegating client authentication and authorization > > in a constrained environment by establishing a Datagram Transport > > Layer Security (DTLS) or Transport Layer Security (TLS) channel > > between resource-constrained nodes." > > Done > > > > > [Nits] > > > > * Section 1 > > --- s/specifies use/specifies the use > > --- s/lacking from the/lacking in the > > --- s/is either DTLS/is provided by either DTLS > > Done > > Grüße > Olaf > -- Daniel Migault Ericsson
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
