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

[Marco Tiloca <[e-mail]>]

Hi Olaf,

Thank you for the quick update!

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

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
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)