Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Neil Madden <neil.madden@forgerock.com> Fri, 22 November 2019 09:44 UTC

Return-Path: <neil.madden@forgerock.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 0EA6D120288 for <oauth@ietfa.amsl.com>; Fri, 22 Nov 2019 01:44:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=forgerock.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 7FctrR4rmMmk for <oauth@ietfa.amsl.com>; Fri, 22 Nov 2019 01:44:16 -0800 (PST)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 51A60120048 for <oauth@ietf.org>; Fri, 22 Nov 2019 01:44:16 -0800 (PST)
Received: by mail-wr1-x433.google.com with SMTP id z3so7807244wru.3 for <oauth@ietf.org>; Fri, 22 Nov 2019 01:44:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=BwQqM8E7ypPfR229QCojV7JHMY1dS1e8fDEk7bHl7mk=; b=XWo6635MDso49RANvtFVOUEwmuFsdN6GqzhxKiP/k1wGLeObqTfQCjs6G89qK4pqh7 gPAebKsWzhFCVJZHADeT/wPBnXj111b+8i9t9KUvHJBw4k+ZrRoA4+OX7GN2pelphZ58 QcpeeVgcbPzulL7EkWV5KMoenim/3VULe+fr4=
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=BwQqM8E7ypPfR229QCojV7JHMY1dS1e8fDEk7bHl7mk=; b=lNxsv9TH/jMUKV+8Uk+km8mKEjQj+LEcnPyUW0Y7Sy2mj/+P7RySddHYGvzQLVAoAZ HjihTIt/P4XFVpxiASKoPpDe1CfyVKlPQOebbyqOzvp2XyRbhBjPssSNKn8V0dg3hhPu ueuvXzpcl0e0YuEBFz5r+jBFoUpI+58E7VOaveGvzfOZr0YtM13nBZQlA0Odyqc0S1iU mmbxpLW702cdj0z0Fk7ZJ64niNq0KZNkDIfVpqg9g1b+ry1sOqiPoWyMLSL/CRObokX1 7MRiz9tQlQyLzrMKmon0MUXt6E/xEyYNBj9usXpwg6VHvJ/QuYVLwtFEfisCTPKN+9ON basg==
X-Gm-Message-State: APjAAAX6Cgbkvw2WtjmoKlK3RauU7k2FKWEl/kewSjeqdALratIR43s5 YqLEHyk9cdyZQeX2+RWk2UwqKg==
X-Google-Smtp-Source: APXvYqx1VVNtRYpnp5lt8IsbKJwiUUhwiEsLt7pAvb3NIEuMRAvY+Ds+01hwwim4gzaG5GOlnkfgSA==
X-Received: by 2002:a5d:6b45:: with SMTP id x5mr416814wrw.16.1574415854433; Fri, 22 Nov 2019 01:44:14 -0800 (PST)
Received: from [192.168.1.64] (72.248.90.146.dyn.plus.net. [146.90.248.72]) by smtp.gmail.com with ESMTPSA id c76sm2892803wme.18.2019.11.22.01.44.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Nov 2019 01:44:13 -0800 (PST)
From: Neil Madden <neil.madden@forgerock.com>
Message-Id: <939F3170-151F-411B-B52B-722D05E4E320@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_06FFFFD5-D7DB-4807-A54C-07785AB758CE"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Fri, 22 Nov 2019 09:44:11 +0000
In-Reply-To: <CAD9ie-u_SM+1hRuBWR7zBGSi4Ex59Ht0SzoVTeFuWTRc3cFJXw@mail.gmail.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, oauth <oauth@ietf.org>
To: Dick Hardt <dick.hardt@gmail.com>
References: <2EF412B8-AF8C-4642-9BE0-1B528B0C63D5@amazon.com> <288343F2-ACF0-43E0-8577-26AF45330E5C@forgerock.com> <CAD9ie-u_SM+1hRuBWR7zBGSi4Ex59Ht0SzoVTeFuWTRc3cFJXw@mail.gmail.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/-6wq8IcbcgLgGdX7Pr145uRXODU>
Subject: Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt
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, 22 Nov 2019 09:44:19 -0000

On 22 Nov 2019, at 07:13, Dick Hardt <dick.hardt@gmail.com> wrote:
> 
> On Fri, Nov 22, 2019 at 3:08 PM Neil Madden <neil.madden@forgerock.com <mailto:neil.madden@forgerock.com>> wrote:
> On 22 Nov 2019, at 01:42, Richard Backman, Annabelle <richanna@amazon.com <mailto:richanna@amazon.com>> wrote:
>> There are key distribution challenges with that if you are doing validation at the RS, but validation at the RS using either approach means you’ve lost protection against replay by the RS. This brings us back to a core question: what threats are in scope for DPoP, and in what contexts?
> 
> 
> Agreed, but validation at the RS is premature optimisation in many cases. And if you do need protection against that the client can even append a confirmation key as a caveat and retrospectively upgrade a bearer token to a pop token. They can even do transfer of ownership by creating copies of the original token bound to other certificates/public keys. 
> 
> While validation at the RS may be an optimization in many cases, it is still a requirement for deployments.

It's a pattern currently used in some deployments. But as Brian (I believe) mentioned at the last OSW in Trento, you often really want to setup a shared key between the AS and the RS and use authenticated encryption instead for performance and PII protection reasons. And if you do that then (a) replay by the RS is not possible because each RS has a different key and (b) you can use the shared key for macaroons too.

(This is why I proposed adding public key authenticated encryption to JOSE [1] after OSW, and why the initial version of the draft included a simple two-way handshake to derive a symmetric session key that could be used for subsequent messages. That handshake had perfect forward secrecy and key compromise impersonation protection as well, which is overkill for DPoP hence my later simplified challenge-response version).

> 
> I echo Annabelle's last question: what threats are in scope (and out of scope) for DPoP?

I agree this is the crucial question as per my original post a week ago asking what the intended threat model is [2].

[1]: https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-02 <https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-02> 
[2]: https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLbavu9s <https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLbavu9s>

-- Neil