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

Michael Thomas <mike@mtcc.com> Thu, 05 January 2012 01:39 UTC

Return-Path: <mike@mtcc.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 4BD1721F85E4 for <oauth@ietfa.amsl.com>; Wed, 4 Jan 2012 17:39:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 wPxik03JZ3GA for <oauth@ietfa.amsl.com>; Wed, 4 Jan 2012 17:39:36 -0800 (PST)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 4C85F21F85CD for <oauth@ietf.org>; Wed, 4 Jan 2012 17:39:36 -0800 (PST)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q051dV1o012967 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 4 Jan 2012 17:39:32 -0800
Message-ID: <4F04FF53.5040002@mtcc.com>
Date: Wed, 04 Jan 2012 17:39:31 -0800
From: Michael Thomas <mike@mtcc.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: William Mills <wmills@yahoo-inc.com>
References: <CALaySJKhYQQdmjvWBLS3mwzzrDt35jfDn2xZCuDOk=hpwEUiKQ@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> <CALaySJLcFGyt97OVFZY34kZSjp2bKRqiH_JSDQQaO-aTjSWh2g@mail.gmail.com> <4F04BF70.3010501@mtcc.com> <4F04CF60.1050000@lodderstedt.net> <4F04E362.5070406@mtcc.com> <90C41DD21FB7C64BB94121FBBC2E723453A72D09B9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F04F134.5050409@mtcc.com> <1325726167.42441.YahooMailNeo@web31813.mail.mud.yahoo.com>
In-Reply-To: <1325726167.42441.YahooMailNeo@web31813.mail.mud.yahoo.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7338; t=1325727573; x=1326591573; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20<mike@mtcc.com> |Subject:=20Re=3A=20[OAUTH-WG]=20WGLC=20on=20draft-ietf-oau th-v2-threatmodel-01,=20ends=209=0A=20Dec=202011 |Sender:=20 |To:=20William=20Mills=20<wmills@yahoo-inc.com> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=IlwxcvgGI4N05vpfAhnABlig5EsvT3qPlMdFqExzGxo=; b=QYvkg4hU1SxHCzOBiR0zLpXEmBzwmZ714vLksVfIVq441VF3z0zqKdZVKb bnjBBcyUUpW95NKi3YdYTpxNJt7TfGEwJsBtKJzypB7QUfv1MGcBibmEyBrK 4Dv3k8vHYZtbvgE1OdiBvtzrBNa4rMFZvkhHIAEwjwpeNQ9VuI0hA=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com
Cc: Barry Leiba <barryleiba@computer.org>, 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: Thu, 05 Jan 2012 01:39:37 -0000

On 01/04/2012 05:16 PM, William Mills wrote:
> The below is unfortunately probably a no-go:
>
> > Given these threats, authentication servers MUST NOT give clients access
> > to authentication services -- and by extension to resource services -- unless the
> > authentication service can thoroughly vet the trustworthiness of the client. How
> > that vetting is achieved is outside of the scope of this document, but the current
> > practice of freely giving client keys to any would-be OAUTH client is not sufficient."
>
> It's unfortunately not really a solved problem for widely distributed clients.  I attack this by spoofing a known client and the resource server or auth server can't tell the difference.  That's why I was falling back to the more brutal "this doesn't protect you from ..." statement.

So what you're saying is that it's even worse than what I wrote, which
is pretty confining as to what clients an auth server should have a
relationship with. I guess that's progress.

A known client whose client keys are compromised is certainly a threat,
but it at least requires one more step beyond just freely getting client
keys from the auth service. On phone apps with no backend, for example,
it's problematic to keep that key secret, but for clients that have backend
servers it's not as bad. Part of the vetting process could be "clients MUST
NOT store client keys in a program that can be disassembled trivially like
a phone app". This may already be in this draft though, so apologies if
I didn't see it.

I guess I'd rather there not be a blanket MUST NOT -- I hope it doesn't
come down to that -- but they way I'm reading you is that it will come
down to just that.

Mike

>
> Native mobile clients where the default experience is likely to be not to spawn a browser for the interaction are going to be a real problem too.
>
> Auth servers (I think that's where you get the best control) can do their best to keep track of what clients a user has authenticated and prompt the user on a new client, but it's still up to the user to make sure they're not being lied to, and in practice this is only marginally effective (and tends in fact to slow adoption with a "scary" message, so product type folks don't like it).
>
> -bill
>
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Michael Thomas <mike@mtcc.com>
> *To:* Eran Hammer-Lahav <eran@hueniverse.com>
> *Cc:* oauth WG <oauth@ietf.org>; Barry Leiba <barryleiba@computer.org>
> *Sent:* Wednesday, January 4, 2012 4:39 PM
> *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
>
> On 01/04/2012 04:05 PM, Eran Hammer-Lahav wrote:
> >
> >> -----Original Message-----
> >> From: oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org> [mailto:oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>] On Behalf
> >> Of Michael Thomas
> >> Sent: Wednesday, January 04, 2012 3:40 PM
> >> My concern is that putting on a veneer of "security" will lull people into
> >> thinking "Oh, it's safe to enter my credentials here because this is really
> >> twitterbook, not evilapp!". When I had to ask them directly to put their
> >> twitterbook credentials into my app, there at least wasn't any confusion that
> >> I had access to them.
> > This is ridiculous (e.g. the fact we are still discussing this).
> >
> > First, end users know nothing about security or OAuth. Second, evil apps can create this veneer of security by faking a redirection flow with or without OAuth. Suggesting that OAuth (which is a de-facto web pattern for over a decade) makes anything worse is patently false.
> >
> > The only thing we can possibly add to the threat model document is to mention that "OAuth does not provide any protection against malicious applications and that the end user is solely responsible for the trustworthiness of any native application installed". That is accurate (and completely obvious to the target audience of this document). It is not very helpful but if it will make you feel better (since no one else here seems to share your concerns), I have no objection to such one line added.
> >
> > And again, to highlight the absurdity of your security claim, it is equally important to warn developers in earthquake-prone countries to put enough distance between the Approve and Deny buttons so that the user will not accidentally hit Approve during a tremor.
> >
>
> It's this kind of hostility and ad hominem that leads me to believe that
> you have forgotten some of your lessons in charm school.
>
> For one, I am not the only one and even if I were that would still not be
> a reason to shoot the messenger. Secondly it is *not* the sole responsibility
> of the end user: the authentication server absolutely has a part to play
> here too. They have to give out client keys, after all, and its their service
> that could be hacked. So they have as much if not more responsibility
> than the end user.
>
> So to Bill's request here is the text I would propose.
>
> "Native apps, not limited to, but including apps which are available on popular
> mobile app stores, have the potential for gaining access to the end user's credentials.
> This can be accomplished by gaining access to browser UI components and key logging,
> spoofing the look and feel of an authentication server's authentication page, and
> potentially many other social engineering attacks. The potential for these attacks
> exist in many existing OAUTH2 deployments including but not limited to Facebook
> and Twitter.
>
> Given these threats, authentication servers MUST NOT give clients access
> to authentication services -- and by extension to resource services -- unless the
> authentication service can thoroughly vet the trustworthiness of the client. How
> that vetting is achieved is outside of the scope of this document, but the current
> practice of freely giving client keys to any would-be OAUTH client is not sufficient."
>
> Mike
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
>