As far as I am aware of, state was meant to be nonce. Replay possibility etc. were known. It is probably a bad documentation that every reviewers missed because they were assuming it.
Best, Nat On Mon, May 9, 2016 at 20:14 Guido Schmitz <[email protected]> wrote: > Hi all, > > can anybody confirm that this is a new / undocumented attack? > > Cheers, > > Guido, Daniel, and Ralf > > On 22.04.2016 16:23, Daniel Fett wrote: > > Hi all, > > > > Besides the state leakage attack we found that another important fact > > regarding state is underspecified: Each state value should only be > > used for one run of the protocol, in particular, each AS should see a > > different state in multi-AS settings. Clients might be tempted to > > generate state once and then re-use each time a user wants to > > authorize. > > > > If state is re-used, given a setup where one Client allows users to > > authorize using two AS, a potentially malicious AS learns the state > > value that is valid for authorization at an honest AS. I.e., each AS > > can mount a CSRF attack on the user using the other AS. > > > > Just as the attack in the other mail, this is not a big deal in > > practice, but should be discussed somewhere. > > > > Cheers, > > Daniel, Guido, and Ralf > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura Chairman of the Board, OpenID Foundation Trustee, Kantara Initiative
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
