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

Ludwig Seitz <> Tue, 01 October 2019 08:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A9CE120125; Tue, 1 Oct 2019 01:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gkMXdn_wvXD2; Tue, 1 Oct 2019 01:50:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A9136120118; Tue, 1 Oct 2019 01:50:27 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; 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;; 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; 1; spf=pass (sender ip is; dmarc=pass (p=none sp=none pct=100) action=none; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 (2a01:111:f400:7e05::200) by (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;; dkim=none (message not signed) header.d=none;; dmarc=pass action=none;
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Received: from ( by ( 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 [] ( by ( 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 <>, Jim Schaad <>
CC: <>, <>
References: <> <> <026401d5751d$8325c690$897153b0$> <>
From: Ludwig Seitz <>
Message-ID: <>
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: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020208010900090102070803"
X-Originating-IP: []
X-ClientProxiedBy: ( To (
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; 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;; 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-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=[]; Helo=[]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P18901MB0201
Archived-At: <>
Subject: Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 
>> Sent: Friday, September 27, 2019 12:03 AM To: Benjamin Kaduk
>> <>du>; Cc:
>> 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 .
>> 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 Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51