Re: [secdir] Secdir review of draft-ietf-ace-oauth-params-06

Benjamin Kaduk <kaduk@mit.edu> Tue, 17 December 2019 22:02 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E92120044; Tue, 17 Dec 2019 14:02:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 da0Wt8piSuxN; Tue, 17 Dec 2019 14:02:02 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BEF712004D; Tue, 17 Dec 2019 14:02:02 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBHM1vHB013099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Dec 2019 17:01:59 -0500
Date: Tue, 17 Dec 2019 14:01:57 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Charlie Kaufman <charliekaufman@outlook.com>
Cc: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-ace-oauth-params.all@ietf.org" <draft-ietf-ace-oauth-params.all@ietf.org>
Message-ID: <20191217220157.GH81833@kduck.mit.edu>
References: <MWHPR04MB036776E5D9FF69796005E730DF540@MWHPR04MB0367.namprd04.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <MWHPR04MB036776E5D9FF69796005E730DF540@MWHPR04MB0367.namprd04.prod.outlook.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/eTXpd6VmqiiDbyBXzOP1YQ6W-lY>
Subject: Re: [secdir] Secdir review of draft-ietf-ace-oauth-params-06
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, 17 Dec 2019 22:02:06 -0000

Hi Charlie,

Thanks for the review!

On Fri, Dec 13, 2019 at 07:48:22AM +0000, Charlie Kaufman wrote:
> 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.
> 
> This document only exists because of a scheduling issue between the ACE and OAUTH working groups. The ACE working group needed some additional OAUTH extensions added more quickly that the OAUTH group could manage to do it. This document is intended to only exist until the OAUTH group can make the corresponding changes. As such, it really doesn't have security considerations beyond those in the document it modifies.
> 
> The security considerations section says (and I agree):
> 
> This document is an extension to [I-D.ietf-ace-oauth-authz]. All security considerations from that document apply here as well.
> 
> Some acronyms that were not defined (but this might be OK in the context of this being a modification to another document): AS, RS, CoAP, cnf, CBOR, pop, CWT
> 
> 
> A few typos / odd phrasing:
> 
> Abstract: whishes -> wishes
> Appendix A: possesion -> possession
> 
> >From Section 2:
> Note that the term "endpoint" is used here following its OAuth 2.0 [RFC6749] definition, which is to denote resources such as token and introspection at the AS and authz-info at the RS.
> 
> Really? The term "endpoint" refers to tokens and authz-info data structures? This seems unlikely.

Not data structures, but (HTTP/CoAP) resources -- "things you can POST to".

> Continuing in Section 2:
> The CoAP [RFC7252] definition, which is "An entity participating in the CoAP protocol" is not used in this specification.
> 
> Why is a definition that does not apply relevant to this document?

This document is at the intersection of two worlds: CoAP and OAuth.  Both
define "endpoint" but in contradictory ways.  Since at least one has to
lose, giving the reader a pretty explicit hint that they're wrong to use a
given definition seems to have value.  But maybe I'm in the rough; we'll
see :)

-Ben