Re: [OAUTH-WG] Comments on ietf-oauth-dpop
Rohan Mahy <rohan.mahy@wire.com> Wed, 23 March 2022 16:01 UTC
Return-Path: <rohan.mahy@wire.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 47C993A177F for <oauth@ietfa.amsl.com>; Wed, 23 Mar 2022 09:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20210112.gappssmtp.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 MMEJEulXVr_h for <oauth@ietfa.amsl.com>; Wed, 23 Mar 2022 09:01:22 -0700 (PDT)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 2128A3A177C for <oauth@ietf.org>; Wed, 23 Mar 2022 09:01:22 -0700 (PDT)
Received: by mail-pf1-x42d.google.com with SMTP id g19so1816477pfc.9 for <oauth@ietf.org>; Wed, 23 Mar 2022 09:01:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eQy/3YTpDiIP3S10YCAW3mXDp/Jx8zOEt1ssSaHGzZM=; b=h8tz9fhS+nr80FtwnyVkB96Xu6TriMi5YS96ObCZ2XZrdB6LpxqRzPqr2NGelix/i3 kg2uUYTcb+fJqVlVI9DrFba9nb42kVOxK4EVapcVJc/o4WUfWsPvhEJ3busjN1p7QH/V hWIbGTtbJbeEmAdA3WGrIrJ6+s078cDB+JeoYek4G8AhlplpRcuFS7MlpWhlZ81dAd7+ zdaUCc/OThR5LvBVKLUscyZQam89sIR46qr6ugC5uARfw8WdY3tIinqsFrvmgUDn4GLt SkybRcIoJgd+ykG9JZEcfxIUS6dhIe7CCQvHr/VxZcllU6GX0jWkFj5NSPOvh0ADYqs/ EF0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eQy/3YTpDiIP3S10YCAW3mXDp/Jx8zOEt1ssSaHGzZM=; b=kRb3QlHZAcE8kAyEFPyVqCob0T3Miz5F2ZpPX4xWTneZ/QStNgKmSau/vr/uxYJxWx CDoOZyTwvma0cM41Or0XzFJvn4LBtEOPJtHcRZuutL35Gay8YPuy0QU5eStfriBHGks1 LCMfQNmMHUScux8ErMlhzHuoPnwQMGXGlko/lVAGH5ofeTjD740IK9WTBMLHTVtTJ4Uz muOCf8oZECcAs3mvgUEowUBbuZqdzNdIzbxUZHJrEWB8Y6J2tKhue/e2hURS88B4z5Fa B0L63jmCf1N/Ckx1hNl1GNSnlbWOFNf2PpFEQZiSvaIZ89YLrB+K3ueG0ORLcIdpRN4M v5yw==
X-Gm-Message-State: AOAM532HdmakinBhkSZXLqRS88mPiYk+C1/xalxkJ12hsm3MXOx+bTwk mtRUo9V0l6qMPoi7c7ReBc1yK59FHmvlL4LCrlLTWQ==
X-Google-Smtp-Source: ABdhPJzs+Q9xYqx8v6wV0DWFeqzuztbipW0H/AuANik8gVDNbr7h38t5QTkzaHgZMR9agzVd6KDiU62Iw7Ukfifm1Ms=
X-Received: by 2002:aa7:8d88:0:b0:4f7:a2f1:8e77 with SMTP id i8-20020aa78d88000000b004f7a2f18e77mr270646pfr.48.1648051280855; Wed, 23 Mar 2022 09:01:20 -0700 (PDT)
MIME-Version: 1.0
References: <CACW8--PPqWp+AMCWTuFT3Q=w6OFpn2xrS=4Cu8oAd8wBEkDNYg@mail.gmail.com> <CACW8--PoQLzO3TP6Xi7PwY4vWoBHpUwn9Q3hz_3j375pvAo9gw@mail.gmail.com> <CA+k3eCTe_+U-ssCmXhtc9SPGti+xC7wHZbnneef3xQjtR=Dixg@mail.gmail.com>
In-Reply-To: <CA+k3eCTe_+U-ssCmXhtc9SPGti+xC7wHZbnneef3xQjtR=Dixg@mail.gmail.com>
From: Rohan Mahy <rohan.mahy@wire.com>
Date: Wed, 23 Mar 2022 09:01:09 -0700
Message-ID: <CACW8--O0Q9tDi0BbCs=BTcAU717-+8sk7qPP3Magopz5P62sOg@mail.gmail.com>
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002ae13305dae4d737"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/XCWJSDDh01ILtnxe_1H6sAHGIHQ>
Subject: Re: [OAUTH-WG] Comments on ietf-oauth-dpop
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, 23 Mar 2022 16:01:27 -0000
Hi Brian, To be clear, for pre-generated proofs, I am not worried about an attack against the client; I am worried about a malicious client. Imagine a malicious client which pre-generates proofs during a brief window while it has access to a private key stored on the iOS secure enclave, or on a Yubikey, or a non-extractable WebCryptoAPI CryptoKey. The ability to pre-generate proofs with no lifetime effectively makes these non-extractable key protections meaningless for some fixed number of proofs. If the WG does not want to make server nonces a SHOULD, then I suggest the following: "Server implementations need some protection against arbitrary pre-generation. Servers MUST require all client proofs to contain either a server-provided nonce, or a server-provided explicit expiration time, or both." Adding "(on the order of seconds or minutes)" would already be a big improvement to what is in the document. The linkage between Figure 12 and Figure 13 is clear. I was talking about the linkage between Figure 5 (or the refresh response to Figure 6) and the token hash in Figure 12. Many Thanks, -rohan *Rohan Mahy *l Vice President Engineering, Architecture Chat: @rohan_wire on Wire Wire <https://wire.com/en/download/> - Secure team messaging. *Zeta Project Germany GmbH *l Rosenthaler Straße 40, <https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>10178 Berlin, <https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g> Germany <https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g> Geschäftsführer/Managing Director: Morten J. Broegger HRB 149847 beim Handelsregister Charlottenburg, Berlin VAT-ID DE288748675 On Wed, Mar 23, 2022 at 8:17 AM Brian Campbell <bcampbell= 40pingidentity.com@dmarc.ietf.org> wrote: > Thanks Rohan, > > Pre-generating a proof requires the ability to execute code on the client, > which is already a problematic situation where other (arguably more) > serious attacks are possible. Such as driving a whole attack directly from > the client. The draft aims to give servers the option to use a nonce but > not push it too much or overstate its protections. > > The vagueness around lifetimes is somewhat intentional. At one point the > document (maybe aspirationally) had something like 'no more than a few > seconds' but there was some push-back that it was unrealistically short to > accommodate real world client clock skew. I'm not sure the draft can make a > much more concrete recommendation as I think it really is something that > has tradeoffs and will be implementation/deployment specific. Perhaps > something like, "(on the order of seconds or minutes)" could be added as a > qualifier around lifetime leniency? That maybe gives a general idea of what > is acceptable and/or relatively brief without being overly prescriptive. > I'm quite hesitant to say anything more specific. > > An access token and its "ath" hash value are shown as part of the examples > https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-06.html#figure-12 > and > https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-06.html#figure-13 > respectively. Perhaps it'd be worthwhile to more explicitly mention the > relationship between the two examples? I think I did the calculations > correctly but anyone double checking that work would be welcome. The > sentence in sec 4.3 step 11 is already pretty darn verbose - probably too > much so. I think breaking it up would probably be a better way to make it > more clear. > > The MIME type registration will be in the next revision > https://mailarchive.ietf.org/arch/msg/oauth/Vj24ZXU4UuG6Rr04U1Cdrz2rx3o/ > > I'll work those nits and fix things up as appropriate. > > > > > > > On Tue, Mar 22, 2022 at 4:24 PM Rohan Mahy <rohan.mahy= > 40wire.com@dmarc.ietf.org> wrote: > >> Hi, >> Here are some comments on draft-ietf-oauth-dpop-06: >> >> 1) With such a significant attack possible as DPoP proof pre-generation, >> why isn't using the server nonce a SHOULD? Preventing a significant attack >> and making lifetime handling sane are two excellent reasons to use a server >> nonce. If an implementation has a good reason to not use a server nonce, we >> can give guidance about what additional steps the implementation needs to >> take. >> >> 2) The handling of lifetimes of DPoP proofs is vague: "acceptable >> timeframe" (Section 4.3), "relatively brief period" (Section 11.1). Is that >> 1 day,15 minutes, or 30 seconds? >> The normative text in the two sections seem contradictory. >> I think you need a lifetime parameter if a server nonce isn't included, >> or just pick a number (5 minutes?). >> >> 3) I had a similar thought to Nicolas Mora about including other >> assertions/tokens. There should be a way to chain, include, or reference >> other OAuth assertions and bind them somehow with the DPoP. This will be a >> common and important model. >> >> 4. Right now you describe the access token hash before describing the >> access token itself. I think it would be very useful to show the a worked >> example of an access token and then its hash used subsequently. Also >> Section 4.3 step 11 feels like a circular description. Please rewrite more >> verbosely to be clearer: >> Currently: >> "when presented to a protected resource in conjunction with an access >> token, ensure that the value of the ath claim equals the hash of that >> access token and confirm that the public key to which the access token is >> bound matches the public key from the DPoP proof." >> >> 5. Re: IANA registration of the MIME type. TL;DR: Just register >> application/dpop+jwt. >> Long version: The semantics of the thing you want to register is >> application/dpop. The first syntax you are defining is jwt. For example, >> iCalendar has three formats: text/calendar (iCal), >> application/calendar+json (jCal), and application/calendar+xml (xCal). >> >> NITS: >> - Spell out first use of acronyms: JWT, JWK, JWS, TLS, JOSE, PKCE, >> - Add reference to TLS, XSS, Crime/Heartbleed/BREACH/etc., HTTP, JOSE, on >> first use >> - First sentence of Section 2 (Objectives): add a comma (access tokens_,_ >> by binding) to make it clear that "binding a token" is doing the preventing >> instead of the stealing in the sentence. >> - Section 2 para 5: s/XXS/XSS/ >> - Maybe mention why you are using ASCII (7-bit) when the charset in the >> examples is UTF-8. >> >> I hope these comments are useful. >> Many thanks, >> -rohan >> >> >> *Rohan Mahy *l Vice President Engineering, Architecture >> >> Chat: @rohan_wire on Wire >> >> >> >> Wire <https://wire.com/en/download/> - Secure team messaging. >> >> *Zeta Project Germany GmbH *l Rosenthaler Straße 40, >> <https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>10178 >> Berlin, >> <https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g> >> Germany >> <https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g> >> >> Geschäftsführer/Managing Director: Morten J. Broegger >> >> HRB 149847 beim Handelsregister Charlottenburg, Berlin >> >> VAT-ID DE288748675 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.*
- [OAUTH-WG] Comments on ietf-oauth-dpop Rohan Mahy
- Re: [OAUTH-WG] Comments on ietf-oauth-dpop Nicolas Mora
- Re: [OAUTH-WG] Comments on ietf-oauth-dpop Joseph Heenan
- Re: [OAUTH-WG] Comments on ietf-oauth-dpop Brian Campbell
- Re: [OAUTH-WG] Comments on ietf-oauth-dpop Rohan Mahy
- Re: [OAUTH-WG] Comments on ietf-oauth-dpop Brian Campbell
- Re: [OAUTH-WG] Comments on ietf-oauth-dpop Brian Campbell
- Re: [OAUTH-WG] Comments on ietf-oauth-dpop Rohan Mahy
- Re: [OAUTH-WG] Comments on ietf-oauth-dpop Brian Campbell
- Re: [OAUTH-WG] Comments on ietf-oauth-dpop Rohan Mahy