Subject: [OAUTH-WG] I'm concerned about how the sniffability of oauth2 requests

From: "L. Preston Sego III" <[email-masked]>
Date: Fri, 1 Feb 2013 10:37:30 -0500

In an oauth2 request, the access token is passed along in the header, with
nothing else.

As I understand it, oauth2 was designed to be simple for everyone to use.
And while, that's true, I don't really like how all of the security is
reliant on SSL.

what if an attack can strip away SSL using a tool such as sslstrip (or
whatever else would be more suitable for modern https)? They would be able
to see the access token and start forging whatever request he or she wants
to.

Why not do some sort of RSA-type public-private key thing like back in
Oauth1, where there is verification of the payload on each request? Just
use a better algorithm?

---

From: William Mills <[email-masked]>
Date: Mon, 4 Feb 2013 08:27:53 -0800 (PST)

There are two efforts at signed token types: MAC which is still a possibility if we wake up and do it, and the "Holder Of Key" type tokens.

There are a lot of folks that agree with you.

________________________________
 From: L. Preston Sego III <[email-masked]>
To: [email-masked] 
Sent: Friday, February 1, 2013 7:37 AM
Subject: [OAUTH-WG] I'm concerned about how the sniffability of oauth2 requests

In an oauth2 request, the access token is passed along in the header, with nothing else.

As I understand it, oauth2 was designed to be simple for everyone to use. And while, that's true, I don't really like how all of the security is reliant on SSL.

what if an attack can strip away SSL using a tool such as sslstrip (or whatever else would be more suitable for modern https)? They would be able to see the access token and start forging whatever request he or she wants to.

Why not do some sort of RSA-type public-private key thing like back in Oauth1, where there is verification of the payload on each request? Just use a better algorithm?
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Prateek Mishra <[email-masked]>
Date: Mon, 04 Feb 2013 11:35:23 -0500

Can you explain how SSLstrip could be used to defeat the OAuth flows? 
Isn't it dependent on web pages with non-HTTPs links?

Which step in the OAuth exchanges would be vulnerable?

BTW, there is a threats analysis document that discusses a variety of 
attacks and countermeasures  -

http://datatracker.ietf.org/doc/rfc6819/

> There are two efforts at signed token types: MAC which is still a 
> possibility if we wake up and do it, and the "Holder Of Key" type tokens.
>
> ------------------------------------------------------------------------
> *From:* L. Preston Sego III <[email-masked]>
> *To:* [email-masked]
> *Sent:* Friday, February 1, 2013 7:37 AM
> *Subject:* [OAUTH-WG] I'm concerned about how the sniffability of 
> oauth2 requests
>
> As I understand it, oauth2 was designed to be simple for everyone to 
> use. And while, that's true, I don't really like how all of the 
> security is reliant on SSL.
>
> whatever else would be more suitable for modern https)? They would be 
> able to see the access token and start forging whatever request he or 
> she wants to.
>
> Oauth1, where there is verification of the payload on each request? 
> Just use a better algorithm?
>
> [email-masked] <mailto:[email-masked]>

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 04 Feb 2013 16:57:47 +0000

On 04/02/13 16:27, William Mills wrote:
> possibility if we wake up and do it,

I'd rephrase it slightly differently, it is a possibility right now, 
OAuth2 supports custom tokens, the fact that OAuth2 may not formally 
approve MAC won't preclude the use of MAC in the OAuth2 compliant manner.

Of course OAuth2 putting a stamp of approval will make it more visible, 
without it, the existing MAC draft issues (if any) will end up being 
addressed at the specific implementations level only - not ideal for the 
community at large but it is up to OAuth2...

Cheers, Sergey

> and the "Holder Of Key" type tokens.
>
> *Subject:* [OAUTH-WG] I'm concerned about how the sniffability of oauth2
> requests
>
> use. And while, that's true, I don't really like how all of the security
> is reliant on SSL.
>

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Mon, 4 Feb 2013 17:02:23 +0000

Speaking of ... what is the status of the HOK work?  The last draft has expired and its fallen off of the OAuth page now.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sergey Beryozkin
Sent: Monday, February 04, 2013 10:58 AM
To: [email-masked]
Subject: Re: [OAUTH-WG] I'm concerned about how the sniffability of oauth2 requests

Cheers, Sergey

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 4 Feb 2013 19:09:28 +0200

Hi Adam, 

we had 3 conference calls to discuss the security requirements and now we have started the design team work. In fact the first call of the design team starts in 45 mins and the conference call details have been sent to the list. You are also welcome to join; it is an open design team. 

The security requirements document had been updated and I have distributed the meeting minutes to the list. 
All the drafts will be refreshed in time for the submission deadline. 

Ciao
Hannes

---

From: Prabath Siriwardena <[email-masked]>
Date: Wed, 6 Feb 2013 21:53:03 +0530

> possibility if we wake up and do it, and the "Holder Of Key" type tokens.

If someone can use sslstrip then even MAC is not safe - since MAC key needs
to be transferred over SSL to the Client from the AS.

There are standard ways in HTTP to avoid or protect from sslstrip - IMHO we
need to occupy those best practices...

Thanks & regards,
-Prabath

>   ------------------------------

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

---

From: William Mills <[email-masked]>
Date: Wed, 6 Feb 2013 09:56:09 -0800 (PST)

Yes, MAC relies on SSL for transport security.  But you have bigger problems than that if SSL is broken, because your primary authentication credential is compromised now.

Do we need to address sslstrip here if it's a general attack on SSL transport for the browser?

________________________________
 From: Prabath Siriwardena <[email-masked]>
To: William Mills <[email-masked]> 
Cc: L. Preston Sego III <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Wednesday, February 6, 2013 8:23 AM
Subject: Re: [OAUTH-WG] I'm concerned about how the sniffability of oauth2 requests

On Mon, Feb 4, 2013 at 9:57 PM, William Mills <[email-masked]> wrote:

If someone can use sslstrip then even MAC is not safe - since MAC key needs to be transferred over SSL to the Client from the AS.

There are standard ways in HTTP to avoid or protect from sslstrip - IMHO we need to occupy those best practices...

Thanks & regards,
-Prabath

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Prabath Siriwardena <[email-masked]>
Date: Wed, 6 Feb 2013 23:30:05 +0530

On Wed, Feb 6, 2013 at 11:26 PM, William Mills <[email-masked]>wrote:

> Yes, MAC relies on SSL for transport security.  But you have bigger
> problems than that if SSL is broken, because your primary authentication
> credential is compromised now.
>

+1

> transport for the browser?

Yes.. its a general attack against SSL and counter measures defined too..

Thanks & regards,
-Prabath

> *From:* Prabath Siriwardena <[email-masked]>
> *To:* William Mills <[email-masked]>
> *Cc:* L. Preston Sego III <[email-masked]>; "[email-masked]" <
> [email-masked]>
> *Sent:* Wednesday, February 6, 2013 8:23 AM
> *Subject:* Re: [OAUTH-WG] I'm concerned about how the sniffability of
> oauth2 requests
>
>
>
> If someone can use sslstrip then even MAC is not safe - since MAC key
> needs to be transferred over SSL to the Client from the AS.
>
> There are standard ways in HTTP to avoid or protect from sslstrip - IMHO
> we need to occupy those best practices...
>
> Thanks & regards,
> -Prabath
>
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 06 Feb 2013 21:48:31 +0000

+1
> transport for the browser?
When MAC is passed back to the client requesting a token in exchange for 
a grant, no browser is even involved, right ? Besides, one can exchange 
MAC token over two-way TLS in order to authenticate and I guess it is 
much much trickier to have a man in the middle attack with two-way TLS

Cheers, Sergey

> *Cc:* L. Preston Sego III <[email-masked]>; "[email-masked]"
> <[email-masked]>
> On Mon, Feb 4, 2013 at 9:57 PM, William Mills <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     *From:* L. Preston Sego III <[email-masked]
>     <mailto:[email-masked]>>
>     *To:* [email-masked] <mailto:[email-masked]>
>     what if an attack can strip away SSL using a tool such as sslstrip
>     (or whatever else would be more suitable for modern https)? They
>     would be able to see the access token and start forging whatever
>     request he or she wants to.
>
>     Why not do some sort of RSA-type public-private key thing like back
>     in Oauth1, where there is verification of the payload on each
>     request? Just use a better algorithm?
>