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

[Warren Parad <[e-mail]>]

I feel like there are a bunch of pieces of the implementation fundamentally
missing here, so we are back to, as it is right now, the draft isn't
sufficient. What prevents the signature from being used without this RFC?
How do you do expect the symmetric key exchange to be oauth compliant? How
does the RS know that there is supposed to be a signature, if the client
doesn't provide it?

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 11:55 PM Richard Backman, Annabelle <
[e-mail]> wrote:

> If keeping DPoP simple means we have to have come up with 10 different
> variants to handle all the different cases that it doesn't support, then it
> isn't keeping it simple, it is just pushing the problem forward to the
> implementers to figure out which set of RFCs to implement.
>
>
> I'm hoping we can stop at 3: mTLS, DPoP, and Justin's draft. If someone
> has use cases that aren't covered by one or more of those, they should
> bring those up so we can discuss them and decide what changes are
> warranted. (Either here, or in HTTPbis if changes should be made to Message
> Signatures) My preference would've been to stop at 2, but the consensus has
> not been in favor of expanding the scope of use cases served by DPoP.
>
>
> If there are really so many cases, then I think we need to focus on
> recreating PoP in an extensible way that allows the DPoP to sit on top, and
> other RFCs to be layered in without a bunch of RFCs to all have competing
> semantics.
>
>
> This is what we are doing with Message Signatures. We're providing a
> general purpose signature mechanism, which higher-level protocols can build
> on.
>
>
> Here's a great example. I think having an additional header is
> unjustified, DPoP, Signature, or whatever you want to call it. But the only
> thing more unjustified than that is having different headers for different
> implementations of PoP. We can start with a new Draft that just says, PoP
> header is X, end of story, might as well call it
> *Authorization-Extra-Info*, and then layer in what you want in there.
>
>
> I can see the argument for DPoP including the proof in the `Authorization`
> header field, since the proof is intrinsically related to the access token
> and request authorization – not making a judgement on that, as this is the
> wrong thread and I don't have a horse in that race. Packing everything into
> a single header field doesn't make sense for Message Signatures, since they
> may or may not have anything to do with request authorization, access
> tokens, or anything of the sort. Additionally, the use of separate
> `Signature-Input` and `Signature` header fields allows us to have a very
> simple field syntax using Structured Field Values for HTTP
> <https://datatracker.ietf.org/doc/html/rfc8941>, and makes it easy for
> intermediaries to chain signatures. (E.g., a reverse proxy might add an
> `X-Forwarded-For` header field, and add a Message Signature covering that
> header field plus the PoP signature included by the client.) …and I'll stop
> there lest we dive into topics for the HTTPbis WG.
>
> —
> Annabelle Backman (she/her)
> [e-mail]
>
>
>
>
> On Oct 13, 2021, at 12:01 PM, Warren Parad <[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.
>
> If keeping DPoP simple means we have to have come up with 10 different
> variants to handle all the different cases that it doesn't support, then it
> isn't keeping it simple, it is just pushing the problem forward to the
> implementers to figure out which set of RFCs to implement.
>
> I would agree with keeping DPoP simple if it meant that 99% of problems
> were solved, in which case the question would be why do we need this RFC,
> and if what is here is so common, then what good is the DPoP one? Simple is
> useless if it is never used.
>
> If there are really so many cases, then I think we need to focus on
> recreating PoP in an extensible way that allows the DPoP to sit on top, and
> other RFCs to be layered in without a bunch of RFCs to all have competing
> semantics.
>
> Here's a great example. I think having an additional header is
> unjustified, DPoP, Signature, or whatever you want to call it. But the only
> thing more unjustified than that is having different headers for different
> implementations of PoP. We can start with a new Draft that just says, PoP
> header is X, end of story, might as well call it
> *Authorization-Extra-Info*, and then layer in what you want in there.
> Then the number of differences through these refactoring between these two
> drafts becomes smaller. Surely we can agree to a draft that contains only
> the semantics that are the same between the existing two, and then reuse
> the same terminology and the same implementation, header name, etc...
>
> We definitely need a PoP RFC, there's no question there (at least I don't
> think there is), so let's start with the subset of all pieces that both
> sets of authors can agree to.
>
> Is this the list of current concerning 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.
>>
>> Can we narrow this down to the non-negotiables? For instance surely (1),
> (4), (6) aren't that bad, sure they may not be optimal for every case. I
> can (2) & (3) to be actually limiting and (5) to be easy to allow
> extensibility. Would your concerns be at least somewhat be mitigated by
> allowing for solutions regarding (2) & (3)?
>
> 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 8:41 PM David Waite <david=
> [e-mail]> wrote:
>
>>
>>
>> > On Oct 13, 2021, at 12:26 PM, Richard Backman, Annabelle <
>> [e-mail]> wrote:
>> >
>> > Those issues that could be addressed without completely redesigning
>> DPoP have been discussed within the Working Group multiple times. (See
>> quotes and meeting notes references in my previous message) The authors
>> have pushed back on extending DPoP to cover additional use cases them due
>> to a desire to keep DPoP simple and lightweight. I don't begrudge them
>> that. I think it's reasonable to have a "dirt simple" solution,
>> particularly for SPAs given the relative limitations of the browser
>> environment.
>> >
>> > Other issues are inherent to fundamental design choices, such as the
>> use of JWS to prove possession of the key. E.g., you cannot avoid the data
>> duplication issue since a JWS signature only covers a specific
>> serialization of the JWT header and body.
>>
>> Agreed with keeping DPoP simple, which was why I was asking if the
>> proposal could indicate it was targeting some of these other use cases. The
>> current draft being proposed for adoption I believe is fixed to the same
>> HTTP properties that DPoP leverages, and thus appears to be targeting the
>> same use cases with a different proof expression.
>>
>> The duplication within the token is also a trade-off: it allows an
>> implementation to have a white list of acceptable internal values, if say
>> the host and path are rewritten by reverse proxies. It also allows an
>> implementation to give richer diagnostic information when receiving
>> unacceptable DPoP tokens, which may very well come at runtime from an
>> independently-operating portion of an organization reconfiguring
>> intermediaries.
>>
>> -DW
>
>
>