Hi Torsten, > We are discussing TLS right now as a mean to prevent > impersonation of the end-user's session on the client > site. Correct? It's definitely a good advice to protect > session from being highjacked that way. But I'm wondering > whether this really belongs into the scope of OAuth? > > BTW: It's covered in > http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.4.1.6.
I'm not sure you undertand the attack. In the section 4.4.1.6 that you reference you propose the following countermeasure: > o The authorization server shall require the client to authenticate > with a secret, so the binding of the authorization code to a > certain client can be validated in a reliable way (see > Section 5.2.4.4). This is not a countermeasure. CLIENT AUTHENTICATION DOES NOTHING TO MITIGATE THE ATTACK. You should read again the attack descriptions I described in the discussion we had back in early January: http://www.ietf.org/mail-archive/web/oauth/current/msg04894.html http://www.ietf.org/mail-archive/web/oauth/current/msg04900.html and those I sent recently: http://www.ietf.org/mail-archive/web/oauth/current/msg04894.html and the attack scneraio that George Fletcher described: http://www.ietf.org/mail-archive/web/oauth/current/msg05825.html The security considerations section that you have just proposed fails to explain the issue. Regarding those security considerations, I also wanted to point out that the section on session fixation does not make sense. What session fixation attack are you talking about? There was a session fixation vulnerability in the original version of OAuth 1.0, but it was due to the fact that the client obtained the temporary credentials (token request and secret, analogous to the current authorization code) in a direct request to the server before redirecting the user's browser to the server for user authentication. The server created a session when it provided the temporary credentials to the client, and the attacker fixated that session by using a fake client to redirect the user to the server with the request token issued to the attacker, which referred the server to the attacker's session. IN OAUTH 2.0 THIS SESSSION FIXATION VULNERABILITY IS NOT AN ISSUE BECAUSE THE DIRECT REQUEST TO OBTAIN TEMPORARY CREDENTIALS HAS BEEN ELIMINATED. Francisco
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
