Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

Carsten Bormann <> Fri, 09 July 2021 12:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A41863A1F5E; Fri, 9 Jul 2021 05:20:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q31C-yrB9wEj; Fri, 9 Jul 2021 05:20:31 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B03073A1F54; Fri, 9 Jul 2021 05:20:31 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4GLsgX2JXZz2xJ4; Fri, 9 Jul 2021 14:20:24 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Fri, 9 Jul 2021 14:20:23 +0200
Cc: Francesca Palombini <>, Daniel Migault <>, Cigdem Sengul <>, "Apple Inc." <>, "" <>, "" <>
X-Mao-Original-Outgoing-Id: 647526023.886564-6e7a8bb3d6c6ddbe304ca80b68537ca2
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Ludwig Seitz <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (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, 09 Jul 2021 12:20:38 -0000

How do we get this done before Monday’s I-D deadline?

On 2021-07-06, at 08:22, Ludwig Seitz <> wrote:
> Hello Francesca, Carsten,
> Sorry but I do not like what you did in the first sentence. Combining profiles does not necessarily equate to creating a new one, and I still don't see why we should needlessly request that it be so.

The devil is in the details.  If we have pairs profiles that combine, the component profiles should say so and say how.

> Given an example use case where a client talks dtls-profile to the AS and gets token and parameters for an oscore-profile back for the client-RS leg, why should there be a need for a new profile to support this?

Because the interaction e.g. with the DTLS and OSCORE/LAKE security setup has details that need to be covered in the component profiles.

> I also do not like that you removed the requirement to design profiles so that the security for the different legs of the communication (C-AS, C-RS, RS-AS) stands on its own.

Some of the security can stand on its own, but the overall security derives from the properties of the legs combining.

> What could happen now is that someone designs clever protocol foo that has a dependency between the C-AS and the C-RS communication for its security, and thus breaks when it is used on only one leg of this communication. I don't think you need to know all possible future profiles to design yours to be secure in that way. Note that the framework puts requirements on the security of future profiles, so you can assume e.g., that communication will be secure.

We may be better off writing a separate document that explains how to exactly do this mixing-and-matching.  

I’d like to hear from others how they see this issue.

Grüße, Carsten