Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12

Seitz Ludwig <ludwig.seitz@combitech.se> Mon, 03 August 2020 06:21 UTC

Return-Path: <ludwig.seitz@combitech.se>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231943A0B8D; Sun, 2 Aug 2020 23:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 dNTuvkbYaKl5; Sun, 2 Aug 2020 23:21:53 -0700 (PDT)
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 ED25B3A0B8C; Sun, 2 Aug 2020 23:21:51 -0700 (PDT)
Received: from mailhub2.air.saab.se ([136.163.213.5]) by weald.air.saab.se (8.14.4/8.14.4) with ESMTP id 0736LjbU015082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Aug 2020 08:21:45 +0200
DKIM-Filter: OpenDKIM Filter v2.11.0 weald.air.saab.se 0736LjbU015082
Received: from corpappl16254.corp.saab.se (corpappl16254.corp.saab.se [10.12.13.174]) by mailhub2.air.saab.se (8.13.8/8.13.8) with ESMTP id 0736LcTw016490 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Aug 2020 08:21:38 +0200
Received: from corpappl16595.corp.saab.se (10.12.12.127) by corpappl16254.corp.saab.se (10.12.13.174) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 3 Aug 2020 08:21:38 +0200
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.1979.003; Mon, 3 Aug 2020 08:21:38 +0200
From: Seitz Ludwig <ludwig.seitz@combitech.se>
To: Benjamin Kaduk <kaduk@mit.edu>, Paul Kyzivat <pkyzivat@alum.mit.edu>
CC: "draft-ietf-ace-dtls-authorize.all@ietf.org" <draft-ietf-ace-dtls-authorize.all@ietf.org>, General Area Review Team <gen-art@ietf.org>, "hannes.tschofenig@arm.com" <hannes.tschofenig@arm.com>
Thread-Topic: Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12
Thread-Index: AQHWXgqUDpsvbdblRUiJuHuQ7Wzh46kbta4AgAFWhQCAATjigIAHurYQ
Date: Mon, 03 Aug 2020 06:21:38 +0000
Message-ID: <3616e441e6e54b8eb6380ff93646b848@combitech.se>
References: <8c2725a3-f89f-7ea1-dda9-681edd463a32@alum.mit.edu> <20200727191052.GI41010@kduck.mit.edu> <74ae7beb-61f3-6ff3-fa36-0b7e0f311558@alum.mit.edu> <20200729101639.GA92412@kduck.mit.edu>
In-Reply-To: <20200729101639.GA92412@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.211]
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: 0736LcTw016490
X-Saab-MailScanner: Found to be clean
X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.5, required 5, ALL_TRUSTED -1.00, KAM_NUMSUBJECT 0.50)
X-Saab-MailScanner-From: ludwig.seitz@combitech.se
X-Saab-MailScanner-Watermark: 1597040499.12892@Kv95TskSGQINKKtSY1mS3Q
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald.air.saab.se [136.163.212.3]); Mon, 03 Aug 2020 08:21:45 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/eKXqAXXjQMzLL4ap0brE6xWwKBI>
X-Mailman-Approved-At: Mon, 03 Aug 2020 05:22:31 -0700
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2020 06:21:56 -0000

> >> * Also in section 3.3.1:
> >>
> >>      ... This
> >>      specification assumes that the access token is a PoP token as
> >>      described in [I-D.ietf-ace-oauth-authz] unless specifically stated
> >>      otherwise.
> >>
> >> I think "assumes ... unless" should be "MUST ... unless".
> > 
> > My understanding is that this is just talking about the text in the 
> > document itself.  But as far as I remember we always require PoP 
> > tokens, so this could just be removed.
> 
> It gets simpler if you always require PoP tokens. Does it state that 
> normatively somewhere?
> 
> The "unless" construct opens a can of worms about how things are to 
> work in that case.

Hmm, I didn't find a clear and unambiguous statement in a quick check.
Similar language about "in this document the access token is assumed to be a PoP token unless specified otherwise" in the core framework document, draft-ietf-ace-oauth-authz.  But that document uses "access token" some 130-odd times, and while I didn't see any mention of non-proof-of-possession in there, I may have missed one.  (There is discussion of not using symmetric proof-of-possession keys in a group-audience context, which is supposed to mean use asymmetric proof of possesion keys in that case.)

Assuming that I remember correctly (and the WG should correct me if I'm wrong), it might be easiest to change both this document and the core framework to flatly assert that PoP tokens are always required.


[LS] I'm not convinced this would be a good resolution, as this will get us some pushback from the OAuth people, who want to be able to support use cases with bearer tokens (I'm Cc-ing Hannes for a more in-depth discussion).


 /Ludwig