Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

Daniel Fett <fett@danielfett.de> Fri, 12 June 2020 15:10 UTC

Return-Path: <fett@danielfett.de>
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 3F9443A0C01 for <oauth@ietfa.amsl.com>; Fri, 12 Jun 2020 08:10:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.de
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 HtHahZp8GZYH for <oauth@ietfa.amsl.com>; Fri, 12 Jun 2020 08:10:43 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825283A0B50 for <oauth@ietf.org>; Fri, 12 Jun 2020 08:10:43 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id A23897822 for <oauth@ietf.org>; Fri, 12 Jun 2020 15:10:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1591974640; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4AvXBE3o+MPg5I8jGErmlrHXfHwqsKQAEhe4r1GWUz8=; b=DMSk7//muQoIQVdp8zPERVV6gKARltDuNWUpg1tZ0ylCAWLSBfUbSKbv3x75Mf1MOh2BzU D/6JwQhhD2kmAS6+dVclgEXDb/aDo/iEVpoAQZk68jnJVH+Ip9WjtVxpyABT54cGNyKceD GlrTc5kCBdoPGH+2cO7ZMEnP9+xg+PY=
To: oauth@ietf.org
References: <8762DAF0-CA56-407D-9DD9-86809BD844B2@lodderstedt.net> <6473D5F3-7C90-400D-9263-FA5B6082496B@forgerock.com> <CA+k3eCTeyBFS4nefFeRVrDDAAofpLJ78fpvtxZ2JQOvXEpF50w@mail.gmail.com>
From: Daniel Fett <fett@danielfett.de>
Message-ID: <8154b9ce-6238-9516-6fe7-a933ec7acc13@danielfett.de>
Date: Fri, 12 Jun 2020 17:10:39 +0200
MIME-Version: 1.0
In-Reply-To: <CA+k3eCTeyBFS4nefFeRVrDDAAofpLJ78fpvtxZ2JQOvXEpF50w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------0A7DA632255ED3EB09EB92B0"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1591974640; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4AvXBE3o+MPg5I8jGErmlrHXfHwqsKQAEhe4r1GWUz8=; b=MF1tYlwyp0s6UIboBkr4LY8rI9QKqNWZVdHgWotSwJTiw1HIbYbXytZ47SVUGaznxDzSwk DRxgjzBa8zXSaV9J2MB9cdVBoEVODaWpM9OBlBEWf94JQ5m2YlmqmAM/zFOWDJ5BXpKmLT 3I7ix8W8ellWxgpCu9SotJHO70xjTMg=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1591974640; a=rsa-sha256; cv=none; b=h2QcrsIjgxJZuZbBljThPpOvupRJ4/rSgu3FowmQ5FrKp7ybUTqOT7x9FqswvBH7BlxDmc 2B2sgIdV7p2xpw+vLn48TzUjKS2CIPTFEOSWBQBLNZhO19OZu2qewvFXYChaOtD4IEUf3Y MGT/RiGnjGdqxm7wY0eAVrBQwcLgsh0=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/uM2shtc4DxbHDDbyNDwsNCYexFg>
Subject: Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments
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: Fri, 12 Jun 2020 15:10:45 -0000

Am 11.06.20 um 23:17 schrieb Brian Campbell:
>
> Also to help facilitate mixed or rollout deployments, I'm not sure
> about "An client should never send a DPoP [bound access] token as a
> Bearer header."  Such a constraint could be put on the client but it
> seems unhelpful. A bad acting client could easily ignore it and I'm
> not sure what it accomplishes if/when followed. Following from
> https://github.com/danielfett/draft-dpop/issues/58 the draft needs to
> be updated to say explicitly that an RS supporting both Bearer and
> DPoP schemes simultaneously needs to update its Bearer token
> evaluation functionality so as to reject tokens that are dpop bound.
> But the draft can't really impose anything on existing RSs supporting
> only Bearer (and unaware of DPoP). And such RSs will most likely
> accept a DPoP bound AT when send via the Bearer scheme (JWT says to
> ignore unrecognized claims, introspection says other parameters might
> be present, and 6750 is basically silent on the content of the AT,
> which is where the binding is carried). This admittedly doesn't seem
> quite right. But there's nothing this draft can realistically do about
> it. And I think it can help with mixed or rollout deployments.
> Especially those where sufficient information about what RS(s) the
> requested token is for are not available in the token request for
> whatever reason. Currently the draft is silent about it and maybe
> that's as it should be. But I'm suggesting in a few messages on this
> thread that the definition of the DPoP token_type would prescribe
> sending the access token with the DPoP authorization scheme in
> conjunction with the DPoP header but also say that, if that was met
> with a 401 WWW-Authenticate: Bearer challenge by a particular RS (or
> the client had prior such knowledge about the RS), that the access
> token could be sent using the Bearer authorization scheme.
I would support that.
>
> It is correct that, as currently written in the draft, a public client
> with a DPoP bound refresh token will have to use the same key for the
> lifetime of the grant. That seemed like a good tradeoff vs. defining a
> mechanism for key rotation for the public client refresh token case
> where two proofs (one to verify the binding for the RT being sent and
> one to newly bind the RT to) would be presented on refresh grant type
> request. I tend to think where it is now hits the right balance in
> functionality and complexity. But if there are strong beliefs
> otherwise, let's discuss the need and cost/benefit and all that.

Absolutely agree. We would create a lot of complexity for very little gain.

-Daniel


-- 
https://danielfett.de