Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures

[Richard Barnes]

The scope argument doesn't really hold any water, since OAuth isn't  
defining the scope that tokens have -- authorization servers could  
issue tokens that have the same power as passwords.  Not all  
implementors are "reasonable" :)

--Richard


On Apr 8, 2010, at 2:27 PM, Allen Tom wrote:

Using a bearer token without a signature over HTTP is not equivalent  
to HTTP Basic Auth in the clear.

A bearer token is far less powerful than the user’s password.  In  
most cases, a MITM who steals the user’s password would be able to  
change the user’s password, locking the user out his account.  
Passwords are not scoped and allow full access to the user’s account.

A bearer token (for all reasonable implementations) would never let  
the holder change the user’s password. Although we have not  
standardized on the concept of scope, presumably, many implementers  
will issue Access Tokens that do not grant access to the entirety of  
the user’ account.

Another important difference between OAuth2 Access Tokens and HTTP  
Basic Auth is that Access Tokens can have a limited lifetime, so a  
MITM would only be able to hijack an Access Token for a short  
duration.

My recommendation is that the spec recommend that Service Providers  
use HTTPS for enhanced security, however in the cases where using  
HTTPS is not feasible or desirable, Services Providers should do one  
or more of the following:

        • Issue access tokens that are less powerful than the user’s password
        • Use signatures
	• Issue access tokens with a short lifetime, and use the Refresh  
workflow

Allen




On 4/7/10 11:06 PM, "Eran Hammer-Lahav" <e...@hueniverse.com> wrote:

How about something like this:

When accessing resources using the http URI scheme, clients SHOULD  
NOT use and servers SHOULD NOT accept bearer token requests  
(unsigned requests) as such a request is equal to sending  
unprotected credentials in the clear. Instead, clients SHOULD  
obtain and utilize an access token with a matching secret by  
sending a signed request. Servers MUST accept signed requests for  
protected resources using the http URI scheme.

EHL




On 4/7/10 6:42 PM, "Richard Barnes" <rbar...@bbn.com> wrote:

You guys are both right: The recommendation I made before is  
basically
saying that you SHOULD only use tokens without signing on HTTPS
resources.

--Richard


On Apr 7, 2010, at 9:24 PM, Dick Hardt wrote:

> Eran
>
> Richard and Lief are describing the same point we had in the past
> where Peter surmised the discussion that an *implementation* MUST
> support TLS is required for bearer tokens to be compliant, and  
that
> TLS is recommended for *deployment*
>
> -- Dick
>
> On 2010-04-07, at 4:21 PM, Eran Hammer-Lahav wrote:
>
>> We are looking at this all wrong.
>>
>> There are two kinds of protected resources OAuth supports:
>>
>> * http://
>> * https://
>>
>> OAuth provides two kinds of token authentication modes:
>>
>> * bearer token
>> * token + signature
>>
>> I don't know how to translate your statement below into text I  
can
>> put in
>> the draft to answer:
>>
>> When you access/serve an http:// protected resource you do what?
>> When you access/serve an https:// protected resource you do what?
>>
>> It is not about requiring SSL for bearer token. It is about  
what you
>> can/should do when accessing an http:// resource.
>>
>> EHL
>>
>> On 4/7/10 7:09 AM, "Richard Barnes" <rbar...@bbn.com> wrote:
>>
>>> To re-iterate and clarify Leif's second point, I would be in  
favor
>>> of
>>> making TLS:
>>>
>>> -- REQUIRED for implementations to support (== MUST)
>>> -- RECOMMENDED for deployments to use (== SHOULD)
>>>
>>> This a pretty universal pattern in IETF protocols.
>>>
>>> --Richard
>>>
>>>
>>> On Apr 7, 2010, at 7:20 AM, Leif Johansson wrote:
>>>
>>>>
>>>>> Go implement whatever you want. But the spec should set the
>>>>> highest
>>>>> practical bar it can, and requiring HTTPS is trivial.
>>>>>
>>>>> As a practical note, if the WG reaches consensus to drop the  
MUST,
>>>>> I would
>>>>> ask the chairs to ask the security area and IESG to provide
>>>>> guidance whether
>>>>> they would approve such document. The IESG did not approve  
OAuth
>>>>> 1.0a for
>>>>> publication as an RFC until this was changed to a MUST (for
>>>>> PLAINTEXT) among
>>>>> other comments, and that with a strong warning.
>>>>>
>>>>> There is also an on going effort to improve cookie security.  
Do we
>>>>> really
>>>>> want OAuth to become the next weakest link?
>>>>
>>>> I emphatically agree.
>>>>
>>>> I suspect that a lot of confusion on this thread is caused by
>>>> confusing implementation requirements with deployment  
requirements
>>>> btw.
>>>>
>>>>     Cheers Leif
>>>> _______________________________________________
>>>> 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
>



_______________________________________________
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