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

On 2021-07-10, at 12:07, Ludwig Seitz <ludwig_seitz@gmx.de> 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 <ludwig.seitz@combitech.com> 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
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace