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 OlafGrüße Olaf
-- Marco Tiloca Ph.D., Senior Researcher Division: Digital Systems Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistagången 16 SE-164 40 Kista (Sweden)
OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
