Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
Torsten Lodderstedt <torsten@lodderstedt.net> Wed, 04 January 2012 22:15 UTC
Return-Path: <torsten@lodderstedt.net>
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 C973711E80D8 for <oauth@ietfa.amsl.com>; Wed, 4 Jan 2012 14:15:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 wjOjkFD6B8jZ for <oauth@ietfa.amsl.com>; Wed, 4 Jan 2012 14:15:00 -0800 (PST)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by ietfa.amsl.com (Postfix) with ESMTP id E2CE911E80B6 for <oauth@ietf.org>; Wed, 4 Jan 2012 14:14:59 -0800 (PST)
Received: from [79.253.13.18] (helo=[192.168.71.41]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1RiZ6n-0002QE-8v; Wed, 04 Jan 2012 23:14:57 +0100
Message-ID: <4F04CF60.1050000@lodderstedt.net>
Date: Wed, 04 Jan 2012 23:14:56 +0100
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Michael Thomas <mike@mtcc.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> <CALaySJLcFGyt97OVFZY34kZSjp2bKRqiH_JSDQQaO-aTjSWh2g@mail.gmail.com> <4F04BF70.3010501@mtcc.com>
In-Reply-To: <4F04BF70.3010501@mtcc.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
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: Wed, 04 Jan 2012 22:15:00 -0000
Hi Michael, Am 04.01.2012 22:06, schrieb Michael Thomas: > I think the "perhaps unwisely" goes to the heart of my objection. You > might as well be talking about "perhaps unwisely" driving a car, > or "perhaps unwisely" eating food: the reality is that people download > apps by the *billions*. When I was initially blown off, many of the > participants including document editors implied that only idiots get > apps for their phones. That is *completely* unhelpful as the reality > is that OAUTH's use is hugely if not primarily deployed in that sort of > environment. I fully agree with you. That's why the core spec and the threat document both consider native apps. > > This is a threat that cuts to the very heart of what OAUTH is, and > purports > to defend against: keeping user credentials out of the hands of an > untrusted third party. If there really aren't any good ways to > mitigate this > in an app environment, why is OAUTH being deployed so aggressively there? > Shouldn't the threat draft say in blinking bold: "DEPLOYING OAUTH > IN NATIVE APPS CONSIDERED HARMFUL"? You lost me. Is the situation getting any worse with OAuth? I don't think so. I think the situation is getting better, probably not as you might expect. The key question is: Why do we aim on "keeping user credentials out of the hands of an untrusted third party"? 1) To prevent phishing or 2) to prevent leakage of end-user credentials due to inappropriate handling or weak defence on the 3rd party? wrt 1) I don't think so. I don't see how an authorization server shall validate the authenticity and trustworthiness of a client-side application. We already state this in section 4.4.1.4. of the threat document. ----------------------- It is not the task of the authorization server to protect the end-user's device from malicious software. This is the responsibility of the platform running on the particular device probably in cooperation with other components of the respective ecosystem (e.g. an application management infrastructure). The sole responsibility of the authorization server is to control access to the end-user's resources living in resource servers and to prevent unauthorized access to them. ----------------------- wrt 2) Yes, I think that's the reason. And OAuth is a appropriate protocol to achieve this goal, even for mobile apps. Why? A typical mobile application consists of the app itself on the device and a corresponding backend service storing user data and implementing business and integration logic. Let's assume this application features address book import from other service providers. W/o OAuth, the app would gather the end-user's credential for a certain address book service and pass it to its backend service. This service in turn uses this credentials to access the service provider's API. So in such a scenario the following parties get in touch with the user credentials: - the app - the app's backend service - the address book resource server What threats do you see here? And which is most likely to occur? My favorite is an attack against the log files or the database of the backend service in order to obtain the end-users passwords for the resource server. Why? Because the cost/benefit ratio for an attacker is much better then attacking any app installation on a device and the protective measure on the resource server might be more appropriate then on the client side (backend service). OAuth mitigates this kind of attack by reducing the number of parties handling user credentials to the authorization server and the user agent. So even if the app itself would be the user agent (which is not recommended), it would directly interact with the authorization server and the app's backend service would use tokens instead of end-user credentials. Moreover, the recommended way is to let the app delegate the flow to a trusted system component on the user's device, such as the system browser or an account manager. In that case, the 3rd party is not getting in touch with the user credentials at all. I think the key question is whether anyone expects OAuth to solve the phishing problem. I don't think this is its main purpose, but it could facilitate to overcome the habit to enter user credentials everywhere. And this in turn may contribute to the fight against phishing. regards, Torsten. > Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmode… Barry Leiba
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Barry Leiba
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Barry Leiba
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Mark Mcgloin
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… André DeMarre
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Phil Hunt
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Michael Thomas
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Mark Mcgloin
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Michael Thomas
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Michael Thomas
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Phillip Hunt
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Michael Thomas
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Mark Mcgloin
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Michael Thomas
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Peter Saint-Andre
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Michael Thomas
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Mark Mcgloin
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Barry Leiba
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Michael Thomas
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Torsten Lodderstedt
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Michael Thomas
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… William Mills
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… William Mills
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Michael Thomas
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Eran Hammer-Lahav
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Michael Thomas
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… William Mills
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Michael Thomas
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Mark Mcgloin
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Mark Mcgloin
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Michael Thomas
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Justin Richer
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Michael Thomas
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… William Mills
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… William Mills
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Michael Thomas
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… George Fletcher
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Mark Mcgloin
- Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threat… Michael Thomas