Re: [OAUTH-WG] DPoP and refresh tokens

Brian Campbell <bcampbell@pingidentity.com> Wed, 28 October 2020 23:09 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 93B063A0A8F for <oauth@ietfa.amsl.com>; Wed, 28 Oct 2020 16:09:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_FONT_LOW_CONTRAST=0.001, 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 (2048-bit key) header.d=pingidentity.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 g0U0yfllniBw for <oauth@ietfa.amsl.com>; Wed, 28 Oct 2020 16:08:59 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 316073A0A56 for <oauth@ietf.org>; Wed, 28 Oct 2020 16:08:59 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id 2so1001703ljj.13 for <oauth@ietf.org>; Wed, 28 Oct 2020 16:08:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sMQZpwmEOCY/r/9ryljjcA2e7CunbgIIFzh+rLc7z2U=; b=c/Fl1fZVMq6lfYC24vcMboLrbgE3670zJfhrp/QgYXQPZzGQb0T8hRwucZjqTphSGj ZPJsE9F50Hmqrg4RkRIyG6McM0MBWX3wcGVPJ71CwipJsADLLSWuHU5aaIlKV6JwRUCr CdcQLC0TqA1PmEZcBaBD5Z6+fJmdY3Dz2G1PnFXsko3t9O3lIi+KUISGhCZF0W0nyc7W Iz3FCuAsEzRxAo5KQ/KXzj0ZpU0a7h1jmyYE2x+i1Cqg1CnqM2X22S1sX2VLEh0RGMci rJpe/rfTEGc2jH8fLgwRvQJnxvZwhuJD+O34rQTePSaOC8AnD6fAEvKLhy5dROrmngk6 q2BA==
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=sMQZpwmEOCY/r/9ryljjcA2e7CunbgIIFzh+rLc7z2U=; b=uPdqOv8Zdj8mgm7bBR8paTTrNt1ObWitRsAaTxu0tKKorGQ23Eo8kl47E9Kl8Tpw3Q sKfeo+KASrQushZDYiDxOs5N6KuSxvonQ9H+6ZmwEU5DlR4tg/tvTy8mIV9WPc6l2J7T xLJLUqCGuc1hr/UwKKLV3p4iKOSOX/43MQrw6LzC2KRarrsNUJVUm/8YBxn9yuUo82JM Sl0GJMluu/1mz1p4NBJdEkN7LWdf4hBDsYW6Z326SnSI10Mg7XMyImsCYEYXuEw/foTk Qhm7hpBssncXsOkXfEIbD1KB4piIYnaf9KgRbOUj7lMGVDnAQznPIXQy934rCbjHShGQ u4qw==
X-Gm-Message-State: AOAM532ifWRTdYKnqC2sP8+0ie7+IBZKNZ5uhz/K4rOx6I6BKDnm2o8I fwWPmnEzs2+6xGsGZ619I7G6GeIKbujxaGi0yeTnpL13H5HOju9SesG9Ro4iPfrbHt7xkqPOkxX uKU3Qx9GaLmNZ3A==
X-Google-Smtp-Source: ABdhPJzRpGO1f7orwD0RmwZKRd8l6lmtp+CwuDFiBr4iKZ847Hfxat2VHkEXC5KzdBAKYDqwpt8qIShETsu4dWnCC5g=
X-Received: by 2002:a05:651c:39a:: with SMTP id e26mr637368ljp.170.1603926537187; Wed, 28 Oct 2020 16:08:57 -0700 (PDT)
MIME-Version: 1.0
References: <CAD9ie-ttterDkFqcW_rbV6gwwU=puL3YJ5c9uLY4Lj3KvEWG-Q@mail.gmail.com> <CA+k3eCQmGa9V5cFy+zFrV8E-agi466=oz_BaR-_cJYMK1HgY+A@mail.gmail.com> <CAD9ie-tw5+aFK5PK3wWKMfq4-17c3X1rO6=oEqt+UgaVfdBzqg@mail.gmail.com>
In-Reply-To: <CAD9ie-tw5+aFK5PK3wWKMfq4-17c3X1rO6=oEqt+UgaVfdBzqg@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 28 Oct 2020 17:08:31 -0600
Message-ID: <CA+k3eCSf+w1iNZgLkFjb_q5SQQ9R2qohGhc0j6zjrPp2ciu80Q@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007f55d505b2c33f8d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/P3NtGvYwF-IxfMy7RStTOxh7ID4>
Subject: Re: [OAUTH-WG] DPoP and refresh tokens
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, 28 Oct 2020 23:09:02 -0000

Okay, I'll look at adding a refresh example and some additional explanation.

There are client authentication methods that use asymmetric cryptography so
sender-constraining a refresh token with an asymmetric key pair (indirectly
via the client's credentials) is already possible and happening in practice
(JWT client auth and MTLS client auth). Nothing in DPoP is trying to
discourage that. DPoP is just avoiding the added complexity and operational
problems that would come with sender-constraining the RT with two different
mechanisms.

On Wed, Oct 28, 2020 at 4:35 PM Dick Hardt <dick.hardt@gmail.com> wrote:

> Hey Brian
>
> A refresh example would make it more clear, and would also assist in
> communicating that DPoP could be used just for refresh.
>
> I see in the updated text that using DPoP with confidential clients is
> discouraged. I understand the RT is sender constrained -- but
> asymmetric cryptography is much stronger than a shared secret. Why
> discourage its use?
>
>
>
>
> ᐧ
>
> On Wed, Oct 28, 2020 at 3:20 PM Brian Campbell <bcampbell@pingidentity.com>
> wrote:
>
>> I'm currently working on the draft and hope to have a new revision
>> published relatively soon. Just the other day I made some changes to the
>> text around RTs with
>> https://github.com/danielfett/draft-dpop/commit/11d90264bffa0325461e7f8d96311fac44986974
>> that maybe/hopefully makes some of it more clear? But basically the RTs are
>> only bound for public clients and the exact mechanism to do it is left up
>> to the AS. The AS both creates and consumes the RT so however it chooses to
>> associate the DPoP key with the RT is its own implementation detail.
>> Getting a new bound access token using an RT is meant to be covered in sec
>> 5 "Token Request (Binding Tokens to a Public Key)" with RT being just one
>> of the grants that could be presented in the token request in conjunction
>> with the DPoP proof, and the AS would bind the AT it issues to the key in
>> that DPoP proof. I'd sort of assumed that would just be understood. But do
>> you think it (including the recent changes) needs more explanation?
>>
>> I do think using DPoP only for token refresh (only for public clients
>> though) would be appropriate, for some cases anyway. This has come up on
>> the list here previously and the general consensus was also that it'd be
>> useful. I plan to add some language describing that (and loosening some
>> language that could be perceived as prohibiting it) but haven't gotten to
>> that item on the editing todo list yet.
>>
>>
>>
>>
>> On Wed, Oct 28, 2020 at 2:46 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>>
>>> Hello
>>>
>>> I was reviewing the latest DPoP draft[1] and saw numerous mentions of
>>> using a DPoP proof for refreshing an access token, but no explicit
>>> description of how to do that, nor an example. Was this intentional?
>>>
>>> Perhaps a new section "Refreshing an Access Token"?
>>>
>>> Additionally, I can imagine that an AS can improve its security posture
>>> by adding support for DPoP *just* to token refresh and not requiring
>>> existing resource servers to upgrade. Rotating refresh tokens would not be
>>> as critical for public clients using DPoP for token refresh.
>>>
>>> Would using DPoP only for token refresh be appropriate? If so, language
>>> describing that would be helpful. :)
>>>
>>> /Dick
>>>
>>> [1] https://tools.ietf.org/html/draft-fett-oauth-dpop-04
>>> ᐧ
>>> _______________________________________________
>>> 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.*
>
>

-- 
_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._