Re: [OAUTH-WG] Public client cloning

Masakazu OHTSUKA <o.masakazu@gmail.com> Wed, 11 September 2019 07:26 UTC

Return-Path: <o.masakazu@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 29CCE120810 for <oauth@ietfa.amsl.com>; 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 <oauth@ietfa.amsl.com>; 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 <oauth@ietf.org>; Wed, 11 Sep 2019 00:26:18 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id h144so43499081iof.7 for <oauth@ietf.org>; 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: <CAP=REHFHeJT=w4ZCmHYJaL4QFQvntWqPTRaXVCH-fz4FciHh5A@mail.gmail.com> <CABpvcNufpaTRk3BnjJs26b5d9k_8+hd5ZEdFjsmtViTokJiXVg@mail.gmail.com> <CAP=REHEN4JVB5xSAj6YZZNeoygPEWueyOXrbU=xuosVU5Z359Q@mail.gmail.com> <9e3c2bee-6d15-4073-9d50-ef5454405cd9@Spark>
In-Reply-To: <9e3c2bee-6d15-4073-9d50-ef5454405cd9@Spark>
From: Masakazu OHTSUKA <o.masakazu@gmail.com>
Date: Wed, 11 Sep 2019 10:26:06 +0300
Message-ID: <CAP=REHHpbuJoVHS0eTXBRhAQ4g-MKnqSA8k-vwqg2QN=zzwHUA@mail.gmail.com>
To: Nat Sakimura <sakimura@gmail.com>
Cc: Marius Scurtescu <marius.scurtescu@coinbase.com>, oauth mailing list <oauth@ietf.org>, Filip Skokan <panva.ip@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000cc66f9059241ef59"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/khOxTS35894H-Zrqgn0mA2tlj5k>
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: Wed, 11 Sep 2019 07:26:20 -0000

Okay,
Marius, Filip and Nat, thank you for your answers. :)

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
> 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年9月11日 4:27 +0900、Masakazu OHTSUKA <o.masakazu@gmail.com>のメール:
>
> 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> 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
>> <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
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>