[OAUTH-WG] Multi-AS State Re-Use

[Daniel Fett]

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

[Guido Schmitz]

Hi all,

can anybody confirm that this is a new / undocumented attack?

Cheers,

Guido, Daniel, and Ralf

Post by Daniel Fett
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

[Nat Sakimura]

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

Post by Daniel Fett
Hi all,
can anybody confirm that this is a new / undocumented attack?
Cheers,
Guido, Daniel, and Ralf

Post by Daniel Fett
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
https://www.ietf.org/mailman/listinfo/oauth

[Anthony Nadalin]

STATE can be anything, it does not have to be a NONCE so changing this would cause issues at this time for existing deployments

From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Nat Sakimura
Sent: Monday, May 9, 2016 7:34 PM
To: Guido Schmitz <***@gtrs.de>; ***@ietf.org
Subject: Re: [OAUTH-WG] Multi-AS State Re-Use

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 <***@gtrs.de<mailto:***@gtrs.de>> wrote:
Hi all,

can anybody confirm that this is a new / undocumented attack?

Cheers,

Guido, Daniel, and Ralf

Post by Daniel Fett
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
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c2ee021209f2e4f77411908d3787b846f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=wLXM0gBBBuftxTsgW0nKOdYPce7WqbOxJKWf77FaJYw%3d>

[Daniel Fett]

Regardless of what state actually is, the documentation (also the one
for OIDC) should make clear that the same state should not be sent to
two different AS, and that a state issued for AS #1 should be invalid
for AS #2.

Post by Anthony Nadalin
STATE can be anything, it does not have to be a NONCE so changing this
would cause issues at this time for existing deployments
*Sent:* Monday, May 9, 2016 7:34 PM
*Subject:* Re: [OAUTH-WG] Multi-AS State Re-Use
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.

[Nat Sakimura]

Agreed. Also, pointing to OWASP guide or something for CSRF token may be
useful.

Post by Daniel Fett
Regardless of what state actually is, the documentation (also the one
for OIDC) should make clear that the same state should not be sent to
two different AS, and that a state issued for AS #1 should be invalid
for AS #2.

Post by Anthony Nadalin
STATE can be anything, it does not have to be a NONCE so changing this
would cause issues at this time for existing deployments
*Sent:* Monday, May 9, 2016 7:34 PM
*Subject:* Re: [OAUTH-WG] Multi-AS State Re-Use
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.

--
Informationssicherheit und Kryptografie
UniversitÀt Trier - Tel. [phone] - H436
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Jim Manico]

Well hey now.

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
is one of the more popular resources on CSRF at OWASP.

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) is
also pretty popular and points to a wide variety of resources on the topic.

If anyone sees any flaws in these or otherwise would like to help make
these better, please drop me a line. I serve on the OWASP board.

Aloha, Jim Manico

Post by Nat Sakimura
Agreed. Also, pointing to OWASP guide or something for CSRF token may
be useful.
Regardless of what state actually is, the documentation (also the one
for OIDC) should make clear that the same state should not be sent to
two different AS, and that a state issued for AS #1 should be invalid
for AS #2.

Post by Anthony Nadalin
STATE can be anything, it does not have to be a NONCE so

changing this

Post by Anthony Nadalin
would cause issues at this time for existing deployments
*Sent:* Monday, May 9, 2016 7:34 PM
*Subject:* Re: [OAUTH-WG] Multi-AS State Re-Use
As far as I am aware of, state was meant to be nonce. Replay

possibility

Post by Anthony Nadalin
etc. were known. It is probably a bad documentation that every

reviewers

Post by Anthony Nadalin
missed because they were assuming it.

--
Informationssicherheit und Kryptografie
Universität Trier - Tel. [phone] - H436
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
Trustee, Kantara Initiative
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth