Hi Francisco,
Am 31.03.2011 20:59, schrieb Francisco Corella:
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
Then you should probably precisely describe the attack you want to talk
about. I refered to MITM.
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.
I'm not sure you read the description carefully enough. It also states
that the redirect_uri shall be authenticated:
"The browser shall be utilized to authenticate the redirect_uri of
the client using server authentication"
--> MITM
Moreover,
http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.4.1.2
requires
"Authorization server as well as the client MUST ensure that these
transmissions are protected using transport-layer mechanisms such
as TLS or SSL (see Section 5.1.1)."
--> Wiretapping
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.
Any proposal of better text is welcome.
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.
I would suggest you calm down a bit and describe what is wrong with the
description.
regards,
Torsten.
Francisco
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
