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

[Warren Parad <[e-mail]>]

I think there are a bunch of different conversations happening here at the
same time. Individual responses arguing for/against others in the WG isn't
going to be productive over email. If the goal is to convince everyone that
there are merits despite the objections, then tracking those objections and
current discussion in another form is going to be necessary. (I recommend a
github repository, with separate issues)

We at least need to group the types of discussions we are having and then
list them out in the order of priority before continuing. We can't be
arguing against individual points in this manner and expect a good outcome.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Fri, Oct 8, 2021 at 10:44 PM Richard Backman, Annabelle <richanna=
[e-mail]> wrote:

> We need to come up with a better argument such as: *This allows a client
> to reduce use of the token to a smaller window to where the signature is
> also valid.*
>
>
> We have one: prevent unauthorized parties from using access tokens. Since
> a client's signing key never needs to leave the client's system, requiring
> a signature over the `Authorization` header raises the bar from "read an
> access token out of a server log" to "compromise the client itself."
> Additionally, Message Signatures defines an optional `nonce` parameter that
> can be used by the recipient of the message to enforce one-time usage of a
> signature, meaning that a signature cannot be replayed in another request,
> even if the signed message components are the same as in the original
> request.
>
>
>  I reject the use of an additional header to transmit additional
> authorization information. Due to the nature of this information may be
> conveyed and stored throughout a number of systems which would all need
> access to this complexity. As headers and authorization evolves the
> introduction and replacement of existing headers provides additional
> security vulnerabilities.
>
>
> I'm not sure I follow the concern here. I agree that this adds complexity.
> While there are many use cases for which this complexity/security tradeoff
> is worth it, this will not be the case for every OAuth 2.0 deployment out
> there.
>
>
> The draft does not support multiple clients with access to the access
> token who all should be able to provide different client signatures and all
> be verifiable by the RS.
>
>
> Access tokens are not intended to be used by multiple clients. They *may* be
> used by multiple hosts/devices, for example if the client is a distributed
> system running on multiple hosts. Different hosts within such a client
> could use different keys, provided they are all identified in the JWKS the
> client registers with the AS.
>
>
> This forces the RS to lookup two pieces of information in the case of
> signed JWTs, the JWKs from the AS and the JWKs from the client
>
>
> Yes, however this could be changed. For example, the AS could embed the
> client's public key in the access token JWT, so the RS only has to retrieve
> the AS key. That comes with its own set of tradeoffs, but this is likely
> not the only solution – it's just the one I came up with while writing this
> email. :)
>
> That's the thing about adopting a draft: once the Working Group adopts it,
> the Working Group gets to change it to cover all the use cases and
> requirements that the original author didn't think of. "The draft doesn't
> cover my use case" is really an argument *for* adoption.
>
> —
> Annabelle Backman (she/her)
> [e-mail]
>
>
>
>
> On Oct 7, 2021, at 3:08 AM, Warren Parad <
> wparad=[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 adoption.
>
> While I love the idea to be able to restrict the usage of the access token
> by the client, enabling longer expiry access tokens, and preventing usage
> to perform unexpected actions with that token, the reasons I do not support
> the adoption are as follows:
>
> * The draft depends on another draft and personally not one that I even
> agree with. Saying that the "draft is officially adopted" doesn't justify
> depending on it.
> * I reject the use of an additional header to transmit additional
> authorization information. Due to the nature of this information may be
> conveyed and stored throughout a number of systems which would all need
> access to this complexity. As headers and authorization evolves the
> introduction and replacement of existing headers provides additional
> security vulnerabilities.
> * The draft does not support multiple clients with access to the access
> token who all should be able to provide different client signatures and all
> be verifiable by the RS.
> * This forces the RS to lookup two pieces of information in the case of
> signed JWTs, the JWKs from the AS and the JWKs from the client
> * The argument in the introduction is flawed
>
> Bearer tokens are simple to implement but also have the significant
>> security downside of allowing anyone who sees the access token to use that
>> token.
>
>
> This is not a complete argument because I can replace the words in the
> sentence and justify that HTTPSig should never be used by the same argument:
>
>> HTTPSig tokens are incredibly complex to implement but also have the
>> significant security downside of allowing anyone who sees the access token
>> and signature to use that token.
>
>
> We need to come up with a better argument such as: *This allows a client
> to reduce use of the token to a smaller window to where the signature is
> also valid.*
> That would allow us to better focus on the value that the RFC would
> provide, rather than getting stuck with arbitrary implementation of another
> RFC draft as it would apply to OAuth.
>
>
>
> Warren Parad
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress <https://authress.io/>.
>
>
> On Thu, Oct 7, 2021 at 11:03 AM Denis <[e-mail]> wrote:
>
>> I am not supportive of adoption of this document by the WG *at this time*
>> .
>>
>> As I said during the last interim meeting, at this time, there is no
>> security considerations section, nor a privacy considerations section.
>>
>> The current draft describes a mechanism but does not state how the
>> signing key will be established and / or come from.
>>
>> From a security considerations point of view, if the client has the
>> control of the private key, it might be able to voluntary transmit
>> the private key to another client in order to mount a client
>> collaborative attack. If the client is unable to transmit the private key
>> to another client in order to mount a collaborative attack, it might be
>> able to perform all the cryptographic computations that
>> the other client needs. It is important to state which protections (or
>> detection) features will be obtained as well as which protections
>> (or detection) features will not be obtained. A top-down approach is
>> currently missing.
>>
>> From a privacy considerations point of view, if the same public key is
>> used to sign the messages whatever the RS is, this will allow
>> different RSs to link the requests from the same client. It is important
>> to state which protections (or detection) features will be obtained
>> as well as which protections (or detection) features will not be obtained.
>>
>> Let us wait to have both the security considerations section and the
>> privacy considerations section written,
>> before adopting this draft as a WG document.
>>
>> Denis
>>
>> Remember token binding? It was a stable draft. The OAuth WG spent a bunch
>> of cycles building on top of token binding, but token binding did not get
>> deployed, so no token binding for OAuth.
>>
>> As I mentioned, I think Justin and Annabelle (and anyone else interested)
>> can influence HTTP Sig to cover OAuth use cases.
>>
>> /Dick
>>
>> ᐧ
>>
>> On Wed, Oct 6, 2021 at 2:48 PM Aaron Parecki <[e-mail]> wrote:
>>
>>> This actually seems like a great time for the OAuth group to start
>>> working on this more closely given the relative stability of this draft as
>>> well as the fact that it is not yet an RFC. This is a perfect time to be
>>> able to influence the draft if needed, rather than wait for it to be
>>> finalized and then have to find a less-than-ideal workaround for something
>>> unforeseen.
>>>
>>> Aaron
>>>
>>> On Wed, Oct 6, 2021 at 2:25 PM Dick Hardt <[e-mail]> wrote:
>>>
>>>> I meant it is not yet adopted as an RFC.
>>>>
>>>> To be clear, I think you are doing great work on the HTTP Sig doc, and
>>>> a number of concerns I have with HTTP signing have been addressed => I just
>>>> think that doing work in the OAuth WG on a moving and unproven draft in the
>>>> HTTP WG is not a good use of resources in the OAuth WG at this time.
>>>>
>>>>
>>>> ᐧ
>>>>
>>>> On Wed, Oct 6, 2021 at 2:20 PM Justin Richer <[e-mail]> wrote:
>>>>
>>>>> > HTTP Sig looks very promising, but it has not been adopted as a
>>>>> draft
>>>>>
>>>>> Just to be clear, the HTTP Sig draft is an official adopted document
>>>>> of the HTTP Working Group since about a year ago. I would not have
>>>>> suggested we depend on it for a document within this WG otherwise.
>>>>>
>>>>>  — Justin
>>>>>
>>>>> On Oct 6, 2021, at 5:08 PM, Dick Hardt <[e-mail]> wrote:
>>>>>
>>>>> I am not supportive of adoption of this document at this time.
>>>>>
>>>>> I am supportive of the concepts in the document. Building upon
>>>>> existing, widely used, proven security mechanisms gives us better security.
>>>>>
>>>>> HTTP Sig looks very promising, but it has not been adopted as a draft,
>>>>> and as far as I know, it is not widely deployed.
>>>>>
>>>>> We should wait to do work on extending HTTP Sig for OAuth until it has
>>>>> stabilized and proven itself in the field. We have more than enough work to
>>>>> do in the WG now, and having yet-another PoP mechanism is more likely to
>>>>> confuse the community at this time.
>>>>>
>>>>> An argument to adopt the draft would be to ensure HTTP Sig can be used
>>>>> in OAuth.
>>>>> Given Justin and Annabelle are also part of the OAuth community, I'm
>>>>> sure they will be considering how HTTP Sig can apply to OAuth, so the
>>>>> overlap is serving us already.
>>>>>
>>>>> /Dick
>>>>>
>>>>>
>>>>> ᐧ
>>>>>
>>>>> On Wed, Oct 6, 2021 at 2:04 PM Aaron Parecki <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> I support adoption of this document.
>>>>>>
>>>>>> - Aaron
>>>>>>
>>>>>> On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef <
>>>>>> [e-mail]> wrote:
>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>> As a followup on the interim meeting today, this is a *call for
>>>>>>> adoption *for the *OAuth Proof of Possession Tokens with HTTP
>>>>>>> Message Signature* draft as a WG document:
>>>>>>> https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/
>>>>>>>
>>>>>>> Please, provide your feedback on the mailing list by* October 20th*.
>>>>>>>
>>>>>>> Regards,
>>>>>>>  Rifaat & Hannes
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>
>> _______________________________________________
>> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>