Yes, its still open to a limited MITM attack, but the real issue is of confidentiality of the request (addressed in 6.2) or blocking the request. The client request will either:
1. read data 2. write/delete data If the attacker executes the #1, they get to see the result (6.2). If they execute #2, nothing bad happens because that's just what the user wanted (assuming the body is protected, which is coming in -01). The only problem is if they attacker does not execute the captured request, but that's just a DOS attack of sorts (and should be easy to detect). I'll see if I can make this clearer, but at most, a MITM can see confidential data (in which case use TLS), or can block execution. It cannot do anything other than what the client was trying to do, as-is. EHL On 1/12/11 11:46 AM, "Zeltsan, Zachary (Zachary)" <zachary.zelt...@alcatel-lucent.com> wrote: Eran, >> - 6.3. Spoofing by Counterfeit Servers >> The protocol does not support server authentication but it should prevent >> token abuse by the Counterfeit server, shouldn't it? > It does because the token secret is never sent. According to section 6.3 a counterfeit server may intercept client's request. Cannot a counterfeit server use the intercepted signed request for getting access to the resource at the real server? Zachary -----Original Message----- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, January 10, 2011 4:46 PM To: Torsten Lodderstedt Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth MAC token type draft > -----Original Message----- > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > Sent: Monday, January 10, 2011 1:08 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] OAuth MAC token type draft > > Eran, > > - Authentication schemes > You propose to use the authentication scheme name "OAuth2" for the > WWW-Authenticate header but another scheme name "MAC" for the > authorization header. I've never seen such an asymmetric approach before. > Don't you think people get confused about that? Moreover, the bearer draft > also uses the name "OAuth2" in the authorization header. Why this > difference? Why don't you just add some parameters to the "OAuth2" > scheme? This was proposed by James Manger and discussed earlier on the list. I'll let James explain it. > - 6.3. Spoofing by Counterfeit Servers > The protocol does not support server authentication but it should prevent > token abuse by the Counterfeit server, shouldn't it? It does because the token secret is never sent. EHL > > regards, > Torsten. > > Am 09.01.2011 18:18, schrieb Eran Hammer-Lahav: > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token > > Feedback appreciated, especially for section 3.2.1 (the new normalized > request string) which is an attempt to take the HMAC-SHA1 flow from 1.0a > and simplify it. > > No body signature support yet, but will add that in -01. > > EHL > > > _______________________________________________ > 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
