Re: [Ace] Francesca Palombini's Yes on draft-ietf-ace-dtls-authorize-16: (with COMMENT)

Stefanie Gerdes <> Tue, 11 May 2021 12:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9E523A1664; Tue, 11 May 2021 05:41:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, 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 k3Q7NbPJ2w3U; Tue, 11 May 2021 05:41:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA6EE3A1651; Tue, 11 May 2021 05:41:38 -0700 (PDT)
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4FfcxD3g1hz315X; Tue, 11 May 2021 14:41:36 +0200 (CEST)
To: Francesca Palombini <>, The IESG <>
References: <>
From: Stefanie Gerdes <>
Message-ID: <>
Date: Tue, 11 May 2021 14:41:36 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Ace] Francesca Palombini's Yes on draft-ietf-ace-dtls-authorize-16: (with 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: Tue, 11 May 2021 12:41:46 -0000

Hi Francesca,

Thank you for your detailed comments, and sorry for the late reply. We
addressed most of your comments in the latest version. Please find my
comments inline.

On 3/24/21 4:49 PM, Francesca Palombini via Datatracker wrote:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thank you for this document. Some minor comments below.
> Francesca
> 1. -----
>    The response MAY contain a "profile" parameter with the value
>    authorizes the client, it returns an AS-to-Client response.  If the
>    profile parameter is present, it is set to "coap_dtls".  The
>          profile    : coap_dtls,
> FP: s/profile/ace_profile


> 2. -----
>    [RFC8747].  A resource server MUST have the capacity to store one
>    access token for every proof-of-possession key of every authorized
>    client.
> FP: I am not sure this BCP 14 MUST is correct here.

The normative language was used here to address a comment from Paul
Kyzivat's GEN-ART review who explicitly has asked for a normative
requirement to keep tokens until their expiry.

> 3. ------
>    raw public keys, it needs to determine which key to use.  The
>    authorization server can help with this decision by including a "cnf"
>    parameter in the access token that is associated with this
>    communication.  In this case, the resource server MUST use the
> FP: The example in Figure 4 show how the whole RPK of the client can be
> included in the access_token, so maybe this paragraph should cover that case,
> or the example changed.

I am not quite sure if I understand your comment. In Figure 4, the
contents of the access token is omitted for brevity. The response
contains access information for the client with the server's RPK in
the rs_cnf parameter. This is required by the client to authenticate
its peer during the DTLS handshake. We changed the example paragraph
so that it now explains the use of the rs_cnf parameter. Does that
make it more clear?

> 4. -----
>    token carries a symmetric key, the access token MUST be encrypted
>    using a "COSE_Encrypt0" structure.  The authorization server MUST use
> FP: Since only CWT is allowed in this profile, it might be good to reference
> section 7.1 of RFC 8392.

Fixed as suggested.

> 5. -----
>    the "psk_identity" field.  If key derivation is used, the resource
>    server uses the "COSE_KDF_Context" information as described above.
> FP: "COSE_KDF_Context" appears here for the first time, so this might need to
> be rephrased.

Okay, done.

> 6. -----
>    As recommended in Section 5.8 of [I-D.ietf-ace-oauth-authz], this
>    specification uses CBOR web tokens to convey claims within an access
>    token issued by the server.  While other formats could be used as
> FP: I think this warrants for RFC 8392 to be moved to normative reference (but
> can be convinced of the contrary).

Yes, changed to normative.

Thank you for your time,