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....@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.mad...@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....@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....@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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
