Thanks On Sat, May 19, 2018, 3:09 PM Daniel Fett <daniel.f...@sec.uni-stuttgart.de> wrote:
> 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 +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
