Re: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split)

Eve Maler <eve@xmlgrrl.com> Thu, 28 October 2010 15:08 UTC

Return-Path: <eve@xmlgrrl.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54EE23A67DA for <oauth@core3.amsl.com>; Thu, 28 Oct 2010 08:08:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.006
X-Spam-Level:
X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEy-0B7TZ98p for <oauth@core3.amsl.com>; Thu, 28 Oct 2010 08:08:37 -0700 (PDT)
Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id AD7013A68CE for <oauth@ietf.org>; Thu, 28 Oct 2010 08:08:37 -0700 (PDT)
Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by mail.promanage-inc.com (8.14.4/8.14.3) with ESMTP id o9SFAQBp010522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Oct 2010 08:10:26 -0700
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Eve Maler <eve@xmlgrrl.com>
In-Reply-To: <C8EF3373.2679%hannes.tschofenig@nsn.com>
Date: Thu, 28 Oct 2010 08:10:25 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A528D3C6-B137-4B07-AC63-A09174CDC4C2@xmlgrrl.com>
References: <C8EF3373.2679%hannes.tschofenig@nsn.com>
To: Hannes Tschofenig <hannes.tschofenig@nsn.com>
X-Mailer: Apple Mail (2.1081)
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] So back to use cases? (was RE: Call for Consensus on Document Split)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Oct 2010 15:08:39 -0000

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.freeman@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