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

[Warren Parad <[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)

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.

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