-----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:
* 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.
Regards,
Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
