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

Olaf Bergmann <bergmann@tzi.org> Mon, 08 February 2021 17:33 UTC

Return-Path: <bergmann@tzi.org>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D13C3A13AA for <ace@ietfa.amsl.com>; Mon, 8 Feb 2021 09:33:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMZTIJBoz8Gy for <ace@ietfa.amsl.com>; Mon, 8 Feb 2021 09:33:05 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C573A126C for <ace@ietf.org>; Mon, 8 Feb 2021 09:33:04 -0800 (PST)
Received: from wangari.tzi.org (p5b36f033.dip0.t-ipconnect.de [91.54.240.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4DZClz3hrVzybM; Mon, 8 Feb 2021 18:33:03 +0100 (CET)
From: Olaf Bergmann <bergmann@tzi.org>
To: Francesca Palombini <francesca.palombini@ericsson.com>, Daniel Migault <daniel.migault@ericsson.com>
Cc: ace@ietf.org
Date: Mon, 08 Feb 2021 18:33:03 +0100
Message-ID: <871rdqihww.fsf@wangari>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/02OvUFacXK6or8hAl0PSnVWQKoY>
Subject: [Ace] [Russ Mundy] Re: secdir review of draft-ietf-ace-dtls-authorize-14
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2021 17:33:11 -0000

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 <mundy@tislabs.com>
Date: Sat, 6 Feb 2021 16:01:00 -0500
Cc: Russ Mundy <mundy@tislabs.com>om>,
        Daniel Migault <daniel.migault@ericsson.com>om>,
        "draft-ietf-ace-dtls-authorize.all@ietf.org" <draft-ietf-ace-dtls-authorize.all@ietf.org>
To: Olaf Bergmann <bergmann@tzi.org>

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 <bergmann@tzi.org> wrote:
> 
> Hi Russ,
> 
> On 2021-01-19, Olaf Bergmann <bergmann@tzi.org> 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 --------------------