+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: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
