[Ace] PoP tokens, mandatory or not in ACE?

Seitz Ludwig <ludwig.seitz@combitech.se> Tue, 04 August 2020 06:11 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 5A2DA3A0EA3 for <ace@ietfa.amsl.com>; Mon, 3 Aug 2020 23:11:42 -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 gf4kfeQ3qF9f for <ace@ietfa.amsl.com>; Mon, 3 Aug 2020 23:11:40 -0700 (PDT)
Received: from weald2.air.saab.se (weald2.air.saab.se [136.163.212.4]) (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 122D13A0EA1 for <ace@ietf.org>; Mon, 3 Aug 2020 23:11:38 -0700 (PDT)
Received: from mailhub2.air.saab.se ([136.163.213.5]) by weald2.air.saab.se (8.14.4/8.14.4) with ESMTP id 0746BZlq012733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ace@ietf.org>; Tue, 4 Aug 2020 08:11:36 +0200
DKIM-Filter: OpenDKIM Filter v2.11.0 weald2.air.saab.se 0746BZlq012733
Received: from corpappl16349.corp.saab.se (corpappl16349.corp.saab.se [10.12.12.112]) by mailhub2.air.saab.se (8.13.8/8.13.8) with ESMTP id 0746BVEC014004 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <ace@ietf.org>; Tue, 4 Aug 2020 08:11:31 +0200
Received: from corpappl16595.corp.saab.se (10.12.12.127) by corpappl16349.corp.saab.se (10.12.12.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Tue, 4 Aug 2020 08:11:31 +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; Tue, 4 Aug 2020 08:11:30 +0200
From: Seitz Ludwig <ludwig.seitz@combitech.se>
To: "ace@ietf.org" <ace@ietf.org>
Thread-Topic: PoP tokens, mandatory or not in ACE?
Thread-Index: AdZqJCyUezTBkcwySvuFA47tyavPMw==
Date: Tue, 04 Aug 2020 06:11:30 +0000
Message-ID: <cdcf6a6212b1441fb33a579173312634@combitech.se>
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: 0746BVEC014004
X-Saab-MailScanner: Found to be clean
X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.5, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_05 -0.50)
X-Saab-MailScanner-From: ludwig.seitz@combitech.se
X-Saab-MailScanner-Watermark: 1597126291.59369@onfKwMf66raBq8obxPRtPg
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald2.air.saab.se [136.163.212.4]); Tue, 04 Aug 2020 08:11:36 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/ddtl8a4fmvEdXhEWc3HQtv6RQgo>
Subject: [Ace] PoP tokens, mandatory or not in ACE?
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, 04 Aug 2020 06:11:42 -0000

Hello ACE,

As a follow-up on a discussion between the authors and the Gen-ART Last Call reviewer we have the following issue I'd like to bring to the list to give you the occasion to comment on our proposed solution:

> * In the previously mentioned paragraph in 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.
>
> The "unless specifically stated otherwise" is too vague to be normative. 
> How would the alternative be indicated? Is this an escape hatch for future extensions? If so, it needs more work to make that clear and to open a path for that
>  future work.

In response, Ben Kaduk suggested to make PoP tokens mandatory in both the framework and the profiles. I objected saying that there may be legitimate use cases for bearer tokens in ACE. Steffi made the following suggestion, which both Ben and me think is the best way forward:

> Since no alternatives to PoP tokens are mentioned in the DTLS profile, I would change this to: "This specification implements access tokens as proof-of-possession 
> tokens".
>
> Maybe the framework may add that a profile that uses a different token type must specify how this would work.

If you disagree with this approach please join the discussion.

Regards,

Ludwig

--
Ludwig Seitz
Infrastructure Security Analyst 
Combitech AB