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

George Fletcher <gffletch@aol.com> Fri, 05 June 2020 20:17 UTC

Return-Path: <gffletch@aol.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 2CDE03A09B1 for <oauth@ietfa.amsl.com>; Fri, 5 Jun 2020 13:17:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=aol.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 7tGxbRWvA4qg for <oauth@ietfa.amsl.com>; Fri, 5 Jun 2020 13:17:23 -0700 (PDT)
Received: from sonic306-21.consmr.mail.ne1.yahoo.com (sonic306-21.consmr.mail.ne1.yahoo.com [66.163.189.83]) (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 A65C63A09B7 for <oauth@ietf.org>; Fri, 5 Jun 2020 13:17:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1591388242; bh=mturvl+w8RbFC7C00E38+4KQQPdzuOtmCKe4VOG4QTk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=AS6QDgzERQahJYcZdZCI785Gm7Hy0hWP9EpVfSRvLKzGs7DcC092oylP4kj9gwRHXE5TFhAUQDM9QQNyseLA+nRs/uWx0pteLglWRn8SfXC4NfnpmBpZTZ33FfVD8hCbbqU//qDWEE7ipD0fee2cYgro5UQaUP3u60Uubv91ZBi1Jq6qsPjMZ7yToW1Sr2oZlckLUPeNXfQjrrASahKzFLDAZ55Wav+oziymPAuvuoKl0DjEP1Nv0qbAbudHcSBfBqukTbRtUybVaTjGUYS/3q5WoVIYuPPiJmzNLC+znt3e58ZcOquxfmUDxBryzpZ1ejbpT4LgIkwO14mIUKBBIw==
X-YMail-OSG: eCnH9voVM1lgBl.JNxEl_cMfRnONDU6hpVV1n9xcxIkFsq6CWyoERgVkg85_LR2 YfZun5HTxjHdjb4DD6oXAmABSLTtnRez44.gONhrucHacnLu1vXivOYhMcJmtvvh8FbhltMWtArC ZlkmXkGn6lCQ3YImZwwUZbq96O2mT2a.5NiEXDPm9qwZZwCOoLtr.FDps0IwqTuiikTyqpzWg5yk ywmh0ynFUlKn8xFsmxkUa_YoujN0usHTrj67bbDyir1O7PZ2kNlLV1kMjBotpX74yi5kUnfF87Gk 8JHH9L5gvhFRSVUsVO.DFR.UpmFpSIIsVrbfTE6CBJYrEfWZJupQALDjyQZndb7Y40cJHfjXXQeO EAL3uk6ECLBt61eRmjw8wcWhquWgfGijJ6X14lyPm0LAcHFJ48oh00OoMEH8bpwTKmgg87USr0_q p.xuW7a62CS8gONmmK92ISJs_TEN5XVBW12vqXgzkdsqZewdz5cluYq7mIluC.zvZS9MoumMGkG1 ZO2NfE.6.ZxwIPXMHpDCNw8VJnE8_XuwMjStInvnpJ9aebIXGYayVidtOjZ2qzZUGFGjwa5S7TZ2 dmiYoISKqUo57RiivKS5qiNYw1SQ_qCC_va_r0J3YOcAA_ynKUf1WNxxY4o2O7jmJs97kxznEQrD RPixuFR487BgyFn4PZ8FvN5VrAATkkM5F3Z4YSjJXMoB6h_JJEWGXWFTYCjG4dKnMXFf7RxSusRe ZERMeR5UF2t.Nmuv5VkDMq6q5uSr0qXumetJ_K1sHbnISiCpzxio6leHtMg9.qYf3JRYNaR_VwnE qo_YpFn7.xIfBkCkC2goNhEvj1Z75yKSL8L5lFyTpfMfYKtd.796cpWh_KWmSXCjjr0O9JGlh5LX BtWYy9t5B.Nv6fUqa4ZVU.r4KbPQgKNS9ygkWSrq2qoNnWtohwGtzg5LhpGGl3XyZPwF_Tfm1sFS nbmDqJLTAhIHxLzH7rSKSIpcp9oA1CakBj936EmPr.PWuwWUXeScb2UHnCmBSuFWN_0HwkRq7rLw 9zf9Ku.JqvhnckL7lO4MvgkbqkFmZVqSyIeFpjBt.FIQAJPnv.uzajTM24x9572QoYMzYNWurlcg uwwelKq5OH1LnzbhKWtwcJ1T2jIhN.iqZTkb2KVBKeAUOMdQicZZ4M_ySd2ViSd6bkUhiwVSLjND qvOynm.V16qaXq19QzLQ9ch0D4WSqCqgDE1vUfwRqXzI6xQVkTvNbH1KucGaVaS.5ikA2bT3PlXm .aZ18LvSFpibqC1YgHAPe0ySKGkA641rZXDCZciTj4r2tykkXcG6F3Ko5s3yw1yuhkHJbCeMfSNu MKkyh8dPEYifTmoTWhMJpm.blYx.NlQFFsUS8oBJ7OJNU6KoKekSFNdGLshOv.T.eyuqO_13KXj1 JQc33Evwykr1ReE8ipA--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Fri, 5 Jun 2020 20:17:22 +0000
Received: by smtp408.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a37857451b6bfd90dc49dc39c6d76d45; Fri, 05 Jun 2020 20:17:19 +0000 (UTC)
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, Filip Skokan <panva.ip@gmail.com>
Cc: oauth <oauth@ietf.org>
References: <CALAqi_8XFZ_ZdCHo2HsH9hKZxhJC2_R_EHz1KqGYeaq_jtyO+Q@mail.gmail.com> <CA+k3eCTb5MraHMNXEHS1gwFhra=rvJb---LLTm_T97hmZbfExQ@mail.gmail.com>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <3e87e004-81a9-4581-9d21-93370e771977@aol.com>
Date: Fri, 05 Jun 2020 16:17:17 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <CA+k3eCTb5MraHMNXEHS1gwFhra=rvJb---LLTm_T97hmZbfExQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------07AAB0DD09AEDC63523E00FD"
Content-Language: en-US
X-Mailer: WebService/1.1.16037 hermes_aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ZE-3TkELhA_uiZ4H9IgA5YZ5OLI>
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, 05 Jun 2020 20:17:26 -0000

The issue I see with sticking with the DPoP token_type is that from a 
roll_out perspective, ALL resource servers must be updated to support 
the new scheme and only then can the DPoP deployment start. For any wide 
ecosystem deployment that can be problematic. I don't have any great 
suggestions:(

Secondly, I do think we need a way to allow for the refresh_token to be 
bound while leaving the access_tokens as bearer tokens. This adds useful 
security without impacting existing RS deployments. It was unclear from 
our interim meeting discussion how the client knows whether the refresh 
token has been bound to the public key or not. The AS can signal that 
the access_token is NOT bound by returning a token_type of "bearer" but 
we should think about adding addition response fields for the refresh 
token binding (e.g. "rt_token_type).

Thanks,
George

On 5/29/20 5:50 PM, Brian Campbell wrote:
> Apologies for the slow reply on this. No excuses other than life  > sometimes happens. > > `token_type` is maybe not the clearest 
extension point (and one I've > arguably misused in OAuth MTLS > 
<https://www.rfc-editor.org/rfc/rfc8705.html> and the now defunct > 
Token Binding > 
<https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08>and > 
admitted to being on the fence about in the issue you linked to > 
<https://github.com/danielfett/draft-dpop/issues/41>). But it is the > 
extension point that was basically left in RFC 6749 to facilitate > this 
exact kind of thing (for MAC really but it's conceptually > similar in 
that it was an application level proof mechanism of sorts) > . The text 
from RFC 6749 sec 7.1 > 
<https://tools.ietf.org/html/rfc6749?#section-7.1> is also copied > 
below. Note that a "client MUST NOT use an access token if it does > not 
understand the token type" so FWIW the client behaviours you > describe 
aren't in line with that. > > It still seems to be that using DPoP 
token_type is the appropriate > thing to do and that it can be defined 
to account and allow for mixed > token type situations. It would define 
that the DPoP authz scheme be > used as the authentication method to 
include the access token when > making a protected resource request. 
That definition can also include > falling back to using the Bearer 
authz scheme when/if so challenged > by a protected resource. > > 
<https://tools.ietf.org/html/rfc6749?#section-7.1> > > 7.1 
<https://tools.ietf.org/html/rfc6749?#section-7.1>. Access Token > Types 
 > > The access token type provides the client with the information > 
required to successfully utilize the access token to make a > protected 
resource request (along with type-specific attributes). > The client 
MUST NOT use an access token if it does not understand the > token type. 
 > > For example, the "bearer" token type defined in [RFC6750 > 
<https://tools.ietf.org/html/rfc6750>] is utilized by simply > including 
the access token string in the request: > > GET /resource/1 HTTP/1.1 
Host: example.com Authorization: Bearer > mF_9.B5f-4.1JqM > > while the 
"mac" token type defined in [OAuth-HTTP-MAC > 
<https://tools.ietf.org/html/rfc6749?#ref-OAuth-HTTP-MAC>] is > utilized 
by issuing a Message Authentication Code (MAC) key together > with the 
access token that is used to sign certain components of the > HTTP 
requests: > > GET /resource/1 HTTP/1.1 Host: example.com Authorization: 
MAC > id="h480djs93hd8", nonce="274312:dj83hs9s", > 
mac="kDZvddkndxvhGRXZhvuDjEWhGeE=" > > The above examples are provided 
for illustration purposes only. > Developers are advised to consult the 
[RFC6750 > <https://tools.ietf.org/html/rfc6750>] and [OAuth-HTTP-MAC > 
<https://tools.ietf.org/html/rfc6749?#ref-OAuth-HTTP-MAC>] > 
specifications before use. > > Each access token type definition 
specifies the additional > attributes (if any) sent to the client 
together with the > "access_token" response parameter. It also defines 
the HTTP > authentication method used to include the access token when 
making a > protected resource request. > > > > On Tue, May 19, 2020 at 
7:20 AM Filip Skokan <panva.ip@gmail.com> > wrote: > >> This is a RE: to 
yesterday's interim meeting discussion, largely >> related to the first 
rollout step where we want to constrain >> refresh tokens but leave 
protected resource access intact. >> >> I'll start off with a case that 
I hope we can agree is absolutely >> necessary for DPoP to solve - that 
is constraining refresh tokens >> for browser based applications. Now, 
*do we see this as a >> secondary objective? I think it should be on par 
with access token >> constraining.* SPAs using code flow and having 
access to refresh >> tokens as means against the continuous browser 
efforts to cut down >> on storage access is a real case servers will be 
eventually forced >> to adopt. >> >> Since rollout for DPoP needs to 
begin with the AS and Client >> supporting it (regardless what order i 
guess) there are going to be >> instances where the RS will be 
supporting both Bearer and DPoP at >> the same time. >> >> As discussed 
yesterday, the client shouldn't know/care and change >> its behaviour 
when it comes to using access tokens. >> >> *But what is the client 
behaviour we take for standard?* Because I >> can see two conflicting 
implementations in the wild >> >> 1. The client echoes the token_type it 
received from the token >> endpoint as the authorization scheme - 
(optionally) throws on >> unrecognized token type values 2. The client 
uses Bearer as a fixed >> authorization scheme and ignores the 
token_type it received >> >> #2 is an implementation which I suspect has 
no idea about DPoP, but >> if extended to send DPoP headers (through 
various mechanism - >> library extensions or even manipulating the 
`XMLHttpRequest` >> prototype) will >> >> - 🎉 get the benefit of having 
its Refresh Tokens bound - 🎉 most >> likely continue to work with RSs 
that only support Bearer - ❌ will >> cease to work with RSs that will 
adopt support for DPoP because >> it'll be using the wrong scheme, that 
is unless (🎉) RSs >> supporting DPoP choose to suspend the requirement 
to use the new >> scheme and instead depend on the presence of `cnf.jkt` 
as means to >> trigger DPoP validation. *Q: is that an acceptable thing 
to do?* >> >> Arguably, client behaviour #1 is what a client should be 
using if >> it supports other schemes besides Bearer. But it may as well 
be the >> behaviour of a client that has no clue about DPoP, right? 
Again, >> such client can be made to support DPoP in a SPA through >> 
manipulation of the XMLHttpRequest prototype, in which case the >> 
developer needs to do the same for the protected resource calls. >> But 
at this point the developer has to know which RS to apply DPoP >> to and 
which not - ergo - which to send Bearer vs. DPoP scheme to? >> The 
developer will have to write a whitelist of resource servers >> anyway - 
and there we get to the point where client has >> information and 
functionality that it shouldn't /need to/ have. >> >> Its great that we 
have token_type, authorization header schemes, >> etc..., but we don't 
seem have a well defined (or at least >> followed) behaviour for our 
clients around handling the token_type >> response values and their 
usage. >> >> A developer has to resolve to navigate this monkey course 
unless >> the RS definition on the AS is aware of the fact that the RS 
does >> support DPoP, so that the issued token_type is always correct 
for >> the RS. So, *should we make that a recommended way of 
'indicating' >> when to issue Bearer vs DPoP access tokens?* >> >> What 
else could we do that doesn't give more decision making to >> the 
clients so that the very first step - *Refresh Tokens get >> 
constrained* - is achieved* but Protected Resource access is >> 
unaffected?* >> >> Note that this was not "a thing" for mTLS because it 
continues to >> use the Bearer scheme (for better or worse) and it 
completely omits >> possible continuous rollout or discussing what are 
the signals the >> RS must use to require mTLS to be used), same for the 
abandoned >> OAuth 2.0 Token Binding draft (also continued to use the 
Bearer >> scheme). >> >> I suspect we have just this opportunity to fix 
token types and >> their use and if we can't, we'll have to resolve to 
abandon that >> extension point as one that doesn't support continued 
rollout of >> real sender constraining mechanism (e.g. http signatures 
in the >> future) and just continue using Bearer because in the end, 
given >> that RSs could be relying on the presence of the cnf claim to 
 >> figure out the token's constraining mechanism, would that be such a 
 >> bad thing? >> >> Put it the other way around. By introducing Bearer 
scheme, do we >> actually gain anything of value that can't be gained 
through other >> means? >> >> Note that this message didn't start with 
the goal of questioning >> the new scheme use, it just sort of landed 
there... My pedantic >> nature would love to see the new scheme and 
token_type extension >> point used as it was meant to be but I also 
recognize the many >> issues it brings that could be sidestepped by not 
introducing it in >> the first place, all without losing capabilities. 
 >> >> Previous material on the topic >> >> - 
https://github.com/danielfett/draft-dpop/issues/41, decision to >> break 
backwards compatibility amongst the authors - ML >> 
<https://mailarchive.ietf.org/arch/browse/oauth/?q=%22DPoP%20-%20new%20authorization%20scheme%20%2F%20immediate%20usability%20concerns%22&gbt=1&index=> 
 >> thread, in my opinion inconclusive, no consensus >> >> >> S 
pozdravem, *Filip Skokan* >> 
_______________________________________________ OAuth mailing list >> 
OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >> > > > 
_______________________________________________ OAuth mailing list > 
OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth