Re: [Ace] WGLC draft-ietf-ace-extend-dtls-authorize

[Marco Tiloca <[e-mail]>]

Hi Olaf,

Thanks! It looks good overall, please see below some suggestions.


* s/connect the Resource Server/connect to the Resource Server


* "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.


* "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).


* "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:

    - 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.


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 <[e-mail]> 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

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www.ri.se

Phone: [phone]
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)