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

Seitz Ludwig <ludwig.seitz@combitech.se> Tue, 07 January 2020 20:17 UTC

Return-Path: <ludwig.seitz@combitech.se>
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 BA2CA120077; Tue, 7 Jan 2020 12:17:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 4RXT9wuLycYN; Tue, 7 Jan 2020 12:17:01 -0800 (PST)
Received: from weald.air.saab.se (weald.air.saab.se [136.163.212.3]) (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 D843E12010C; Tue, 7 Jan 2020 12:17:00 -0800 (PST)
Received: from mailhub1.air.saab.se ([136.163.213.4]) by weald.air.saab.se (8.14.4/8.14.4) with ESMTP id 007KGw1a030920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Jan 2020 21:16:58 +0100
Received: from corpappl16596.corp.saab.se (corpappl16596.corp.saab.se [10.12.12.128]) by mailhub1.air.saab.se (8.13.8/8.13.8) with ESMTP id 007KGiTD024527 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Jan 2020 21:16:44 +0100
Received: from corpappl16595.corp.saab.se (10.12.12.127) by corpappl16596.corp.saab.se (10.12.12.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Tue, 7 Jan 2020 21:16:44 +0100
Received: from corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f]) by corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f%4]) with mapi id 15.01.1847.003; Tue, 7 Jan 2020 21:16:44 +0100
From: Seitz Ludwig <ludwig.seitz@combitech.se>
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>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: Secdir review of draft-ietf-ace-oauth-params-06
Thread-Index: AQHVtSWsVML0EqYNLk+qsAH30Mo1kKffwt9Q
Date: Tue, 07 Jan 2020 20:16:44 +0000
Message-ID: <2a0e711297c642b49413d7d749e619b4@combitech.se>
References: <MWHPR04MB036776E5D9FF69796005E730DF540@MWHPR04MB0367.namprd04.prod.outlook.com> <20191217220157.GH81833@kduck.mit.edu>
In-Reply-To: <20191217220157.GH81833@kduck.mit.edu>
Accept-Language: en-SE, sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.12.13.198]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Saab-MailScanner-Information: Please contact the ISP for more information
X-Saab-MailScanner-ID: 007KGiTD024527
X-Saab-MailScanner: Found to be clean
X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.498, required 5, ALL_TRUSTED -1.00, KAM_NUMSUBJECT 0.50, SURBL_BLOCKED 0.00, URIBL_BLOCKED 0.00)
X-Saab-MailScanner-From: ludwig.seitz@combitech.se
X-Saab-MailScanner-Watermark: 1579033004.95031@Rqw2G2HARVI185TIGoWbSw
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald.air.saab.se [136.163.212.3]); Tue, 07 Jan 2020 21:16:58 +0100 (CET)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/F2bSFZ6wcg1LISpbC1bbIUbCshE>
Subject: Re: [Ace] Secdir review of draft-ietf-ace-oauth-params-06
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: Tue, 07 Jan 2020 20:17:09 -0000

Hello Charlie,

Thank you for the review, sorry for the tardive reply (things got a bit chaotic due to an affiliation change on my part). The -10 version here: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params addresses your comments given the additional explanations by Ben.

Please confirm if this satisfies your requested changes.

Regards,

Ludwig


-----Original Message-----
From: Benjamin Kaduk <kaduk@mit.edu> 
Sent: den 17 december 2019 23:02
To: Charlie Kaufman <charliekaufman@outlook.com>
Cc: secdir@ietf.org; iesg@ietf.org; draft-ietf-ace-oauth-params.all@ietf.org
Subject: Re: Secdir review of draft-ietf-ace-oauth-params-06

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