I am not against having "as" as REQUIRED. While we are at it should we recommend that rfp be single use?
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 need to update this in the next couple of weeks to keep it from expiring anyway. John B. From: Daniel Fett Sent: Friday, May 18, 3:46 PM Subject: [OAUTH-WG] Reuse of "state" across different AS in draft-bradley-oauth-jwt-encoded-state-08 To: oauth@ietf.org Hi all, Looking at draft-bradley-oauth-jwt-encoded-state-08, I see in Section 2 (https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-08#section-2) that all contents of the JWT that would bind the specific state value to the AS are optional. This means that the following attack is possible (we described this attack in our OAuth paper [0], Section 5.1, albeit very briefly): Precondition: A client that supports multiple AS (with one being an attacker-controlled AS, let's call it A-AS). 1. An honest user tries to authorize using A-AS, the attacker receives the value of "state" which is bound to the honest user's session with the client. 2. A-AS aborts the authorization (e.g., by redirecting the user back to the client's web site without any parameters). 3. The user starts a new authorization flow with an honest AS (H-AS). Since the state JWT is not bound to the AS selected by the user, the state value generated in (1.) will likely be valid for the login flow started in (3.). The attacker therefore knows a valid state value and can mount a CSRF attack (which was supposed to be prevented by using state). Solution: Always bind state to the chosen AS, i.e., make the "as" part of the JWT mandatory -or- use some other mechanism on the client (if the client is stateful) to invalidate the old state value. If we agree that this is problematic, I think this should be changed in draft-bradley-oauth-jwt-encoded-state and should at least briefly be discussed in the security topics document (I will be happy to write a section for the latter). - Daniel [0] https://sec.uni-stuttgart.de/_media/publications/FettKuestersSchmitz-TR-OAuth-2016.pdf -- SEC - Institute of Information Security University of Stuttgart Phone +49 711 685 88468 Universitätsstraße 38 - 70569 Stuttgart - Room 2.434
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
