Hi all, This is my official "Ok" for that point. Thanks.
I still have the following point open from the mail exchange with Ludwig, to which I hadn't replied (all other points are good). CC Cigdem, Carsten and Göran as they participated in the discussion. 6.7. Combining Profiles 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. My original comment and Ludwig's replies: >FP: This seems strange - maybe I just don't understand how this is >supposed to work, but each profile defines exactly at least C - RS >communication and security, if several are combined, it seems that at >least the C-RS would conflict. > >LS: You could use one profile for C-RS (e.g. MQTT) and another one for C-AS >(e.g. DTLS) in the same interaction. So the writer of e.g. the DTLS profile >MUST NOT make security assumptions that this profile is used on _every_ leg of >the communication. > FP: Ok, I see, you mean that the C-RS interaction uses for example one profile, while the C-AS uses another? I am not convinced this text is enough - first of all you'd have to make sure that the profiles are "combinable" - the OSCORE profile for example requires the security context to be derived, and simply using another profile without tweaking it would not be enough. Additionally, I am confused about the implications for implementers to mix and match different profiles for different legs of communication, this sounds like interoperability could be an issue. Can we discuss this more? LS: I don't really see the problem here. Say you have a client that uses DTLS to talk to the AS. The AS determines that the client should use the OSCORE profile to talk to the RS and prepares the token accordingly (including the OSCORE parameters in the cnf claim of the token and the cnf parameter of the response). The client is informed of the chosen profile with the 'profile' parameter and proceeds to derive the OSCORE context for client-RS communication. We discussed this during the May interim: https://datatracker.ietf.org/doc/minutes-interim-2021-ace-08-202105111000/ However the minutes don't capture the whole discussion so I suggest you listen to the recording to catch up (and I am sorry I was indeed delayed and breaking up): https://youtu.be/Cp5P2q78iVY?t=823 . 13:43 I try to explain what problem I have with the section; 16:20 the discussion starts; 27:40 the conclusion starts; 31:40 we move on. To summarize my understanding - we agreed that the Section 6.7 was unclear. * The first sentence is confusing in the sense that it is not clear what "combining profiles" mean. The way MQTT interprets it: different transport and security protocols can be used in different legs. Profiles MUST specify how that works (as for example MQTT allows for CoAP and CBOR to be used, and defines how). * The last sentence is problematic because a profile cannot guess all profiles that will be defined afterwards and make sure they could interoperate. So my suggestion for this section is 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 were different transport and security protocols are allowed for the different interactions, and that corresponds to combining profiles. For example, a new profile could define 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. I hope this helps, Francesca On 05/07/2021, 13:59, "Ludwig Seitz" <[email protected]> wrote: Hello, I am waiting for an "OK" from Francesca, since the change was originally related to her IESG DISCUSS. /Ludwig -----Original Message----- From: Stefanie Gerdes <[email protected]> Sent: den 5 juli 2021 13:27 To: Carsten Bormann <[email protected]>; Daniel Migault <[email protected]> Cc: [email protected]; Ludwig Seitz <[email protected]>; [email protected]; [email protected]; The IESG <[email protected]>; Seitz Ludwig <[email protected]>; [email protected]; Francesca Palombini <[email protected]> Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT) Hi all, There is an unresolved issue that is holding up the process of finishing the ACE framework. As I understand it, the issue can be resolved by adding a sentence to section 3: OLD: CBOR is a binary encoding designed for small code and message size. Self-contained tokens and protocol message payloads are encoded in CBOR when CoAP is used. NEW: CBOR is a binary encoding designed for small code and message size. Self-contained tokens and protocol message payloads are encoded in CBOR when CoAP is used. When used outside CoAP, the use of CBOR remains RECOMMENDED. Can we add this and finally finish the framework and the DTLS profile? Thanks, Steffi On 6/29/21 11:47 PM, Carsten Bormann wrote: > On 29. Jun 2021, at 20:11, Daniel Migault <[email protected]> wrote: >> >> Hi, >> >> So here is the current text: >> """ >> CBOR is a binary encoding designed for small code and message size. Self-contained tokens and protocol message payloads are encoded in CBOR when CoAP is used. >> """ >> >> I think Carsten is suggesting the text does not limit the use of CBOR to the use of CoAP but eventually when other protocols are used..The difference is that when CoAp is used there is a stronger insentive to use CBOR than when CoAP is not used. If that is correct, we could clarify that by adding. ""When used outside CoAP, the use of CBOR remains RECOMMENDED.""". >> >> Please provide some text that would address your concern. > > That works very well for me. > > (My main concern is that the current text sounds like CBOR is only > used in CoAP, while in reality CBOR remains the encoding of choice > unless there is a good reason to use something else; this concern is > addressed in a very precise way by your suggested wording.) > > Grüße, Carsten > > > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace > -- Stefanie Gerdes Tel: +49 421 218 63906 TZI Universität Bremen E-Mail: [email protected] Bibliothekstr. 1, MZH 5150 28359 Bremen, Germany _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
