Specifically to the discussion of symmetric keys: Adding symmetric keys implies one of a set of rather different architectures. For example, one may look (even more) close to Kerberos, with access tokens resembling service tickets, while another might negotiate a symmetric key/token local to a RS based on an RS challenge. In either case, a symmetric key basis requires resource-constrained keys and possibly tokens.
It also makes preventing exfiltration of keys (and the associated tokens) harder to prevent - you would likely want to include key derivation in grant processes. The HTTP Signature key identifier might actually be from the AS or server, and even represent a wrapped key. I suspect adding this use case to DPoP would be more than a doubling of complexity. IMHO past discussions around symmetric keys were more arguments over whether DPoP could be considered complete without that additional complexity, due to the computational efficiencies of symmetric keys over asymmetric ones. This comes into play when the network/computational and complexity costs of a per-RS key/token negotiation is dwarfed by the ongoing use of that token to talk to a particular RS. This also means that it is primarily a concern when MTLS is not possible, as MTLS will negotiate a symmetric key at a lower level anyway. -DW > On Oct 13, 2021, at 3:51 AM, Warren Parad <wpa...@rhosys.ch> wrote: > > 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 <mailto: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: > Does not support symmetric keys. > Requires the same key to be used with AS and RSes. > Does not support multiple valid signing keys. > 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) > 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. > Depends on JWT, which may be a new dependency, particularly for clients that > are doing OAuth 2.0 but not OIDC. > > mTLS Limitations: > 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. > 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: > Allows for flexibility regarding key selection. > Allows signing of as much or as little of the HTTP message as is appropriate > for the request. > Does not duplicate signed content. > Does not depend on JWT, unless you want it to. > Does not depend on an end-to-end TLS connection, or any other specifics below > the HTTP layer. > 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 <mailto:richa...@amazon.com> > > > > >> On Oct 8, 2021, at 5:38 PM, David Waite >> <david=40alkaline-solutions....@dmarc.ietf.org >> <mailto: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 <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
