Francisco, correct me if I'm wrong, but in your discussion you assume that the application is incapable of keeping secrets from the public (eg, mobile, desktop apps, etc.). According to the spec, those applications should never receive client credentials to begin with. They can't keep secrets so they aren't issued any. Obfuscating secrets in binary code doesn't count - if the tokens in question are outside a secured firewall, they aren't secrets.
George's attack is a MITM attack which can be expensive or difficult to pull off, but a possibility. At the least, it's a security consideration of why a callback *should* use TLS. Someone speak up if George's scenario is flawed or I'm misunderstanding it. My understanding is this: - Bob uses (web) client C to access provider P. - Mallory has set up a MITM attack between client C and Bob's computer. - Mallory also uses client to C and starts an an approval process from the client to provider P - Bob sends a request over HTTPS to provider P with client ID for C. - Provider P responds to his request with a redirect to an authentication code. - Meanwhile, Mallory does not continue with the auth flow at provider P. Instead, he waits for Bob. - Bob's browser performs the redirect sent from provider P back to client C (over HTTP). - Mallory intercepts the clear-text request from Bob's computer and does not pass the request on to client C. - Mallory uses the auth code from Bob (and any state information) to forge a redirect request to client C on his own session. - Client C requests an access token from provider P for Bob's account using it's secured client credentials. - Mallory now has credentials for Bob on client C. Bob has a dead or invalid auth handshake which was interrupted by Mallory (and not passed on to P to avoid replay detection). (NOTE: I wrote this before the other examples, so apologies if it repeats the example Dick made). On Mar 31, 2011, at 2:59 PM, Francisco Corella wrote: > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
