On Fri, Sep 27, 2019 at 03:22:45AM -0700, Jim Schaad wrote: > > > -----Original Message----- > From: Ludwig Seitz <[email protected]> > Sent: Friday, September 27, 2019 12:03 AM > To: Benjamin Kaduk <[email protected]>; [email protected] > Cc: [email protected] > 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 _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
