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

From: Francesca Palombini <[email-masked]>
Date: Mon, 5 Jul 2021 13:32:11 +0000

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-masked]> 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-masked]> 
    Sent: den 5 juli 2021 13:27
    To: Carsten Bormann <[email-masked]>; Daniel Migault <[email-masked]>
    Cc: [email-masked]; Ludwig Seitz <[email-masked]>; [email-masked]; [email-masked]; The IESG <[email-masked]>; Seitz Ludwig <[email-masked]>; [email-masked]; Francesca Palombini <[email-masked]>
    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-masked]> 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-masked]
    > https://www.ietf.org/mailman/listinfo/ace
    > 

    -- 
    Stefanie Gerdes			Tel: +49 421 218 63906
    TZI Universität Bremen		E-Mail: [email-masked]
    Bibliothekstr. 1, MZH 5150
    28359 Bremen, Germany

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 Jul 2021 16:15:07 +0200

Hi Francesca:

>   There may be use cases were different transport and security protocols

Amazingly, this still says “were” where it needs to say “where”, as if the “were” were invisible :-)

>   are allowed for the different interactions, and that corresponds to combining profiles.

“Corresponds to” is weirdly weak, but works here.
But may be we can fully explain that here before the example (which is just an example):

NEWNEW:
>   , and, if that is not explicitly covered by an existing profile, it corresponds to combining profiles into a new one.

And then we can continue with the example.

>   combination and to make sure interoperability and security properties are achieved.

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.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 Jul 2021 16:35:51 +0200

> 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

---

From: Francesca Palombini <[email-masked]>
Date: Mon, 5 Jul 2021 16:58:51 +0000

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:

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-masked]> wrote:

    NEWNEWNEW:

    Grüße, Carsten

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 6 Jul 2021 06:22:13 +0000

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-masked]> 
Sent: den 5 juli 2021 18:59
To: Carsten Bormann <[email-masked]>
Cc: Ludwig Seitz <[email-masked]>; Daniel Migault <[email-masked]>; Cigdem Sengul <[email-masked]>; Göran Selander <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

Hi Carsten,

OLD:

NEW:

Francesca

    NEWNEWNEW:

    Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 6 Jul 2021 09:09:52 +0200

Hi Francesca,

Thanks for picking this up and turning it serious.

>   its security requirements.

The BCP14 keyword MAY would be appropriate to announce some behavior that a peer MUST prepare for.  But that is not what we are trying to say here.  Maybe:

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

(Stating may be another alternative word for specifying.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 9 Jul 2021 14:20:23 +0200

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

On 2021-07-06, at 08:22, Ludwig Seitz <[email-masked]> wrote:
> 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…

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

---

From: Ludwig Seitz <[email-masked]>
Date: Sat, 10 Jul 2021 12:07:34 +0200

I can remove the text entirely, since we don't seem to agree on the details. Would that be acceptable? 

/Ludwig 

Sent from my smartphone

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 10 Jul 2021 13:13:08 +0200

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.

> 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

---

From: Olaf Bergmann <[email-masked]>
Date: Sat, 10 Jul 2021 14:49:32 +0200

Hi Carsten, Ludwig,

I think removing the discussed is not an option as the whole discussion
was about "something needs to be said" but not being clear about what
this is.

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

The result would be text that makes a profile document its security
requirements and a new profile that combines existing profiles to
document how the combination meets these requirements.

>From Francesca's previous proposal and your previous proposals this
could be:

NEW^n+1:

   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. The
   new profile that combines existing profiles MUST specify how the
   existing profiles' security properties are achieved. Any profile
   therefore MUST clearly specify its security requirements and MUST
   document if its security depends on the combination of various
   protocol interactions.

Grüße
Olaf

---

From: Ludwig Seitz <[email-masked]>
Date: Sat, 10 Jul 2021 17:58:16 +0200

Olaf's compromise text looks OK to me. If no one objects I'll submit this later today. 

/Ludwig 

Sent from my smartphone