Re: [OAUTH-WG] Reuse of "state" across different AS in draft-bradley-oauth-jwt-encoded-state-08

[Daniel Fett <[e-mail]>]

Am 18.05.2018 um 18:20 schrieb John Bradley:
> I am not against having "as" as REQUIRED.
>
> While we are at it should we recommend that rfp be single use?  
If the state JWT is *not* signed and the client has no other means to
check the integrity of the JWT (e.g., by storing a copy in the browser's
session), rfp MUST be single use, where single use means that once a new
authorization request has been sent, all old "rfp" values (for that
browser session) become invalid.
(Rationale: The state reuse attack across AS would still be possible,
since an attacker could just replace the "as" value in an unsigned JWT.)

If the state JWT is signed and "as" is contained in the JWT, rfp does
not need to be single use in this sense.

To prevent defense-in-depth against the usage of leaked of state values,
in both cases, a state value that has once been accepted at the
redirection endpoint SHOULD be invalidated for future uses. In the the
case of an unsigned JWT, this means that a specific rfp value SHOULD
only be accepted once. If the JWT is signed, it would be sufficient to
memorize the hashes of used JWTs or their jti values, and decline JWTs
with the same hash/jti. (SHOULD since this is impossible for stateless
clients.)

(Overall, it seems like not signing state JWTs is not a good idea.)

>
> This draft hangs around as a ID and probably is not read by most
> people.  
>
> We may also want to mention it in security topics if we haven't. 
I will check the status there.
>
> I need to update this in the next couple of weeks to keep it from
> expiring anyway. 
I took a cursory look at the draft and I see two more issues:

(1)

> The "as" claim if present MUST correspond to the URI endpoint
registered as the "redirect_uri" for that AS.

This wording is not sufficient:
- The AS must be the expected AS (if there are means to check that, for
example the browser session).
- The redirection URI on which the authorization response was actually
received matches the "as" value.

(2)

> The client parses it as a JWT.  It then verifies the signature of the
JWT (if signed)

The client should check the signature if it expects the JWT to be
signed, not only if the received JWT is signed. I may be nitpicking
here, but developers should not be lead to believe that "if
signed(received_jwt): check_sig(received_jwt)" would be a good
implementation choice.

- Daniel

-- 
SEC - Institute of Information Security
University of Stuttgart
Phone [phone]
Universitätsstraße 38 - 70569 Stuttgart - Room 2.434