Re: [OAUTH-WG] Comments on ietf-oauth-dpop

Brian Campbell <bcampbell@pingidentity.com> Fri, 25 March 2022 09:27 UTC

Return-Path: <bcampbell@pingidentity.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 7A64B3A115D for <oauth@ietfa.amsl.com>; Fri, 25 Mar 2022 02:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, 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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.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 81AD7gfxj5Ie for <oauth@ietfa.amsl.com>; Fri, 25 Mar 2022 02:26:58 -0700 (PDT)
Received: from mail-oa1-x2f.google.com (mail-oa1-x2f.google.com [IPv6:2001:4860:4864:20::2f]) (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 A6D993A118A for <oauth@ietf.org>; Fri, 25 Mar 2022 02:26:57 -0700 (PDT)
Received: by mail-oa1-x2f.google.com with SMTP id 586e51a60fabf-d39f741ba0so7560821fac.13 for <oauth@ietf.org>; Fri, 25 Mar 2022 02:26:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3cLK6UGvLI4FxTASe5YTMirTwJqd+BH61inh48MROiQ=; b=HjJlNgFzoG4+ozTJYeiclGE9NkpoCLqyYLgBrMakhZAHh4y24yjkIx8Hb7gGeVkO+v XXic97mlNAfpPGcsO0mPGFnvrdDfLvqsv0df91D0lXZNZkB9HGIMfWl2E/jZe+q1yykd h4nCX2f7vZuC3VQx19FFgKy9BCi5oYhtKH0VwanllHGJas2cSmih1dUFALQp0FPGBSAE YfDHO0Y9dqsFUfJ2XT4R2kEQny6lqz9Dkbmc0/hEz780fh6l1gDEpC65/j0EqqULGX2N AU3OR6f5pnPFi4up1dv8mpmWvn1BUNl/byyUdGgS0z0aQd5lVVSSrKapxjzFQQIN/wLM Xy2w==
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=3cLK6UGvLI4FxTASe5YTMirTwJqd+BH61inh48MROiQ=; b=wAw1u7Ap2cOU0MiLYITTtLAvib97gQNg4ch6+ISKmUTQWl6NZLTxj7WqolEy/Uu/Wd Iu4gdwyXMMFYQ1Ltfw915Jmm+RNxKsneMGLctlMho27aq5hb4Mo9zPa5NufPWyzFmRoX vxZcPY9S6ywm5/G4wI9ek8q7BXbEc//rqKWGNO2hFN/foUYJ9rOcvokNwBYKCg4jc/7O JLOrTRcbM4ZINSeEDOA302rFtbypYqcRFnu3+gs48ZwlhLFJULz2KjtXuKN6DFpPyYnU Lhokk2hgycKzxoEmqVondsCk5lPKwsO5AZTCFjNoyRDYLbi10HGM7VfcTV4Zq0eFup3w mSWQ==
X-Gm-Message-State: AOAM5302Oi+lXskPlatjGih0t/CwjFfURGLJ/NwxvqDQJlnCpIbvis79 X+xNn/05CQarDUlMcbtgcnLsNccyasMJyvM89hGi5CA9WQ2U810HsHWpYfsc1fHrAdNd8soXd+R m+JhfnFb9EJwVjQ==
X-Google-Smtp-Source: ABdhPJx0YhRD0DeC7oT4ZWWDsaINwMm9D3ZQT3jj781rjHdd3LiLMfYUmyBKLNcXUrsVb0zPwaFYMpfxsn/wOLsl6Ww=
X-Received: by 2002:a05:6870:15c9:b0:dd:e6db:cfce with SMTP id k9-20020a05687015c900b000dde6dbcfcemr7840899oad.269.1648200415036; Fri, 25 Mar 2022 02:26:55 -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> <CACW8--O0Q9tDi0BbCs=BTcAU717-+8sk7qPP3Magopz5P62sOg@mail.gmail.com> <CA+k3eCRdo2p0xrgk8mkoDSxNuWgEO-QnBjaan7OczdzY6OYDXg@mail.gmail.com> <CACW8--MScNcpJ4ZpR-L7b4dJBoumAqB2mPNzFgiJisrgzt6_eA@mail.gmail.com>
In-Reply-To: <CACW8--MScNcpJ4ZpR-L7b4dJBoumAqB2mPNzFgiJisrgzt6_eA@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 25 Mar 2022 10:26:27 +0100
Message-ID: <CA+k3eCRJta=u63YY_RYvVQKisreAZXxDj1hB7WBv3WLMC10t9Q@mail.gmail.com>
To: Rohan Mahy <rohan.mahy=40wire.com@dmarc.ietf.org>
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000041e01a05db0790f5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/U4-fKWi50DcGlaGtrpo9iPHT7QI>
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: Fri, 25 Mar 2022 09:27:04 -0000

Hello Rohan,

The ath claim value in the proof is always the hash of the access token
sent in the same request.

A decision was made fairly early on to not use `exp` in the proof but
rather to rely on the proof's `iat` and give the server some discretion
around the window of acceptance.
https://github.com/danielfett/draft-dpop/issues/38 has some of the
discussion around that. There'd need to be a very compelling reason with WG
agreement to change something fundamental like that at this stage in the
document lifecycle. Note also that, in the context of the proof, the `exp`
value would be something that's set by the client. So it wouldn't be a
"server-provided explicit expiration time" that was in the prior suggested
text.

Similarly, reorganizing the document is not to be undertaken lightly
especially at this point.



On Fri, Mar 25, 2022 at 12:19 AM Rohan Mahy <rohan.mahy=
40wire.com@dmarc.ietf.org> wrote:

> Hi Brian,
> 1) Re: requiring a nonce or an expiration time, I'll propose some specific
> text.
> Section 4.2
> insert after "* iat: Time at which the JWT was created (REQUIRED)."
>
> "The DPoP proof MUST include either one or both of the following:
>  * exp: time after which the proof is no longer valid.
>
> * nonce: an Authorization Server-provided nonce as defined in Section 8."
>
> Section 4.3, insert between steps 9 and 10:
> "10.  if an exp claim is present, verify that it is in the future and that
> the resulting
> duration is acceptable to the server. A proof which contains neither an exp
> claim nor a server-provided nonce is invalid;"
>
> Renumber step 10 -> 11 and 11 -> 12.
>
> 2) Regarding linking Figure 5 and Figure 12, perhaps the simplest way to
> make this linkage clear would be to move Section 7 and Section 7.1 in front
> of Section 5.1, and then show the calculation of the hash:
>
> "In our example, we take the value of the access_token in Figure 5:
>    Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU
> and calculate the base64 encoding of the SHA256:
>    fUHyO2r2Z3DZ53EsNrWBb0xWXoaNy59IiKCAqksmQE "
>
> One specific question which I could not find the answer to is if the token
> has been refreshed, is the ath the hash of the original token or the
> most-recent token?
>
> 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 Thu, Mar 24, 2022 at 3:23 AM Brian Campbell <bcampbell=
> 40pingidentity.com@dmarc.ietf.org> wrote:
>
>>
>>
>> On Wed, Mar 23, 2022 at 5:01 PM Rohan Mahy <rohan.mahy=
>> 40wire.com@dmarc.ietf.org> wrote:
>>
>>> 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.
>>>
>>
>> Direct usage of everything is also possible during that brief window.
>> Yes, a nonce helps protect against usage after the window has closed. But
>> it's not a panacea of protection. Which is, again, why it's an option
>> provided by the draft to server implementations/deployments that need or
>> want it. But not more.
>>
>>
>>
>>> 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."
>>>
>>
>> I'm not sure what, other than a nonce, a "server-provided explicit
>> expiration time" would be in the context of DPoP? Any
>> recommendations/requirements the document makes need to be rooted in actual
>> existing pieces of the protocol defined by that document.
>>
>>
>>
>>> Adding "(on the order of seconds or minutes)" would already be a big
>>> improvement to what is in the document.
>>>
>>
>> Will do. Thanks.
>>
>>
>>
>>> 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.
>>>
>>
>> The access token returned in Fig 5 is the same one used in Fig 12. But
>> that it's in Fig 5 is not really meaningful to the ath or much else. I'm
>> not sure what could be clarified or better linked?
>>
>>
>>
>>> 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.*
>>>
>>>
>> *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.*
>
>

-- 
_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._