[secdir] secdir review of draft-ietf-ace-dtls-authorize-14

Russ Mundy <mundy@tislabs.com> Tue, 19 January 2021 02:08 UTC

Return-Path: <mundy@tislabs.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4484A3A0F7F; Mon, 18 Jan 2021 18:08:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id KffbXcWXpNq3; Mon, 18 Jan 2021 18:08:25 -0800 (PST)
Received: from walnut.tislabs.com (walnut.tislabs.com []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3523A0C36; Mon, 18 Jan 2021 18:08:22 -0800 (PST)
Received: from nova.tislabs.com (unknown []) by walnut.tislabs.com (Postfix) with ESMTP id D4A0A28B003D; Mon, 18 Jan 2021 21:08:19 -0500 (EST)
Received: from [] (nova.tislabs.com []) by nova.tislabs.com (Postfix) with ESMTP id F3DE91F8051; Mon, 18 Jan 2021 21:08:16 -0500 (EST)
From: Russ Mundy <mundy@tislabs.com>
Content-Type: text/plain; charset=us-ascii
X-Mao-Original-Outgoing-Id: 632714893.8317111-de1a95e47afac8a31a437be01a721229
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
Message-Id: <4BED04D6-5BB6-4F7A-A0E5-3CC718E55169@tislabs.com>
Date: Mon, 18 Jan 2021 21:08:15 -0500
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ace-dtls-authorize.all@ietf.org
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/cvj5eZ44oQS2c8S0qQLuDkyBL3Y>
Subject: [secdir] secdir review of draft-ietf-ace-dtls-authorize-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jan 2021 02:08:28 -0000

Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)


I apologize for the lateness of the review but I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

The summary of the review is Ready with one issue:

The draft-ietf-ace-dtls-authorize document is well written and provides a very good profile for use of the ACE framework with a client and a resource server use CoAP [RFC7252] over DTLS version 1.2 [RFC6347] to communicate.  The document provides the necessary specification details to use Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) [I-D.ietf-ace-oauth-authz] with one single exception.

Since the document under review is a profile for [I-D.ietf-ace-oauth-authz], it must meet the requirements for a profile contained in [I-D.ietf-ace-oauth-authz].  Section 6.2 of [I-D.ietf-ace-oauth-authz] specifically requires that "Profiles MUST specify how communication security according to the requirements in Section 5 is provided." The document under review does provide this detail for use of CoAP and DTLS however the current wording of this profile document does not require that CoAP and DTLS be used for this profile. Quoting a part of 6. "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."  

Since use of other protocols (besides CoAP and DTLS) is clearly permitted by current wording and there is no information about how communication security will be provided by these other protocols, section 6 of this profile does not appear to meet the MUST requirement of 6.2 of [I-D.ietf-ace-oauth-authz].

The simplest resolution of this inconsistency appears to be to require use of CoAP and DTLS for compliance with this profile and revise the wording relating to the other currently listed protocols to define additional profile specifications.

For example, current wording: 
"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." 

could be changed to: 
"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)."

Another possible resolution of the inconsistency would be to include additional details in this specification to define how communication security requirements will be met by these other protocols.