Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

Barry Leiba <barryleiba@computer.org> Wed, 04 January 2012 20:41 UTC

Return-Path: <barryleiba@gmail.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 50D9B11E80A1 for <oauth@ietfa.amsl.com>; Wed, 4 Jan 2012 12:41:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.717
X-Spam-Level:
X-Spam-Status: No, score=-102.717 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 36MMiLYGNxtg for <oauth@ietfa.amsl.com>; Wed, 4 Jan 2012 12:41:18 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC82511E809F for <oauth@ietf.org>; Wed, 4 Jan 2012 12:41:18 -0800 (PST)
Received: by ggnk5 with SMTP id k5so11874607ggn.31 for <oauth@ietf.org>; Wed, 04 Jan 2012 12:41:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lwRkxyE7QM0IA29dl2IjU52plVoAKNpqYmKrf6+hsWY=; b=s4lVkc7vCEiYVqLQ8+GuLWJTBH41gvtokbCkzDgd9HKoI1lnpnq1w1pa89IiLzFSGF ABWB6QVZXPc7+1+CF6T3dqJ9dIQZOBrqJsU0s1Z7/7c8lX4RDa0imZIQNYROQiMD78CI 7RukU9NvDoL0Nhep/BD/2D+oo+uOV928FKnLw=
MIME-Version: 1.0
Received: by 10.101.23.12 with SMTP id a12mr8788607anj.17.1325709678342; Wed, 04 Jan 2012 12:41:18 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.236.46.169 with HTTP; Wed, 4 Jan 2012 12:41:18 -0800 (PST)
In-Reply-To: <OF0587BA9E.B7B40207-ON8025797B.00702BFB-8025797B.007103EA@ie.ibm.com>
References: <CALaySJKhYQQdmjvWBLS3mwzzrDt35jfDn2xZCuDOk=hpwEUiKQ@mail.gmail.com> <CAC4RtVDyiuqCGO25nZQEVxi0uchTi2gu_peh=+FwmWwZsQ=LEQ@mail.gmail.com> <CAC4RtVCvnz7n9Ei08h7QRruesJ=GeOMOOvBkNAVmcc8_gzg7QQ@mail.gmail.com> <8AB6F5CC-E9A2-4A07-9AA0-83FB7C67A221@oracle.com> <4EEA3951.5010904@mtcc.com> <OF6C9EBE7C.1B053FE3-ON80257968.003C02DF-80257968.003CAA12@ie.ibm.com> <4EEB5BDD.7080401@mtcc.com> <4F038CB9.1040403@mtcc.com> <F674B8D6-54D6-4B39-A494-9D7EB6E058D6@oracle.com> <4F0394D6.1090006@mtcc.com> <OFD88021B6.E1FD29B9-ON8025797B.004036CF-8025797B.00404EA6@ie.ibm.com> <4F04AAAE.6080702@mtcc.com> <4F04ACE4.1070006@stpeter.im> <4F04B101.3070708@mtcc.com> <OF0587BA9E.B7B40207-ON8025797B.00702BFB-8025797B.007103EA@ie.ibm.com>
Date: Wed, 04 Jan 2012 15:41:18 -0500
X-Google-Sender-Auth: XbvdpnkJM3mVARZpYoGeCBJJtgM
Message-ID: <CALaySJLcFGyt97OVFZY34kZSjp2bKRqiH_JSDQQaO-aTjSWh2g@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Mark Mcgloin <mark.mcgloin@ie.ibm.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
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, 04 Jan 2012 20:41:19 -0000

> I have asked you to clearly describe the threat, not the mitigation.
>
> It obviously was either not clear or convincing the first time and I am not
> going to start digging through emails when you clearly understand it.

To try to shortcut this:
Mike did lay it out clearly, I think, in his first note (which I
linked at the beginning of this thread), and that should be the only
one that needs to be read to understand his point.  The basic point is
that the OAuth framework relies on both the end user and the
authorization server being able to trust the user's UA.  If that winds
up being a compromised browser or a native application that the user
perhaps unwisely installed, all the security in the framework goes out
the window, because an untrustworthy UA can fiddle with pretty much
everything.

Mike's note said much more than that, but I think I've encapsulated
things in an oversimplified version above.  I agree that this is
something that needs to be made very clear... and that I don't see any
way to mitigate it -- it's basically an aspect of what we're working
with here.

I don't think this is a difficult issue to document, and perhaps two
paragraphs should be enough to do it.  Identifying the right place and
the right two paragraphs should be something that a combination of
Mike and the documnet editors can do, if you can do it without getting
on each others' nerves.  :-)

Barry