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

[Daniel Migault <[e-mail]>]

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


-- 
Daniel Migault
Ericsson