Hi Torsten, > > 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
I'm very glad you want to require TLS for the callback endpoint. But many people in this mailing list believe that client credentials mitigate the attack. That belief is mistaken, and it's causing a lot of confusion. Your second countermeasure in section 4.4.1.6, > > > 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). indicates that you believe that too. I'm trying to dispel that misconception. > > > > 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. Here is some text: "If the redirect URI is not protected by TLS and is not local to the host where the user's browser is running, an attacker who intercepts the authorization code as it is sent by the browser to the callback endpoint can gain access to protected resources by submitting the authorization code to the client. The client will exchange the authorization code for an access token and use the access token to access protected resources for the benefit of the attacker, delivering protected resources to the attacker, or modifying protected resources as directed by the attacker. If OAuth is used by the client to delegate authentication to a social site (e.g. as in the implementation of the "Facebook Login" button), the attacker can use the intercapted authorization code to log in to the client as the user." > > 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. What's wrong with the session fixation section is that it addresses a problem that does not exist, unless there is a session fixation attack that I'm not aware of. If there is such an attack, it should be described. Telling implementors "do this" or "don't do that" without explanation is not helpful. Regards, Francisco
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
