Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

["Richard Backman, Annabelle" <[e-mail]>]

(Honestly I'm struggling to fathom a circumstance where symmetric keys not only could be used effectively, but should be used, especially in the context of PoP where there is more than one entity involved)

Performance of asymmetric crypto continues to improve, but there is still enough of a difference for it to be significant in services with extremely high volume and extremely low latency requirements.


Handling key exchange is so fundamentally different as well as signature verification steps, token and source trusting, that I agree having both in the same document is problematic.

This is precisely why we chose to push HTTP Message Signatures through HTTPbis. Provide a single, generic solution for message component signing at the HTTP layer, and let higher level protocols (e.g., OAuth 2.0) solve the key exchange problem.

—
Annabelle Backman (she/her)
[e-mail]<mailto:[e-mail]>




On Oct 13, 2021, at 12:11 PM, Warren Parad <wparad=[e-mail]<mailto:wparad=[e-mail]>> wrote:

(Honestly I'm struggling to fathom a circumstance where symmetric keys not only could be used effectively, but should be used, especially in the context of PoP where there is more than one entity involved)

If the breaking point is symmetric keys, then I would recommend two drafts with as close to the same semantics as possible, except name them:
* Symmetric DPoP for OAuth
* Asymmetric DPoP for OAuth

Handling key exchange is so fundamentally different as well as signature verification steps, token and source trusting, that I agree having both in the same document is problematic. Which is the reason I wanted to suggest what are the non-negotiables for the authors of the new draft.

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

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 9:05 PM David Waite <[e-mail]<mailto:[e-mail]>> wrote:
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 <[e-mail]<mailto:[e-mail]>> 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?

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

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=[e-mail]<mailto:[e-mail]>> 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)
[e-mail]<mailto:[e-mail]>




On Oct 8, 2021, at 5:38 PM, David Waite <david=[e-mail]<mailto:david=[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth