Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24

Ludwig Seitz <ludwig.seitz@ri.se> Tue, 01 October 2019 08:50 UTC

Return-Path: <ludwig.seitz@ri.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 6A9CE120125; Tue, 1 Oct 2019 01:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com
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 gkMXdn_wvXD2; Tue, 1 Oct 2019 01:50:28 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60078.outbound.protection.outlook.com [40.107.6.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9136120118; Tue, 1 Oct 2019 01:50:27 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W7IN4o4FaI3laUhEYXqmlR2sKANCUu7rgpwCDU9mRuwOZyUjHLpW9FjWj2grOQxWH9Mez+9szc8nodqPFGWEb5lhPKT0VoIl5B4XHA8JYz0z0ceVEg2Ei/rvpdkBLZyhUsdrJvAQ/Dl7DVAobZB8iy+QCJsDytV3vcOcT4jXZYH6FZIR/eKSu2YELO/XiE308oeXwShzQTVWiM3vKNaAB6T37uqnH44zGrmq0uHijMZYPkuaOu+DtH7xISa5RW5i3APlTrJWrG3NA6D3G4+d3ioKyvsmra/5B2kDLFs7rSmxCDKEAJBXKFKsaLtcum9/DkPcpbIPskIFXjiMnM1JFg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8LlxAE/x11Bd5jtEH82hVeSKoFuK0Ojrv1yB0OZgr4o=; b=cbNldm4OVB9V/Iyehzm9fu3XJm89Lm6jqX8rpBB5Lis5vyrBp0ISRQZL5phIyC1Vd0qFS0lWhEIaspx3PAoqtdClY7CUIjl2FNnsvOH7CZho1uMihaJmjUq9JsJrqkvMpxQPw7YC6j/mOuEkpWMqPu4LkCwXAfQvYOJ77aukfsDY5BmBBfUmzDPv2MzZnIse7RW1prqxEZtJKHwD29E+dzSKBrUPezUBJbKkkZBQ9Ctqm8YkwZkjRzRt3ufDNzd5mLdmgacUoTxlPNw5eyNS0VZPH49ua9PLHvcuOhO1yU5fvj1l84Pe9ggv1riYIpx9QEofaRiKa+XWpXdBD6Q1IQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 194.218.146.197) smtp.rcpttodomain=ietf.org smtp.mailfrom=ri.se; dmarc=pass (p=none sp=none pct=100) action=none header.from=ri.se; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector2-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8LlxAE/x11Bd5jtEH82hVeSKoFuK0Ojrv1yB0OZgr4o=; b=Qcqi67RW5HC0IbgjXagmJxNvhig3Qkjw/WmM4EquaDIs255z0Wxyn7VBgQDVyOBB1dcKhK1aRukwKPBLwYxkPUBnciPjTo+8w+K9t8BqDcVSqdwTinYYE9cW3kL1pIpBYYPVHw/+EXv5n9MfpiiLTCNubo2ZEoiQ4cHGewakaDg=
Received: from AM5P189CA0003.EURP189.PROD.OUTLOOK.COM (2603:10a6:206:15::16) by HE1P18901MB0201.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:95::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.17; Tue, 1 Oct 2019 08:50:23 +0000
Received: from HE1EUR02FT031.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::200) by AM5P189CA0003.outlook.office365.com (2603:10a6:206:15::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2305.20 via Frontend Transport; Tue, 1 Oct 2019 08:50:23 +0000
Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=ri.se;
Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se;
Received: from mail.ri.se (194.218.146.197) by HE1EUR02FT031.mail.protection.outlook.com (10.152.10.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2305.15 via Frontend Transport; Tue, 1 Oct 2019 08:50:23 +0000
Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1779.2; Tue, 1 Oct 2019 10:50:22 +0200
To: Benjamin Kaduk <kaduk@mit.edu>, Jim Schaad <ietf@augustcellars.com>
CC: <draft-ietf-ace-oauth-authz.all@ietf.org>, <ace@ietf.org>
References: <20190927015154.GY6424@kduck.mit.edu> <e1b6d4bf-81e4-a1c4-1aa6-3fb669083adf@ri.se> <026401d5751d$8325c690$897153b0$@augustcellars.com> <20191001031340.GG6424@kduck.mit.edu>
From: Ludwig Seitz <ludwig.seitz@ri.se>
Message-ID: <b174fd0d-5441-5f35-8da1-01461207b704@ri.se>
Date: Tue, 1 Oct 2019 10:50:22 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <20191001031340.GG6424@kduck.mit.edu>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020208010900090102070803"
X-Originating-IP: [10.100.0.158]
X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(346002)(136003)(376002)(199004)(189003)(13464003)(53754006)(26005)(8676002)(40036005)(44832011)(65806001)(16526019)(126002)(11346002)(2616005)(2906002)(486006)(476003)(446003)(186003)(36756003)(70586007)(22746008)(65956001)(33964004)(86362001)(70206006)(31696002)(76176011)(386003)(305945005)(356004)(336012)(53546011)(7736002)(6246003)(568964002)(235185007)(5024004)(229853002)(54906003)(22756006)(4326008)(71190400001)(316002)(6306002)(2171002)(478600001)(31686004)(14444005)(106002)(3846002)(16576012)(966005)(8936002)(110136005)(16586007)(81156014)(58126008)(81166006)(6116002)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1P18901MB0201; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 10b9d2ff-e8ad-4a68-ddc1-08d7464c65c5
X-MS-TrafficTypeDiagnostic: HE1P18901MB0201:
X-Microsoft-Antispam-PRVS: <HE1P18901MB0201263DC362DAD9EEC78BC1829D0@HE1P18901MB0201.EURP189.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:5236;
X-Forefront-PRVS: 0177904E6B
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: D/b18RiZgXbTqDqXhixC4c6YDIJhNicvT/AdyMLAB/j+oQe9fbOZCxVSAE+n53WMsjOAxObHujnXsK1qMSK4uUHbD6xc7Z+CRC3U/fCkTWJhTCOF8UpPDSep/ipRKQU2QYOlzG8TROPfBzxgQswthzumihyIfG0gOAaMxX/dz3HIwERbX8vVO+5IlLmOwCbHerYQgY4Fer3T1UKAbYxZGNIrb86F7dRG27Ootf6kl/jPFGpMwL+Po2YLcz5lv6PyjE+93g9JZKL+n1FRCcjQkiaP6YUl/royzx+XSoMcZmxNvqvTLeAqZo9DD8WQCJnATzgTAoXtn6P0PeBIwrVUQcKJDMB611byz8p5NMwrfepWME9Gm27nQME20O0/bVBcpphvPP0RPqhHH+1mJagALP02Fojnq5osmbU781dnBfM=
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Oct 2019 08:50:23.4549 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 10b9d2ff-e8ad-4a68-ddc1-08d7464c65c5
X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P18901MB0201
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/iSMA2ddR_e4pI1ERdj_qmuF0c_E>
Subject: Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24
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, 01 Oct 2019 08:50:31 -0000

On 01/10/2019 05:13, Benjamin Kaduk wrote:
> On Fri, Sep 27, 2019 at 03:22:45AM -0700, Jim Schaad wrote:
>> 
>> 
>> -----Original Message----- From: Ludwig Seitz <ludwig.seitz@ri.se>; 
>> Sent: Friday, September 27, 2019 12:03 AM To: Benjamin Kaduk
>> <kaduk@mit.edu>;; draft-ietf-ace-oauth-authz.all@ietf.org Cc:
>> ace@ietf.org Subject: Re: AD review of
>> draft-ietf-ace-oauth-authz-24
>> 
>> On 27/09/2019 03:51, Benjamin Kaduk wrote:
>>> Hi all,
>>> 
>>> The length of this review notwithstanding, this document is
>>> generally in good shape -- there's a bunch of localized items to
>>> tighten up, and we can flesh out the security considerations some
>>> more, but nothing too drastic should be needed.  Perhaps the most
>>> far-reaching changes needed will be to rename the "profile"
>>> claim, since that has already been allocated to OIDC Core for a
>>> very different usage.  I also made a pull request with a bunch of
>>> trivial editorial stuff that's easier to fix than describe how to
>>> fix, up at https://github.com/ace-wg/ace-oauth/pull/175 .
>>> 
>> 
>> I have a non-trivial comment on your pull request: In appendix B
>> we summarize the steps taken by an RS to process a freshly received
>> access token. You changed the suggested sequence from:
> 
> First off, thank you for spotting it and bringing the discussion
> here!  I'm sorry that you had to do so; I wasn't trying to sneak it
> in :)
> 

I didn't think so.

>> * Verify the token is from a recognized AS. * Verify that the token
>> applies to this RS. * Check that the token has not expired (if the
>> token provides expiration information). * Check the token's
>> integrity. * Store the token so that it can be retrieved in the
>> context of a matching request.
>> 
>> To
>> 
>> * Verify the token is from a recognized AS. * Check the token's
>> integrity. * Verify that the token applies to this RS. * Check that
>> the token has not expired (if the token provides expiration 
>> information). * Store the token so that it can be retrieved in the
>> context of a matching request.
>> 
>> 
>> I don't think this is a big deal, but I put the integrity check
>> later for a good reason (or so I believe): The integrity check is
>> a potentially expensive cryptographic operation. Checking that the
>> token applies to the RS is a matter of checking the audience claim,
>> and checking that the token is not expired is a matter of comparing
>> two timestamps, I consider both to be computationally much lighter
>> and therefore quicker to execute. A failure of any of those two may
>> make it unnecessary to verify the token integrity.
>> 
>> BUT! My suggested sequence only works if the token is signed or
>> MACed and not if it is encrypted. If the token is encrypted the
>> AEAD integrity check (and decryption) is necessarily the first
>> processing step.
>> 
>> Any ideas how to resolve this gracefully (i.e. without adding a
>> large amount of text) are most welcome.
>> 
>> [JLS] I normally get out of this type of problem by saying "The
>> order of the steps is not normative, any process which produces an
>> equivalent result can be used."  And then you can add a comment
>> about switching the two steps for signed items.
> 
> That seems like a reasonable approach.  FWIW, my thinking was that 
> signature validation is a great way to toss out a bunch of malformed
> input, and we tend to do it first in non-constrained environments,
> but I can see the tradeoff running the other way in some cases.
> 
> -Ben
> 

I'll formulate some text to capture this. It's an appendix that is not 
supposed to be normative anyways, rather it's intention was to serve a 
guideline to help implementers.

/Ludwig



-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51