Subject: [OAUTH-WG] Client authentication requirement

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 15 Jun 2011 10:26:59 -0700

Client authentication has been one of the main problem areas in OAuth 1.0 and 2.0 does nothing to resolve it (arguably, it makes it more confusing).

Because of the desire to allow any client type in any deployment environment, we ended up with a barely defined client authentication model. We offer password-based client authentication using HTTP Basic (and an alternative parameter), but leave it optional.

It has been suggested that by doing so, we have made the protocol security hard to define and harder to implement properly. The document was written largely with the requirement to use client authentication with any request to the access token endpoint. However, it does allow unauthenticated requests in section 3.

Are there any other client properties than the client's ability to authenticate with regards to security?

We have one grant type without client authentication (implicit), two with optional authentication (authorization code and username/password), and one with required authentication (client credentials).

I would like to go back to requiring client authentication for the access token endpoint, using HTTP Basic or other schemes. To leave the door open for clients incapable of authenticating to use the endpoint, we will add a security consideration section discussing the ramifications of using the access token endpoint without client authentication.

This suggestions is linked to the topic of refresh tokens which I'll post separately.

EHL

---

From: Brian Campbell <[email-masked]>
Date: Wed, 15 Jun 2011 12:47:20 -0600

Also seems this is related to the topic of native/mobile clients.  As I
understand it, native apps using the authorization code grant/flow have been
the primary motivator for keeping client authentication optional.  Anonymous
client have come up too.

On Wed, Jun 15, 2011 at 11:26 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> Client authentication has been one of the main problem areas in OAuth 1.0
> and 2.0 does nothing to resolve it (arguably, it makes it more confusing).
>
>
>
> Because of the desire to allow any client type in any deployment
> environment, we ended up with a barely defined client authentication model.
> We offer password-based client authentication using HTTP Basic (and an
> alternative parameter), but leave it optional.
>
>
>
> It has been suggested that by doing so, we have made the protocol security
> hard to define and harder to implement properly. The document was written
> largely with the requirement to use client authentication with any request
> to the access token endpoint. However, it does allow unauthenticated
> requests in section 3.
>
>
>
> Are there any other client properties than the client’s ability to
> authenticate with regards to security?
>
>
>
> We have one grant type without client authentication (implicit), two with
> optional authentication (authorization code and username/password), and one
> with required authentication (client credentials).
>
>
>
> I would like to go back to requiring client authentication for the access
> token endpoint, using HTTP Basic or other schemes. To leave the door open
> for clients incapable of authenticating to use the endpoint, we will add a
> security consideration section discussing the ramifications of using the
> access token endpoint without client authentication.
>
>
>
> This suggestions is linked to the topic of refresh tokens which I’ll post
> separately.
>
>
>
> EHL
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 15 Jun 2011 12:58:12 -0700

Well, that's where this is coming from...

Client registration needs to be defined, and it should be specific about the requirements for clients capable of authentication vs. not, as well as the redirection URI registration requirements for using the implicit grant type (see other message).

We need to be clear about the value of client authentication, and what does it enables us to do.

The only value I know of for client authentication is when using an authorization code, it prevents others from stealing the code and using it. This enables the authorization server to present information about the client to the user with more confidence which helps the user make better decisions.

But I have no idea why we need client authentication for using a refresh token?

I can see the value of using client authentication with the username/password grant type, to restrict most clients from being allowed to use this flow, but at the same time, the most likely clients to use this grant type are those who cannot authentication (native applications).

This is goo.

EHL

From: Brian Campbell [mailto:[email-masked]]
Sent: Wednesday, June 15, 2011 11:47 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Client authentication requirement

Also seems this is related to the topic of native/mobile clients.  As I understand it, native apps using the authorization code grant/flow have been the primary motivator for keeping client authentication optional.  Anonymous client have come up too.

On Wed, Jun 15, 2011 at 11:26 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
Client authentication has been one of the main problem areas in OAuth 1.0 and 2.0 does nothing to resolve it (arguably, it makes it more confusing).

EHL

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

---

From: Brian Eaton <[email-masked]>
Date: Wed, 15 Jun 2011 13:52:48 -0700

> We have one grant type without client authentication (implicit)

I suspect another choice of words would be useful there.  Implicit grants
rely on the browser's authentication of the receiving web site.  When https
is used, that authentication is fairly strong.

> I would like to go back to requiring client authentication for the access
token endpoint

Sure.  Why not?

1) It makes the spec simpler.
2) It has no impact on the security of clients that can't keep secrets.
3) It has no impact on the security of clients that can keep secrets.

> But I have no idea why we need client authentication for using a refresh
token?

****

This is covered here:
http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html.

Cheers,
Brian

On Wed, Jun 15, 2011 at 12:58 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> Well, that’s where this is coming from…****
>
> ** **
>
> Client registration needs to be defined, and it should be specific about
> the requirements for clients capable of authentication vs. not, as well as
> the redirection URI registration requirements for using the implicit grant
> type (see other message).****
>
> ** **
>
> We need to be clear about the value of client authentication, and what does
> it enables us to do.****
>
> ** **
>
> The only value I know of for client authentication is when using an
> authorization code, it prevents others from stealing the code and using it.
> This enables the authorization server to present information about the
> client to the user with more confidence which helps the user make better
> decisions.****
>
> ** **
>
> But I have no idea why we need client authentication for using a refresh
> token?****
>
> ** **
>
> I can see the value of using client authentication with the
> username/password grant type, to restrict most clients from being allowed to
> use this flow, but at the same time, the most likely clients to use this
> grant type are those who cannot authentication (native applications).****
>
> ** **
>
> This is goo.****
>
> ** **
>
> EHL****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Brian Campbell [mailto:[email-masked]]
> *Sent:* Wednesday, June 15, 2011 11:47 AM
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG
> *Subject:* Re: [OAUTH-WG] Client authentication requirement****
>
> ** **
>
> ****
> On Wed, Jun 15, 2011 at 11:26 AM, Eran Hammer-Lahav <[email-masked]>
> wrote:****
>
> ****
>  ****
> alternative parameter), but leave it optional.****
>
>  ****
>
> requests in section 3.****
>
>  ****
>
> authenticate with regards to security?****
>
>  ****
>
> with required authentication (client credentials). ****
>
>  ****
>
> access token endpoint without client authentication.****
>
>  ****
>
> separately.****
>  ****
> EHL****
>  ****
> https://www.ietf.org/mailman/listinfo/oauth****
>
> ** **
>

---

From: Shane B Weeden <[email-masked]>
Date: Thu, 16 Jun 2011 08:50:50 +1000

Eran: > > I would like to go back to requiring client authentication for
the access token endpoint

Brian: > Sure.  Why not?
> 3) It has no impact on the security of clients that can keep secrets.

Brain - can you elaborate on that a little? Are you suggesting that clients
that can't keep secrets use a dummy (notasecret) pwd anyway to satisfy
"requiring client authentication"?

I can't see any point in the spec saying client authentication is required
if it doesn't add value in a way that can be explained to everyone (eg.
what you said in
http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html about
rolling over the client secret to deal with compromised refresh tokens).

What seems to be missing in the discussion and the security considerations
of the spec is a decent list of general and grant-type-specific security
implications/pros/cons for the system if meaningful client authentication
at the token endpoint is available or not available.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 15 Jun 2011 17:21:05 -0700

> -----Original Message-----
> From: Brian Eaton [mailto:[email-masked]]
> Sent: Wednesday, June 15, 2011 1:53 PM
> To: Eran Hammer-Lahav
> Cc: Brian Campbell; OAuth WG
> I suspect another choice of words would be useful there.  Implicit grants rely
> on the browser's authentication of the receiving web site.  When https is
> used, that authentication is fairly strong.

"authentication of the receiving web site"? Authentication how, and what is a receiving web site?

The implicit grant relies on the presence of the user to "vouch" for the client by making the connection of how it got to the authorization server and what she is being asked to approve. In other words, the user does something that lands her in front an authorization page. If that page makes sense to her in that flow, she approves access to the party that got her there.

What does HTTPS has to do with this?

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 15 Jun 2011 17:27:14 -0700

> This is covered here: http://www.ietf.org/mail-
> archive/web/oauth/current/msg06362.html.

So basically, it is authentication on top of bearer credentials to achieve another level of security. Are we just assuming that stealing the refresh token will be harder than stealing the client credentials? Seems a bit optimistic.

Both client secret and refresh token are sent in plain text over TLS during the same client-server interaction. If there is a problem with TLS, both secrets are exposed. The client is more likely to store its client secret in source code or local storage because it rarely changes, as opposed to storing the refresh token in some other cache or database. I can't figure out which one will be harder to steal.

What attack vector is requiring client authentication when using the refresh token protects against?

EHL

---

From: Brian Eaton <[email-masked]>
Date: Wed, 15 Jun 2011 17:29:28 -0700

On Wed, Jun 15, 2011 at 5:21 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> rely
> The implicit grant relies on the presence of the user to "vouch" for the
> client by making the connection of how it got to the authorization server
> and what she is being asked to approve. In other words, the user does
> something that lands her in front an authorization page. If that page makes
> sense to her in that flow, she approves access to the party that got her
> there.
>

Security for the implicit grant type comes from identifying the client based
on the redirect URI.  At client registration time, you bind client_id X to
redirect URIs Y and Z.

If the redirect URIs use HTTPs, that gives you reasonable security.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 15 Jun 2011 17:32:33 -0700

Ok. That makes sense and in line with my other thread about implicit grant and registration.

So if a callback is not registered, we are basically at the mercy of the user not being an idiot.

Seems like a good reason to require redirection URI registration for implicit grant clients.

EHL

From: Brian Eaton [mailto:[email-masked]]
Sent: Wednesday, June 15, 2011 5:29 PM
To: Eran Hammer-Lahav
Cc: Brian Campbell; OAuth WG
Subject: Re: [OAUTH-WG] Client authentication requirement

Security for the implicit grant type comes from identifying the client based on the redirect URI.  At client registration time, you bind client_id X to redirect URIs Y and Z.

---

From: Brian Eaton <[email-masked]>
Date: Wed, 15 Jun 2011 17:33:01 -0700

On Wed, Jun 15, 2011 at 5:27 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> So basically, it is authentication on top of bearer credentials to achieve
> another level of security. Are we just assuming that stealing the refresh
> token will be harder than stealing the client credentials? Seems a bit
> optimistic.
>
> Both client secret and refresh token are sent in plain text over TLS during
> the same client-server interaction. If there is a problem with TLS, both
> secrets are exposed. The client is more likely to store its client secret in
> source code or local storage because it rarely changes, as opposed to
> storing the refresh token in some other cache or database. I can't figure
> out which one will be harder to steal.
>

Requiring client authentication doesn't defend against attacks directly; it
makes recovery after a successful attack easier.

If you use the assertion profiles for OAuth2, then it also binds the refresh
token to private keys that are much easier to store securely than client
secrets.

---

From: Brian Eaton <[email-masked]>
Date: Wed, 15 Jun 2011 17:36:18 -0700

> "requiring client authentication"?

Or use random secrets.  Whatever floats your boat and keeps your product
managers happy.  It does not make a practical security difference for
installed applications.

> at the token endpoint is available or not available.

Yep.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 15 Jun 2011 18:02:40 -0700

How does it make recovery easier? Why is revoking refresh token any harder than changing client secret?

As for the assertion grant type, where is the specified that the refresh token is bound to the private keys used to produce the assertion used to obtain the refresh token in the first place?

EHL

From: Brian Eaton [mailto:[email-masked]]
Sent: Wednesday, June 15, 2011 5:33 PM
To: Eran Hammer-Lahav
Cc: Brian Campbell; OAuth WG
Subject: Re: [OAUTH-WG] Client authentication requirement

On Wed, Jun 15, 2011 at 5:27 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
So basically, it is authentication on top of bearer credentials to achieve another level of security. Are we just assuming that stealing the refresh token will be harder than stealing the client credentials? Seems a bit optimistic.

Requiring client authentication doesn't defend against attacks directly; it makes recovery after a successful attack easier.

If you use the assertion profiles for OAuth2, then it also binds the refresh token to private keys that are much easier to store securely than client secrets.

---

From: Brian Eaton <[email-masked]>
Date: Wed, 15 Jun 2011 18:14:54 -0700

> than changing client secret?

Changing a client secret can be done without disrupting users.  You can even
schedule it, do it every 30 days as part of your general operational
procedures.  It's part of a healthy system.

Revoking refresh tokens every 30 days is not really feasible.

> As for the assertion grant type, where is the specified that the refresh
> token is bound to the private keys used to produce the assertion used to
> obtain the refresh token in the first place?
>

Well, the spec currently has refresh tokens bound to client ids.

And the assertion spec proposal authenticated client ids with public/private
key pairs.

You wouldn't bind the refresh token directly to a private key, for the same
reason that you don't bind the refresh token directly to the client secret.
 You bind refresh tokens to clients, and then you require client
authentication.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 15 Jun 2011 18:19:25 -0700

Your comment was that having client authentication makes it easier to recovery from an attack. I don't understand how the comments below about changing client secrets every 30 days are relevant. Are you suggesting to wait until the next routine secret cycle to revoke compromised credentials? Or that 30 days is a reasonable time period for ignoring an attack?

EHL

From: Brian Eaton [mailto:[email-masked]]
Sent: Wednesday, June 15, 2011 6:15 PM
To: Eran Hammer-Lahav
Cc: Brian Campbell; OAuth WG
Subject: Re: [OAUTH-WG] Client authentication requirement

On Wed, Jun 15, 2011 at 6:02 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
How does it make recovery easier? Why is revoking refresh token any harder than changing client secret?

Changing a client secret can be done without disrupting users.  You can even schedule it, do it every 30 days as part of your general operational procedures.  It's part of a healthy system.

And the assertion spec proposal authenticated client ids with public/private key pairs.

You wouldn't bind the refresh token directly to a private key, for the same reason that you don't bind the refresh token directly to the client secret.  You bind refresh tokens to clients, and then you require client authentication.

---

From: Shane B Weeden <[email-masked]>
Date: Thu, 16 Jun 2011 11:28:35 +1000

Brian Eaton <[email-masked]> wrote on 16-06-2011 10:36:18 AM:

> From: Brian Eaton <[email-masked]>
> To: Shane B Weeden/Australia/IBM@IBMAU
> Cc: OAuth WG <[email-masked]>
> Date: 16-06-11 10:49 AM
> Or use random secrets.  Whatever floats your boat and keeps your
> product managers happy.  It does not make a practical security
> difference for installed applications.

That is the same thing as not requiring client authentication at all (for
installed applications). Having the spec say client authentication is
REQUIRED for the token endpoint is therefore misleading and nonsensical.

> at the token endpoint is available or not available.

I believe this piece of work would go a long way to settling the disputes
about when/why/if client authentication should be required at the token
endpoint. For example I would like to see attempts to answer this question:
If client authentication is not possible or required at the token endpoint
for native/installed apps, what advantages are gained from requiring it for
clients that can authenticate?

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 16 Jun 2011 11:08:46 -0400

Apologies for the late response.

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eran Hammer-Lahav
> Sent: Wednesday, June 15, 2011 1:27 PM
> To: OAuth WG
> Subject: [OAUTH-WG] Client authentication requirement
> 
> Client authentication has been one of the main problem areas in OAuth
> 1.0 and 2.0 does nothing to resolve it (arguably, it makes it more
> confusing).
> 
> environment, we ended up with a barely defined client authentication
> model. We offer password-based client authentication using HTTP Basic
> (and an alternative parameter), but leave it optional.

I would to suggest that perhaps we need a better definition of the "client" by way of identifying one or two (or three) types of clients and listing their respective security properties/capabilities. For example, if a client can/cannot keep cryptographic keys (secrets), then say so. Similarly, if a client can do TLS but cannot do proper X509 processing, then list this, etc. etc.

In this way developers can at least map (in the minds) which client type matches their deployment scenario, based on the best-match capabilities list.

> I would like to go back to requiring client authentication for the
> access token endpoint, using HTTP Basic or other schemes. To leave the
> door open for clients incapable of authenticating to use the endpoint,
> we will add a security consideration section discussing the
> ramifications of using the access token endpoint without client
> authentication.
> 

+1 agree that client authentication (to access token endpoint) should be made a requirement. 

/thomas/

---

From: Brian Eaton <[email-masked]>
Date: Thu, 16 Jun 2011 08:37:53 -0700

On Wed, Jun 15, 2011 at 6:19 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> Your comment was that having client authentication makes it easier to
> recovery from an attack. I don’t understand how the comments below about
> changing client secrets every 30 days are relevant. Are you suggesting to
> wait until the next routine secret cycle to revoke compromised credentials?
> Or that 30 days is a reasonable time period for ignoring an attack?
>

Sorry, there are multiple good reasons to require client authentication for
the access token endpoint.

- if you need to recover from a compromise, changing the client credentials
will prevent the attacker from abusing refresh tokens they have stolen.
 Changing a single client credential is much faster than revoking lots of
refresh tokens.

- if you want to follow best practices for management of authentication
credentials, you should do periodic key rotation.  Rotation of lots of
refresh tokens is quite challenging.  Rotation of client credentials is much
easier.

- if you want to bind refresh tokens to stronger authentication credentials,
such as private keys stored in an HSM, you need to require client
authentication when using the refresh token.

Is that helpful?

Cheers,
Brian

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 16 Jun 2011 11:48:26 -0400

Eran:
I think the issue of refreshing tokens should be a configurable parameter (security policy) that the authorization server  (ie. admin managing it) sets. Perhaps the parameter value should be advertised in the "service documentation" of the authorization end-point.  So the client can choose to accept or walkaway when it sees this parameter (depending on its own security policies). Changing keying material is necessary to prevent crypto-attacks on stale keys.

Just to give an idea about timing: many large scale Kerberos infra require the user to get a new TGT every 24-hours, and some even sooner.

Brian:
I don't fully understand your earlier email:

>>> Requiring client authentication doesn't defend against 
>>> attacks directly; it makes recovery after a successful 
>>> attack easier.

I presume you mean direct attacks on the authorization server. 
But wouldn't requiring OAuth clients to authenticate (in 
some manner to the authorization server) at least reduce
the opportunity for DOS attacks to the authorization server.

Thanks.

/thomas/

_____________

> Sent: Wednesday, June 15, 2011 9:19 PM
> To: Brian Eaton
> Cc: OAuth WG
> recovery from an attack. I don't understand how the comments below
> about changing client secrets every 30 days are relevant. Are you
> suggesting to wait until the next routine secret cycle to revoke
> compromised credentials? Or that 30 days is a reasonable time period
> for ignoring an attack?
> 
> EHL
> 
> On Wed, Jun 15, 2011 at 6:02 PM, Eran Hammer-Lahav
> <[email-masked]> wrote:
> Changing a client secret can be done without disrupting users.  You can
> even schedule it, do it every 30 days as part of your general
> operational procedures.  It's part of a healthy system.
> 
> As for the assertion grant type, where is the specified that the
> refresh token is bound to the private keys used to produce the
> assertion used to obtain the refresh token in the first place?
> 
> You wouldn't bind the refresh token directly to a private key, for the
> same reason that you don't bind the refresh token directly to the
> client secret.  You bind refresh tokens to clients, and then you
> require client authentication.

---

From: Brian Eaton <[email-masked]>
Date: Thu, 16 Jun 2011 08:51:03 -0700

> I presume you mean direct attacks on the authorization server.

Also attacks on the clients.

> the opportunity for DOS attacks to the authorization server.

One more reason to use client authentication for the access token endpoint.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 16 Jun 2011 21:31:31 +0200

> at the token endpoint is available or not available.

What about this? 
http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01

regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 16 Jun 2011 21:42:18 +0200

-1 making client authentication required at the access token endpoint

Client authentication is useful in some situations to raise the security 
level. But requiring it will either keep out native apps or force there 
developers to use useless/insecure secrets (I would call this "pseudo 
security").

+1 making the client authentication required for certain client types.

for a definition of client types and there respective security 
properties see http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10

In my opinion, the security considerations section already gives a clear 
guideline when client authentication should be used and when the authz 
server should rely on other mechanims.

regards,
Torsten.

---

From: Brian Eaton <[email-masked]>
Date: Thu, 16 Jun 2011 12:46:59 -0700

> developers to use useless/insecure secrets (I would call this "pseudo

Are you seriously arguing that including the phrase "notasecret" in the
request would make native applications less secure?

---

From: Justin Richer <[email-masked]>
Date: Thu, 16 Jun 2011 15:45:41 -0400

Agree with Torsten -- I would hate for us to repeat the
"anonymous/anonymous" thing that Google implemented for OAuth1.

 -- Justin

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 16 Jun 2011 21:56:31 +0200

Certainly not. Are we discussing to make client authentication required 
just for syntactical purposes?

To me, "notasecret" logically means to abandon on client authentication.

regards,
Torsten.

Am 16.06.2011 21:46, schrieb Brian Eaton:
> On Thu, Jun 16, 2011 at 12:42 PM, Torsten Lodderstedt 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Client authentication is useful in some situations to raise the
>     security level. But requiring it will either keep out native apps
>     or force there developers to use useless/insecure secrets (I would
>     call this "pseudo security").
>
>
> Are you seriously arguing that including the phrase "notasecret" in 
> the request would make native applications less secure?

---

From: Brian Eaton <[email-masked]>
Date: Thu, 16 Jun 2011 13:02:23 -0700

On Thu, Jun 16, 2011 at 12:56 PM, Torsten Lodderstedt <
[email-masked]> wrote:

> **

That is what I'd like to see.

>From my perspective, no harm is done by making client authentication a
syntactical requirement of the protocol.

- clients that can't keep secrets aren't harmed; they have the exact same
security they do today.
- everyone else benefits because the spec becomes simpler and more
consistent.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 16 Jun 2011 22:05:47 +0200

Am 16.06.2011 22:02, schrieb Brian Eaton:
> On Thu, Jun 16, 2011 at 12:56 PM, Torsten Lodderstedt 
>     Certainly not. Are we discussing to make client authentication
>     required just for syntactical purposes?
>
>
> - clients that can't keep secrets aren't harmed; they have the exact 
> same security they do today.

No, it's not simpler nor clearer. Such a client secret is useless, so 
the security implications have to be explained anyway. Moreover, 
whatever the spec will state people would start to _rely_ on client 
secrets even for native apps, which is a really bad idea.

regards,
Torsten.

---

From: Justin Richer <[email-masked]>
Date: Thu, 16 Jun 2011 16:19:05 -0400

> >         Certainly not. Are we discussing to make client
> >         authentication required just for syntactical purposes? 
> > 
> > From my perspective, no harm is done by making client authentication
> > a syntactical requirement of the protocol.
> > 
> > 

Not only does it give the wrong impression for developers using this, it
forces client developers to use a pattern that doesn't make sense. I
really don't like the approach of "if you're not going to really use
this, then use this well-known dummy value instead." I'd rather have the
useless bits simply not sent instead of filled in with nonsense values. 

This is getting back to the one-size-fits-all OAuth 1.0 approach that we
were trying to get *away* from here. At least, I thought we were.

 -- Justin

---

From: Brian Eaton <[email-masked]>
Date: Thu, 16 Jun 2011 13:20:53 -0700

On Thu, Jun 16, 2011 at 1:05 PM, Torsten Lodderstedt <
[email-masked]> wrote:

> **
> No, it's not simpler nor clearer. Such a client secret is useless, so the
> security implications have to be explained anyway.
>

The issue really isn't the security implications being unclear; the issue is
that the normative language that describes the protocol flows is ambiguous.

Moreover, whatever the spec will state people would start to _rely_ on
> client secrets even for native apps, which is a really bad idea.
>

OK, so you are arguing that baking the string "notasecret" into a client
application makes that client application less secure.  That's not really
plausible.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 16 Jun 2011 22:25:25 +0200

no I'm saying people will use real secrets and rely on them - just as 
with OAuth 1.0

Am 16.06.2011 22:20, schrieb Brian Eaton:
> On Thu, Jun 16, 2011 at 1:05 PM, Torsten Lodderstedt 
>     No, it's not simpler nor clearer. Such a client secret is useless,
>     so the security implications have to be explained anyway.
>
>
> The issue really isn't the security implications being unclear; the 
> issue is that the normative language that describes the protocol flows 
> is ambiguous.
>
>     Moreover, whatever the spec will state people would start to
>     _rely_ on client secrets even for native apps, which is a really
>     bad idea.
>
>
> OK, so you are arguing that baking the string "notasecret" into a 
> client application makes that client application less secure.  That's 
> not really plausible.

---

From: Brian Eaton <[email-masked]>
Date: Thu, 16 Jun 2011 13:30:31 -0700

On Thu, Jun 16, 2011 at 1:25 PM, Torsten Lodderstedt <
[email-masked]> wrote:

> **
> no I'm saying people will use real secrets and rely on them - just as with
> OAuth 1.0
>

=)

People are going to ignore what the spec says on this.  If you read through
the mailing list threads on this topic, you'll notice several people have
stated quite clearly that they are going to be baking secrets into installed
applications, and that they think they have reasonable mitigations in place
for the security risk.

It's not that those people are dumb, either.  They understand exactly what
they are doing.  And their native applications are not going to be any less
secure because of the choices they are making.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 16 Jun 2011 22:49:58 +0200

Am 16.06.2011 22:30, schrieb Brian Eaton:
> On Thu, Jun 16, 2011 at 1:25 PM, Torsten Lodderstedt 
>     no I'm saying people will use real secrets and rely on them - just
>     as with OAuth 1.0
>
>
> =)
>
> People are going to ignore what the spec says on this.  If you read 
> through the mailing list threads on this topic, you'll notice several 
> people have stated quite clearly that they are going to be baking 
> secrets into installed applications, and that they think they have 
> reasonable mitigations in place for the security risk.
>
> It's not that those people are dumb, either.  They understand exactly 
> what they are doing.  And their native applications are not going to 
> be any less secure because of the choices they are making.

If those people have reasonable means in place to protect secrets on 
deployment channels and in the local installation - fine. I would be 
eager to learn more about those means because I would be willed to 
utilize them as well.

My current assumption is that in a open market scenario secrets can be 
reverse engineered from binary or source code. Since the same secret is 
used for all installations of the same software, an attacker can utilize 
it to built a counterfeit app. Because of this risk, I would not 
recommend to rely on the secret for authenticating such an app.

The situation may vary for corporate/enterprise scenarios, where an 
application can be installed by an administrator and equiped with an 
installation specific id/secret during this process. In that case, the 
authz server can rely on the secret for authenticating and authorizing 
the client.

That's why the security considerations section states:

    ... The authorization server MAY issue
    a client password or other credentials for a specific installation of
    a native application on a specific device.

regards,
Torsten.

---

From: Brian Eaton <[email-masked]>
Date: Thu, 16 Jun 2011 13:51:52 -0700

On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodderstedt <
[email-masked]> wrote:

> deployment channels and in the local installation - fine. I would be eager
> to learn more about those means because I would be willed to utilize them as
> well.
>

No, they don't have anything that really protects the secrets.  They are
just willing to accept the risk.

In particular, they realize that having the client application present a
secret doesn't increase the risk at all.

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 16 Jun 2011 17:14:57 -0400

On 6/16/2011 4:51 PM, Brian Eaton wrote:
> On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodderstedt 
>     If those people have reasonable means in place to protect secrets
>     on deployment channels and in the local installation - fine. I
>     would be eager to learn more about those means because I would be
>     willed to utilize them as well.
>
>
> No, they don't have anything that really protects the secrets.  They 
> are just willing to accept the risk.
And what about the people who are not willing to accept the risk?  (I am 
one of them!)

Igor

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 16 Jun 2011 17:16:32 -0400

I agree with the factual information, but I disagree with the conclusion.

Indeed, there were postings from people who will "bake secrets into 
installed applications."  But there have also been postings from people 
(like Torsten and me) who said they "will use real secrets and rely on 
them."

I don't see why the latter group has to be ignored, but I surely 
disagree that "people are going to ignore what the spec says on this."

Igor

---

From: Brian Eaton <[email-masked]>
Date: Thu, 16 Jun 2011 15:10:46 -0700

> And what about the people who are not willing to accept the risk?  (I am

If you aren't willing to accept the risk of native apps that can't keep
secrets, don't support such apps.  You're done.

What the spec says does not impact what risk you need to take on.

---

From: Dave Nelson <[email-masked]>
Date: Fri, 17 Jun 2011 07:41:29 -0400

> secrets, don't support such apps.

We continue to say "can't keep secrets".  I think what we mean is
"can't keep secrets that are embedded in the code".  One could imagine
an install-time, leap-of-faith binding to a remotely received secret,
via some on-line registration process, that the native app asks the
operating system to store for it securely.  The user can make an
assertion of trust in the validity of the app that he/she has
downloaded and is subsequently installing.  Of course, that initial
faith might be misplaced, but that's true of almost all
user-installable software, even that receive on physical media.  If
browsers are trusted to store secrets securely, then that same
capability is available to native apps.

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Shane B Weeden <[email-masked]>
Date: Fri, 17 Jun 2011 22:14:58 +1000

As I understand it, what you've described is precisely the intent of the
refresh token. The online registration process you refer to is a
corresponding one-time authorization code flow. The authorization code
effectively becomes a one-time-use, short-lived credential for the client
instance which it should use immediately (since it has been exposed to the
resource owner via the user-agent in getting to the client) to directly
request an access token (typically short-lived and may not be needed
immediately) and refresh token (typically long-lived). The refresh token is
stored securely locally. It is essentially an instance secret bound to the
client id and representing the original resource owner grant. Provided:
1. The resource owner and user-agent safely deliver the authorization code
to the client instance in first place
2. The client uses it immediately in secure transport-level communications
to the authorization server and then securely stores the long-lived refresh
token
3. The client always uses the refresh token in secure transport-level
communications to the authorization server to get an access token (and
optionally rollover the refresh token)
.. then securely authenticating the client doesn't seem to be a big deal.

I trust "the list" will correct me if that's a wrong interpretation of a
classic native app scenario.

It still leads to my question from some posts ago about why then is it
advantageous to require client authentication at all for the authorization
code flow in classic web app three-legged scenarios, and I am yet to fully
digest Torsten's response to that (
http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01). About the
only documented advantage I've seen to date has to do with the
recovery/next steps from a compromised refresh token, but the usefulness of
that idea has been debated as well.

From:	Dave Nelson <[email-masked]>
To:	Brian Eaton <[email-masked]>
Cc:	"[email-masked]" <[email-masked]>
Date:	17-06-11 09:45 PM
Subject:	Re: [OAUTH-WG] Client authentication requirement
Sent by:	[email-masked]

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 17 Jun 2011 17:31:04 +0200

>classic native app scenario.

I fully agree with your description.

>http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01).

I hope it was delicious :-). 
Pls. note: Mark & Phil were involved as well.

About
>the

In my opinion, there are the following advantages:
- the user can be provided with trustworthy information about the client
- the authentication is a further measure against guessing attacks on authz codes and refresh tokens (beside high entropy and short duration)
- it might make token theft more difficult given the secret is stored somewhere/somehow else than the refresh tokens

regards,
Torsten.

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 20 Jun 2011 13:59:53 -0400

> Of Torsten Lodderstedt
> Sent: Friday, June 17, 2011 11:31 AM
> To: Shane B Weeden; Dave Nelson
> Cc: [email-masked]
> >As I understand it, what you've described is precisely the intent of
> >the refresh token. The online registration process you refer to is a
> >effectively becomes a one-time-use, short-lived credential for the
> >client instance which it should use immediately (since it has been
> >exposed to the resource owner via the user-agent in getting to the
> >client) to directly request an access token (typically short-lived and
> >may not be needed
> >immediately) and refresh token (typically long-lived). The refresh
> >token is stored securely locally. It is essentially an instance secret
> >bound to the client id and representing the original resource owner
> >grant. Provided:
> >1. The resource owner and user-agent safely deliver the authorization
> >code to the client instance in first place 2. The client uses it
> >immediately in secure transport-level communications to the
> >authorization server and then securely stores the long-lived refresh
> >token 3. The client always uses the refresh token in secure
> >transport-level communications to the authorization server to get an
> >access token (and optionally rollover the refresh token) .. then
> >securely authenticating the client doesn't seem to be a big deal.
> >
> >I trust "the list" will correct me if that's a wrong interpretation of
> >a classic native app scenario.
> 

Shane:
The issue is actually best summarized by your own email.  Client authentication is not needed provided (1), (2) and (3).  This is a lot of assumptions to rely on.

> >   1. The resource owner and user-agent safely deliver the 
> >   authorization  code to the client instance in first place

What does "safely deliver" mean? How is it implemented and deployed?

> >   2. The client uses it
> >   immediately in secure transport-level communications 
> >   to the authorization server and then securely stores 
> >   the long-lived refresh token.

What is the time-limit for "immediately"? (60 secs, 30 mins, 24hr?).

> >   3. The client always uses the refresh token in secure
> >   transport-level communications to the authorization 
> >   server to get an access token

Oauth2.0-draft16 only devotes two lines to X509 certificates (Section 10.6), for the authorization-server and client interaction.  Its not clear how binding is done (eg. binding of the TLS session and transaction), for example for audit/logging purposes. 

/thomas/

---

From: Shane B Weeden <[email-masked]>
Date: Wed, 22 Jun 2011 09:08:04 +1000

One might argue these are deployment-time considerations rather than spec
issues.

From:	Thomas Hardjono <[email-masked]>
To:	Shane B Weeden/Australia/IBM@IBMAU
Cc:	"[email-masked]" <[email-masked]>
Date:	21-06-11 04:03 AM
Subject:	RE: [OAUTH-WG] Client authentication requirement

> I fully agree with your description.

Shane:
The issue is actually best summarized by your own email.  Client
authentication is not needed provided (1), (2) and (3).  This is a lot of
assumptions to rely on.

> >   server to get an access token

Oauth2.0-draft16 only devotes two lines to X509 certificates (Section
10.6), for the authorization-server and client interaction.  Its not clear
how binding is done (eg. binding of the TLS session and transaction), for
example for audit/logging purposes.

/thomas/