Hi Hannes,
Regarding UMA's "security use cases", indeed we haven't been producing formal
use cases in a form that readily maps to what this group is looking for.
However, I've reproduced below the comments I sent you privately on your OAuth
signature thoughts doc (too late for your IETF submission editing round); they
contain specific descriptions and pointers to a major security requirement of
UMA that relates to this discussion.
Eve
====
- The Alice/Bob/Carol language is a bit distracting. I kept scribbling "authz
server" etc. on my copy to make sure I had it straight. Given that you're
talking about OAuth specifically, do you think using real OAuth terminology
would be okay?
- (Nit:) At the bottom of page 2, I couldn't understand "...and in managing a
resource that is work delegating access to."
- I think there's a threat missing, something like "token replay" (but that
doesn't seem quite right). This is where the Alice language is holding me
back! If Alice == client, the token might be stolen by a malicious client Eve
(or Alice might maliciously give it to Eve to use), then used at Bob as if Eve
were Alice. Naming all the threats "token <something>" makes it hard to decide
what to call it, but left to my own devices I'd call it "client correlation".
OAuth seems to want to put this out of scope, but it's a real problem for UMA,
given that our authorization server and resource server might be in different
administrative domains. You can see the problem statement here:
http://groups.google.com/group/kantara-initiative-uma-wg/browse_frm/thread/cafa098084c7c208/703617741a124124?lnk=gst&q=step+3#703617741a124124
...and our current (very constrained and signature-free!) solution in Step 3
here:
http://mrtopf.clprojects.net/uma/draft-uma-core.html
One of the reasons we want to be able to point to/build on an OAuth signing
solution is that a short token lifetime isn't very performant/scalable. But
we're inclined to leave our simple solution in place as mandatory-to-implement.
- Another thing that's probably worth observing is that OAuth thinks of a token
as either containing real assertions or being an artifact that can be
referenced to get to assertions. But UMA's treatment is entirely consistent
too: a token stands for an authorization decision, with all the specifics of
assertions/claims pushed exclusively to the Alice/Carol (client/authz server)
communication.
On 28 Oct 2010, at 4:04 AM, Hannes Tschofenig wrote:
> Hey Tim,
>
> Earlier this year we had discussions around use cases but they did not lead
> to more insight.
>
> There is a document in the draft repository that talks about use cases,
> namely
> http://datatracker.ietf.org/doc/draft-zeltsan-oauth-use-cases/
> But it had never gotten a lot of attention on the list. (I don't know why.)
>
> Efforts to reach out to the Kantara UMA group for more sophisticated uses
> cases that motivate some security mechanisms have not produced anything
> either. (I believe the reason was that the scenarios focused on the
> user-experience aspect rather than on security differences.)
>
> If you look at the draft that Blaine and I put together recently (see
> http://datatracker.ietf.org/doc/draft-tschofenig-oauth-signature-thoughts/
> ) then you will notice that from a security point of view there is very
> little difference between using message signing on the HTTP layer and using
> TLS with respect to a certain class of security threats.
>
> In our recommendation we actually suggest to recommend to go for the HTTP
> layer security because we are worried that ***operational*** aspects will go
> wrong in deployments.
>
> While I was convinced initially that looking at the use cases will get us
> further on the security questions it actually does not.
>
> Ciao
> Hannes
>
> PS: Btw, your feedback on the security draft would be of interest to us.
>
>
> On 10/27/10 9:09 PM, "ext Freeman, Tim" <tim.free...@hp.com> wrote:
>
>> On the face of it, it seems that discussion of whether and how to split the
>> document has derailed collection of use cases. If we had consensus on a list
>> of use cases, that would mean we have identified the problems we're trying to
>> solve. This would still allow slimy political manipulation of the process by
>> manipulating the use case list, but that would be progress. It's better to
>> have a protocol that solves a politically-defined set of problems than to
>> have
>> a politically-defined protocol that solves no identified problem.
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
