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

Torsten Lodderstedt <torsten@lodderstedt.net> Sun, 07 June 2020 17:11 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 1B5B03A0A0C for <oauth@ietfa.amsl.com>; Sun, 7 Jun 2020 10:11:26 -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 9b2Lmyt2HVl8 for <oauth@ietfa.amsl.com>; Sun, 7 Jun 2020 10:11:23 -0700 (PDT)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 7E4CD3A097D for <oauth@ietf.org>; Sun, 7 Jun 2020 10:11:23 -0700 (PDT)
Received: by mail-ej1-x62f.google.com with SMTP id o15so15605820ejm.12 for <oauth@ietf.org>; Sun, 07 Jun 2020 10:11:23 -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=0oCR8Sfw57slKLZ8mF0CS7eI5mkceIlO0OAyxWhAkLQ=; b=TeFSW6OO9cu3jlMwv3o8X2+g9+uEZyPFK0S0cttbQI5JvC3PXX3PLYmHtGRXyayHUp kwPwogp7E+nqZInqy9ybNJDKM15hzeUa4/4VFk5T2IP7OoegHZS7UUbCPARzOKi74gl7 pAsX/O41FVzP9CQDtMoaH/rX+fZgghrAYsvAzizm9yjWD0sUkbRENx3VnG9IBZ9faCxT 2OBL+6p6xeCo0QDukgutawikotKF3rkzavxAujPgbkLL5mY0y0XRzAQnE9jMGf0iscWQ HGSHBXe0g+RkhVEFJ4HemJTWyYmDiLrwhJhmlXKEw2aFcXngu4CuXcH6ZbfLspgyIYb8 VizA==
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=0oCR8Sfw57slKLZ8mF0CS7eI5mkceIlO0OAyxWhAkLQ=; b=tguusGgk0Vi77Pqnf+wTFuB2qD3/NAHDvhH+mqCB73UlplobiM4JnQLYOgokDNZbtM xOXDayRaOoIhmJeLjWdEa4KD6sR5G72aErFOZDuuidrqKyw1BnbZhlunbud4YdpDBTYQ KBkPoAUtd0zPTUwJrLd3aeXYcZGXUKeceA53wn5X13MoiqRjSlPXmyfVZ8nXiiYgHtOQ LOTBqfyxONkRqmqYXdsybELwPOSCBR+DXnNgT40ZuqEAFTiWaRqWpkAXOZu8hg2cjnIW VWQZrSzjE4pDfglg0vEBAhAfmvpwq8JoH1FJjNZWvj0unyRCuIdTL20WJuz+uoBP08W4 KACA==
X-Gm-Message-State: AOAM531vbjP6IPu5EibSMKRNvOf0MgCgQAIEDvO/iZy0HITz/xg+MrPh zbDqte2EALWcuuW9pJ+uvI7dvw==
X-Google-Smtp-Source: ABdhPJxoJcB9E5MxDP9o0m239skP4YTS83IYtC6O1uSLNdeknp4o0gIh2op4P6QCfmj8fWC08AtKWg==
X-Received: by 2002:a17:906:11d9:: with SMTP id o25mr17144160eja.377.1591549881597; Sun, 07 Jun 2020 10:11:21 -0700 (PDT)
Received: from p200300eb8f184cac11bf175ea3b0e1bc.dip0.t-ipconnect.de (p200300eb8f184cac11bf175ea3b0e1bc.dip0.t-ipconnect.de. [2003:eb:8f18:4cac:11bf:175e:a3b0:e1bc]) by smtp.gmail.com with ESMTPSA id t9sm8888697ejy.43.2020.06.07.10.11.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jun 2020 10:11:20 -0700 (PDT)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <1164F63D-F22E-4B70-96A0-BC83779587F1@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_D3B632E5-1A72-4D7F-B634-1C11B7C7D803"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Sun, 7 Jun 2020 19:11:18 +0200
In-Reply-To: <AE81333F-F19B-4C00-AF21-64310BF56704@gmail.com>
Cc: Francis Pouatcha <fpo@adorsys.de>, oauth <oauth@ietf.org>
To: Nov Matake <matake@gmail.com>
References: <375FA230-5700-42A5-B933-2A37D296BCDF@forgerock.com> <AC87697A-07BC-43E6-82C3-73892A7C505D@gmail.com> <BB604649-B01B-460B-B312-126600CD69DE@gmail.com> <CAOW4vyOL0ZTZKpMghVLEmFmaaBq+nZCZ1b8KPZKetsa9c=fPnw@mail.gmail.com> <AE81333F-F19B-4C00-AF21-64310BF56704@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/IgChy7nqPTIDqnzG2t-EFHPqYVE>
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: Sun, 07 Jun 2020 17:11:26 -0000


> On 7. Jun 2020, at 16:18, Nov Matake <matake@gmail.com> wrote:
> 
> private_key_jwt and mTLS can be sender PoP method for code too.

Seems we need to distinguish certain “kinds” of PoP for code. 

1) private_key_jwt, mTLS and other client secrets can be used to authenticate the client and thus check the binding of the code to a particular client_id.

2) PKCE is different in that it allows to tie the code to a certain transaction running on a certain device. 

(2) detects code replay at the same client_id on a different device, (1) does not. 

Regarding PoP for access tokens: private_key_jwt does not provide this capability. mTLS and DPoP provide it for both confidential and public clients. 

> 
>> 2020/06/07 23:00、Francis Pouatcha <fpo@adorsys.de>のメールt;のメール:
>> 
>> I am a little bit confused. Let me  break it down:
>> 
>> code :
>>   -> sender : Client
>>   -> consumer : AS
>>   -> sender PoP : 
>>        --> confidential client: code_verifier (PKCE)
>>        --> public client:  code_verifier (PKCE)?
>> 
>> refresh_token :
>>   -> sender : Client
>>   -> consumer : AS
>>   -> sender PoP : 
>>        --> confidential client: private_key_jwt, mTLS
>>        --> public client:  DPoP?
>> 
>> access_token :
>>   -> presenter : Client
>>   -> consumer : RS
>>   -> sender PoP : 
>>        --> confidential client: private_key_jwt, mTLS
>>        --> public client:  DPoP?
>>   
>> Is this correct?
>> 
>> On Sun, Jun 7, 2020 at 8:42 AM Nov Matake <matake@gmail.com> wrote:
>> * sender-constrained code, bearer access token and sender-constrained refresh token, use DynReg or "PKCE + DPoP allowing access token remaining bearer".
>> * sender-constrained code, sender-constrained access token and sender-constrained refresh token, use "DynReg + DPoP" or "PKCE + DPoP".
>> * bearer code, sender-constrained access token and sender-constrained refresh token, use DPoP only.
>> * sender-constrained code, bearer access token and bearer refresh token, use PKCE only.
>> * bearer code, bearer access token and bearer refresh token, use none of them.
>> 
>>> 2020/06/07 21:36、Nov Matake <matake@gmail.com>のメールt;のメール:
>>> 
>>> Yeah, both PKCE and Client Credential provide sender-constrained code...
>>> lots of choices
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Jun 7, 2020, at 21:26, Neil Madden <neil.madden@forgerock.com> wrote:
>>>> 
>>>> 
>>>> Answers inline: 
>>>> 
>>>>> On 7 Jun 2020, at 13:07, Nov Matake <matake@gmail.com> wrote:
>>>>> 
>>>>> So, you mean…
>>>>> 
>>>>> If a frontend client want to use
>>>>> * sender-constrained code, bearer access token and sender-constrained refresh token, use DynReg.
>>>> 
>>>> I’m not really sure what a sender-constrained code would be, but I suspect the right answer here is PKCE + DPoP. PKCE basically is PoP for auth codes. 
>>>> 
>>>>> * sender-constrained code, sender-constrained access token and sender-constrained refresh token, use DynReg + DPoP.
>>>> 
>>>> PKCE + DPoP
>>>> 
>>>>> * bearer code, sender-constrained access token and sender-constrained refresh token, use DPoP only.
>>>> 
>>>> Sure, but you should always use PKCE, so PKCE + DPoP. 
>>>> 
>>>>> * bearer code, bearer access token and bearer refresh token, use neither.
>>>>> 
>>>>> is my understanding correct??
>>>> 
>>>> Just use PKCE + DPoP. (Or a different PoP mechanism, eg mTLS cert-bound tokens, or etc). 
>>>> 
>>>>> 
>>>>>> 2020/06/07 20:49、Neil Madden <neil.madden@forgerock.com>のメールt;のメール:
>>>>>> 
>>>>>> There are multiple issues with using dynamic client registration for this. If a user uninstalls and later reinstalls an app then they can end up with multiple registrations for the same client, which makes it harder for them to manage access. Additionally, client registrations typically don’t expire so the AS doesn’t know when it can remove unused clients.
>>>>>> 
>>>>>> Besides, this ship already sailed with mTLS cert-bound refresh tokens. 
>>>>>> 
>>>>>> Neil
>>>>>> 
>> 
>> 
>> -- 
>> Francis Pouatcha
>> Co-Founder and Technical Lead at adorys
>> https://adorsys-platform.de/solutions/
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth