Re: [OAUTH-WG] Dynamic Client Registration with Native Apps

William Denniss <wdenniss@google.com> Thu, 29 November 2018 18:49 UTC

Return-Path: <wdenniss@google.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 50C2E130E61 for <oauth@ietfa.amsl.com>; Thu, 29 Nov 2018 10:49:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -18.959
X-Spam-Level:
X-Spam-Status: No, score=-18.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 67RKxmbwNlFW for <oauth@ietfa.amsl.com>; Thu, 29 Nov 2018 10:49:22 -0800 (PST)
Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 A0FF0130E5C for <oauth@ietf.org>; Thu, 29 Nov 2018 10:49:22 -0800 (PST)
Received: by mail-it1-x12b.google.com with SMTP id a6so5319859itl.4 for <oauth@ietf.org>; Thu, 29 Nov 2018 10:49:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B/cbLD3MXRBWn4GA3Q3py+9EIvL0NRKSs+rxcNC6K7M=; b=JoOLebtShNVx+vG9wsd750DEMjGqBJXjcgmjtol/hLqNGz+1XE7oj7psKQdvP5KlmG n6knos7QfvoAboSLUWvx9jfC2c8iwo1y39nfsg23bqjTwfOyVeec1yGwZx5A+mS32/x0 ZrslqrXA3YDOE2yVxC2PmUYDrVCkmRKxM/FEI8ZW/G8nplO2z4Q2L0OQre80+hs1Nvai cI/wOPzWi9LZy0YhMMcjRGLZxeRBCZQUgIvRU0sreKiEwuPHtlQIClWWmys9VvgbBs6Z w5vh9WvMNH93baAfHt36QDE/1WvnIyh1NrxkrBlTktGNKXOp2fVUGRP8bVH9E4pU2RU9 f91w==
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=B/cbLD3MXRBWn4GA3Q3py+9EIvL0NRKSs+rxcNC6K7M=; b=UhimL9Qrb1vFpte03EFJcN/U2l2A/8lH/ibftbbxJQJWrWVjBGR5Jyq/cVlbNs0Nuh PVBtc2ywKJvUAP2MQkf/Pmqb8IZ8sTEmpZOmczmBjboTpME3EZCHR4SwngN/U6/eA4I5 Xvd1c9YAt+KYSqOZ4FDaEp/XLnWqPurmuw0d4rR1Vp8/NgJzgsivvnqkFmLmKsBi90MQ fze8IivcghWx25cupZvgCC9AG8uIMA5xGi1tuHIUkyPUfMoGsa3O8utROfCbk6aODBru sonfUSuZzKz2E1X8vMbOUXCi4KC6UT1/8ILi9tD6pzSYD7dwij/V3KXcOhyYS3ALOFy5 52zg==
X-Gm-Message-State: AA+aEWbkCTxMRGCuZJ44Bq7OLFJmGRrHYGlNZpD0ybh01PrxVpn2qQEI R3o3aJT1SOoTwj+tzDCrOscYWGLa0f5vyKWSpoK6yIxzoRyopQ==
X-Google-Smtp-Source: AFSGD/XBd8mgsr7amynqSpSCnR4allYuNU5+annMAAeVelpA5VxK0ZUv/pHH2ysIAeaJCwsrOEJ/ccWh5iRY/z7eSco=
X-Received: by 2002:a24:97c3:: with SMTP id k186mr2755430ite.125.1543517361504; Thu, 29 Nov 2018 10:49:21 -0800 (PST)
MIME-Version: 1.0
References: <ef1cc4ac-a85b-ef73-1ba2-3e7d76b3849d@rub.de> <CAAP42hB05ktBPES-vYqy=qrp8wBJM7JnMLomuPGYT8wLFY=SVA@mail.gmail.com> <0bdd9b63-939b-f1db-a87b-8e1e450bb1cc@aol.com> <CALAqi_-YhrC21Kw2TUJs86+bQbXbmo3ar1tvYLgYUZNTJatMTg@mail.gmail.com> <fd7bdf42-cb68-8e95-6e2e-1b5e0c528906@aol.com> <CALAqi_88fq4Ht7MHWxO28B+BcYYNoS0dkZGH85WdYW91oXC36g@mail.gmail.com> <D6AFB7CE-EDBF-4309-BA0C-2A4AAF62D3EA@amazon.com> <065bba73-eade-2f07-038f-8afa708e38be@rub.de>
In-Reply-To: <065bba73-eade-2f07-038f-8afa708e38be@rub.de>
From: William Denniss <wdenniss@google.com>
Date: Thu, 29 Nov 2018 10:49:09 -0800
Message-ID: <CAAP42hAhPzm0kvSyuo5CcoGhvm+ymG8ZM7_at-Nh6+Y-AFCtgg@mail.gmail.com>
To: Christian Mainka <Christian.Mainka=40rub.de@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000a07d8057bd224e5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/qBdHjjhAWPB4eI8WIioTN7b9nZM>
Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
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: Thu, 29 Nov 2018 18:49:27 -0000

On Thu, Nov 29, 2018 at 6:03 AM Christian Mainka <Christian.Mainka=
40rub.de@dmarc.ietf.org> wrote:

> Hi,
>
> thanks for pointing this out!
> This was exactly what confused us during reading *-* the main threat we
> see and which is not addressed is related to the app impersonation attack.
> Even PKCE does not help against the app impersonation attack.
>

Claimed "https" scheme URIs (RFC 8252, Sec 7.2) can be used to provide some
identity guarantees (security considerations in Sec 8.6), as the OS will
only open apps that can verify domain ownership to process the redirect.
This is what I would recommend as a starting point if you want assurances
over the app's identity.

A spoofing app can still use a web-view to intercept the response that way,
but in that case they'd also have full access to the session cookie (due to
the use of webview for the sign-in), which is potentially a more valuable
token (i.e. you have bigger issues). It does effectively prevent against
tokens issued form the browser SSO session being intercepted by the wrong
app.



>
> So a "Native App + Dynamic Client Registration" can be seen at a different
> "confidentiality level" than a "public client", because every native App
> can dynamically register itself on the IdP.
> The IdP cannot distinguish, for example, an honest native client from an
> malicious client starting an app impersonation attack.
>
> We agree that, e.g., a leaked code cannot be redeemed unless you have the
> respective client_id/client_secret.
>
> But... we asked ourselfs, in which cases does a code leak?
>
> 1) In the front-channel. In this case, it is true that no client
> credentials leak and an attacker cannot redeem the code.
>
> 2) In the back-channel. But if this channel is insecure, you directly get
> client credentials (unless client_secret_jwt is used as pointed out by
> George).
>
> So, Dynamic Client Registration only helps if the code leaks alone (as in
> 1.), or if it leaks on different levels (e.g. logfiles).
>
> On the opposite site, if Dynamic Registration is available, an attacker
> can very easily do an app impersonation attack by registering on the IdP.
> To be clear, it is not "impersonation" as in the "one secret per software"
> scenario, because different client_id and client_secret is used, but to the
> best of my knowledge, the IdP cannot distinguish between an honest app and
> an app impersonation client that has simply registered.
>
> In addition, if the IdP supports the dynamic client registration:
> How can the IdP distinguish between confidential and public/native clients?
> With respect to the consent page, which must be shown every time for
> native apps, this is an important issue, which should be addressed properly.
>
> Best Regards
> Vladi/Christian
>
> Am 29.11.18 um 00:38 schrieb Richard Backman, Annabelle:
>
> It should be noted that “traditional” confidential clients with registered return URLs and server-side secrets may provide a higher degree of confidence in the true identity of the client that doesn’t carry over to confidential native app clients. A native app instance’s registration call is necessarily unauthenticated (for the same reasons that statically registered native app clients are public clients), so the Client Impersonation concerns described in section 8.6 of RFC8252<https://tools.ietf.org/html/rfc8252#section-8.6> <https://tools.ietf.org/html/rfc8252#section-8.6> still apply.
> --
> Annabelle Richard Backman
> AWS Identity
>
>
> From: OAuth <oauth-bounces@ietf.org> <oauth-bounces@ietf.org> on behalf of Filip Skokan <panva.ip@gmail.com> <panva.ip@gmail.com>
> Date: Wednesday, November 28, 2018 at 9:11 AM
> To: George Fletcher <gffletch@aol.com> <gffletch@aol.com>
> Cc: oauth <oauth@ietf.org> <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps
>
> Apologies, I missed the issued in "issued a shared secret", just reading "shared secret" alone is the exact opposite of a per-instance secret. The rest is clear and as you say it brings the benefit of the secret never being sent over the wire (except during the initial registration via TLS).
>
> Best,
> Filip
>
>
> On Wed, Nov 28, 2018 at 6:03 PM George Fletcher <gffletch@aol.com<mailto:gffletch@aol.com> <gffletch@aol.com>> wrote:
> It's "confidential" in that the shared secret is unique to that app instance registration (as Dennis described in his response). If an attacker gets my phone and compromises the data stored on my device, they only get the secret for my device. This is no different than a server side client having their client secret compromised through an attack (and in some ways is better because it's instance specific).
>
> The main point I was trying to make, is that the 'client_secret_jwt' method allows the client to never send the shared secret across the wire as is created in the default OAuth2 HTTP Basic Authentication method.
>
> Thanks,
> George
> On 11/28/18 11:03 AM, Filip Skokan wrote:
> Hi George,
>
> #2 doesn't seem confidential, it's still a secret shared amongst installations and anyone reverse engineering the apk, extracting the secret, can form the client_secret_jwt client_assertion with it just fine.
>
> Best,
> Filip
>
> On Wed, Nov 28, 2018 at 4:48 PM George Fletcher <gffletch=40aol.com@dmarc.ietf.org<mailto:40aol.com@dmarc.ietf.org> <40aol.com@dmarc.ietf.org>> wrote:
> In addition, a few additional patterns are enabled...
>
> 1. The native app can generate a public/private key pair and then use private_secret_jwt as the client credential validation method via the client credentials flow (defined in OpenID Connect).
>
> 2. Maybe more simply, if the native app is issued a shared secret, the app can use client_secret_jwt method for client authentication which ensures the shared secret never leaves the device. (Again defined in the OpenID Connect spec).
>
> 3. Once the native app instance has credentials, they can be used for additional securing of app API transactions in addition to just the OAuth2/OpenID Connect flows.
>
> Thanks,
> George
> On 11/27/18 3:28 PM, William Denniss wrote:
> If the secret is dynamically provisioned then you have a confidential client. Anyone reverse engineering their own installation of the native app would only extract their own client's credentials, as opposed to the shared secret of all installations. Having a confidential client means that requests to the token endpoint (code, refresh) are client authenticated, so PKCE wouldn't be needed.
>
> On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka <Christian.Mainka=40rub.de@dmarc.ietf..org<mailto:Christian.Mainka=40rub.de@dmarc.ietf.org> <Christian.Mainka=40rub.de@dmarc.ietf.org>> wrote:
> Hi,
>
> we just stumbled upon this [1] statement:
> "Except when using a mechanism like Dynamic Client Registration
>    [RFC7591] to provision per-instance secrets, native apps are
>    classified as public clients ..."
>
> What does this mean for us? Native App + Dynamic Client Registration =
> Confidential Client?
> Which threats are covered if Dynamic Client Registration is used on
> Native Apps?
>
> Best Regards,
> Vladi/Christian
>
> [1]: https://tools.ietf.org/html/rfc8252#section-8.4
>
> --
> Dr.-Ing. Christian Mainka
> Horst Görtz Institute for IT-Security
> Chair for Network and Data Security
> Ruhr-University Bochum, Germany
>
> Universitätsstr. 150, ID 2/463
> D-44801 Bochum, Germany
>
> Telefon: +49 (0) 234 / 32-26796
> Fax: +49 (0) 234 / 32-14347http://nds.rub.de/chair/people/cmainka/
> @CheariX
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.org<mailto:OAuth@ietf.org> <OAuth@ietf.org>https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
> OAuth@ietf.org<mailto:OAuth@ietf.org> <OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.org<mailto:OAuth@ietf.org> <OAuth@ietf.org>https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
>
> OAuth mailing list
> OAuth@ietf.org<mailto:OAuth@ietf.org> <OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth<https://www..ietf.org/mailman/listinfo/oauth> <https://www..ietf.org/mailman/listinfo/oauth>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> --
> Dr.-Ing. Christian Mainka
> Horst Görtz Institute for IT-Security
> Chair for Network and Data Security
> Ruhr-University Bochum, Germany
>
> Universitätsstr. 150, ID 2/463
> D-44801 Bochum, Germany
>
> Telefon: +49 (0) 234 / 32-26796
> Fax: +49 (0) 234 / 32-14347http://nds.rub.de/chair/people/cmainka/
> @CheariX
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>