Subject: [OAUTH-WG] OAuth MAC token type draft

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 9 Jan 2011 10:18:50 -0700

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

---

From: "Richer, Justin P." <[email-masked]>
Date: Sun, 9 Jan 2011 14:46:50 -0500

I'd like to see a way to use this mechanism without tokens -- that is, the traditional two-legged signed-http-fetch approach. Maybe have the spec here give details of a method using pre-shared client secrets instead of OAuth tokens would be all it'd take. 

 -- Justin

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Eran Hammer-Lahav [[email-masked]]
Sent: Sunday, January 09, 2011 12:18 PM
To: OAuth WG
Subject: [OAUTH-WG] OAuth MAC token type draft

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 9 Jan 2011 13:39:43 -0700

Well, you need the token as the identifier of the secret being used. So if you think of a token as an 'id', then it works as is.

EHL

> -----Original Message-----
> From: Richer, Justin P. [mailto:[email-masked]]
> Sent: Sunday, January 09, 2011 11:47 AM
> To: Eran Hammer-Lahav; OAuth WG
> Subject: RE: OAuth MAC token type draft
> 
> I'd like to see a way to use this mechanism without tokens -- that is, the
> traditional two-legged signed-http-fetch approach. Maybe have the spec
> here give details of a method using pre-shared client secrets instead of
> OAuth tokens would be all it'd take.
> 
>  -- Justin
> 
> 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.
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 10 Jan 2011 08:45:56 -0500

Right -- if you substitute "token" with "client id" and "token secret" with "client secret", then you've got the makings for 2-legged OAuth 2.0 right there. I think you should call out that use case explicitly in your draft.

 -- Justin
________________________________________
From: Eran Hammer-Lahav [[email-masked]]
Sent: Sunday, January 09, 2011 3:39 PM
To: Richer, Justin P.; OAuth WG
Subject: RE: OAuth MAC token type draft

EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 10 Jan 2011 22:07:47 +0100

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?

- 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?

regards,
Torsten.

Am 09.01.2011 18:18, schrieb Eran Hammer-Lahav:
> request string) which is an attempt to take the HMAC-SHA1 flow from 
> 1.0a and simplify it.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 10 Jan 2011 16:31:34 -0500

I just wanted to bring these points up, but Torsten got there first!

It only remains for me then to +1 on both.

Igor

Torsten Lodderstedt wrote:
>> 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.
>>
>>  
>>
> ------------------------------------------------------------------------
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 10 Jan 2011 14:46:22 -0700

> From: Torsten Lodderstedt [mailto:[email-masked]]
> 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
> 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.

> 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

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 11 Jan 2011 16:44:49 +1100

>> Don't you think people get confused about that?

> This was proposed by James Manger and discussed earlier on the list. I'll let James explain it.

The MAC draft doesn't bother to define a "WWW-Authenticate: MAC ..." response header because Eran is only interested in using MAC in conjunction with OAuth2.
The server can say (in response to an unauthenticated request): "you can use OAuth flows to be delegated access to this server". It says this with a "WWW-Authenticate: OAuth2" response. This statement is not specific to MAC.

I think the MAC scheme should define its own "WWW-Authenticate: MAC ..." response header. It might not be used by systems using OAuth2, but it makes MAC a more complete standalone HTTP authentication mechanism.

>> Moreover, the bearer draft

The bearer draft should change to use its own scheme name (eg "BEARER") in Authorization request headers.

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 10 Jan 2011 23:00:22 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Manger, James H
> Sent: Monday, January 10, 2011 9:45 PM
> To: OAuth WG
> before.
> The MAC draft doesn't bother to define a "WWW-Authenticate: MAC ..."
> response header because Eran is only interested in using MAC in conjunction
> with OAuth2.
> The server can say (in response to an unauthenticated request): "you can
> use OAuth flows to be delegated access to this server". It says this with a
> "WWW-Authenticate: OAuth2" response. This statement is not specific to
> MAC.
> 
> I think the MAC scheme should define its own "WWW-Authenticate: MAC
> ..." response header. It might not be used by systems using OAuth2, but it
> makes MAC a more complete standalone HTTP authentication mechanism.

I will consider adding it, but need to find a way that doesn't bring up the 'how to get a token' part if you are not using OAuth.

EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 11 Jan 2011 23:18:23 +0100

> The bearer draft should change to use its own scheme name (eg "BEARER") in Authorization request headers.

I'm trying to understand your proposal.

Let's assume a client sends a unauthorized request to a protected 
resource. The resource server answers with 401/WWW-Authenticate OAuth2. 
What is the client supposed to learn from this response? It can use an 
OAuth2-Server to obtain a token, correct?

The client additionally needs an indication which authorization header 
(== mechanism) to use for the service invocation. An additional header 
WWW-Authenticate "MAC" could indicate support for MAC authorization 
headers whereas WWW-Authenticate "BEARER" could indicate support for 
BEARER authorization headers.

Bottom line: The server has at least to send "MAC" or "BEARER" and can 
additionally send "OAuth2".

As far as I understand, WWW-Authenticate headers are intended to signal 
the authentication methods a certain server supports + to deliver method 
specific parameters to the caller.  Nothing more. I feel your 
interpretation goes beyond that point in that this headers shall tell 
the client not only (1) how to send credentials accross but als (2) how 
to obtain this credentials.

I would suggest to publish (2) by other means than a WWW-Authenticate 
header.

regards,
Torsten.

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Wed, 12 Jan 2011 13:46:10 -0600

Eran,

> 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: [email-masked] [mailto:[email-masked]] 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

EHL

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 12 Jan 2011 14:57:00 -0500

Eran,

I still don't understand, sorry.

Here is the scenario: When a principal that impersonates the resource 
server gets a token (already signed and ready to go, of course) it can 
present it to the real resource server and get access to resources.

This is what I thought Torsten meant by "token abuse", and what, for 
sure, I meant.  I don't see how this threat is addressed. I do think it 
must be addressed.

The simplest thing, I believe, is always to require server 
authentication. (This will cover the case of the counterfeit servers, 
but it would not cover any case in which the token is intercepted or 
stolen. For the latter case client authentication must be nundatory.)

Igor

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 12 Jan 2011 12:57:26 -0700

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)" <[email-masked]> wrote:

Eran,

Zachary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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

EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 12 Jan 2011 21:40:24 +0100

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)" 
> <[email-masked]> wrote:
>
>     Eran,
>
>     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
>
>     normalized

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Wed, 12 Jan 2011 15:12:39 -0600

It should not fail because the intercepted signed request included the hostname and port of the real resource server.

Zachary

________________________________
From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Wednesday, January 12, 2011 3:40 PM
To: Eran Hammer-Lahav
Cc: Zeltsan, Zachary (Zachary); OAuth WG
Subject: Re: [OAUTH-WG] OAuth MAC token type draft

Shouldn't signature verification fail on the real server because of different hostnames/ports?

regards,
Torsten.

 1.  read data
 2.  write/delete data

EHL

Zachary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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

EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 12 Jan 2011 22:17:24 +0100

Ok, understood, I had a proxying server with another address in mind.

You assume an attack on unencrypted channels, which could by prevented 
using HTTPS (as Eran described).

regards,
Torsten.

Am 12.01.2011 22:12, schrieb Zeltsan, Zachary (Zachary):
>
>  It should not fail because the intercepted signed request included 
> the hostname and port of the real resource server.
>
> Zachary
>
> *From:*Torsten Lodderstedt [mailto:[email-masked]]
> *Sent:* Wednesday, January 12, 2011 3:40 PM
> *To:* Eran Hammer-Lahav
> *Cc:* Zeltsan, Zachary (Zachary); OAuth WG
> *Subject:* Re: [OAUTH-WG] OAuth MAC token type draft
>
> 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
>
> Of Eran Hammer-Lahav

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 20 Jan 2011 17:37:43 -0700

Please let me know if -01 addresses your concerns.

EHL

> Sent: Monday, January 10, 2011 5:46 AM
> Right -- if you substitute "token" with "client id" and "token secret" with
> "client secret", then you've got the makings for 2-legged OAuth 2.0 right
> there. I think you should call out that use case explicitly in your draft.
> 
>  -- Justin
> Well, you need the token as the identifier of the secret being used. So if you
> think of a token as an 'id', then it works as is.
> 
> EHL
> 
> > I'd like to see a way to use this mechanism without tokens -- that is,
> > the traditional two-legged signed-http-fetch approach. Maybe have the
> > spec here give details of a method using pre-shared client secrets
> > instead of OAuth tokens would be all it'd take.
> >
> >  -- Justin
> >