Shouldn't signature verification fail on the real server because of
different hostnames/ports?
regards,
Torsten.
Am 12.01.2011 20:57, schrieb Eran Hammer-Lahav:
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
