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
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
