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

Benjamin Kaduk <kaduk@mit.edu> Tue, 01 October 2019 03:13 UTC

Return-Path: <kaduk@mit.edu>
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 384F2120025; Mon, 30 Sep 2019 20:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 10yLRZGKxzmX; Mon, 30 Sep 2019 20:13:49 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 3180812006D; Mon, 30 Sep 2019 20:13:49 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x913DePN013512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Sep 2019 23:13:43 -0400
Date: Mon, 30 Sep 2019 20:13:40 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Jim Schaad <ietf@augustcellars.com>, "'Ludwig Seitz'" <ludwig.seitz@ri.se>
Cc: draft-ietf-ace-oauth-authz.all@ietf.org, ace@ietf.org
Message-ID: <20191001031340.GG6424@kduck.mit.edu>
References: <20190927015154.GY6424@kduck.mit.edu> <e1b6d4bf-81e4-a1c4-1aa6-3fb669083adf@ri.se> <026401d5751d$8325c690$897153b0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <026401d5751d$8325c690$897153b0$@augustcellars.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/IQFwS7aus9LLnYZwgy9Oxy7aVTQ>
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 03:13:51 -0000

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 :)

> * 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