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

Justin Richer <jricher@mit.edu> Wed, 10 June 2020 20:32 UTC

Return-Path: <jricher@mit.edu>
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 660003A11F7; Wed, 10 Jun 2020 13:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 spHIoo9Ciyim; Wed, 10 Jun 2020 13:32:51 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721033A11F6; Wed, 10 Jun 2020 13:32:51 -0700 (PDT)
Received: from [192.168.1.14] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05AKWnFX006031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Jun 2020 16:32:49 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <496465C8-0A44-4169-8FA4-CA2F17DED488@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2BA832DF-6D90-4489-A32A-2ED9EA01CA80"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 10 Jun 2020 16:32:48 -0400
In-Reply-To: <C1441100-0259-48E6-B013-70B74D0AD8E1@lodderstedt.net>
Cc: Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org>, oauth <oauth@ietf.org>
To: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
References: <CAOW4vyNXyCm65ifYQ97H1yySU0E-2n1xRPbAau8zLTubUxA+1g@mail.gmail.com> <C1441100-0259-48E6-B013-70B74D0AD8E1@lodderstedt.net>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ZLL2tjLMnHegtDsFQLSiZLS2VMs>
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: Wed, 10 Jun 2020 20:32:53 -0000

What if we simply declare that refresh tokens are always bound to the DPoP key used to request them? Is there value in NOT binding the refresh token?

As for access tokens, the way I read it, all of this is true:

- The AS could still decide to issue a Bearer token, using the token_type field, for whatever policy reason.
- A client getting back a Bearer token from a DPoP request would do Bearer headers. 
- A client getting a DPoP token from a DPoP request would do DPoP headers.
- An client should never send a DPoP token as a Bearer header.
- An RS should ALWAYS look for a DPoP binding signature from a DPoP scheme token. Missing that is an error.

So if we just declare that a refresh token must always be DPoP bound when DPoP is used to request it and a refresh token is issued, then we’re in the clear here, as best as I can tell, and it allows the AS some flexibility.

Some problems with this:

1) Pretty much every single OAuth client in the world ignores the “token_type” field. But clients being updated to support DPoP wouldn’t ignore it, so that’s probably ok.
2) If we wanted to make refresh token binding switchable we’d need a “refresh_token_type” field or similar, and the client would need to know how to understand it and deal with its absence (since most servers won’t send it).
3) This presumes the client will not rotate its key before using the refresh token. If it does it’ll have to do a whole new grant.
4) None of this prevents an RS from ignoring the DPoP signature, but I think that’s a separate problem.
5) It’s arguable that we’d want a client to be able to bind a NEW DPoP key during a refresh, using the old key as proof for the refresh token and the new key going forward. Is this a case we want to enable?

 — Justin

> On Jun 7, 2020, at 3:22 AM, Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org> wrote:
> 
> That’s correct for confidential clients.
> 
> For a public client, the refresh token is just bound to the client id. DPoP allows binding to an ephemeral key pair for this kind of clients.
> 
>> Am 07.06.2020 um 00:57 schrieb Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org>rg>:
>> 
>> 
>> 
>> > Am 05.06.2020 um 22:17 schrieb George Fletcher <gffletch=40aol.com@dmarc..ietf.org <http://ietf.org/>>:
>> > 
>> > 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.
>> 
>> +1 that’s a very useful feature_______________________________________________
>> AFAIK a refresh_token is always bound. What am I missing here?
>> -- 
>> Francis Pouatcha
>> Co-Founder and Technical Lead at adorys
>> https://adorsys-platform.de/solutions/ <https://adorsys-platform.de/solutions/>_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth