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...@hueniverse.com> 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:tors...@lodderstedt.net] > 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...@hueniverse.com> schrieb: > > >I still don’t find it useful. I think the existing text overall makes > >this point already. > > > >EHL > > > >From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > >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...@hueniverse.com<mailto:e...@hueniverse.com>> > >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 > ><tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>> > >Date: Wed, 1 Jun 2011 00:53:37 -0700 > >To: Eran Hammer-lahav > ><e...@hueniverse.com<mailto:e...@hueniverse.com>>, OAuth WG > ><oauth@ietf.org<mailto:oauth@ietf.org>> > >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.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
