Subject: [Ace] I-D Action: draft-ietf-ace-extend-dtls-authorize-01.txt

From: [email-masked]
Date: Fri, 04 Feb 2022 00:53:59 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF.

        Title           : Extension of the ACE CoAP-DTLS Profile to TLS
        Authors         : Olaf Bergmann
                          John Preuß Mattsson
                          Göran Selander
	Filename        : draft-ietf-ace-extend-dtls-authorize-01.txt
	Pages           : 4
	Date            : 2022-02-04

Abstract:
   This document updates the ACE CoAP-DTLS profile by specifying that
   the profile applies to TLS as well as DTLS.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Authentication and
   Authorization for Constrained Environments Working Group mailing list
   ([email-masked]), which is archived at
   https://mailarchive.ietf.org/arch/browse/ace/.

   Source for this draft and an issue tracker can be found at
   https://github.com/ace-wg/ace-extend-dtls-authorize.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-extend-dtls-authorize/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-ace-extend-dtls-authorize-01.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-extend-dtls-authorize-01

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Olaf Bergmann <[email-masked]>
Date: Fri, 04 Feb 2022 10:04:52 +0100

Hi all,

we have updated draft-ietf-ace-extend-dtls-authorize to reflect that
the authorization is tied to the underlying secure channel. This
change was proposed in the ACE WG meeting during IETF 112 but has
not made it into the document since then.

The authors think that this document now is ready for WGLC.

Grüße
Olaf

On 2022-02-04, [email-masked] wrote:

> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Daniel Migault <[email-masked]>
Date: Tue, 15 Feb 2022 08:08:33 -0500

Hi all,

This email starts a WGLC for Extension of the ACE CoAP-DTLS Profile to TLS.
If you think the document is ready or have any comments please indicate it
by Feb 22 on the mailing list.

The document is available here:
https://datatracker.ietf.org/doc/draft-ietf-ace-extend-dtls-authorize/

Yours,
Daniel

---------- Forwarded message ---------
From: <[email-masked]>
Date: Fri, Feb 4, 2022 at 3:54 AM
Subject: [Ace] I-D Action: draft-ietf-ace-extend-dtls-authorize-01.txt
To: <[email-masked]>
Cc: <[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Authentication and Authorization for
Constrained Environments WG of the IETF.

Abstract:

Discussion Venues

Internet-Drafts are also available by rsync at rsync.ietf.org:
:internet-drafts

-- 
Daniel Migault
Ericsson

---

From: Marco Tiloca <[email-masked]>
Date: Fri, 18 Feb 2022 10:06:52 +0100

Hi all,

Please, see below my WGLC comments.

Best,
/Marco

[General]

* In the document header, "Network Working Group" should be replaced by 
"ACE Working Group".

* Looking at the phrasing in Section 2 of draft-ietf-ace-dtls-authorize, 
it would be more consistent to use "Extension of the CoAP-DTLS Profile 
for ACE to TLS", as document title and in the abstract.

[Abstract]

* Also as a feedback from the ID nit checker, the abstract should 
explicitly mention the updated document draft-ietf-ace-dtls-authorize.

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

* Please, add a reference to RFC 8446 for TLS.

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

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

[Section 2]

* Shouldn't this section update the IANA considerations from Section 9 
of draft-ietf-ace-dtls-authorize ? The "Profile Description" column of 
the "coap_dtls" entry in the ACE OAuth Profile registry should become:

    "Profile for delegating client authentication and authorization in a 
constrained environment by establishing a Datagram Transport Layer 
Security (DTLS) or Transport Layer Security (TLS) channel between 
resource-constrained nodes."

[Nits]

* Section 1
--- s/specifies use/specifies the use
--- s/lacking from the/lacking in the
--- s/is either DTLS/is provided by either DTLS

On 2022-02-15 14:08, Daniel Migault wrote:
> Hi all,
>
> This email starts a WGLC for Extension of the ACE CoAP-DTLS Profile to 
> TLS. If you think the document is ready or have any comments please 
> indicate it by Feb 22 on the mailing list.
>
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-extend-dtls-authorize%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb132588f84204e1c1d1308d9f0845a2f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637805274622910877%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qYOhGjTxtmNiayeE39rZiSU3rmcQOnCZgneS2sU2cas%3D&reserved=0>
>
> Yours,
> Daniel
>
> https://mailarchive.ietf.org/arch/browse/ace/ 
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Face%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb132588f84204e1c1d1308d9f0845a2f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637805274622910877%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SA8jbaFsmaFEOJHlG7dreBzReeUJjGL7F18a92Iqgas%3D&reserved=0>.
>
> https://github.com/ace-wg/ace-extend-dtls-authorize 
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Face-wg%2Face-extend-dtls-authorize&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb132588f84204e1c1d1308d9f0845a2f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637805274622910877%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mfBbqLYqnS1rfZnNICW5WFuyNxmz%2Bhf0mAJVzNlLIg4%3D&reserved=0>.
>
>
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-extend-dtls-authorize%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb132588f84204e1c1d1308d9f0845a2f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637805274622910877%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qYOhGjTxtmNiayeE39rZiSU3rmcQOnCZgneS2sU2cas%3D&reserved=0>
>
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-ace-extend-dtls-authorize-01.html&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb132588f84204e1c1d1308d9f0845a2f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637805274622910877%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4bI97BfKaQGvcgOo%2B%2Bc9cK28%2F5HGO3H%2BDf1p52JdOyg%3D&reserved=0>
>
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-ace-extend-dtls-authorize-01&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb132588f84204e1c1d1308d9f0845a2f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637805274622910877%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EkBGC0G0HFt5Z6gSgG5X0hw4YxIePHCV0Q2vRTlyKz0%3D&reserved=0>
>
>
> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb132588f84204e1c1d1308d9f0845a2f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637805274622910877%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=E%2B8vt1EoIFLRRFJJvptB6cLLZYT5AJgf80UTyHRMCEU%3D&reserved=0>
>
>
> -- 
> Daniel Migault
> Ericsson
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
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, 18 Feb 2022 13:42:34 +0100

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

> [General]
>
> * In the document header, "Network Working Group" should be
> replaced by "ACE Working Group".

Done

> * Looking at the phrasing in Section 2 of
> draft-ietf-ace-dtls-authorize, it would be more consistent to use
> "Extension of the CoAP-DTLS Profile for ACE to TLS", as document
> title and in the abstract.

Done

> draft-ietf-ace-dtls-authorize.

Done

> [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?

> * Please, add a reference to RFC 8446 for TLS.

Done.

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

> * 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?
    
> [Section 2]
>
> * Shouldn't this section update the IANA considerations from
> Section 9 of draft-ietf-ace-dtls-authorize ? The "Profile
> Description" column of the "coap_dtls" entry in the ACE OAuth
> Profile registry should become:
>
>    "Profile for delegating client authentication and authorization
> in a constrained environment by establishing a Datagram Transport
> Layer Security (DTLS) or Transport Layer Security (TLS) channel
> between resource-constrained nodes."

Done

> --- s/is either DTLS/is provided by either DTLS

Done

Grüße
Olaf

---

From: Daniel Migault <[email-masked]>
Date: Fri, 18 Feb 2022 07:48:30 -0500

Thanks for the review and fast response.

Yours,
Daniel

On Fri, Feb 18, 2022 at 7:42 AM Olaf Bergmann <[email-masked]> wrote:

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

-- 
Daniel Migault
Ericsson

---

From: Marco Tiloca <[email-masked]>
Date: Fri, 18 Feb 2022 14:20:10 +0100

Hi Olaf,

Thank you for the quick update!

Please, see my replies inline (trimming the solved points)

> 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.
<==
>    transport layer security.

==>MT
Looks good.
<==

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

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System

---

From: Olaf Bergmann <[email-masked]>
Date: Fri, 18 Feb 2022 15:22:30 +0100

Marco,

Thanks. I have removed the reference to DTLS1.3 and will propose
text to address the interoperability issues asap.

Grüße
Olaf

On 2022-02-18, Marco Tiloca <marco.tiloca=[email-masked]> wrote:

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

---

From: Daniel Migault <[email-masked]>
Date: Mon, 28 Feb 2022 19:01:49 -0500

This email closes the WGLC.

If anyone is willing to shepherd the document please let us know. For all
co-authors, please provide an IPR statement and let us know of any known
implementations.

Yours,
Logan and Daniel

-- 
Daniel Migault
Ericsson