Re: [OAUTH-WG] Public client cloning

Justin Richer <jricher@mit.edu> Fri, 13 September 2019 19:13 UTC

Return-Path: <jricher@mit.edu>
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 D25DB120111 for <oauth@ietfa.amsl.com>; Fri, 13 Sep 2019 12:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTmrNu0fiqRQ for <oauth@ietfa.amsl.com>; Fri, 13 Sep 2019 12:13:05 -0700 (PDT)
Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF72B1200FA for <oauth@ietf.org>; Fri, 13 Sep 2019 12:13:04 -0700 (PDT)
Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id x8DJDD9b011013; Fri, 13 Sep 2019 15:13:24 -0400
Received: from w92expo18.exchange.mit.edu (18.7.74.72) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 13 Sep 2019 15:12:41 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 13 Sep 2019 15:12:48 -0400
Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Fri, 13 Sep 2019 15:12:48 -0400
From: Justin Richer <jricher@mit.edu>
To: Masakazu OHTSUKA <o.masakazu@gmail.com>
CC: Marius Scurtescu <marius.scurtescu@coinbase.com>, "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Public client cloning
Thread-Index: AQHVZ/j4JiICU9vqDEmbu/R19TzDAKcla9wAgAAit4CABLL9gA==
Date: Fri, 13 Sep 2019 19:12:47 +0000
Message-ID: <CC052670-A4A0-4AD6-9D7F-DDB7096E7128@mit.edu>
References: <CAP=REHFHeJT=w4ZCmHYJaL4QFQvntWqPTRaXVCH-fz4FciHh5A@mail.gmail.com> <CABpvcNufpaTRk3BnjJs26b5d9k_8+hd5ZEdFjsmtViTokJiXVg@mail.gmail.com> <CAP=REHEN4JVB5xSAj6YZZNeoygPEWueyOXrbU=xuosVU5Z359Q@mail.gmail.com>
In-Reply-To: <CAP=REHEN4JVB5xSAj6YZZNeoygPEWueyOXrbU=xuosVU5Z359Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [71.174.62.56]
Content-Type: multipart/alternative; boundary="_000_CC052670A4A04AD69D7FDDB7096E7128mitedu_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/V0ADpzxgaUsCNpF4Ei6ATISuJw4>
Subject: Re: [OAUTH-WG] Public client cloning
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 13 Sep 2019 19:13:07 -0000

If the phone is compromised, it doesn’t matter if the client is public or confidential. In the latter case, an attacker could exfiltrate or capture the client’s own credentials and use them maliciously.

— Justin

On Sep 10, 2019, at 3:27 PM, Masakazu OHTSUKA <o.masakazu@gmail.com<mailto:o.masakazu@gmail.com>> wrote:

I see.

Then is this understandable to think from the Authorization Server's point of view ...

If phone being compromised is a threat that the Client cares,
AS might be interested in NOT supporting public Clients,
and forcing the Client to have a server side, do client authentication, and have some way to hold a session between the native app and it's server side.

Because if phone is compromised, when AS supports public Clients and access_token leaks, it's kind of AS's fault (well depending on the terms...),
but if whatever the means that the phone app and it's server side keeps a session leaks, it's NOT the AS's fault.


On Tue, Sep 10, 2019 at 8:23 PM Marius Scurtescu <marius.scurtescu@coinbase.com<mailto:marius.scurtescu@coinbase.com>> wrote:
If the phone is compromised, original app replaced by malicious app, then RFC8252 will not help. The assumption is that the phone is not compromised.

On Tue, Sep 10, 2019 at 9:58 AM Masakazu OHTSUKA <o..masakazu@gmail.com<mailto:o.masakazu@gmail.com>> wrote:
Hi,

I've read rfc8252 and have questions about native apps, that I couldn't find answers on Internet.

Imagine an attacker doing:
1. original app and authorization server conforms to rfc8252 4.1.  Authorization Flow for Native Apps Using the Browser
2. clone the original app, name it malicious app and install on the target phone
3. remove the original app from the target phone
4. use the malicious app and authorize, OS will invoke malicious app using custom URL scheme
5. now malicious app has access to the access token

How should we think about this?
What am I missing?

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth