Hi Marco, thanks again for the quick response. I will add your suggested change and submit a new version.
Grüße Olaf On 2022-03-04, Marco Tiloca <marco.til...@ri.se> wrote: > Hi Olaf, > > On 2022-03-04 13:04, Olaf Bergmann wrote: >> 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 > > ==>MT > ~snip > <== > >>> * "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? > > ==>MT > Maybe this text? > > "... as unsupported ACE profiles. If the Client is modified > accordingly or it learns that the Resource Server has been, the Client > may try to connect to the Resource Server using the transport layer > security mechanism that was previously not mutually supported, as long > as the access token is still valid." > <== >>> - 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. > > ==>MT > Perfect, thanks! > > Best, > /Marco > <== > >> >>> 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
