Hi Marco, On 2022-03-03, Marco Tiloca <marco.til...@ri.se> wrote:
> Thanks! It looks good overall, please see below some suggestions. Thanks. I have merged the changes into the main branch together with the changes proposed in this email (see Editor's copy [2]). More comments inline. [2] https://ace-wg.github.io/ace-extend-dtls-authorize/draft-ietf-ace-extend-dtls-authorize.html > * s/connect the Resource Server/connect to the Resource Server Fixed. > > * "SHOULD be prepared that no communication channel with the Resource > Server can be established" > > Suggested alternative text: "might fail in establishing a secure > communication channel with the Resource Server altogether." > > I'm just trying to phrase an uncontroversial fact, while I'm not > sure how "SHOULD be prepared" is practically enforceable. Very good. > * "This error SHOULD be handled by the Client in the same way as > unsupported ACE profiles." > > I think this sentence is fine, but it might practically be limited > to the Client somehow obtaining a better pre-configuration (if it has > any at all already) about how to communicate with the Resource Server. > > That's because the only relatable text seems to be the last > sentence in Section 6.5 of [1]. However, here the AS cannot help to > distinguish exactly between TLS and DTLS, hence obtaining a > good/better knowledge of the Resource Server through some other means > is probably what's best left to do for the Client (unless if can be > promptly upgraded to support the transport layer security protocol it > is currently missing). Agreed. It basically comes down to: Without changing the Client, there is no point in retrying, unless the Client knows for certain that the Resource Server has been modified accordingly. Do you see the need for adding something like this? > * "the Client SHOULD use the same underlying transport protocol for > the establishment of the security association as well (i.e., DTLS > for UDP, and TLS for TCP)." > > Perhaps you mean "SHOULD first use" ? I'm thinking of the > (admittedly weird) case where: Done. > - The Resource Server supports both TCP and UDP, but only DTLS. > - The Client supports both TCP and UDP, as well as both TLS and DTLS. > - The unauthorized resource request successfully happens over TCP. > - Based on the previous step, the Client starts a TLS handshake > with the Resource Server, which fails since it is not commonly > supported. > > What I'd expect next is the Client trying again with a DTLS > handshake over UDP, which would work fine. > > Also, if the Client supports only DTLS (TLS) and performs an > unauthorized resource request, it SHOULD do it over UDP (TCP) in the > first place, even when supporting both UDP and TCP. That is, the > Client would have no use in performing this exchange over a transport > protocol if it does not support the corresponding transport layer > security protocol. Good point. I think the scenario you have outlined above is not that exotic if you switch DTLS and TLS because more libraries seem to support TLS but not DTLS. To address this, I have added the following paragraph at the end. The SHOULD is used here because NEW: As a consequence, the selection of the transport protocol used for the initial unauthorized resource request also depends on the transport layer security mechanism supported by the Client. Clients that support either DTLS or TLS but not both SHOULD use the transport protocol underlying the supported transport layer security mechanism also for an initial unauthorized resource request. > > Best, > /Marco > > [1] https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-46 > > On 2022-03-03 16:22, Olaf Bergmann wrote: >> Hi Marco, >> >> as you have suggested before, I have now included more test in >> draft-ietf-ace-extend-dtls-authorize that elaborates on the caveats >> of session establishment for the extended DTLS profile. >> >> Please see [1] for the new text. (To use keywords from BCP14 and ACE >> terminology, I also had to add a new section Terminology.) >> >> [1] https://github.com/ace-wg/ace-extend-dtls-authorize/pull/1 >> >> On 2022-02-18, Marco Tiloca <marco.til...@ri.se> wrote: >> >>>> 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. >> Grüße >> Olaf Grüße Olaf
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
