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

Torsten Lodderstedt <torsten@lodderstedt.net> Thu, 11 June 2020 06:36 UTC

Return-Path: <torsten@lodderstedt.net>
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 13FD73A1731 for <oauth@ietfa.amsl.com>; Wed, 10 Jun 2020 23:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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=lodderstedt.net
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 Py27uvXecU74 for <oauth@ietfa.amsl.com>; Wed, 10 Jun 2020 23:36:21 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 08CA03A1730 for <oauth@ietf.org>; Wed, 10 Jun 2020 23:36:20 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id l10so4850117wrr.10 for <oauth@ietf.org>; Wed, 10 Jun 2020 23:36:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xRlcHIx0jH5CdGUnnYgKydql95K00ht/qID0k3fJnpQ=; b=lQYB37ewdNpXkXdhi+3/ipeMkaPEsZhql6t48r7jHxU74rLe5PoFPSCeZ8mq6kUFKD PgBtpERvY6ZNErVEcYov6Egkl+s/ilwNJH1J1iArmd+tkDNAQGFIrM3PcqsMrU1CZ2f6 3Hp0gySRMr6B4ruxiaD/vwXNwTcBYB65CGP409/1BWfPN1hhE6pjjpbxYoopZiQxzyZW he/XW1g3JKalPI+KGkKZzFRL6SoH0ha8RANqgGJzik33ZeoU2ry6SK4eDlxV3khjS2cm U5zlQaB+q3rMI56NS0PBDMTMMD2FBLjHezFzG6/IHVwjRl6WGwEVeLsMpytBqSgPO0Eh 8+dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xRlcHIx0jH5CdGUnnYgKydql95K00ht/qID0k3fJnpQ=; b=KzxeRrXylxSiWGYAnvqCcwEzdZHLr2fJC6m5YKBWywIzjSp5wPh/8WlH9dMLyVAIpt lWCP0K4wJp3GgyVmEe4mflwgga/BN4diwjkRItdcB2c6RR/54nhINDA9/u8QAAIVLiaf FfWf9/Cuu+HlH0pes9Yxvsa5MgHSLNAvDS5mfRaCkp4ulaPswhb/wluBxvNqQM7tsatf /N0Qh3DsNioVhIVLZNkvs68fLH7zaJRSDNZryYUWO4MGmbA0Oaz1A7Dx5pU3m1NBZHtu wartgDqRBpdsfD1GXnpFhuir0o9fbuwf8/hed17saDWlbqY3p23hoH3xPyXIp3OLbSUw GMKA==
X-Gm-Message-State: AOAM530jKR2ZXssY0Yo6bd7S6+YL9LgviFRH7Z92uF2aEE+g1JONJYDK Kg2LFqoACZ+r2sHR1GZd0FZTCw==
X-Google-Smtp-Source: ABdhPJxoKuI/HmTLbcnGxgmlxQTd1YfWk8Yyors5bToDDiUzbQs47UAz7x6N5bVwwLKmufie8ZD6cA==
X-Received: by 2002:adf:bac8:: with SMTP id w8mr7445900wrg.47.1591857378924; Wed, 10 Jun 2020 23:36:18 -0700 (PDT)
Received: from p200300eb8f184cdad587c99b0cde18fd.dip0.t-ipconnect.de (p200300eb8f184cdad587c99b0cde18fd.dip0.t-ipconnect.de. [2003:eb:8f18:4cda:d587:c99b:cde:18fd]) by smtp.gmail.com with ESMTPSA id v7sm3325152wro.76.2020.06.10.23.36.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jun 2020 23:36:17 -0700 (PDT)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <8762DAF0-CA56-407D-9DD9-86809BD844B2@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_642BB858-DA71-4FA6-BCEC-A220955CDBE1"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 11 Jun 2020 08:36:16 +0200
In-Reply-To: <CAOW4vyNS--H+6zV4vA9yBgU2v2NgrtFAiftoEYPEPReDkcDVPA@mail.gmail.com>
Cc: oauth <oauth@ietf.org>, Justin Richer <jricher@mit.edu>
To: Francis Pouatcha <fpo@adorsys.de>
References: <CAOW4vyNXyCm65ifYQ97H1yySU0E-2n1xRPbAau8zLTubUxA+1g@mail.gmail.com> <C1441100-0259-48E6-B013-70B74D0AD8E1@lodderstedt.net> <496465C8-0A44-4169-8FA4-CA2F17DED488@mit.edu> <CAOW4vyNS--H+6zV4vA9yBgU2v2NgrtFAiftoEYPEPReDkcDVPA@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/VsRNkBCAovZ4v1MHTqTfLjxEpxM>
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: Thu, 11 Jun 2020 06:36:23 -0000

I generally agree with the proposal, but I would suggest to limit it to public clients. 

In case of confidential clients, the refresh token is (via the client_id) already bound to the client’s secret(s) and those can be rotated. Additionally binding the refresh token to a DPoP key would limit it’s applicability w/o a benefit. 

> On 11. Jun 2020, at 01:35, Francis Pouatcha <fpo@adorsys.de> wrote:
> 
> 
> On Wed, Jun 10, 2020 at 4:32 PM Justin Richer <jricher@mit.edu> wrote:
> 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?
> 
> Fully agree. I will add a refresh_token shall always be PoP bound. Independent of the type of PoP.
>  
> 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?
> Key rotation shall be handled separately from the refresh_token process. If a refresh_token is bound to a key, the client shall keep that key till the refresh_token is consumed. A key rotation process shall be designed such as to allow the key holder to keep obsolete keys for the completion of pending processes.
> 
>  — 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.
> 
> 
> -- 
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/