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

From: Olaf Bergmann <[email-masked]>
Date: Thu, 03 Mar 2022 16:22:39 +0100

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 <[email-masked]> 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

---

From: Marco Tiloca <[email-masked]>
Date: Thu, 3 Mar 2022 23:37:24 +0100

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

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

---

From: Olaf Bergmann <[email-masked]>
Date: Fri, 04 Mar 2022 13:04:49 +0100

Hi Marco,

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

> sure how "SHOULD be prepared" is practically enforceable.

Very good.

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

Done.

>    - Based on the previous step, the Client starts a TLS handshake
> with the Resource Server, which fails since it is not commonly
> supported.
>
> 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.

Grüße
Olaf

---

From: Marco Tiloca <[email-masked]>
Date: Fri, 4 Mar 2022 14:37:34 +0100

Hi Olaf,

> [2] https://ace-wg.github.io/ace-extend-dtls-authorize/draft-ietf-ace-extend-dtls-authorize.html

==>MT
~snip
<==

> 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."
<==
>    also for an initial unauthorized resource request.

==>MT
Perfect, thanks!

Best,
/Marco
<==

-- 
Marco Tiloca
Ph.D., Senior Researcher

---

From: Olaf Bergmann <[email-masked]>
Date: Fri, 04 Mar 2022 14:49:37 +0100

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 <[email-masked]> wrote:

>> [2]
>> https://ace-wg.github.io/ace-extend-dtls-authorize/draft-ietf-ace-extend-dtls-authorize.html
>
> ==>MT
> ~snip
> <==
>
> "... 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."
> <==

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 07 Mar 2022 11:56:31 +0100

Hi Marco,

> as the access token is still valid."

I have added this text as suggested except for the last part, "as
long as the access token is still valid."

The reason I left this out is that if the software has changed it is
likely that the modified peer does not have the existing
token. Therefore, it would also be reasonable to retrieve a new
access token for the subsequent attempt.

Grüße
Olaf

---

From: Olaf Bergmann <[email-masked]>
Date: Tue, 15 Mar 2022 16:00:57 +0100

Hi Logan and Daniel,

On 2022-02-28, Daniel Migault <[email-masked]> wrote:

> For all co-authors, please provide an IPR statement and let us
> know of any known implementations.

I am not aware of any IPR related to this document.

Our implementation (WIP) at [1] supports CoAP transport over DTLS
and TLS using libcoap [2]. The client-side retry with different
transport layer security is not yet implemented, though.

[1] https://gitlab.informatik.uni-bremen.de/DCAF/dcaf
[2] https://libcoap.net

Grüße
Olaf

---

From: Daniel Migault <[email-masked]>
Date: Tue, 22 Mar 2022 09:42:24 -0400

Just reminding other co-authors
.
Yours,
Daniel

-- 
Daniel Migault
Ericsson

---

From: Göran Selander <[email-masked]>
Date: Fri, 25 Mar 2022 09:10:32 +0000

Besides the recent notification on the ACE mailing list, I'm not aware of any other IPR related to this document.

Göran

From: Ace <[email-masked]> on behalf of Daniel Migault <[email-masked]>
Date: Tuesday, 22 March 2022 at 14:43
To: Olaf Bergmann <[email-masked]>
Cc: Loganaden Velvindron <[email-masked]>, Marco Tiloca <marco.tiloca=[email-masked]>, Ace Wg <[email-masked]>
Subject: Re: [Ace] WGLC draft-ietf-ace-extend-dtls-authorize
Just reminding other co-authors
.
Yours,
Daniel

On Tue, Mar 15, 2022 at 11:00 AM Olaf Bergmann <[email-masked]<mailto:[email-masked]>> wrote:
Hi Logan and Daniel,

[1] https://gitlab.informatik.uni-bremen.de/DCAF/dcaf
[2] https://libcoap.net<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-9eebff0b38b41c2e&q=1&e=042c1784-6f4f-49c7-8d69-16ba333a0f9b&u=https%3A%2F%2Flibcoap.net%2F>

Grüße
Olaf

--
Daniel Migault
Ericsson