Subject: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3

From: John Bradley <[email-masked]>
Date: Sun, 1 Jul 2012 17:21:47 -0400

Sec 4.1.2 states:

The authorization code is bound to the client identifier and redirection URI.

The security concern Sec 10.5 states

   If the client can be authenticated, the authorization servers MUST
   authenticate the client and ensure that the authorization code was
   issued to the same client.

Sec 3.2.1 
A public client that was not issued a client password MAY use the
   "client_id" request parameter to identify itself when sending
   requests to the token endpoint (e.g. for the purpose of providing
   end-user context, client usage statistics).

Nothing in the current spec requires that a Public client send it's client_id or redirect_uri to the token endpoint.
The client _id is only sent if it is a confidential client capable of authenticating itself.
The redirect_uri is only sent if the 'redirect_uri' parameter was included in the authorization request.
If the client has one registered redirect_uri it would not be sent to the authorization or token endpoint.

This leaves us with public clients using code flow that cannot determine if a token was granted to them or some other public client.

I propose changing Sec 3.2.1 to read:

A public client that was not issued a client password MUST use the
   "client_id" request parameter to identify itself when sending
   requests to the token endpoint. This allows the authorization server 
   to ensure that the code was issued to the same client.  
   Sending "client_id" prevents the client from
   inadvertently accepting a code intended for a client with a different
   "client_id".

Also change Sec 4.1.3 from:
o  authenticate the client if client authentication is included and
      ensure the authorization code was issued to the authenticated
      client,

To:
o  authenticate the client if client authentication is included,
o  ensure the authorization code was issued to the authenticated 
   confidential client or to the public client identified by the
  'client_id',

The Original text implies that it is a good idea to send it, but is unclear on what security it provides.

It is a small change that should not brake existing implementations, but will increase security for public clients using the code flow.

Regards
John B.

---

From: Mike Jones <[email-masked]>
Date: Mon, 2 Jul 2012 15:17:18 +0000

I believe we should adopt this revised text.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Sunday, July 01, 2012 2:22 PM
To: [email-masked] WG
Subject: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3

Sec 4.1.2 states:

Sec 3.2.1

   "client_id".

      client,

To:

  'client_id',

Regards

John B.

---

From: Phil Hunt <[email-masked]>
Date: Mon, 2 Jul 2012 08:25:16 -0700

+1

Phil

On 2012-07-02, at 8:17, Mike Jones <[email-masked]> wrote:

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

---

From: Justin Richer <[email-masked]>
Date: Mon, 2 Jul 2012 11:32:15 -0400

I'm generally OK with the change, though it does change One problem I 
have with this is that it can give a false sense of security about the 
information being sent to the token endpoint and how trustworthy it is. 
A client_id is public knowledge, and so someone impersonating a client 
on the Authentication Endpoint could also impersonate it on the Token 
Endpoint just as easily. This is not the attack that's being addressed 
here, and the possible phishing vector in the one I'm describing is both 
well known and, I believe, well covered by the existing documents. 
However, I think the new text might confuse people into conflating these 
two.

Basically, I think it needs to be made very clear, especially with this 
change of text, that a client_id on its own should never be taken as 
sufficient for authentication of the client. The context of the user's 
decision, among other things, is as important as a client secret.

  -- Justin

On 07/02/2012 11:17 AM, Mike Jones wrote:
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *John Bradley
> *Sent:* Sunday, July 01, 2012 2:22 PM
> *To:* [email-masked] WG
> *Subject:* [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3
>
> Sec 4.1.2 states:
>

---

From: John Bradley <[email-masked]>
Date: Mon, 2 Jul 2012 12:16:46 -0400

Using the code flow with a public client in itself creates a false sense of security.

I suspect that most developers think public == implicit and confidential == code.
While it is clear that there is a whole group of native apps that are public using the code flow.
For those clients the registered redirect URI is the only security.

This change adds a bit of protection for the client against an attacker swapping code in the message to gain privilege.

I agree that it adds no additional protection for the protected resource. (That is the reason it was not originally included I am guessing)

Confidential clients being protected from code being swapped,  is mostly a side effect of protecting code from being stolen over non TLS connections.

While I do appreciate the problem of making something incrementally safer but not safe,  I don't think it is a good idea to leave something vulnerable to a known attack that can be easily fixed.

In some ways not fixing this and just saying:
OAuth MUST NOT be used as a form of delegated end-user authentication by the client (e.g. third-party sign-in service).

The obvious problem with that is that people will just ignore it.

John B.
On 2012-07-02, at 11:32 AM, Justin Richer wrote:

> I'm generally OK with the change, though it does change One problem I have with this is that it can give a false sense of security about the information being sent to the token endpoint and how trustworthy it is. A client_id is public knowledge, and so someone impersonating a client on the Authentication Endpoint could also impersonate it on the Token Endpoint just as easily. This is not the attack that's being addressed here, and the possible phishing vector in the one I'm describing is both well known and, I believe, well covered by the existing documents. However, I think the new text might confuse people into conflating these two.
> 
> Basically, I think it needs to be made very clear, especially with this change of text, that a client_id on its own should never be taken as sufficient for authentication of the client. The context of the user's decision, among other things, is as important as a client secret.
> 
>  -- Justin
>

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 2 Jul 2012 21:38:58 +0000

Not sure why this has to be a MUST in section 3.2.1 as the token endpoint has to the choice to reject it either way (provided or not)

Sec 4.1.2 states:

Sec 3.2.1

   "client_id".

      client,

To:

  'client_id',

Regards

John B.

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 2 Jul 2012 21:45:24 +0000

While the client may be forced to provide the client_id there are no requirements for the endpoint to process the client_id (or how that is done) so not sure what good the change actually does

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Monday, July 02, 2012 8:32 AM
To: [email-masked]
Subject: Re: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3

 -- Justin

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Sunday, July 01, 2012 2:22 PM
To: [email-masked]<mailto:[email-masked]> WG
Subject: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3

Sec 4.1.2 states:

Sec 3.2.1

   "client_id".

      client,

To:

  'client_id',

Regards

John B.

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Mon, 2 Jul 2012 17:51:06 -0400

The token endpoint can always reject it.

The issue is if the client can count on it being rejected if the client_id is wrong.

If the Authorization server is allowed to not to compare the client_id  to the one it issued the token to there is no point in making the change.

As Justin pointed out leaving it insecure to discourage people from using this flow is also an option. 

This just mitigates against one attack on public clients using the code flow.   At the end of the day a confidential client is going to be more secure.

John B.

---

From: John Bradley <[email-masked]>
Date: Mon, 2 Jul 2012 17:54:14 -0400

The change to 4.1.3 requires the endpoint to process it.  At least as much as the the text for the Confidential client is requiring it.

John B.

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 2 Jul 2012 22:02:24 +0000

I read 4.1.3 as the client_id just has to have been issued to a  (or any) public client

From: John Bradley [mailto:[email-masked]]
Sent: Monday, July 02, 2012 2:54 PM
To: Anthony Nadalin
Cc: Justin Richer; [email-masked]
Subject: Re: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3

John B.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Justin Richer
Sent: Monday, July 02, 2012 8:32 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3

 -- Justin

                                                            -- Mike

Sec 4.1.2 states:

Sec 3.2.1

   "client_id".

      client,

To:

  'client_id',

Regards

John B.

OAuth mailing list

---

From: John Bradley <[email-masked]>
Date: Mon, 2 Jul 2012 18:15:01 -0400

Would this be clearer:

   ensure the authorization code was issued to the authenticated 
   confidential client, or to the public client identified by the
  'client_id' in the request,

The intent is always that the code must be presented by the client to which it was issued.  That is acceded by authenticating the client in the confidential case and by inspecting the client_id in the public case.

Yes a client can always fake a client_id in the public case, so it is not intended to protect the protected resource, only the client from token substitution.

John B.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 3 Jul 2012 15:41:35 -0600

That seems clear enough.

Perhaps also saying something along the lines of your last sentence
(saying that including the client_id only protects the client from
substitution of the authorization code) would help address the concern
Justin raised?

On Mon, Jul 2, 2012 at 4:15 PM, John Bradley <[email-masked]> wrote:
> The intent is always that the code must be presented by the client to which
> it was issued.  That is acceded by authenticating the client in the
> confidential case and by inspecting the client_id in the public case.
>
>
> Yes a client can always fake a client_id in the public case, so it is not
> intended to protect the protected resource, only the client from token
> substitution.
>
>
> John B.
>
>
>
>
> The change to 4.1.3 requires the endpoint to process it.  At least as much
> as the the text for the Confidential client is requiring it.
>
> John B.
> While the client may be forced to provide the client_id there are no
> requirements for the endpoint to process the client_id (or how that is done)
> so not sure what good the change actually does
>
> I'm generally OK with the change, though it does change One problem I have
> with this is that it can give a false sense of security about the
> information being sent to the token endpoint and how trustworthy it is. A
> client_id is public knowledge, and so someone impersonating a client on the
> Authentication Endpoint could also impersonate it on the Token Endpoint just
> as easily. This is not the attack that's being addressed here, and the
> possible phishing vector in the one I'm describing is both well known and, I
> believe, well covered by the existing documents. However, I think the new
> text might confuse people into conflating these two.
>
> Nothing in the current spec requires that a Public client send it's
> client_id or redirect_uri to the token endpoint.
>
> This leaves us with public clients using code flow that cannot determine if
> a token was granted to them or some other public client.
>
>
>
>
>
> It is a small change that should not brake existing implementations, but
> will increase security for public clients using the code flow.
>
>
> Regards
>
> John B.
>
>
>
>
>
>
>
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 04 Jul 2012 18:31:18 +0200

+1

I basically support John's proposal but would also propose to explain 
the rationale.

regards,
Torsten.