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

[Ludwig Seitz <[e-mail]>]

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 <[e-mail]> 
>> Sent: Friday, September 27, 2019 12:03 AM To: Benjamin Kaduk
>> <[e-mail]>; [e-mail] Cc:
>> [e-mail] 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 [phone]