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. 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?
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. 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. I propose the following alternative for discussion: NEW^4: There may be use cases where the transport and security protocols defined by different profiles are used for different steps of the same authorization flow. For example, an implementation could use the CoAP-DTLS profile for interactions between the client and the AS, obtaining the token and parameters for an OSCORE-profile interaction with the RS. 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). /Ludwig -----Original Message----- From: Francesca Palombini <[email protected]> Sent: den 5 juli 2021 18:59 To: Carsten Bormann <[email protected]> Cc: Ludwig Seitz <[email protected]>; Daniel Migault <[email protected]>; Cigdem Sengul <[email protected]>; Göran Selander <[email protected]>; [email protected]; [email protected] Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT) Hi Carsten, I like your proposals! I changed a "define" to "specify" to remove some repetition, so finally the text change would be the following: OLD: There may be use cases were different profiles of this framework are combined. For example, an MQTT-TLS profile is used between the client and the RS in combination with a CoAP-DTLS profile for interactions between the client and the AS. The security of a profile MUST NOT depend on the assumption that the profile is used for all the different types of interactions in this framework. NEW: There may be use cases where different transport and security protocols are allowed for the different interactions , and, if that is not explicitly covered by an existing profile, it corresponds to combining profiles into a new one. For example, a new profile could specify that a previously-defined MQTT-TLS profile is used between the client and the RS in combination with a previously-defined CoAP-DTLS profile for interactions between the client and the AS. It is REQUIRED of the new profile to specify the combination and to make sure interoperability and security properties are achieved. A profile MAY want to prepare for being combined with others by clearly specifying its security requirements. Francesca On 05/07/2021, 16:36, "Carsten Bormann" <[email protected]> wrote: On 2021-07-05, at 16:15, Carsten Bormann <[email protected]> wrote: > > The last sentence is kind of obvious (I hope that the same applies to non-combined profiles), but Section 6.7 is short, so a little superfluity does not hurt. In offline communication, I have been reminded that adding this sentence would appear to be appropriate :-) NEWNEWNEW: A profile MAY WANT TO prepare for being combined with others by clearly specifying its security requirements. (Using an RFC 6919 keyword.) I wish I didn’t have the strong feeling that this sentence may actually be required. Grüße, Carsten _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
