Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel

Derek Atkins <derek@ihtfp.com> Wed, 25 April 2012 15:38 UTC

Return-Path: <derek@ihtfp.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5128221F87B4 for <oauth@ietfa.amsl.com>; Wed, 25 Apr 2012 08:38:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.419
X-Spam-Level:
X-Spam-Status: No, score=-101.419 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, J_BACKHAIR_42=1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pgJh5DSzeS0 for <oauth@ietfa.amsl.com>; Wed, 25 Apr 2012 08:38:18 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCC121F87B0 for <oauth@ietf.org>; Wed, 25 Apr 2012 08:38:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 628C82602A6; Wed, 25 Apr 2012 11:38:13 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 12044-02; Wed, 25 Apr 2012 11:38:12 -0400 (EDT)
Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 586512601D8; Wed, 25 Apr 2012 11:38:12 -0400 (EDT)
Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q3PFc9x2003861; Wed, 25 Apr 2012 11:38:09 -0400
From: Derek Atkins <derek@ihtfp.com>
To: Eran Hammer <eran@hueniverse.com>
References: <CALaySJLy6jpuPqxQXfKfpx0TpcK1gav1NtcTOoh+NOr11JSCbw@mail.gmail.com> <4F8DE789.4030704@mtcc.com> <CALaySJK1ej_HkP5Jz26XT-KjULirD2iFfVOpRkHgPZp-CbJCrg@mail.gmail.com> <4F957EA7.3060004@mtcc.com> <OF3ECF645E.478720A4-ON802579EA.002D0B13-802579EA.002D8D07@ie.ibm.com> <4F96A99F.7010303@mtcc.com> <85556C53-99DD-47A2-A0D5-2F86DD2B668F@oracle.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net> <sjmhaw9vyvl.fsf@mocana.ihtfp.org> <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC664@P3PWEX2MB008.ex2.secureserver.net>
Date: Wed, 25 Apr 2012 11:38:07 -0400
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC664@P3PWEX2MB008.ex2.secureserver.net> (Eran Hammer's message of "Tue, 24 Apr 2012 18:05:02 +0000")
Message-ID: <sjm8vhjx1nk.fsf@mocana.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: Maia Mailguard 1.0.2a
Cc: "oauth-chairs@tools.ietf.org" <oauth-chairs@tools.ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 25 Apr 2012 15:38:19 -0000

Eran Hammer <eran@hueniverse.com> writes:

> There is a lot of history on this thread.

I know.  I have read it all.  Frankly, I feel that Michael was treated
poorly by the members of this group.

> At the heart of it is a request from a working group member that the
> specification makes it clear that OAuth does not protect against
> malware and viruses, or other malicious software installed on the user
> device. During the first (or second, I can't recall) run of this
> debate, the chair *did* make a consensus call that the WG did not feel
> this was an OAuth specific threat. The chair's proposed resolution at
> the time was clearly too vague to close the issue and hence we are
> still arguing about it.

That's not exactly how I read the original request.  One part I remember
clearly was more a question about user interface and "protecting" the
User<->AS request.  I think this could've been handled by a simple
statement that "protecting a device or end-user user interface is out of
scope for OAUTH".

There was also an issue about handling bad players in the system (e.g. a
Bad Client player).  As a security person I'm afraid I do have to agree
with Michael here, a threats document cannot say that to counteract a
bad player you need to have a good player.  You need to either say that
the protocol does not protect against a bad player, or you need to say
how to protect against a bad player.  There is nothing wrong saying that
it doesn't protect against a bad player, but writing it off will
definitely make you look less credible.

> Adding the requested threat will make the document look less credible
> for stating the obvious. I do not agree that any threat mentioned
> should be listed. At some point, and we're almost there, you lose the
> forest for the trees.

And it looks credible to imply that OAUTH protects against all attacks
including the kitchen-sink attack?  Maybe it is obvious to you, but
you've been knee deep in the protocol for years.  It is not necessarily
obvious to the next person who reads the drafts.  Being honest about
what OAUTH does (and more importantly does NOT) do is more credible than
ignoring what might be obvious to some but not obvious to others.

> And BTW, as a response to Michael's original comment, I have requested
> that the threat of earthquakes will also be listed under UX
> considerations to prevent a user from clicking 'Approve' during an
> earthquake if it is too close to the 'Deny' button. Is my threat,
> which is clearly valid (no matter how unlikely), going to be added as
> well? Please don't, but I hope you see my point here. Many bad things
> can happen to you while using OAuth.

And you're worried about sounding credible by talking about bad players
and being explicit about the scope of OAUTH protection on a client
device?  Following your suggestion, ad absurdium, why not talk about the
threat of a meteor shower?  Seriously, yes, there is a line that has to
be drawn; clearly *I* needed to be more explicit about that.  Yes, of
course the threat has to actually apply, but dismissing a threat out of
hand because you don't like it or you feel it will make you look less
"credible" only makes you look less credible.

> I don't care how this is resolved. At this point I don't mind the
> threat being added just to close the issue.

Sold.  Thank you, Eran.

> EH

-derek
-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant