Subject: Re: [OAUTH-WG] Section 10.1 (Client authentication)

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 4 Jul 2011 12:00:22 -0700

It's a pointless MUST given how undefined the requirements are. It will only be understood by security experts and they don't really need it. At a minimum, it needs some examples.

EHL

From: Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>
Date: Wed, 1 Jun 2011 00:53:37 -0700
To: Eran Hammer-lahav <[email-masked]<mailto:[email-masked]>>, OAuth WG <[email-masked]<mailto:[email-masked]>>
Subject: Section 10.1 (Client authentication)

Hi Eran,

would you please add the following sentence (which was contained in the
original security considerations text) to the second paragraph of
section 1.0.1?

Alternatively, authorization servers MUST utilize
    other means than client authentication to achieve their security
    objectives.

I think it's important to state that authorization server should
consider alternative way to validate the client identity if secrets
cannot be used. The security threat document also suggest some.

regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 06 Jul 2011 10:48:16 +0300

Hi Eran,

I would suggest to change it to SHOULD and add a reference to https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections 3.7 and 5.2.3.

regards,
Torsten.

Eran Hammer-Lahav <[email-masked]> schrieb:

EHL

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 1 Jun 2011 00:53:37 -0700
To: Eran Hammer-lahav <[email-masked]>, OAuth WG <[email-masked]>
Subject: Section 10.1 (Client authentication)

Hi Eran,

section 1.0.1?

    objectives.

regards,

Torsten.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 7 Jul 2011 21:51:01 -0700

I still don’t find it useful. I think the existing text overall makes this point already.

EHL

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Wednesday, July 06, 2011 12:48 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: Re: Section 10.1 (Client authentication)

Hi Eran,

regards,
Torsten.

Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> schrieb:
It's a pointless MUST given how undefined the requirements are. It will only be understood by security experts and they don't really need it. At a minimum, it needs some examples.

EHL

Hi Eran,

regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 08 Jul 2011 10:58:49 +0300

seems you are contradicting yourself. 

You criticised the MUST and suggested to include some examples. I bought into your argument and suggested to refer to the security doc for examples and additional explanations. That's what this document is intended for, to provide background beyond what we can cover in the core spec.

And I don't think the spec already makes that point. But you are free to refer me to the respective text.

regards,
Torsten.

Eran Hammer-Lahav <[email-masked]> schrieb:

>I would suggest to change it to SHOULD and add a reference to
>https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections
>3.7 and 5.2.3.
>
>regards,
>Torsten.
>
>
>It's a pointless MUST given how undefined the requirements are. It will
>only be understood by security experts and they don't really need it.
>At a minimum, it needs some examples.
>
>EHL
>
>From: Torsten Lodderstedt
><[email-masked]<mailto:[email-masked]>>
>To: Eran Hammer-lahav
><[email-masked]<mailto:[email-masked]>>, OAuth WG
><[email-masked]<mailto:[email-masked]>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 8 Jul 2011 09:25:14 -0700

Hey Torsten,

The provided text and alternative text are just not helpful. If I am unable to understand it, I have doubt other readers will be able to.

I don't know what you mean by 'other means' which are not already described in the document (based on -17). Referencing the security thread model document in a normative reference requires making it a normative reference which I am opposed to doing - the v2 document should include everything needed to implement the protocol without any additional specifications (for the core functionality).

When I was asking for examples, I was hoping for something like 'for example, use x, y, or z', not a reference to about 10 pages of text (which by itself is pretty confusing, but that's a different issue - I hope to find the time to provide detailed feedback for that document).

I think the current document makes a pretty good case for using the redirection URI as a form of client validation, and clearly lays out the differences between a public and private client. It has new requirements for the registration of redirection URIs when client authentication is not possible.

If there are specific things the authorization server can do to improve security beyond client authentication, we should list them explicitly in the document.

Can you list exactly what you have in mind by 'other means'? Just the bullet points will be enough.

EHL

> -----Original Message-----
> Sent: Friday, July 08, 2011 12:59 AM
> Subject: RE: Section 10.1 (Client authentication)
> 
> You criticised the MUST and suggested to include some examples. I bought
> into your argument and suggested to refer to the security doc for examples
> and additional explanations. That's what this document is intended for, to
> provide background beyond what we can cover in the core spec.
> 
> >Eran Hammer-Lahav
> <[email-masked]<mailto:[email-masked]>>
> >schrieb:

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 10 Jul 2011 11:59:04 +0300

Hi,

I just remembered the original aim of the text. We not just intended to list alternative means but to get a general message across: If you cannot authenticate a client considers this in your security design! Either (1) you accept the fact the respective identities can be forged and handle them as untrusted entities through your logic (as far as I remember Skylar suggested the term forgeable clients) or (2) you find other ways to establish trust in the client's identity. 

The effect of (1) depends on the security policy of the certain deployment and the risk associated with certain functions. It could e.g. mean to rely on the id to aggregate log entries (not critical) but never to automatically process authz processes or settle payment transaction.

Examples for (2) are: redirect uri validation, relying on the user to identify the client, and (subsequently) use refresh tokens as mean for client authentication. I don't think we can give a complete list of means here since I assume some deployments will have their own capabilities.

Please also note: redirect uri validation is not an adequate replacement for client authentication. It's not effective for native apps and useless if the attacker uses a native app (no matter whether the legitimate client is a web, user agent based or native app).

regards,
Torsten.

Hey Torsten,

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 24 Jul 2011 23:16:11 -0700

How about, add this to 10.1:

          When client authentication is not possible, the authorization server SHOULD employ other
          means to validate the client's identity. For example, by requiring the registration of
          the client redirection URI or enlisting the resource owner to confirm identity. The
          authorization server must consider the security implications of interacting with
          unauthenticated clients and take measures to limit the potential exposure of other
          credentials (e.g. refresh tokens) issued to such clients.

EHL

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Sunday, July 10, 2011 1:59 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Section 10.1 (Client authentication)

Hi,

regards,
Torsten.

Hey Torsten,

I think the current document makes a pretty

good case for using the redirection URI as a form of client validation, and clearly lays out the differences between a public and private client. It has new requirements for the registration of redirection URIs when client authentication is not possible.

EHL

> From: Torsten Lodderstedt [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
> into your

argument and suggested to refer to the security doc for examples
> >From: Torsten Lodderstedt [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
> >I would

suggest to change it to SHOULD and add a reference to
> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>
> >schrieb:
> ><[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>

><[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>, OAuth WG
> ><[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 25 Jul 2011 10:10:40 -0400

+1

Am 25.07.2011 02:16, schrieb Eran Hammer-Lahav:
> *From:*Torsten Lodderstedt [mailto:[email-masked]]
> *Sent:* Sunday, July 10, 2011 1:59 AM
> *To:* Eran Hammer-Lahav; OAuth WG
> *Subject:* RE: Section 10.1 (Client authentication)
>
> Hi,
>
> I just remembered the original aim of the text. We not just intended 
> to list alternative means but to get a general message across: If you 
> cannot authenticate a client considers this in your security design! 
> Either (1) you accept the fact the respective identities can be forged 
> and handle them as untrusted entities through your logic (as far as I 
> remember Skylar suggested the term forgeable clients) or (2) you find 
> other ways to establish trust in the client's identity.
>
> The effect of (1) depends on the security policy of the certain 
> deployment and the risk associated with certain functions. It could 
> e.g. mean to rely on the id to aggregate log entries (not critical) 
> but never to automatically process authz processes or settle payment 
> transaction.
>
> Examples for (2) are: redirect uri validation, relying on the user to 
> identify the client, and (subsequently) use refresh tokens as mean for 
> client authentication. I don't think we can give a complete list of 
> means here since I assume some deployments will have their own 
> capabilities.
>
> Please also note: redirect uri validation is not an adequate 
> replacement for client authentication. It's not effective for native 
> apps and useless if the attacker uses a native app (no matter whether 
> the legitimate client is a web, user agent based or native app).
>
> regards,
> Torsten.
>
>
>
> Eran Hammer-Lahav <[email-masked] <mailto:[email-masked]>> 
> schrieb:
>
> Hey Torsten,
>
> >  From: Torsten Lodderstedt[mailto:[email-masked]]  <mailto:[mailto:[email-masked]]>
> >  Eran Hammer-Lahav<[email-masked]  <mailto:[email-masked]>>  schrieb:
> >
> >  >From: Torsten Lodderstedt[mailto:[email-masked]]  <mailto:[mailto:[email-masked]]>
> >  <[email-masked]<mailto:[email-masked]  <mailto:[email-masked]%3cmailto:[email-masked]>>>
> >  >schrieb:
> >  ><[email-masked]<mailto:[email-masked]  <mailto:[email-masked]%3cmailto:[email-masked]>>>
> ><[email-masked]<mailto:[email-masked]  <mailto:[email-masked]%3cmailto:[email-masked]>>>, OAuth WG
> >  ><[email-masked]<mailto:[email-masked]  <mailto:[email-masked]%3cmailto:[email-masked]>>>