Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

Dick Hardt <dick.hardt@gmail.com> Tue, 15 September 2020 22:51 UTC

Return-Path: <dick.hardt@gmail.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 26C363A0B6B for <oauth@ietfa.amsl.com>; Tue, 15 Sep 2020 15:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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=gmail.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 R2dYwcJdC5MZ for <oauth@ietfa.amsl.com>; Tue, 15 Sep 2020 15:51:45 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 08F243A0AE1 for <oauth@ietf.org>; Tue, 15 Sep 2020 15:51:45 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id y11so4858204lfl.5 for <oauth@ietf.org>; Tue, 15 Sep 2020 15:51:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mMUVfiK7dDhy5NcKXGHen5NadJhgeZLSZhX3GXyw7j0=; b=IM/Y400GEUv1We9JNpuou9LSPXYCsf7wGcQmfk02hpSblmKIfPZXRIhfJTKT7RGEnR EXDKVUlIi2e/QEwL5QaohzCNr6Q5RmEgmrdOILXT04+GjBi0VjD++a3DGd/SptFnaQBh +Iscc2NmJdNCJH22y9hBsoDQcsPAzLCUCl8HlC9FcF/rDTJYeArp5SaYANL3hIEg2ryG tUdRO5bIKQIuYqDeLaSeMk0/l6Ols7Hj+dN9c60b4/sMUOEjUgrOF3urYPsMdHqs+z7y bmnPU2YwpOJru3sXhAJyK2cKqMS/Q1fjWfd0fkft3VSddfs17+XpO+FGr6fK3C7RXOke JHpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mMUVfiK7dDhy5NcKXGHen5NadJhgeZLSZhX3GXyw7j0=; b=pesI40Iyn1DKM7BTJ5P6NL+b/g+ka0ioNaVjEOcKw6+Cvj6Dt6SNOkGUH6tRMJv003 Co0dmKpbKZDDG4NABw6w3iW1iQF9PIxYXLdH60CYdVjT2HirVaMmN8d004uj09AvfuMe umyGYTVmznoXTDMEqx/Fm8hbeYGS5x0v95BcMHU3uEpVRjRwC5cft6I/L3CPvK9J3tQy C9m3lxWfX1FELZuAhJruWRfbXZkSShbiwRFdWSnsf3UffbrZ6sypxtOVBdOlRjt+UszT gUB7bt7YlJigc1kHRAYTepg4ZsVv6RINvxA0g+u0d/1Dq0OLLjKM/nyVrBrS3CRjoLT2 reyw==
X-Gm-Message-State: AOAM532VbAWZ78X+Oft87g4WZnpK7wkOpfa+nADAmT6+a4gNwO8eHr4Y PsCWbAUcQ2FkkD023K3NS56CrOz2pjdkfhYCE0s=
X-Google-Smtp-Source: ABdhPJyYdAe7UNVWB/NorV8+iO+/sXE91Exxbqil2NDbgRzZgHlnPpNtyGTJYlL6hFCmqx8ueSdSg68CqfcSeU0+W4E=
X-Received: by 2002:a05:6512:31d2:: with SMTP id j18mr7355900lfe.316.1600210302921; Tue, 15 Sep 2020 15:51:42 -0700 (PDT)
MIME-Version: 1.0
References: <CA+k3eCRffzry_+GVieOcWs0RHqwo_XGgMTwx4LOCZFPioD_xdw@mail.gmail.com> <C5175328-2C70-4FF9-9BFD-22E081154F5B@forgerock.com> <CA+k3eCTj0Ch+NdBinSx7JtdJ0EiXbOqKTFj_K7bGuyyRewZtOA@mail.gmail.com>
In-Reply-To: <CA+k3eCTj0Ch+NdBinSx7JtdJ0EiXbOqKTFj_K7bGuyyRewZtOA@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 15 Sep 2020 15:51:06 -0700
Message-ID: <CAD9ie-srEO_TTY21Q8A0MAG43PMSsGcJTR=5sfhSBrNtgVThpA@mail.gmail.com>
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Cc: Neil Madden <neil.madden@forgerock.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000abf39705af61fe82"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/DeHY4TYKgnU96G4tUnH2bBju6QQ>
Subject: Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?
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: Tue, 15 Sep 2020 22:51:48 -0000

That was a lot of words Brian. What is the "tl;dr:"? (I read it, but I'm
not sure where you landed given your last sentence)
ᐧ

On Tue, Sep 15, 2020 at 3:16 PM Brian Campbell <bcampbell=
40pingidentity.com@dmarc.ietf.org> wrote:

> Sorry for the slow reply to this one, Neil. It's gotten me thinking a bit
> and it took some time to gather my thoughts and attempt to articulate them.
>
> It is true that, as defined in the current -01 draft, there is the
> additional step for the RS to check that the proof key matches the hash in
> the AT. But I think that equating it to "exactly" that kind of
> CVE-2018-0114 mistake or Moxie’s Cryptographic Doom Principle is a
> significant mischaracterization. The DPoP proof message and its signature
> are used to establish that the sender holds the corresponding private key.
> Then binding tokens to that key or checking such bindings can be done.
> That's quite different from checking the signature/integrity of a message
> against a trusted key before relying on the content of the message, which
> is what CVE-2018-0114 and erroneously trusting the key is about. I'm
> admittedly a little touchy about this because I tried to speak up about the
> potential problems with blindly trusting the jwk header back in the days of
> developing the JOSE specs. And have even joked more recently that the DPoP
> proof finally uncovered a legitimate use for it. So with all that said, I
> don't think it rises to the level of doom. And the step of checking the
> binding of the token to the proof key is pretty fundamental. It's
> conceptually the same as how the AT binding is done with MTLS / RFC 8705
> and the expired/defunct draft-ietf-oauth-token-binding. That doesn't make
> it right per se but there's some precedent for the general approach.
> Following that conceptual precedent was part of the motivation for the
> current approach - not so much as simplicity for the client but simplicity
> in the form of consistency in the protocol definition itself. But maybe
> that motivation was too much so as the hash based cnf binding is kinda
> necessary in those that are doing the key proof at or closer to the
> transport layer but DPoP has all the stuff at the same layer so could do it
> differently. Putting the jwk in the cnf of the AT would eliminate the
> possibility of resource servers forgetting to check the binding. Of course
> there are still mistakes that could be made but removing even the
> possibility of that particular one is compelling.
>
> The efficiency gains you mention are dependent on circumstance and not
> always applicable, as you've kinda alluded to. The many variations of
> deployment options (e.g., reference vs self-contained tokens, introspection
> vs. local validation and either with various caching strategies, location
> of entities and communication path between them) make quantifying it rather
> difficult and circumstantially dependent. However, moving the jwk from the
> DPoP proof to the AT (by value or reference) would reduce the overall
> amount of data that is conveyed across the two items from a jwk and its
> hash to just the jwk. That's not a huge gain but it is more than nothing.
> It would also eliminate the need to codify a hash function for the jwk
> thumbprint, which admittedly would be rather nice.
>
> I guess that's a lot of words to try and kinda defend the current approach
> while also admitting that I'm coming around to seeing the light in your
> suggestion.
>
> On Wed, Sep 9, 2020 at 12:43 AM Neil Madden <neil.madden@forgerock.com>
> wrote:
>
>> I disagree with this rationale, I’m afraid. I don’t think the simplicity
>> gain for the client is really very great and I think we will regret this
>> decision.
>>
>> Most importantly, including the JWK directly in the proof token increases
>> the likelihood that somebody will just validate the signature using that
>> key and fail to check that it matches the hash in the AT. We’ve already
>> seen at least one vendor make exactly this kind of mistake in the past [1].
>> Letting the proof tell you the key to use to verify the proof is another
>> example of Moxie’s Cryptographic Doom Principle [2] - trusting the message
>> before you’ve authenticated it.
>>
>> Moving the jwk from the DPoP proof to the AT/introspection response
>> reduces the chances of these kind of mistakes.
>>
>> As a bonus it also has efficiency gains because the size of the DPoP
>> proof is reduced - potentially by a lot for RSA keys. Although the JWK
>> still has to be communicated to the RS, this can be more efficient because:
>> - For token introspection, in many deployments the introspection request
>> will be within a datacenter and so over a high-bandwidth low-latency
>> network. This is usually not the case for the DPoP proof, which may be over
>> a poor mobile connection.
>> - For embedded directly in a JWT access token, the JWK will be in the
>> claims rather than the header and so can at least be compressed. (Albeit
>> not by much, because public keys don’t compress well, but the rest of the
>> AT will and that can compensate a little for the extra bulk).
>>
>> [1]: https://nvd.nist.gov/vuln/detail/CVE-2018-0114
>> [2]: https://moxie.org/2011/12/13/the-cryptographic-doom-principle.html
>>
>> — Neil
>>
>> On 8 Sep 2020, at 23:46, Brian Campbell <bcampbell=
>> 40pingidentity.com@dmarc.ietf.org> wrote:
>>
>> 
>> Indeed there are cases, as you point out, where the key might be knowable
>> to the server via some other means, which makes the "jwk" header in the
>> DPoP proof not strictly necessary. And while omitting the key in such cases
>> would reduce the size of some messages (the DPoP proof anyway), such
>> optionality would add complexity to implementations and deployments (and
>> that kind of complexity can and often does degrade interoperability and
>> even security). How, for example, would a client know if the access token
>> includes the public key and thus whether or not to include the key with the
>> proof? Sure the access token could always include the key (rather than
>> thumbprint) but then there's the question of how to get the key to the AS.
>> As well as the stated desire to utilize the same DPoP Proof structure for
>> requests to both the AS and RS. There will be some clients that have public
>> key(s) registered and some that won't (maybe a lot that won't as a driving
>> use case for many for this is key binding access and refresh tokens for
>> public clients). The protocol defined by the draft needs to account for
>> both.
>>
>> Ultimately there are a number of different ways the necessary data could
>> flow through the various protocol elements. And there are some tradeoffs
>> with different approaches and/or trying to accommodate variations under one
>> approach. The approach the draft has taken thus far is to prioritize
>> consistency and simplicity as much as is possible. And that ethos has led
>> to how it's currently defined, which is to always include the key in the
>> proof and bind to a hash of the key in the access token.
>>
>>
>> On Tue, Sep 8, 2020 at 3:29 AM <toshio9.ito@toshiba.co.jp> wrote:
>>
>>> Hi all,
>>>
>>> In section 4.1 of draft-ietf-oauth-dpop-01, the "jwk" header parameter is
>>> REQUIRED. However, there are some cases where "jwk" is not necessary in
>>> theory.
>>>
>>> For example, consider a case where the client is registered with the
>>> Authorization Server, and its one and only public key is also registered
>>> with
>>> the AS. In that case, when the AS receives a request on Token endpoint,
>>> it can
>>> just use the public key registered for the client to verify the DPoP
>>> Proof.
>>> There is no need to send the public key in DPoP Proof.
>>>
>>> The same goes for requests to the Resource Server, if the AS and RS
>>> share the
>>> storage for clients' public keys. Things are a little difficult if the
>>> AS and RS
>>> are separate. Probably the Access Token or its introspection result have
>>> to
>>> include the public key (instead of its thumbprint as described in
>>> section 7).
>>>
>>> If the client registers multiple keys with the AS, it needs to specify
>>> which key
>>> it uses to sign the DPoP Proof. However, there is still no absolute need
>>> to send
>>> the whole key in DPoP Proof. Instead, the client could use "kid" header
>>> parameter to specify the key.
>>>
>>> Daniel Fett once mentioned the above case in the GitHub issue #26 [*1],
>>> but I'm
>>> not sure what happened to the discussion. There was also a comment on
>>> the latest
>>> draft about the "jwk" header parameter [*2]. I agree with using the same
>>> DPoP
>>> Proof structure for requests to AS and RS, but I think there are some
>>> cases
>>> where we can omit "jwk" in BOTH requests. Making "jwk" OPTIONAL would
>>> allow
>>> those cases to reduce some messaging overhead.
>>>
>>> I'd like to hear your opinions about it.
>>>
>>>
>>> [*1]:
>>> https://github.com/danielfett/draft-dpop/issues/26#issuecomment-480701746
>>> [*2]:
>>> https://mailarchive.ietf.org/arch/msg/oauth/smwsONA6c4H2UICcZMzb8Yv2QRc/
>>>
>>>
>>> Best regards,
>>> Toshio Ito
>>>
>>> -------------
>>> Toshio Ito
>>> Research and Development Center
>>> Toshiba Corporation
>>>
>>> _______________________________________________
>>> 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 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 mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>