Subject: [OAUTH-WG] "shared symmetric secret"

From: Brian Eaton <[email-masked]>
Date: Mon, 12 Jul 2010 22:39:20 -0700

Section 5: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5

Calling access tokens "shared symmetric secrets" is misleading,
because if they are implemented well the authorization server and
protected resource do not store a copy of the secret.

Instead they store a one-way hash of the token.  Or they verify the
token cryptographically.  Under no circumstances do they need to store
a copy.

I'd suggest the following language:

"Access tokens are bearer authentication tokens or capabilities."

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 13 Jul 2010 07:18:44 -0700

>From the client's perspective, they are 'shared symmetric secrets' because
the client has to store them as-is and present them as-is. The act exactly
like passwords. I added that text to make that stand out.

When using passwords, the server doesn't need to store them in plain-text
either (e.g. uses a way one hash).

I would like the specification to make it clear that bearer tokens are only
secure while they remain *secret* and that *anyone* holding them can gain
full access to what their protect.

EHL

On 7/12/10 10:39 PM, "Brian Eaton" <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 13 Jul 2010 11:45:12 -0400

I tend to agree with Eran, although it should be qualified that a token 
is BASED on a shared secret, rather than is a shared secret itself. (By 
the way, I think the word "symmetric" is redundant here.).

I also think that the text in the Security Considerations must contain 
the last paragraph of Eran's message. Probably the recommendation not to 
store the token on the server, along with the suggestion of storing the 
hash should also be in place.

Igor

---

From: Dirk Balfanz <[email-masked]>
Date: Tue, 13 Jul 2010 08:55:57 -0700

> either (e.g. uses a way one hash).

That's why we don't call passwords "shared symmetric secrets", either. The
verifier of a passwords can verify it without knowing the secret. In that
sense, it's not "shared" with the verifier.

> full access to what their protect.

I think the word "capability" expresses that better than the word "shared
secret".

Dirk.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 13 Jul 2010 09:02:11 -0700

I am ok replacing it with 'acts as a password'.

EHL

On 7/13/10 8:55 AM, "Dirk Balfanz" <[email-masked]> wrote:

That's why we don't call passwords "shared symmetric secrets", either. The verifier of a passwords can verify it without knowing the secret. In that sense, it's not "shared" with the verifier.

I think the word "capability" expresses that better than the word "shared secret".

Dirk.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 13 Jul 2010 09:11:23 -0700

New text:

        Clients access protected resources by presenting an access token to the resource server.
        Access tokens are bearer tokens, where the token string acts as a password. This requires
        treating the access token with the same care as other passwords. Access tokens SHOULD NOT
        be sent in the clear over an insecure channel.

EHL

On 7/13/10 9:02 AM, "Eran Hammer-Lahav" <[email-masked]> wrote:

EHL

Dirk.

EHL

---

From: John Kemp <[email-masked]>
Date: Tue, 13 Jul 2010 13:25:05 -0400

On Jul 13, 2010, at 12:02 PM, Eran Hammer-Lahav wrote:

> I am ok replacing it with ‘acts as a password’.

An access token is something used by the server to decide whether a request is authorized. Although it may also be used for authenticating the request(er), it's purpose is to authorize the request. 

In the "bearer token" case (and even over SSL unless client certs are used), the token clearly SHOULD NOT be used as a password. Rather, authentication should be performed by some other mechanism, unrelated to the token itself (such as an HMAC, or via client-certificate SSL/TLS, or even via an actual username/password) 

I would be very unhappy if we equated access tokens with passwords. 

I agree with Dirk that "capability" is a more expressive phrase than either "shared secret" or "password". 

Regards,

- johnk

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 13 Jul 2010 10:40:46 -0700

On 7/13/10 10:25 AM, "John Kemp" <[email-masked]> wrote:

>> I am ok replacing it with Oacts as a password¹.
> 
> An access token is something used by the server to decide whether a request is
> authorized. Although it may also be used for authenticating the request(er),
> it's purpose is to authorize the request.

It is used to authenticate the *request*, it is used in the same manner
other HTTP authentication schemes operate, and it has the same behavior as a
password (security wise: plain-text storage on the client side, can be
phished, usable by any bearer).

> In the "bearer token" case (and even over SSL unless client certs are used),
> the token clearly SHOULD NOT be used as a password. Rather, authentication
> should be performed by some other mechanism, unrelated to the token itself
> (such as an HMAC, or via client-certificate SSL/TLS, or even via an actual
> username/password)

OAuth only includes the "bearer token case". There are no other cases
specified.

> "shared secret" or "password".

Expressive to you and people well-versed in security theory. It means
nothing to a casual reader. The token definition includes the term, but in
this section, it is referring to how an access token is used, and it is used
just like a password.

For better or worse, we turned the 1.0 access token into a 2.0 password.

EHL

---

From: John Kemp <[email-masked]>
Date: Tue, 13 Jul 2010 14:45:45 -0400

Hi Eran,

On Jul 13, 2010, at 1:40 PM, Eran Hammer-Lahav wrote:

> It is used to authenticate the *request*

Can you give me a rough pointer to where that text is in the specification?

I see your assertion in section 5, but for example, the glossary definition of "token" says:

"A string representing an access authorization issued to the
         client."

(note "authorization")

and:

"Specific additional authentication
         credentials may be required in order for a client to use a
         token."

Which suggests that in addition to the presence of an authorizing token, the server should authenticate the client. We could be more explicit about that, but the idea seems to be there already (as it should, in my opinion). 

> , it is used in the same manner

You may be right that the token MIGHT be stored plain-text on the client. MIGHT be phished. MIGHT be used by someone who is not the entity to which the token was originally given. 

But it is not required to be used that way, and if the client security properties that you mention are employed, certainly SHOULD NOT be used to authenticate the client. 

> OAuth only includes the "bearer token case". There are no other cases

Authentication of the request is out of scope for OAuth. OK, but security considerations should note that requests should be authenticated as well as being authorized. 

> nothing to a casual reader. The token definition includes the term,

And I am happy with the text included in the definition (as shown above). Why should it be different in section 5?

> but in

I'd really like to understand why you feel that way - is there text that you feel specifically supports your assertion that the token is used to *authenticate* rather than *authorize* the request? 

- johnk

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 13 Jul 2010 14:46:41 -0400

> this section, it is referring to how an access token is used, and it is used

 Definitely agree with Eran here. The term "capability" doesn't mean much to me in this circumstance, but "like a password" tells me exactly what I, as an implementer, can expect. 

 -- Justin

---

From: John Kemp <[email-masked]>
Date: Tue, 13 Jul 2010 15:07:01 -0400

> Definitely agree with Eran here. The term "capability" doesn't mean much to me in this circumstance, but "like a password" tells me exactly what I, as an implementer, can expect. 

Perhaps so, but it doesn't correctly describe how the token should be used, or deal with the difference between authentication and authorization. It also doesn't reflect the language used elsewhere in the specification. 

Regards,

- johnk

---

From: Blaine Cook <[email-masked]>
Date: Tue, 13 Jul 2010 20:03:08 +0100

+1 on "like a password", or something similar-and-meaningful because
that's exactly how it's being used here. Pre-shared key, shared
secret, etc, would be fine. Keep in mind that authentication *will be
done* using the bearer token, and the bearer token alone.

An OAuth token is unlike capabilities in that capabilities tend to be
bound to addressable data – in most OAuth deployments, the data
addressing is separate from the token.

b.

---

From: John Kemp <[email-masked]>
Date: Tue, 13 Jul 2010 15:31:58 -0400

> done* using the bearer token, and the bearer token alone.

Where is that specified? Is that required for all implementations?

> addressing is separate from the token.

A capability, basically, is a reference to an object and the permission to use it, bound together. Possession of the capability is enough to authorize the use of the reference. Bearer tokens follow roughly that model. They are about authorization and MAY be used alone for authentication, but may also be used with (specified, or not, in OAuth) other mechanisms for authentication. At least I hope that is the model (not to *require* servers to authenticate using the bearer token alone even if *some* implementations do that)?

- johnk

---

From: Blaine Cook <[email-masked]>
Date: Tue, 13 Jul 2010 21:06:41 +0100

It's not specified - I was referring to your earlier comments:

> In the "bearer token" case (and even over SSL unless client certs are used), the
> token clearly SHOULD NOT be used as a password. Rather, authentication should
> be performed by some other mechanism, unrelated to the token itself (such as an
> HMAC, or via client-certificate SSL/TLS, or even via an actual username/password)

> I would be very unhappy if we equated access tokens with passwords.

The token is never used as the authentication mechanism (i.e., the
mechanism to authenticate the user), except in schemes where it
explicitly makes sense (e.g., UMA as I understand it, Twitter's OAuth
Echo, etc). So there's no concern about that.

What I was trying to say, and I'm just re-iterating Eran's comments
here, is that once issued [in the context of a request made by an
authenticated user that grants authorization to the OAuth client], the
token will be used de-facto as a password, passphrase, shared secret,
or whatever we want to call it. By calling it a "capability", we don't
signal to implementors what the security implications are, and what
they can do to avoid disappointment.

> A capability, basically, is a reference to an object and the permission to use it, bound together. Possession of the capability is enough to authorize the use of the reference. Bearer tokens follow…

It's unclear what you mean is being authenticated by the server – do
you mean the user, or the client, or something else? This question is
persistent and points to exactly the kind of confusion I think Eran is
correct to try to avoid by simply calling the token password-like. If
we use language that clearly indicates to developers that "with the
clear-text token, requests can be made [modulo reduced permissions] as
though they were made by someone in possession of the user's username
and password. Don't leak it, and treat it as though it were a
password", then we avoid having to explain (embarrassingly) that the
"capability" actually meant something like "password".

b.

---

From: Brian Eaton <[email-masked]>
Date: Tue, 13 Jul 2010 13:35:16 -0700

On Tue, Jul 13, 2010 at 1:06 PM, Blaine Cook <[email-masked]> wrote:
> Don't leak it, and treat it as though it were a

For the initiated, that's what "capability" means.

How about this language

"Access tokens are bearer authentication tokens, such as passwords or
capabilities."

I'd encourage the use of the word "capability" because a lot of the
use cases that OAuth 2 enables over OAuth 1 involve using the token
like a capability, sharing it across multiple components to convey
authorization.

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 13 Jul 2010 16:40:56 -0400

In this case, the term "capability" MUST be defined up front. The word 
"capability" seems to carry a much broader meaning than password...

Igor

---

From: Brian Eaton <[email-masked]>
Date: Tue, 13 Jul 2010 13:43:16 -0700

> "capability" seems to carry a much broader meaning than password...

It has a standard definition we can reference.  From
http://www.ietf.org/rfc/rfc2828.txt

   $ capability
      (I) A token, usually an unforgeable data value (sometimes called a
      "ticket") that gives the bearer or holder the right to access a
      system resource. Possession of the token is accepted by a system
      as proof that the holder has been authorized to access the
      resource named or indicated by the token. (See: access control
      list, credential, digital certificate.)

      (C) This concept can be implemented as a digital certificate.
      (See: attribute certificate.)

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 13 Jul 2010 13:46:17 -0700

I'll work with this text.

EHL

On 7/13/10 1:35 PM, "Brian Eaton" <[email-masked]> wrote:

How about this language

---

From: John Kemp <[email-masked]>
Date: Tue, 13 Jul 2010 17:05:27 -0400

> they can do to avoid disappointment.

By using the word "password" to apply to the token itself you are suggesting that the token is the authenticator for the request, which may or may not be true. And you are tying in to a rich history of what a "password" means, which is not necessarily how the token will be used, particularly if some other means of authenticating the requester is used _in addition to_ the bearer token being used to authorize the request.
 
> you mean the user, or the client, or something else?

Which thing do you think the bearer token is a password for?

I think the bearer token is used by the server to authorize access by the requester. It MAY be used as an authenticator for the requester.... but it may not (or not alone)

> This question is
> correct to try to avoid by simply calling the token password-like.

"Password-like", in some circumstances, but not a password. In OAuth, as I understand it, the token is used to authorize the request. Authenticating the request is then out of scope for OAuth proper, but various authentication methods for the client may be used in conjunction with the use of the token, including allowing the token to act as a "password" for the client. 

> If

You see the bearer token as being a password for the user? Or should it simply be protected in the same ways that one would protect a user's password -- in other words, document the security considerations of tokens in detail (stored securely, not passed in cleartext etc.) rather than using a single word to indicate something which may or may not be accurate, and is certainly not wholly descriptive.

- johnk

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 13 Jul 2010 17:05:32 -0400

YES!!!

Brian, could you please add this?

Igor

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 13 Jul 2010 14:33:35 -0700

This is how OAuth works: The client wants to access a protected resource. The resource requires authentication (that's the definition of protected). The client presents the access token to authenticate (using an HTTP authentication header). The access token has all the security characteristics of a password:

- Opaque to the client - just a string
- Client must store it in a way that provides access to the clear-text token
- Anyone holding the token can access - the bearer of the token is considered its rightful owner
- The token can be leaked or phished - which is sufficient for full access

I don't care much about the philosophical debate (authentication vs authorization) as I don't think it adds much value here. When it comes to using an access token, the client uses it just like a password, it serves as the authentication construct, and it has all the same problems passwords have.

I do recognize that unlike users' passwords, the tokens are not bound to a person's memory and therefore can be longer, short-lived, and client-specific which is an improvement over users' passwords. But that's just an implementation detail. There is little in the protocol today that enforces this.

My assumption is that for the most part, OAuth 2.0 will be used without any additional authentication. For example, my employer (whom I do not represents here in any way) intends to use access tokens over plain HTTP without SSL/TLS (current BBAuth deployment).

As soon as we add discovery, bearer token phishing will become an issue - mark my words. This is why I find bearer tokens so offensive (I consider discovery a required feature) - but I have lost that battle. All I can do now is use my editorial capacity to warn readers of what they are dealing with *in practice*, and in practice, bearer tokens are used just like passwords.

--

Either way, this is the new text:

        Clients access protected resources by presenting an access token to the resource server.
        Access tokens are bearer authentication tokens, such as passwords or capabilities (as
        defined by RFC2828). This requires treating the access token with the
        same care as other passwords. Access tokens SHOULD NOT be sent in the clear over an
        insecure channel.

EHL

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Tue, 13 Jul 2010 17:20:38 -0500

According to the RFC 2828 an access token is rather a capability than a password. The passwords are usually associated with the matching identifiers, but an access token of OAuth 2.0 is used as a single credential that allows access to a protected resource.

>From RFC 2828:
$ password
      
      (C) A password is usually matched with a user identifier that is
      explicitly presented in the authentication process, but in some
      cases the identity may be implicit.

Zachary
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Eaton
Sent: Tuesday, July 13, 2010 4:43 PM
To: Faynberg, Igor (Igor)
Cc: OAuth WG
Subject: Re: [OAUTH-WG] "shared symmetric secret"

   $ capability

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 13 Jul 2010 16:34:20 -0700

I'm only using 2828 definition of capability, not password.

EHL

On 7/13/10 3:20 PM, "Zachary Zeltsan" <[email-masked]> wrote:

$ password

Zachary
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Eaton
Sent: Tuesday, July 13, 2010 4:43 PM
To: Faynberg, Igor (Igor)
Cc: OAuth WG
Subject: Re: [OAUTH-WG] "shared symmetric secret"

   $ capability

---

From: Evan Gilbert <[email-masked]>
Date: Wed, 14 Jul 2010 23:04:26 -0700

"Password" doesn't seem to be the right analogy. You don't (or really
shouldn't) store passwords in plain text or in cookies.

How about "cookies"? Most web developers understand that cookies are used as
a token that grants access to resources. We've also called these tokens"API
cookies" when trying to describe them internally.

On Tue, Jul 13, 2010 at 4:34 PM, Eran Hammer-Lahav <[email-masked]>wrote:

>  I’m only using 2828 definition of capability, not password.
>
> EHL
>
>
>
> According to the RFC 2828 an access token is rather a capability than a
> password. The passwords are usually associated with the matching
> identifiers, but an access token of OAuth 2.0 is used as a single credential
> that allows access to a protected resource.
>
> From RFC 2828:
> $ password
>
> From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf Of Brian Eaton

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Jul 2010 06:35:39 -0700

Access tokens should not be stored in plain text either since stealing them is just like stealing a password.

As for cookies, client developers do very little to protect cookies today. While the theory might be similar, in practice, telling a client developer this is just like a cookies doesn't warn them enough.

EHL

On 7/14/10 11:04 PM, "Evan Gilbert" <[email-masked]> wrote:

"Password" doesn't seem to be the right analogy. You don't (or really shouldn't) store passwords in plain text or in cookies.

How about "cookies"? Most web developers understand that cookies are used as a token that grants access to resources. We've also called these tokens"API cookies" when trying to describe them internally.

On Tue, Jul 13, 2010 at 4:34 PM, Eran Hammer-Lahav <[email-masked]> wrote:
I'm only using 2828 definition of capability, not password.

EHL

On 7/13/10 3:20 PM, "Zachary Zeltsan" <[email-masked] <http://[email-masked]> > wrote:

$ password

Zachary
-----Original Message-----
From: [email-masked] <http://[email-masked]>  [mailto:[email-masked]] On Behalf Of Brian Eaton
Sent: Tuesday, July 13, 2010 4:43 PM
To: Faynberg, Igor (Igor)
Cc: OAuth WG
Subject: Re: [OAUTH-WG] "shared symmetric secret"

   $ capability

_______________________________________________
OAuth mailing list
[email-masked] <http://[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email-masked] <http://[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Evan Gilbert <[email-masked]>
Date: Thu, 15 Jul 2010 17:43:26 -0700

> them is just like stealing a password.

Access tokens are designed to be stored in plain text in less secure
environments - web browser cookie JAR, in RAM in installed apps, etc.

They last only a short period, can only be used to access specific
resources, can be traced back to a specific 3rd party who is granted access,
and are sent with every request.

This is very similar to cookies. This is not very similar to passwords.

>
> As for cookies, client developers do very little to protect cookies today.
> While the theory might be similar, in practice, telling a client developer
> this is just like a cookies doesn’t warn them enough.
>

I think that's about the right message to give, actually. If you can steal
the cookie on the 3rd party web site you will likely be able to access the
same data as the access token (web site uses refresh token on backend to
make API calls on behalf of the logged in user... which is based on the
cookie that was stolen).

> How about "cookies"? Most web developers understand that cookies are used
> as a token that grants access to resources. We've also called these
> tokens"API cookies" when trying to describe them internally.
>
>
> On 7/13/10 3:20 PM, "Zachary Zeltsan" <[email-masked]<
> http://[email-masked]> > wrote:
>
> From: [email-masked] <http://[email-masked]>  [
> mailto:[email-masked] <[email-masked]>] On Behalf Of Brian
> Eaton
> <[email-masked] <http://[email-masked]>
> > wrote: