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:tors...@lodderstedt.net]
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...@hueniverse.com<mailto: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]<mailto:[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<mailto: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]<mailto:[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<mailto:e...@hueniverse.com%3cmailto: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<mailto:tors...@lodderstedt.net%3cmailto:tors...@lodderstedt.net>>>
> >Date: Wed, 1 Jun 2011 00:53:37 -0700
> >To: Eran Hammer-lahav
>
><e...@hueniverse.com<mailto:e...@hueniverse.com<mailto:e...@hueniverse.com%3cmailto:e...@hueniverse.com>>>,
> OAuth WG
> ><oauth@ietf.org<mailto:oauth@ietf.org<mailto:oauth@ietf.org%3cmailto: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
