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 protected]
on behalf of [email protected]> wrote:
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 protected]>
Date: Sat, 6 Feb 2021 16:01:00 -0500
Cc: Russ Mundy <[email protected]>,
Daniel Migault <[email protected]>,
"[email protected]"
<[email protected]>
To: Olaf Bergmann <[email protected]>
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 protected]> wrote:
>
> Hi Russ,
>
> On 2021-01-19, Olaf Bergmann <[email protected]> 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 --------------------
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
