Re: [Ace] Roman Danyliw's Discuss on draft-ietf-ace-dtls-authorize-16: (with DISCUSS and COMMENT)

Stefanie Gerdes <> Fri, 23 April 2021 16:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2D313A141D; Fri, 23 Apr 2021 09:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G8KYmKbIvVBY; Fri, 23 Apr 2021 09:08:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B6AA43A140F; Fri, 23 Apr 2021 09:08:24 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4FRfN56cTTzyS4; Fri, 23 Apr 2021 18:08:21 +0200 (CEST)
To: Roman Danyliw <>, The IESG <>
References: <>
From: Stefanie Gerdes <>
Message-ID: <>
Date: Fri, 23 Apr 2021 18:08:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Ace] Roman Danyliw's Discuss on draft-ietf-ace-dtls-authorize-16: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Apr 2021 16:08:29 -0000

Hi Roman,

Thank you very much for your detailed comments!

We addressed your comments with two exceptions as explained in detail
below. You can see most of the changes at

On 3/23/21 4:32 AM, Roman Danyliw via Datatracker wrote:
> Roman Danyliw has entered the following ballot position for
> draft-ietf-ace-dtls-authorize-16: Discuss
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> (A simple editorial fix) Per Section 5.8.2 of
[I-D.ietf-ace-oauth-authz], the
> name of the parameter in the C-to-AS communication is “ace_profile” (not
> “profile”).  The “ace_profile” parameter is mistakenly referenced as
> in the following places:
> -- Section 3.2.1:
>    The response MAY contain a "profile" parameter with the value
>    "coap_dtls" to indicate that this profile MUST be used for
>    communication between the client and the resource server.
> -- Section 3.3.1:
>    If the
>    profile parameter is present, it is set to "coap_dtls".

Okay, done.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> > Thank you to Russ Mundy for the SECDIR review, and thank you to the
authors for
> responding to it.
> ** Does this profile only cover part of the oauth-authz framework?
Section 3.3
> explicitly says “the use of introspection is out of scope for this
> specification.”  It might be helpful to note in the introduction that this
> profile only covers C-to-AS and C-to-RS communication.

Fixed in introduction.

> ** Section 3.2.1 Figure 3, uses the “req_aud” parameter, but this was
> to “audience” in -20 of draft-ietf-ace-oauth-authz

Good catch! Fixed.

> ** Section 3.2.1.  Per ‘The response MAY contain a "profile" parameter
with the
> value "coap_dtls" to indicate that this profile MUST be used for
> between the client and the resource server’, this is true (see the DISCUSS
> above though).  However, it might be worthwhile to point out that per
> 5.8.2 of draft-ietf-ace-oauth-authz-38, this “MAY” is actually a MUST
if the
> request has an empty “ace_profile” parameter.

Okay, fixed.

> ** Section 3.2.2.  Per “This specification therefore mandates
> support for curve25519 ...”, perhaps RFC2119 language should be used here

Okay, changed to MUST implement.

> ** Section 3.3.1.  Per all of the text after “The method for how the
> server determines the symmetric key from an access token containing
only a key
> identifier is application-specific; the remainder of this section
provides one
> example”, consider removing all of the RFC2119 language is this text
as its an
> example.

The Gen-ART review from Paul Kyzivat of 19 Jul 2020 suggested to include
the normative language to avoid ending up with unclear specifications.
(The normative language has been added in

> ** Section 3.3.2.  Per “When the resource server receives an access
token, it
> MUST check if the access token is still valid ...”, a reference to Section
> of [I-D.ietf-ace-oauth-authz] for additional verification
> might be helpful


> ** Section 3.2.2. and 7:
> (a) Section 3.2.2.
>    To be consistent with [RFC7252] which allows for shortened MAC tags
>    in constrained environments, an implementation that supports the RPK
>    mode of this profile MUST at least support the ciphersuite
> (b) As this specification aims at constrained devices and
>    uses CoAP [RFC7252] as transfer protocol, at least the ciphersuite
>    TLS_PSK_WITH_AES_128_CCM_8 [RFC6655] should be supported
> The text in (b) is weaker on the mandatory required of the
ciphersuite.  In
> (b), likely s/should be supported/must be supported/.

We changed (b) to MUST support.

> ** Section 7.  Per “For longer-lived access tokens, DHE ciphersuites
should be
> used”, perhaps add a parenthetical at the end of this sentence of “(i.e.,
> ciphersuites of the form TLS_DHE_PSK_*)”.

Fixed as suggested.

> ** Section 7.1.  Session resumption is noted to be NOT RECOMMENDED.
Is there a
> reason this can’t be stronger (MUST NOT)?

Prohibiting session resumption would be too restrictive as this can be
useful for very constrained clients. We therefore changed it as follows:


   Therefore, the use of session resumption is NOT RECOMMENDED for
   resource servers.


   Therefore, session resumption should be used only in combination with
   reasonably short-lived PoP keys.

> ** Section 7.2.  No issues with the guidance here.  Is there anything DTLS
> specific that suggests that developers "SHOULD" avoid multiple access
> per client?  That guidance isn’t in the core framework.  I made the
comment on
> the core framework that perhaps this text should be there (too?).

We are working on that with the other authors.

> ** Please reviews all of the reference numbers to
[I-D.ietf-ace-oauth-authz] as
> a number of them seem to be incorrect (likely due to renumbering).
For example:

We fixed all framework references (including the ones below).

> -- Section 2.  Per “the client MUST upload the access token to the
> resource, i.e. the authz-info endpoint, on the resource server before
> the DTLS handshake, as described in Section 5.8.1 of
> [I-D.ietf-ace-oauth-authz]”, Section 5.8.1 is not the right reference.
> likely 5.10.1.
> -- Section 3.4.  Per “The authorization server may, e.g., specify a "cti"
> claim for the access token (see Section 5.8.3 of
[I-D.ietf-ace-oauth-authz]) to
> employ a strict order”, Section 5.8.3 is the wrong section in
> [I-D.ietf-ace-oauth-authz].
> -- Section 3.4.  Per “The response SHOULD include AS Request Creation
Hints as
> described in Section 5.1.1 of [I-D.ietf-ace-oauth-authz].”, there is
no Section
> 5.1.1. The appropriate section is either 5.2 to reference this
behavior or 5.3
> for the details of the hints.
> -- Section 3.4. Per “Incoming CoAP requests received on a secure DTLS
> that are not thus authorized MUST be rejected according to Section
5.8.2 of
> [I-D.ietf-ace-oauth-authz]”, Section 5.8.2 is not the right reference
> ** idnits returned the following:
>   == Unused Reference: 'RFC8152' is defined on line 1148, but no explicit
>      reference was found in the text


>   == Unused Reference: 'RFC8613' is defined on line 1212, but no explicit
>      reference was found in the text


> ** Nits
> -- Section 7.1.  Typo. s/renogiation/renegotiation/


Best regards