Re: [OAUTH-WG] Rotating client secret

Amarendra Godbole <ag@broadcom.com> Tue, 14 July 2020 00:40 UTC

Return-Path: <ag@broadcom.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 B64403A0C38 for <oauth@ietfa.amsl.com>; Mon, 13 Jul 2020 17:40:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 TCO_cOO0cAgz for <oauth@ietfa.amsl.com>; Mon, 13 Jul 2020 17:40:00 -0700 (PDT)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 2C2C03A07C8 for <oauth@ietf.org>; Mon, 13 Jul 2020 17:39:59 -0700 (PDT)
Received: by mail-pl1-x62a.google.com with SMTP id b9so6272664plx.6 for <oauth@ietf.org>; Mon, 13 Jul 2020 17:39:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bKwRvAmgNwuKLrm+Tn7QM3TtqA/lOZKN8uDCI0NfIdg=; b=Jw3X0LmrmS0h0pIBCehkwA4K+xCdP0UxkSZkIw1GxET9nEGohan6PuknVqqE2EPRx7 ecrvZM+xSRRupjs/D70cgwR57granpGP/v5jjn1teeAz5XVMfYhJAVuzWq781rDA4mWr nMlVmNapIrPLL6W5z3bADsnAHgNfcgY0Fg1WQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=bKwRvAmgNwuKLrm+Tn7QM3TtqA/lOZKN8uDCI0NfIdg=; b=alag+hppNpo1qrzt92nHDQnfFcPRcgPTUX4iazNY6Qrmy6iE4YxHAONS+Vyxm/LJIp uneeu1ymKbuQk38FPxwBlRI9jkJMmtoDha9kwuKunK7+IzEvUweeHPzboDpgKJVn8CGF XZUhzJIz5Dl66wZkyDV9SLsuw/Lwb+fwiiwT3dI8JgwixQv5iWEi7zzcy5NdOu/5WRzf wFB3mR+juE9KoiisnU+gv1dugd27NhLZG3P0DW/N1PbR2InEY7/pxN7e/Gb3vqvUcTSy KyIM8vDMrzt/18XHWjl/kYWn/+8WvePNaua8lat5nNhPnY0GczeLiedtsFGV5/QVB6yN laUA==
X-Gm-Message-State: AOAM531dQ3wJBab2Jp+RgCTcygzA4u8dJAiBdqzwsxL6p2Wvotg6fiG6 McZXUNRKLZjlMhBzcaYTMcdBjcoAgh8=
X-Google-Smtp-Source: ABdhPJyk+txO2ML0Q+9vtI4DeAr9vL9yeHewDIfRiJk8Mf9ZG+zUtpbrtKN8V//G+Ju6BFpHsHiAXA==
X-Received: by 2002:a17:902:c209:: with SMTP id 9mr1816341pll.133.1594687199081; Mon, 13 Jul 2020 17:39:59 -0700 (PDT)
Received: from c02w42tjhtdd.lan (c-98-248-136-122.hsd1.ca.comcast.net. [98.248.136.122]) by smtp.gmail.com with ESMTPSA id io3sm624691pjb.22.2020.07.13.17.39.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jul 2020 17:39:58 -0700 (PDT)
From: Amarendra Godbole <ag@broadcom.com>
Message-Id: <5F99C5D2-2805-4C28-BE4F-4DDB5F0F2E80@broadcom.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_35A1C054-470C-428B-A28C-9EC4B1F39ACA"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.4\))
Date: Mon, 13 Jul 2020 17:39:56 -0700
In-Reply-To: <CAJot-L0jsX8Gzr2xMo1E7=q0H4H694UQW3eOHAoRapezofEW7w@mail.gmail.com>
Cc: oauth@ietf.org
To: Warren Parad <wparad@rhosys.ch>
References: <7619889F-6A75-4179-B4A8-DEAAC359E5EB@broadcom.com> <CAJot-L2ci3uf2TcP_6jWP5ExwBCam=pTLAOQOKnDperG7NwzCg@mail.gmail.com> <BF20EE1A-F070-4E27-B13D-97DA70676ADB@broadcom.com> <CAJot-L0jsX8Gzr2xMo1E7=q0H4H694UQW3eOHAoRapezofEW7w@mail.gmail.com>
X-Mailer: Apple Mail (2.3601.0.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/KhnL__M0ZDd2JP-ZM0nLmEiWraE>
Subject: Re: [OAUTH-WG] Rotating client secret
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: Tue, 14 Jul 2020 00:40:03 -0000

Ah! That isn’t the issue as much as the fact that Admin B does not want to share the client_secret with Admin A in the first place!

As Dick Hardt suggested earlier, we are already considering moving it up a layer since this is largely a trust-between-humans-issue, though its still a bummer that OAuth2 doesn’t support rotating client_secret.

Thanks everyone who responded, I have enough food for thought!

-Amarendra

--
sent via recycled electrons, from my portable command center.



> On Jul 13, 2020, at 3:50 PM, Warren Parad <wparad@rhosys.ch> wrote:
> 
> Why is #3 a problem, and why do the admin A incorrectly use App A to store the service credentials of App B in their repository? Admin A should be using their source control/database to store the tenant B client secret.
> 
> Warren Parad
> Secure your user data and complete your authorization architecture. Implement Authress <https://bit.ly/37SSO1p>.
>  <https://rhosys.ch/>
> 
> On Mon, Jul 13, 2020 at 11:34 PM Amarendra Godbole <ag@broadcom.com <mailto:ag@broadcom.com>> wrote:
> Let me see if I can provide more details on the usecase:
> 1. A tenant is subscribed to SaaS application A and SaaS application B, and both applications are separately managed by different teams in the same organization. No assumption can be made about the trust between those teams.
> 2. Application A backend is supposed to access Application B. App B also has the authorization server. Both applications expose administration UI for its tenants.
> 3. App B admin generates client_id and client_secret, and hands them over to App A admin.
> 4. App A admin enters the client_id and clilent_secret in the UI, so the backend App A can now communicate with/access App B.
> 
> #3 exposes client credentials of App B to admins of app A — this is our problem. As stated in #1, we cannot make any assumptions about the level of trust between the two groups.
> 
> If OAuth2 provided a client credential rotation, this exposure of credentials can be limited to a small time window. The original client_secret can be a one-time-use-bootstrap, that App A backend exchanges for another secret from the authorization server. Generalizing it, the OAuth2 spec can provide for servers to trigger a client_secret rotation.
> 
> To your analogy, the front-end app can “leak” the credentials during provisioning (it can be a simple copy/paste that the user has to do), thus creating a security issue. But if the credentials are one-time-bootstrap, then first time the front-end app connects to Google drive, drive changes the client_secret for a different one, which then would be used by front-end app in the future. Drive also has the ability to periodically rotate the client_secret in a similar manner. This assumes front-end app cannot access the client_secret once it is provisioned.
> 
> Is this better? Thanks!
> 
> -Amarendra
> 
> --
> sent via recycled electrons, from my portable command center.
> 
> 
> 
>> On Jul 13, 2020, at 1:48 PM, Warren Parad <wparad@rhosys.ch <mailto:wparad@rhosys.ch>> wrote:
>> 
>> I'm not sure if it is just me, but I'm not sure I'm totally following.
>> 
>> I can see a concrete analogy being that, Tenant application B could be Google Drive, and Tenant application A being any front end app that wants to offer a service that saves files in a user's Google Drive. If application A wants to interact with application B offline then tenant A needs a service client/secret along with an authorization grant initiated through application A (currently via UI in OAuth2).
>> 
>> Whether application A cycles the client secret or not seems like a different problem. But I think I'm missing something. Given the example I provided, would you be able to provide more insight into the problem you are seeing?
>> 
>> Warren Parad
>> Secure your user data and complete your authorization architecture. Implement Authress <https://bit.ly/37SSO1p>.
>>  <https://rhosys.ch/>
>> 
>> On Mon, Jul 13, 2020 at 10:36 PM Amarendra Godbole <ag=40broadcom.com@dmarc.ietf.org <mailto:40broadcom.com@dmarc.ietf.org>> wrote:
>> Hi All,
>> 
>> First post to the list, and hopefully I am articulate enough to describe the problem I am facing — did OAuth ever consider an ability to dynamically rotate client secret (part of the “client credentials” authorization grant)? I stumbled across rfc7591 (OAuth 2.0 Dynamic Client Registration Protocol), but the OAuth 2.0 implementation I am looking at [1], does not support it. I also found some previous reference to client secret rotation [2], but it does not discuss my use case.
>> 
>> We operate a SaaS application A, which is supposed to talk with another SaaS application B. Our customers subscribe to both, our application A as well as application B. However, the teams adminstering A and B are separate teams within the same organization, though we cannot assume the level of trust between them. Let’s call them Tenant Admin A and Tenant Admin B. In our usecase, application A is the client for application B, and application B provides OAuth 2.0 authorization workflows. Now, Tenant Admin A has to provision the "client credentials” authorization grant — in order to do that, Tenant Admin B generates the client_id and client_secret, and sends them to Tenant Admin B. There is the problem — as I earlier stated, we cannot assume the level of trust between Tenant Admin A and Tenant Admin B, and exchanging client_id and client_secret now means the circle of trust for application B includes individuals who may or may not be trusted.
>> 
>> One thought that occured to me was a provision in OAuth 2.0’s client credentials grant flow was the ability to “bootstrap” a client application — basically the client_secret is one-time-use-and-timebound-only, and allows the client to exchange it for a different client_secret. In our case, this can be handled by the SaaS application backend, thus making sure the Tenant Admin A no longer have access to it once they provision the client. This can be generalized, such that the authZ server can periodically trigger client_secret rotation, and won’t require manual intervention [3]. As I stated earlier, rfc7591 talks about this, but but in the context of dynamic registration.
>> 
>> Having the client secret rotation a part of the protocol exchange messages, maybe a bootstrap, would be the ideal solution for our usecase.
>> 
>> Or the bigger question: Did I misinterpret it all? Looking for guidance from this list.
>> 
>> Thanks in advance.
>> 
>> -Amarendra
>> 
>> [1] Microsoft Azure https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-app-types <https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-app-types>
>> [2] https://mailarchive.ietf.org/arch/msg/oauth/7ICMSRI2tjfXDD1Bk_G-qNpLy-0/ <https://mailarchive.ietf.org/arch/msg/oauth/7ICMSRI2tjfXDD1Bk_G-qNpLy-0/>
>> [3] Auth0 rotate client secret: https://auth0.com/docs/dashboard/guides/applications/rotate-client-secret <https://auth0.com/docs/dashboard/guides/applications/rotate-client-secret>
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>