Subject: [Ace] [Russ Mundy] Re: secdir review of draft-ietf-ace-dtls-authorize-14

From: Olaf Bergmann <[email-masked]>
Date: Mon, 08 Feb 2021 18:33:03 +0100

Hi Francesca, Daniel,

I did check with Russ if the new text will resolve his concerns. As the
new wording still does not seem to be sufficient, I am forwarding Russ's
response here as I am not entirely clear how to proceed. 

Any ideas?

Grüße
Olaf

-------------------- Start of forwarded message --------------------
Subject: Re: secdir review of draft-ietf-ace-dtls-authorize-14
From: Russ Mundy <[email-masked]>
Date: Sat, 6 Feb 2021 16:01:00 -0500
Cc: Russ Mundy <[email-masked]>,
        Daniel Migault <[email-masked]>,
        "[email-masked]" <[email-masked]>
To: Olaf Bergmann <[email-masked]>

Hi Olaf,

Thanks for the follow up and the additional suggested revision.  

Unfortunately, the NEW: wording does not resolve my concern. In my view, this newest suggested wording has the same fundamental problem as the original wording, i.e., it does not meet the MUST requirement from [I-D.ietf-ace-oauth-authz] to define how "other protocols" meet the requirements in Section 5.  

I certainly understand that there are a number of choices that implementations can make for various parts of the ACE framework. However, the framework does seem to be very clear that profiles have to define how communications security requirements of  [I-D.ietf-ace-oauth-authz] are met.  Even though other protocol combinations can meet the security requirements in Section 5 of  [I-D.ietf-ace-oauth-authz], the ACE framework requires that profiles define how these requirements will be met.  So the problem remains with the current profile only defining how communications security requirements are met for CoAP and DTLS but both the NEW: and OLD: wording would permit "other protocols" to be used under this profile without defining how the "other protocols" meet the security requirements in Section 5 of  [I-D.ietf-ace-oauth-authz].

Given the requirements of [I-D.ietf-ace-oauth-authz], it seems like any protocols allowed by a profile have to define how the framework communications security requirements are met when using the allowed protocols.  

Sorry but it seems like including "other protocols" in a profile that have no ACE framework profile defined is a significant deviation from the MUST requirement of 6.2 of [I-D.ietf-ace-oauth-authz].

Regards,
Russ

> On Feb 4, 2021, at 5:26 AM, Olaf Bergmann <[email-masked]> wrote:
> 
> Hi Russ,
> 
> On 2021-01-19, Olaf Bergmann <[email-masked]> wrote:
> 
>> Thank you, Russ, very much for your review.
>> 
>> I am perfectly happy with your suggested change to make CoAP over DTLS
>> REQUIRED for this profile.
> 
> as it turned out, people felt that making CoAP over DTLS a requirement
> would be too restrictive. The reason is that the ACE framework generally
> allows for different protocols to be used between the different legs of
> the communication. Usually, the ACE profiles focus specifically on the
> communication between the Client and the Resource Server. Both entities
> may communicate with the Authorization Server to retrieve the required
> information to establish this communication.
> 
> Now, if the CoAP over DTLS was required for the communication between
> the Client and the Authorization Server (or the Resource Server and the
> Authorization Server, respectively), a combinatory number of additional
> specifications was required to enable the Client and the Resource Server
> to use a different protocol for communicating with the Authorization
> Server, e.g. HTTP over TLS.
> 
> We therefore propose the following change, referring to the requirements
> set by the ACE framework document on the security of the communication
> with the Authorization Server:
> 
> OLD:
> 
>  The use of CoAP and DTLS for this communication is RECOMMENDED in this
>  profile, other protocols (such as HTTP and TLS, or CoAP and OSCORE
>  [RFC8613]) MAY be used instead.
> 
> NEW:
> 
>  The use of CoAP and DTLS for this communication is RECOMMENDED in this
>   profile, other protocols fulfilling the security requirements defined
>   in Section 5 of [I-D.ietf-ace-oauth-authz] MAY be used instead.
> 
> Does this resolve your concern?
> 
> Best regards
> Olaf

-------------------- End of forwarded message --------------------

---

From: Göran Selander <[email-masked]>
Date: Mon, 8 Feb 2021 21:21:31 +0000

Hi,

Russ commented on a formulation in [I-D.ietf-ace-dtls-authorize] (which also exist in [I-D.ietf-ace-oscore-profile]) that he characterizes as a deviation from the MUST requirement of 6.2 of [I-D.ietf-ace-oauth-authz]: 

  "Profiles MUST specify how communication security according
   to the requirements in Section 5 is provided."
	
which in turn is referencing the requirements in Section 5:

"(---) it is REQUIRED that the
   communications named above are encrypted, integrity protected and protected against message replay.  
   It is also REQUIRED that the communicating endpoints perform mutual authentication.  
   Furthermore it MUST be assured that responses are bound to the requests in the
   sense that the receiver of a response can be certain that the
   response actually belongs to a certain request.  Note that setting up
   such a secure communication may require some unprotected messages to
   be exchanged first (e.g. sending the token from the client to the
   RS).

   Profiles MUST specify a communication security protocol that provides
   the features required above."

As I recall the intent with the text in Section 5, its purpose is to ensure that there is *at least* one common secure protocol complying with the requirements.

Furthermore, I think the formulation in section 6.2 is unfortunate - there is no need for additional normative text since it is referring to a section where the relevant requirements are stated. So, rather than change the text in the DTLS/OSCORE profiles, I propose we make a clarification in the ACE framework.

Proposal 1 (Section 6.2):
OLD
  "Profiles MUST specify how communication security according
   to the requirements in Section 5 is provided."
NEW
"The requirements for communication security of profiles are specified in Section 5."
  
Proposal 2 (Section 5):
OLD
"Profiles MUST specify a communication security protocol that provides
   the features required above."
NEW
"Profiles MUST specify at least one communication security protocol that provides
   the features required above."

All: Does this accurately account for the intent of the framework?
Russ: Would this address your concern?

Göran

On 2021-02-08, 18:33, "Ace on behalf of Olaf Bergmann" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Francesca, Daniel,

    Any ideas?

    Grüße
    Olaf

    -------------------- Start of forwarded message --------------------
    Subject: Re: secdir review of draft-ietf-ace-dtls-authorize-14
    From: Russ Mundy <[email-masked]>
    Date: Sat, 6 Feb 2021 16:01:00 -0500
    Cc: Russ Mundy <[email-masked]>,
            Daniel Migault <[email-masked]>,
            "[email-masked]" <[email-masked]>
    To: Olaf Bergmann <[email-masked]>

    Hi Olaf,

    Regards,
    Russ

    -------------------- End of forwarded message --------------------

    _______________________________________________
    Ace mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/ace

---

From: Daniel Migault <[email-masked]>
Date: Wed, 10 Feb 2021 22:26:37 -0500

Hi,

My understanding of the concern is that when a profile is implemented, we
would like to know which protocol can be used for sure  with the
authentication server.  In that sense if I have a constraint device
that implements the OSCORE profile, it might make sense to ensure there
is no need to implement TLS "just" to get the authentication credentials
from the AS. Reversely, we may expect that implementers of the TLS profile
doesn't need to implement OSCORE for the communication with the AS.

The OSCORE profile says:
This profile RECOMMENDS the use of OSCORE between client and AS, to reduce
the number of libraries the client has to support, but other protocols
fulfilling the security requirements defined in section 5 of
[I-D.ietf-ace-oauth-authz] (such as TLS or DTLS) MAY be used as well.

The TLS profiles is willing to say:
The use of CoAP and DTLS for this communication is RECOMMENDED in this
profile, other protocols fulfilling the security requirements defined
in Section 5 of [I-D.ietf-ace-oauth-authz] MAY be used instead.

I like the formulation of the OSCORE profile. I thought initially that
RECOMMENDS was lighter than SHOULD but considering RFC2119 it appears to be
the same. The primary matter is security, that is to say that security
requirements MUST be fulfilled. The second matter is to provide sufficient
confidence that constrained clients can expect AS to support their
protocols. The problem is that mandating one protocol may provide
unnecessary restrictions too.

I would personally be happy if the RECOMMENDATION is followed by the
reasons of the recommendation. In this case, it makes very clear this is a
MUST unless there is a good reason for not doing it. We also know this will
happen if we aritte it will never happen. I agree with Goran the ACE
framework could clarify between the security protocols there are no
compromises and the actual protocol  that is recommended on other
considerations that are subject to softer requirements. I am wondering if
the following rewording could meet this compromise:

for the DTLS profile:
This profile RECOMMENDS the use of DTLS between client and AS, to reduce
the number of libraries the client has to support, but other protocols
fulfilling the security requirements defined in section 5 of
[I-D.ietf-ace-oauth-authz] (such as TLS or DTLS) MAY be used as well.

For the ACE framework:

OLD: section 6.2
 "Profiles MUST specify how communication security according
   to the requirements in Section 5 is provided."
NEW:
section 6.2 is focused on security but the security requirements are
provided in section 5. We may simply remove this sentence.

OLD section 5.
"Profiles MUST specify a communication security protocol that provides
   the features required above."
NEW:
Profiles MUST provide some recommendation on protocols used to establish
these communications.
These communications MUST meet these security requirements. As
communications meeting these requirements may be established in multiple
ways, profiles MUST provide some recommendations as to favor
interoperability. In most cases the recommendations aim at limiting the
number of libraries the client has to support.

of course, this may be written in a nicer way.

Yours,
Daniel

On Mon, Feb 8, 2021 at 4:21 PM Göran Selander <goran.selander=
[email-masked]> wrote:

> Hi,
>
> Russ commented on a formulation in [I-D.ietf-ace-dtls-authorize] (which
> also exist in [I-D.ietf-ace-oscore-profile]) that he characterizes as a
> deviation from the MUST requirement of 6.2 of [I-D.ietf-ace-oauth-authz]:
>
> As I recall the intent with the text in Section 5, its purpose is to
> ensure that there is *at least* one common secure protocol complying with
> the requirements.
>
> Furthermore, I think the formulation in section 6.2 is unfortunate - there
> is no need for additional normative text since it is referring to a section
> where the relevant requirements are stated. So, rather than change the text
> in the DTLS/OSCORE profiles, I propose we make a clarification in the ACE
> framework.
>
> On 2021-02-08, 18:33, "Ace on behalf of Olaf Bergmann" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     Hi Francesca, Daniel,
>
>             "[email-masked]" <
> [email-masked]>
>     Unfortunately, the NEW: wording does not resolve my concern. In my
> view, this newest suggested wording has the same fundamental problem as the
> original wording, i.e., it does not meet the MUST requirement from
> [I-D.ietf-ace-oauth-authz] to define how "other protocols" meet the
> requirements in Section 5.
>
>     I certainly understand that there are a number of choices that
> implementations can make for various parts of the ACE framework. However,
> the framework does seem to be very clear that profiles have to define how
> communications security requirements of  [I-D.ietf-ace-oauth-authz] are
> met.  Even though other protocol combinations can meet the security
> requirements in Section 5 of  [I-D.ietf-ace-oauth-authz], the ACE framework
> requires that profiles define how these requirements will be met.  So the
> problem remains with the current profile only defining how communications
> security requirements are met for CoAP and DTLS but both the NEW: and OLD:
> wording would permit "other protocols" to be used under this profile
> without defining how the "other protocols" meet the security requirements
> in Section 5 of  [I-D.ietf-ace-oauth-authz].
>
>     Given the requirements of [I-D.ietf-ace-oauth-authz], it seems like
> any protocols allowed by a profile have to define how the framework
> communications security requirements are met when using the allowed
> protocols.
>
>     Sorry but it seems like including "other protocols" in a profile that
> have no ACE framework profile defined is a significant deviation from the
> MUST requirement of 6.2 of [I-D.ietf-ace-oauth-authz].
>
>     Regards,
>     Russ
>
>

-- 
Daniel Migault
Ericsson

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 11 Feb 2021 12:34:46 +0100

> number of libraries the client has to support.

The reason that this requirement on the profiles was included in the
framework is that the framework itself does not specify how
communication security is provided. For the security of the solution it
is important that the profiles fill this gap. I think that it is
important to emphasize this security requirement. I therefore prefer
Goeran's proposals:

Proposal 1 (Section 6.2):
OLD
  "Profiles MUST specify how communication security according
   to the requirements in Section 5 is provided."
NEW
"The requirements for communication security of profiles are specified
in Section 5."

Proposal 2 (Section 5):
OLD
"Profiles MUST specify a communication security protocol that provides
   the features required above."
NEW
"Profiles MUST specify at least one communication security protocol that
provides the features required above."

Viele Grüße
Steffi

---

From: Francesca Palombini <[email-masked]>
Date: Thu, 11 Feb 2021 15:02:55 +0000

Hi,

I am fine with Daniel's change to the DTLS profile (which wants to add motivation on why the DTLS profile is RECOMMENDED), and prefer Göran's formulation to the Ace framework. 

I had to think about it and figured out where the different interpretations come from, and hence what needs to be clarified:

Russ reads this sentence as: one (and only one) protocol MUST be specified *and used* between Client and AS.
I (and others) read this sentence as: (at least) one protocol fulfilling the security requirements MUST be specified in the profile. (and as a consequence: One and only one of these protocols specified in the profile MUST be used between client and AS)

I think Göran's modification clarifies the above, but hopefully Russ can let us know how to make his even clearer.

Francesca

On 11/02/2021, 12:35, "Stefanie Gerdes" <[email-masked]> wrote:

    Proposal 2 (Section 5):
    OLD

    Viele Grüße
    Steffi

---

From: Daniel Migault <[email-masked]>
Date: Thu, 11 Feb 2021 11:13:55 -0500

Hi,

Thanks for the feed back Francesca. We have discussed this issue during the
interim meeting, so I would encourage Olaf and Stefanie to propose some
text that reflected the discussion before pinging Russ.

Yours,
Daniel

On Thu, Feb 11, 2021 at 10:02 AM Francesca Palombini <
[email-masked]> wrote:

> Hi,
>
> I am fine with Daniel's change to the DTLS profile (which wants to add
> motivation on why the DTLS profile is RECOMMENDED), and prefer Göran's
> formulation to the Ace framework.
>
> I had to think about it and figured out where the different
> interpretations come from, and hence what needs to be clarified:
>
> I (and others) read this sentence as: (at least) one protocol fulfilling
> the security requirements MUST be specified in the profile. (and as a
> consequence: One and only one of these protocols specified in the profile
> MUST be used between client and AS)
>
> I think Göran's modification clarifies the above, but hopefully Russ can
> let us know how to make his even clearer.
>
> Francesca
>

-- 
Daniel Migault
Ericsson

---

From: Stefanie Gerdes <[email-masked]>
Date: Tue, 16 Feb 2021 16:15:53 +0100

Hi,

I propose that we use the following text for the ACE framework (as
originally proposed by Göran):

Section 6.2:
OLD

Section 5:
OLD

For the DTLS profile, I propose the following text:

OLD
"The use of CoAP and DTLS for this communication is REQUIRED in this
profile.  Other protocols (such as HTTP and TLS, or CoAP and OSCORE
[RFC8613]) will require specification of additional profile(s)."

NEW
"The use of CoAP and and DTLS for this communication is RECOMMENDED in
this profile. Other protocols fulfilling the security requirements
defined in Section 5 of [I-D.ietf-ace-oauth-authz] MAY be used instead."

additional explanation:

one proposal was to state as the reason for recommending DTLS that it
reduces the number of libraries the client has to support. But the
reason why the ACE framework requires that the profiles specify a
security protocol for the communication between C and AS is to provide
security for the data that is transmitted between these two parties.
Without a protocol that fulfills the requirements listed in the ACE
framework, the solution would not be secure. Requiring that the profiles
must specify at least one protocol ensures that implementers have an
idea how to implement the profile securely (instead of leaving them in
the dark about that). It is also nice if the number of libraries on the
client can be reduced, but I am not that comfortable with stating that
as the main the reason for recommending DTLS.

Viele Grüße
Steffi

---

From: Daniel Migault <[email-masked]>
Date: Tue, 16 Feb 2021 15:53:57 +0000

Hi Stefanie, 

Thanks, for the suggestion. I would like to propose a slight update to one sentence, but I see this moving in the right direction. 

Please find my comments, in line. 

Yours, 
Daniel

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Stefanie Gerdes
Sent: Tuesday, February 16, 2021 10:16 AM
To: Daniel Migault <[email-masked]>; Francesca Palombini <[email-masked]>
Cc: Göran Selander <goran.selander=[email-masked]>; Russ Mundy <[email-masked]>; Olaf Bergmann <[email-masked]>; [email-masked]
Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14

Hi,

I propose that we use the following text for the ACE framework (as originally proposed by Göran):

Section 6.2:
OLD

Section 5:
OLD
"Profiles MUST specify a communication security protocol that provides
   the features required above."
NEW
"Profiles MUST specify at least one communication security protocol that provides the features required above."

<mglt>
I have the impression that with MUST specify one expects a mandatory protocol to be provided. Would the following text be acceptable ?

NEW2:
"Profiles RECOMMENDs at least one communication security protocol that provides the features required above."
</mglt>

OLD
"The use of CoAP and DTLS for this communication is REQUIRED in this profile.  Other protocols (such as HTTP and TLS, or CoAP and OSCORE
[RFC8613]) will require specification of additional profile(s)."

NEW
"The use of CoAP and and DTLS for this communication is RECOMMENDED in this profile. Other protocols fulfilling the security requirements defined in Section 5 of [I-D.ietf-ace-oauth-authz] MAY be used instead."

additional explanation:

one proposal was to state as the reason for recommending DTLS that it reduces the number of libraries the client has to support. But the reason why the ACE framework requires that the profiles specify a security protocol for the communication between C and AS is to provide security for the data that is transmitted between these two parties.
Without a protocol that fulfills the requirements listed in the ACE framework, the solution would not be secure. Requiring that the profiles must specify at least one protocol ensures that implementers have an idea how to implement the profile securely (instead of leaving them in the dark about that). It is also nice if the number of libraries on the client can be reduced, but I am not that comfortable with stating that as the main the reason for recommending DTLS.

<mglt>
I agree that security was the main driver but it seems also to me that limiting the number of libraries was the reason of choosing that one - as opposed to another one. That said, I think the reason is rather obvious and may not need to be specified so I am fine with that text. 
</mglt>

Viele Grüße
Steffi

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 17 Feb 2021 14:51:31 +0100

Hi Daniel,

> "Profiles RECOMMENDs at least one communication security protocol that provides the features required above."

I don't understand it like that but I see your point. But I think
"RECOMMENDS" leaves too much wiggle room :). The profiles could then
omit the protocols completely, which I think is a bad idea. Implementers
should have at least one example how the communication between C and AS
is protected. Since we don't provide it in the framework we must have it
in the profiles. How about:

NEW3:
"Profiles MUST specify at least one communication security protocol that
provides the features required above as an example how the respective
communication can be secured."

Viele Grüße
Steffi

---

From: Daniel Migault <[email-masked]>
Date: Wed, 17 Feb 2021 16:16:05 +0000

Hi,

I think that could work for me. If the changes address the initial concerns, we may publish these changes in the coming days.

Yours,.
Daniel
________________________________
From: Stefanie Gerdes <[email-masked]>
Sent: Wednesday, February 17, 2021 8:51 AM
To: Daniel Migault <[email-masked]>; Daniel Migault <[email-masked]>; Francesca Palombini <[email-masked]>
Cc: Göran Selander <goran.selander=[email-masked]>; Russ Mundy <[email-masked]>; Olaf Bergmann <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14

Hi Daniel,

NEW3:

Viele Grüße
Steffi

---

From: Russ Mundy <[email-masked]>
Date: Thu, 18 Feb 2021 15:38:08 -0500

Hi Daniel & others,

Thanks for the continuing effort to make the documents more clear and understandable. 

I think that there may be a fairly fundamental difficulty understanding (possibly on my part) about the intended relationship between the ACE framework and profile documents.  It seems appropriate to me that the framework would define the overall requirements (especially security requirements) that implementers need to meet and profiles provide the ‘how’ for implementers so the result is secure, interoperable implementations potentially from multiple different implementers of the framework using a particular profile for that framework.

If I’m following the discussion correctly, the changes being proposed to the framework would only require a profile to define one ‘example (or description)’ definition that met the security requirements of the framework (even if it was the RECOMMENDED protocol set) but other protocol set(s) could be used (MAY) within the definition of a profile.  Including what amounts to unspecified protocol set(s) that do not define how they will meet security requirements of the framework will likely result in different implementations that comply with the profile but do not interoperate from either a protocol or a security basis (or both).

Regards,
Russ

> On Feb 17, 2021, at 11:16 AM, Daniel Migault <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi, 
> 
> From: Stefanie Gerdes <[email-masked] <mailto:[email-masked]>>
> To: Daniel Migault <[email-masked] <mailto:[email-masked]>>; Daniel Migault <[email-masked] <mailto:[email-masked]>>; Francesca Palombini <[email-masked] <mailto:[email-masked]>>
> Cc: Göran Selander <goran.selander=[email-masked] <mailto:goran.selander=[email-masked]>>; Russ Mundy <[email-masked] <mailto:[email-masked]>>; Olaf Bergmann <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>

---

From: Daniel Migault <[email-masked]>
Date: Thu, 18 Feb 2021 22:02:54 +0000

Hi Russ,

Thanks for the follow-up. I was waiting clearer agreement from eth WG before pinging you back. I think I agree with your understanding. My understanding is that the WG is willing to specify one way (RECOMMMEND) and not leave that unspecified while not preventing other configurations (MAY). This obviously results in implementation not following the RECOMMENDED way do not interoperate with those following these recommendations.

The question remains open on whether we should favor openness or inter-operability. I suppose that this will be raised at the IESG so we need to address this issue clearly.

Going back to the profiles, it would be good to understand what concrete deployment issues the two statements below would raise:

  *   OSCORE profile mandating the AS to support OSCORE and have the C <-> AS using OSCORE.
  *   DTLS profile mandating the AS to support DTLS and have the C <-> AS using DTLS.

Yours,
Daniel

________________________________
From: Russ Mundy <[email-masked]>
Sent: Thursday, February 18, 2021 3:38 PM
To: Daniel Migault <[email-masked]>
Cc: Russ Mundy <[email-masked]>; Stefanie Gerdes <[email-masked]>; Daniel Migault <[email-masked]>; Francesca Palombini <[email-masked]>; Göran Selander <goran.selander=[email-masked]>; Olaf Bergmann <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14

Hi Daniel & others,

Regards,
Russ

On Feb 17, 2021, at 11:16 AM, Daniel Migault <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Yours,.
Daniel
________________________________
From: Stefanie Gerdes <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, February 17, 2021 8:51 AM
To: Daniel Migault <[email-masked]<mailto:[email-masked]>>; Daniel Migault <[email-masked]<mailto:[email-masked]>>; Francesca Palombini <[email-masked]<mailto:[email-masked]>>
Cc: Göran Selander <goran.selander=[email-masked]<mailto:goran.selander=[email-masked]>>; Russ Mundy <[email-masked]<mailto:[email-masked]>>; Olaf Bergmann <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14

Hi Daniel,

NEW3:

Viele Grüße
Steffi

---

From: Göran Selander <[email-masked]>
Date: Mon, 22 Feb 2021 09:53:56 +0000

Hi Daniel and all,

It seems to me that there is no full consensus, so we probably have to inform the AD about the disagreement. However, we do seem to agree that we want to clarify some parts of the framework. Here is yet another proposal: 

Section 5:
OLD
"Profiles MUST specify a communication security protocol that provides the features required above."

NEW
"Profiles MUST specify a communication security protocol between client and RS that provides the features required above. Profiles MUST  specify a communication security protocol RECOMMENDED to be used between client and AS that provides the features required above. Profiles MUST  specify a communication security protocol RECOMMENDED to be used between RS and AS that provides the features required above."

Section 6.2:
OLD

If there is an unequivocal positive response from the WG then I may be able to publish a new version today.

Göran

On 2021-02-18, 23:03, "Daniel Migault" <daniel.migault=[email-masked]> wrote:

    Hi Russ, 

    Yours, 
    Daniel

    ________________________________________

    Hi Daniel & others, 

    Regards,
    Russ

    On Feb 17, 2021, at 11:16 AM, Daniel Migault <[email-masked]> wrote:

    Hi, 

    Yours,. 
    Daniel
    ________________________________________

    Hi Daniel,

    NEW3:

    Viele Grüße
    Steffi

---

From: Daniel Migault <[email-masked]>
Date: Mon, 22 Feb 2021 10:00:20 -0500

Thanks Gorand,

I think the text goes in the right direction. I am reading this as
the framework defines the protocol should be used between the client and AS
or client and RS. It is not mandatory, sure, but at that point, my
understanding is that it makes it clear that if you do not follow the
recommendations you are at your own risks and so that interoperability is
provided by this recommendation.
I am wondering if the framework prevents a profile to mandate a protocol ?.
I assume not

The one point I need to document in my shepherd is why recommendation is
sufficient to provide interoperability. I am happy to hear why the WG
thinks it is sufficient other than we want to leave that open.

It  would be good for me to hear from the WG and understand what concrete
deployment issues the two statements below would raise:
    * OSCORE profile mandating the AS to support OSCORE and have the C <->
AS using OSCORE.
    * DTLS profile mandating the AS to support DTLS and have the C <-> AS
using DTLS.

Yours,
Daniel

On Mon, Feb 22, 2021 at 4:53 AM Göran Selander <[email-masked]>
wrote:

> Hi Daniel and all,
>
> It seems to me that there is no full consensus, so we probably have to
> inform the AD about the disagreement. However, we do seem to agree that we
> want to clarify some parts of the framework. Here is yet another proposal:
>
> Section 5:
> OLD
> "Profiles MUST specify a communication security protocol between client
> and RS that provides the features required above. Profiles MUST  specify a
> communication security protocol RECOMMENDED to be used between client and
> AS that provides the features required above. Profiles MUST  specify a
> communication security protocol RECOMMENDED to be used between RS and AS
> that provides the features required above."
>
>
> Section 6.2:
> OLD
>     Thanks for the follow-up. I was waiting clearer agreement from eth WG
> before pinging you back. I think I agree with your understanding. My
> understanding is that the WG is willing to specify one way (RECOMMMEND) and
> not leave that unspecified while not preventing other configurations (MAY).
> This obviously results in implementation not following the RECOMMENDED way
> do not interoperate with those following these recommendations.
>
>     The question remains open on whether we should favor openness or
> inter-operability. I suppose that this will be raised at the IESG so we
> need to address this issue clearly.
>
>     Going back to the profiles, it would be good to understand what
> concrete deployment issues the two statements below would raise:
>
>     Cc: Russ Mundy <[email-masked]>; Stefanie Gerdes <[email-masked]>;
> Daniel Migault <[email-masked]>; Francesca Palombini <
> [email-masked]>; Göran Selander <goran.selander=
> [email-masked]>; Olaf Bergmann <[email-masked]>;
> [email-masked] <[email-masked]>
>     I think that there may be a fairly fundamental difficulty
> understanding (possibly on my part) about the intended relationship between
> the ACE framework and profile documents.  It seems appropriate to me that
> the framework would define the overall requirements (especially security
> requirements) that implementers need to meet and profiles provide the ‘how’
> for implementers so the result is secure, interoperable implementations
> potentially from multiple different implementers of the framework using a
> particular profile for that framework.
>
>     If I’m following the discussion correctly, the changes being proposed
> to the framework would only require a profile to define one ‘example (or
> description)’ definition that met the security requirements of the
> framework (even if it was the RECOMMENDED protocol set) but other protocol
> set(s) could be used (MAY) within the definition of a profile.  Including
> what amounts to unspecified protocol set(s) that do not define how they
> will meet security requirements of the framework will likely result in
> different implementations that comply with the profile but do not
> interoperate from either a protocol or a security basis (or both).
>
>     Regards,
>     Russ
>
>
>     I think that could work for me. If the changes address the initial
> concerns, we may publish these changes in the coming days.
>
>     Yours,.
>     Daniel
>     To: Daniel Migault <[email-masked]>; Daniel Migault <
> [email-masked]>; Francesca Palombini <
> [email-masked]>
>     Cc: Göran Selander <goran.selander=[email-masked]>;
> Russ Mundy <[email-masked]>; Olaf Bergmann <[email-masked]>;
> [email-masked] <[email-masked]>
>     > "Profiles MUST specify at least one communication security protocol
> that provides the features required above."
>     >
>     > <mglt>
>     > I have the impression that with MUST specify one expects a mandatory
> protocol to be provided. Would the following text be acceptable ?
>     >
>     > NEW2:
>     > "Profiles RECOMMENDs at least one communication security protocol
> that provides the features required above."
>     > </mglt>
>

-- 
Daniel Migault
Ericsson