Return-Path: 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 29CCE120810 for ; Wed, 11 Sep 2019 00:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 y_-ysY6alfFM for ; Wed, 11 Sep 2019 00:26:18 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CDB212009C for ; Wed, 11 Sep 2019 00:26:18 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id h144so43499081iof.7 for ; Wed, 11 Sep 2019 00:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M2qK6RPTRLNkKuT89TPL+ybUUIlfXr/YDGerj8C7UDk=; b=peTSnAlrDgNRk58Swx2zWoEwaiIhnsBIU0AoxYv/lDIB4l9lvtLylS/ySMvKd8os6+ nTam2W/OfYsiEDEJ008hojO2trDUsH/kmg9KCNJcBDgjZ+hXe8nqBvHZ58wY9BSqxwzp +qgZjquEqRecqVbasPNP/WDX1SIpADquV5x/GT7j2pAvnUOaPJLKQMBrmm8+1TUv6cC4 w8eBhNJ2R1Mrt3rExWsrie5YkZl2PrI06w1Ma001D2miOi0uko1JFdIGLWaL3KH61LNy Mqr90AfVQDYmXkS9V+WaOPpUfCnuOHauXXIaU5Yes/lvhQ4ErAB0h6iQKQOORV9Zdren dpfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M2qK6RPTRLNkKuT89TPL+ybUUIlfXr/YDGerj8C7UDk=; b=AL2A8WzqcprfCb+ENsQWkyBqI8JAhDWFVGwC+9E3ZwsTp2SS0Pn4xnxf+ucai8df9w FqTh07nYrxr8T1c7LucCjz28Fsw8OlQ8dq5Knzvj6vLd6qIS18gS3TYSefQz+KJlv1Iq xV8xexhgAxZaxKWyCIvYXNoHjaWJkYouiAzk7zeOvT7FXQZd4DWGP7UkU/26XO/3BlMk d84IXDXoL93cej3UbiOnkco0jV4kzyr8hKwSAZDE+lMy5UmWiAVI/q2uiwTuCEm/0lUU CIw0sfuTEfGoWwi4vqDgwtgMZe9Xiq2fzUowynLg9TikwYAH4D0+IlDF+oEj+80lSI/H ZJEw== X-Gm-Message-State: APjAAAXHQiQZosEmVgh5pdI1hQMd4HGwTDtSdqlyzu4pb5mNHXbYEFqS Ua6GxiGdwZ1nMp5C2xCPa+MNKLUuSm+UtPyE5uc= X-Google-Smtp-Source: APXvYqycjyp3c8gmvq9Lk8sJIlTeZ3k/GqlJtT5vnrWiU19ZqBu/QAXnvpNJTWLCi8yT2/F4X9FKdEQqLIoZK0UcGpM= X-Received: by 2002:a5d:9153:: with SMTP id y19mr17619872ioq.109.1568186777229; Wed, 11 Sep 2019 00:26:17 -0700 (PDT) MIME-Version: 1.0 References: <9e3c2bee-6d15-4073-9d50-ef5454405cd9@Spark> In-Reply-To: <9e3c2bee-6d15-4073-9d50-ef5454405cd9@Spark> From: Masakazu OHTSUKA Date: Wed, 11 Sep 2019 10:26:06 +0300 Message-ID: To: Nat Sakimura Cc: Marius Scurtescu , oauth mailing list , Filip Skokan Content-Type: multipart/alternative; boundary="000000000000cc66f9059241ef59" Archived-At: Subject: Re: [OAUTH-WG] Public client cloning X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 07:26:20 -0000 --000000000000cc66f9059241ef59 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Okay, Marius, Filip and Nat, thank you for your answers. :) On Wed, Sep 11, 2019 at 3:51 AM Nat Sakimura wrote: > As Filip mentioned, I feel that claimed HTTPS URI would help. Further, if > that is used within the dynamic client registration, it could be more > secure. > > The security assumptions are > > 1. Phone is not rooted; > 2. App Store's vetting of claimed URI is not compromised; etc. > > Nat Sakimura > Chairman, OpenID Foundation > https://nat.sakimura.org > 2019=E5=B9=B49=E6=9C=8811=E6=97=A5 4:27 +0900=E3=80=81Masakazu OHTSUKA =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: > > I see. > > Then is this understandable to think from the Authorization Server's poin= t > 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 serve= r > 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> wrote: > >> If the phone is compromised, original app replaced by malicious app, the= n >> RFC8252 will not help. The assumption is that the phone is not compromis= ed. >> >> On Tue, Sep 10, 2019 at 9:58 AM Masakazu OHTSUKA > > 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 >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --000000000000cc66f9059241ef59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Okay,
Marius, Filip and Nat, thank you for your answer= s. :)

On Wed, Sep 11, 2019 at 3:51 AM Nat Sakimura <sakimura@gmail.com> wrote:
As Filip mentioned, I feel that claimed HTTPS URI would help. Further,= if that is used within the dynamic client registration, it could be more s= ecure.

The security assumptions are

1. Phone is not rooted;
2. App Store's vetting of claimed URI is not compromised; etc.

Nat Sakimura
Chairman, OpenID Foundation
https://nat.sakimura= .org
2019=E5=B9=B49=E6=9C=8811=E6=97=A5 4:27 += 0900=E3=80=81Masakazu OHTSUKA <o.masakazu@gmail.com>=E3=81=AE=E3=83=A1=E3=83=BC=E3= =83=AB:
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 s= erver side.

Because if phone is compromised, when AS supports public Clients and a= ccess_token leaks, it's kind of AS's fault (well depending on the t= erms...),
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 Mariu= s Scurtescu <marius.scurtescu@coinbase.com> wrote:
If the phone is compromised, original app replaced by mali= cious app, then RFC8252 will not help. The assumption is that the phone is = not compromised.

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

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

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

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
--000000000000cc66f9059241ef59--