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

Carsten Bormann <> Sat, 10 July 2021 11:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C6283A11D9; Sat, 10 Jul 2021 04:13:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 yf5kZ9wHfhTy; Sat, 10 Jul 2021 04:13:13 -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 C344D3A11D7; Sat, 10 Jul 2021 04:13:12 -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 4GMS7T05gCz2xH1; Sat, 10 Jul 2021 13:13:08 +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: Sat, 10 Jul 2021 13:13:08 +0200
Cc: Ludwig Seitz <>, Jim Schaad <>, Cigdem Sengul <>, Francesca Palombini <>,, "Apple Inc." <>, Daniel Migault <>
X-Mao-Original-Outgoing-Id: 647608388.587265-27e546491af3a98fbd66d63a54725315
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: Sat, 10 Jul 2021 11:13:20 -0000

On 2021-07-10, at 12:07, Ludwig Seitz <> wrote:
> I can remove the text entirely, since we don't seem to agree on the details. Would that be acceptable?

I can’t answer that question, but it seems to me that we both have a requirement in mind.  The text that resulted from processing my version is:

> Profiles are expected to prepare for being combined with others by clearly specifying their security requirements.

While you had:

> The security of a profile MUST NOT depend on the assumption that this profile is used in all steps of the authorization flow (C-AS, C-RS, RS-AS). 

The difference is that you want to impose a requirement on all profiles, a requirement that I believe is hard to provably fulfill in general.
While I was mainly putting out a requirement that profiles document their properties in this space, which is both more practical and more general.

Maybe we can combine these two into one sentence that covers a common requirement?

Grüße, Carsten

> /Ludwig
> Sent from my smartphone
> ---- Carsten Bormann wrote ----
> 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
> _______________________________________________
> Ace mailing list