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

[Torsten Lodderstedt <[e-mail]>]

+1

Am 25.07.2011 02:16, schrieb Eran Hammer-Lahav:
>
> 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:[e-mail]]
> *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 <[e-mail] <mailto:[e-mail]>> 
> schrieb:
>
> 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-----
> >  From: Torsten Lodderstedt[mailto:[e-mail]]  <mailto:[mailto:[e-mail]]>
> >  Sent: Friday, July 08, 2011 12:59 AM
> >  To: Eran Hammer-Lahav; OAuth WG
> >  Subject: RE: Section 10.1 (Client authentication)
> >
> >  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<[e-mail]  <mailto:[e-mail]>>  schrieb:
> >
> >  >I still don’t find it useful. I think the existing text overall makes
> >  >this point already.
> >  >
> >  >EHL
> >  >
> >  >From: Torsten Lodderstedt[mailto:[e-mail]]  <mailto:[mailto:[e-mail]]>
> >  >Sent: Wednesday, July 06, 2011 12:48 AM
> >  >To: Eran Hammer-Lahav; OAuth WG
> >  >Subject: Re: Section 10.1 (Client authentication)
> >  >
> >  >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
> >  <[e-mail]<mailto:[e-mail]  <mailto:[e-mail]%3cmailto:[e-mail]>>>
> >  >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
> >  >
> >  >From: Torsten Lodderstedt
> >  ><[e-mail]<mailto:[e-mail]  <mailto:[e-mail]%3cmailto:[e-mail]>>>
> >  >Date: Wed, 1 Jun 2011 00:53:37 -0700
> >  >To: Eran Hammer-lahav
> >
> ><[e-mail]<mailto:[e-mail]  <mailto:[e-mail]%3cmailto:[e-mail]>>>, OAuth WG
> >  ><[e-mail]<mailto:[e-mail]  <mailto:[e-mail]%3cmailto:[e-mail]>>>
> >  >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.