This email closes the WGLC. If anyone is willing to shepherd the document please let us know. For all co-authors, please provide an IPR statement and let us know of any known implementations.
Yours, Logan and Daniel On Fri, Feb 18, 2022 at 9:22 AM Olaf Bergmann <bergm...@tzi.org> wrote: > Marco, > > Thanks. I have removed the reference to DTLS1.3 and will propose > text to address the interoperability issues asap. > > Grüße > Olaf > > On 2022-02-18, Marco Tiloca <marco.tiloca=40ri...@dmarc.ietf.org> wrote: > > > 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 <marco.tiloca=40ri...@dmarc.ietf.org> > >> 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? > > > > ==>MT > > I 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 > >>> 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? > > > > ==>MT > > Yes, 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 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > -- Daniel Migault Ericsson
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
