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) richa...@amazon.com<mailto:richa...@amazon.com> On Oct 7, 2021, at 3:08 AM, Warren Parad <wparad=40rhosys...@dmarc.ietf.org<mailto:wparad=40rhosys...@dmarc.ietf.org>> 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. [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 Thu, Oct 7, 2021 at 11:03 AM Denis <denis.i...@free.fr<mailto:denis.i...@free.fr>> 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 [X]ᐧ On Wed, Oct 6, 2021 at 2:48 PM Aaron Parecki <aa...@parecki.com<mailto:aa...@parecki.com>> 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 <dick.ha...@gmail.com<mailto:dick.ha...@gmail.com>> 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. [X]ᐧ On Wed, Oct 6, 2021 at 2:20 PM Justin Richer <jric...@mit.edu<mailto:jric...@mit.edu>> 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 <dick.ha...@gmail.com<mailto:dick.ha...@gmail.com>> 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 [X]ᐧ On Wed, Oct 6, 2021 at 2:04 PM Aaron Parecki <aa...@parecki.com<mailto:aa...@parecki.com>> wrote: I support adoption of this document. - Aaron On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com<mailto:rifaat.s.i...@gmail.com>> 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 OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
