Re: [OAUTH-WG] Certificate-bound refresh tokens and certificate expiration handling in case of the confidential clients

Brian Campbell <bcampbell@pingidentity.com> Thu, 11 August 2022 17:04 UTC

Return-Path: <bcampbell@pingidentity.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 3E9B9C14F733 for <oauth@ietfa.amsl.com>; Thu, 11 Aug 2022 10:04:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsKJZ9WnPAOH for <oauth@ietfa.amsl.com>; Thu, 11 Aug 2022 10:04:22 -0700 (PDT)
Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com [IPv6:2607:f8b0:4864:20::112f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2789C14F727 for <oauth@ietf.org>; Thu, 11 Aug 2022 10:04:22 -0700 (PDT)
Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-324ec5a9e97so178855887b3.7 for <oauth@ietf.org>; Thu, 11 Aug 2022 10:04:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=UnlwkMp0XkQWACDgaCZfAqb6cABXAThOdrZ7Pw2jKeE=; b=V3l8Lk7DFKJR2VoMHFcFgrwl2Y2PfgU0Jq24UeZZCaFfsj75tOg0gLHvPlwFiprR3D E/YlB4bMAH58+c3bIGN79kCabENwqr8SCAg5rRVovFTgeGm2l1hV0Oemm5R5G5Eho7c3 N5HiSKto3TiiuMUACTUxzQzhzObu8KmMpS5xG+Hk5elFTQVTB4xPO92P4m2rVGY4E8R/ J/Tc12rTEM/aane4F3hkfRxaNAgfGNwi++wvH/EKoQR6p5w48rfSRLFBJ/eG9umsU4KD vC3oTZ+O198Zu1h+3pcDLGrcJxk3mJuL4Vaol7I2jiI/rg1ga3e7+9TPfBroQxpGemDm 1ExQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=UnlwkMp0XkQWACDgaCZfAqb6cABXAThOdrZ7Pw2jKeE=; b=IC5D/dxI56+eMCtXeM0Ha5FyU2WeJE89hUwZquc/x6FvqzkZPqoeL5S/ZUGGO521lc hOmRYwXAeGkkYliwLQXD6Ksw9kkT53lGLemXE2bnZjHvZE2/la6fDfsfGHiRy+he+FRt 774yB5BrsgCmRmwZd7HRb7GTwQnTwAqYeJvyPUA5n4uUgZwKbIuQi9r3dsW3dOa9dq2o RYX4wrSj0GLm2YEJ4biL4OPdsLJTTXlnjqIBLJXsEAbNMiAIbtaduIsr1njxaOmthwkr 8bC+Ly0gtVkkziUbnCQA4LohcYcc5+j+bCuFkfhO9AGVTZryGNRVAd1R1iVUz+4rtdaz 7TnQ==
X-Gm-Message-State: ACgBeo0S789kgSwNxkAWOK8YRbZfjR0D7w8ukkHSqOULicKj+iSgFzmY 1rrqShWBJBW10Mj4xQ3QxBKKUE8Jf6H94cLJ9phS5nnfwOrYcfx5ZRQwHew4KCUDT0cPH0b4na9 0tpqolHV0PPYsaUhJNQY=
X-Google-Smtp-Source: AA6agR7d/iRiN8d4y9Rcu/rxgvDBEAypPspLs3StLHbZNsKVSTb+YgdwAKdaw4y+GaBT7oqR+QytCAns5tJjNw62Vs4=
X-Received: by 2002:a81:4e0d:0:b0:324:5174:5c4d with SMTP id c13-20020a814e0d000000b0032451745c4dmr192842ywb.136.1660237461740; Thu, 11 Aug 2022 10:04:21 -0700 (PDT)
MIME-Version: 1.0
References: <006c01d8ad93$776364f0$662a2ed0$@association.ge> <007201d8ad94$710026b0$53007410$@association.ge>
In-Reply-To: <007201d8ad94$710026b0$53007410$@association.ge>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 11 Aug 2022 11:03:45 -0600
Message-ID: <CA+k3eCSzUaNiO=NpqT5284+JQK=fDK_uGP_QuD65M_J5oWdWzA@mail.gmail.com>
To: mikheil@association.ge
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000267dc405e5fa2849"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/IWJ-Hs6pl-b3WK9yBspj1odRXrI>
Subject: Re: [OAUTH-WG] Certificate-bound refresh tokens and certificate expiration handling in case of the confidential clients
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
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, 11 Aug 2022 17:04:26 -0000

Hi Mikheil,

Your assumption is the correct reading of the RFC. Or the intent of the RFC
anyway. For confidential clients, refresh tokens are bound to the client id
(not the certificate thumbprint or anything else for that matter).

RFCs can't be changed after publication so adding more clarification isn't
really possible.



On Thu, Aug 11, 2022 at 9:11 AM <mikheil@association.ge> wrote:

> Hi,
>
> I have noticed is that some OAuth2 AS implementations use certificate
> thumbprints to bind not only access tokens but also refresh tokens to
> client
> certificates. This happens for both public and confidential clients. As a
> result, when the certificate is replaced (e.g., it is about to expire
> soon),
> both access and refresh tokens are drawn unusable.
>
> While RFC 8705 indeed requires binding refresh token to the certificate in
> case of the public clients in Section 4 and Section 7.1, the wording is not
> that explicit for the confidential clients. More specifically, Section 7.1
> of the RFC 8705 is worded in a way which does not explicitly deny keeping
> refresh tokens alive after certificate change: it talks about binding to
> client ID, thus binding "indirectly" to the certificate. Also, Section 6.3
> requires access tokens to be invalidated after certificate change and
> mentions refresh tokens as typical tools for renewing them.
>
> >From the practical perspective, if the confidential client got a refresh
> token for the offline access and sufficient time (e.g., for a month), this
> would be quite impractical and not very user-friendly to ask a lot of users
> to give consents again when the confidential client wants to upgrade its
> certificate. But seems like software vendors did not interpret the RFC that
> way.
>
> So, the questions:
> 1) Is my assumption correct and it will not be a violation of the RFC if
> refresh tokens issued to the confidential clients survive certificate
> change
> (e.g., by binding them to Client ID, not the certificate thumbprint)?
> 2) If the answer on the 1st question is “yes”, would it be better to
> provide
> more clarification in the section 7.1 to avoid misinterpretations in the
> future?
>
> Best Regards,
> Mikheil Kapanadze
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._