Are there things about the OAuth DPoP that are possibly problematic, definitely, but it is still in draft. Wouldn't this be the best opportunity to expose these problems to the authors and work through possible solutions? This conversation has already brought some things to mind which I'd be interested in improving, for instance *cnf *being an array, and attempting to utilize the Authorization header more effectively, but this isn't the thread to discuss those. Is there a reason we can't just improve the existing DPoP draft to remove the limitations you listed above?
Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Wed, Oct 13, 2021 at 2:54 AM Richard Backman, Annabelle <richanna= 40amazon....@dmarc.ietf.org> wrote: > David, Warren, Hannes and others: > > The limitations of DPoP and mTLS have been discussed numerous times within > the Working Group. Here is a summary of those that I am aware of; others > may have additional concerns. > > (Though please note first that none of this is to say that DPoP and mTLS > are bad or useless – they each are targeted at certain use cases, and they > serve those well. They just don't serve *every* use case well.) > > DPoP Limitations: > > 1. Does not support symmetric keys. > 2. Requires the same key to be used with AS and RSes. > 3. Does not support multiple valid signing keys. > 4. Signed content is copied into the JWT and therefore duplicated > within the message. This allows for bugs where the verifier fails to check > that these values match, or performs that check incorrectly. (e.g., > assuming case insensitivity) > 5. Only covers the method, scheme, host, and path. Allows for > additional arbitrary content to be signed, but does not provide any > guidance or support for defining interoperable extensions. > 6. Depends on JWT, which may be a new dependency, particularly for > clients that are doing OAuth 2.0 but not OIDC. > > > mTLS Limitations: > > 1. Requires a single end-to-end TLS connection between client and > AS/RS. This often is not the case in modern distributed systems, e.g., TLS > may be terminated at a load balancer, or by the hosting platform in the > case of a "serverless" application. On the client side, enterprises may > have TLS inspection appliances that break the TLS connection. > 2. Abysmal user experience in the browser. (though that is what DPoP > was intended to address, at least initially) > > > In contrast, Justin's HTTP Message Signatures-based approach: > > 1. Allows for flexibility regarding key selection. > 2. Allows signing of as much or as little of the HTTP message as is > appropriate for the request. > 3. Does not duplicate signed content. > 4. Does not depend on JWT, unless you want it to. > 5. Does not depend on an end-to-end TLS connection, or any other > specifics below the HTTP layer. > 6. Allows servers to use the same signature mechanism for other HTTP > signing use cases. (e.g., browser signing authorization cookies, LBs adding > a signature over the `X-Forwarded-For` header field) > > > Note that these concerns regarding use cases not addressed by DPoP and > mTLS are not new. Below are excerpts taken from WG meeting notes going back > to 2019: > > > - IETF 105 > <https://datatracker.ietf.org/doc/minutes-105-oauth-201907261000/>: > - MTLS is good but not great for browser. TOKBIND has no current > browser support. Need solution for browser apps. > > - [Daniel Fett]: DPOP is hopefully a simple and concise mechanism. > > - [Brian Campbell]: DPOP came out of a desire for a simplified > concise public key mechanism at both the authz and resource > server….there > isn’t the overhead for symmetric keys. > > - [Annabelle Backman]: We too find [DPoP] limiting without > symmetric as asymmetric can be just too slow. > > - [John Bradley]: The origin of [DPoP] came from the security > workshop specifically focused on applications to do PoP should token > binding not come to fruition. We could use web-crypto and create a > non-exportable key in the browser. This is why there is no support for > symmetric key. > > - [Mike Jones]: Want to use different POP keys for AT and RT. > > - [Justin Richer]: I really like this approach. But I agree with > Hannes that having a server provided symmetric key is useful. > > - Roman [Danyliw]: Strongly urge the equities of other groups and > surface them. > > - IETF 106 > > <https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03.pdf>: > > - Annabelle [Backman]: Would you consider using a HTTP signing > solution and not do this > John [Bradley]: ...[DPoP] has limited aspirations than the http > signing. > > - Some discussions on symmetric vs asymmetric encryption and > Annabelle is concerned about the scaling and crypto costs. So some folks > want both types, this would increase the scope of the effort [for DPoP]. > > The scope [of DPoP] was to be able to use something with sender > constraint for SPA, this is not for broader usage, so this is limited > scope > not doing what HTTP Signing would be used for. So this needs to be > presented as a very focused effort. > > - Mike [Jones]: The usage of TLS for sender constraint is not > deployable > > - OAuth WG Interim Meeting – 2021-03-15 > > <https://datatracker.ietf.org/doc/minutes-interim-2021-oauth-01-202103151200/>: > > - Francis [Pouatcha]: DPoP should be by no way a replacement for > HTTP signing. > > > — > Annabelle Backman (she/her) > richa...@amazon.com > > > > > On Oct 8, 2021, at 5:38 PM, David Waite < > david=40alkaline-solutions....@dmarc.ietf.org> wrote: > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > > > I do not support adopting this work as proposed, with the caveat that I am > a co-editor of the DPoP work. > > We unfortunately do not have a single approach for PoP which works for all > scenarios and deployments, why we have had several proposals and standards > such as Token Binding, mutual TLS, and DPoP. There have been other less > generalized approaches as well, such as forming signed request and response > objects on the channel when one needs end-to-end message integrity or > confidentiality. > > Each of these has their own capabilities and trade-offs, and their > applicability to scenarios where the others falter is why multiple > approaches is justified. > > The preferred solution for HTTPS resource server access is to leverage > MTLS. However, browsers have both poor/nonexistent API to manage ephemeral > client keys and poor UX around mutual TLS in general. > > DPoP was proposed to attempt a “lightest lift” to provide cryptographic > evidence of the sender being involved, so that browsers could protect their > tokens from exfiltration by non-exportable, ephemeral keys. In that way, we > keep from having to define a completely separate security posture for > resource-constraining browser apps. > > The motivations for the HTTPSig specification don’t clearly state why it > is essential to have another promoted PoP approach. I would expect more > prescriptive text about the use case that this is proposed for. In > particular, I would love to see an additional use case, outside of DPoP, > not solved by MTLS but solved by this proposal. > > If it turns out the target between a HTTP Message Signatures and DPoP > overlap completely, I suspect we would have the issue of two competing > adopted drafts in the working group. I personally do not know the > ramifications of such an event. I do not believe there would be consensus > on eliminating one, nor would there be a significant reduction in > complexity by combining them. > > Deferring until HTTPSig is interoperably implemented in the industry gives > us concrete motivation in the future to support both. > > -DW > _______________________________________________ > 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
