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

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

On Oct 7, 2021, at 2:03 AM, Denis <[e-mail]<mailto:[e-mail]>> wrote:
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.

These items can (and I'd argue should) be addressed within the Working Group. I think key establishment in particular would benefit from a broader discussion than is typically possible with only an individual draft.

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.
I assume the private key in question is the one used by the client to generate the message signature? By definition, the client has possession of the client's private key. I would argue that if System A shares their keys and tokens with System B, then for the purposes of OAuth 2.0 both A and B are part of the same client. Constraining client architecture is outside the scope of this draft. It could be interesting to explore this separately, perhaps via a generic "token usage constraints" mechanism.

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.
Correct, save that per above I would argue both such systems are part of the same OAuth 2.0 client. Note that it is also the case that this is not really any different from System A accessing RSes at the direction of System B, and sharing results with System B. That is actually a common pattern, e.g., a web application back end (System A) making a request to an RS because the end user clicked a button in the web application front end (System B).

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.
If correlation across RSes is a concern, then a client must use different access tokens with each RS. It ought to be possible for a client to use a different key for each of these access tokens. This gets into the key establishment topic mentioned above. For my part, I think this is a good example of why the doc should cover key establishment/agreement, and I'd like to see that discussed within the Working Group.

Let us wait to have both the security considerations section and the privacy considerations section written, before adopting this draft as a WG document.
Why make adoption contingent on drafts of each of those sections? I think it would be more effective to develop those within the Working Group, as WG discussions/decisions are likely to have security and privacy implications. (e.g., if key establishment is included in this doc, those sections need to cover that; if it is left out of scope, then they don't need to cover it)

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




On Oct 7, 2021, at 2:03 AM, Denis <[e-mail]<mailto:[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 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

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=220e8879-1cf9-481e-804c-a9ca9622d19e]ᐧ

On Wed, Oct 6, 2021 at 2:48 PM Aaron Parecki <[e-mail]<mailto:[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]<mailto:[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.


[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=43ada4a0-1251-44ee-b32c-f82f530a9e53]ᐧ

On Wed, Oct 6, 2021 at 2:20 PM Justin Richer <[e-mail]<mailto:[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]<mailto:[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


[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=50ab0782-c889-43c8-9cb2-819eda9391bc]ᐧ

On Wed, Oct 6, 2021 at 2:04 PM Aaron Parecki <[e-mail]<mailto:[e-mail]>> wrote:
I support adoption of this document.

- Aaron

On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef <[e-mail]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth




_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth