4 ms·
(Shameless plug.) I had some thoughts in this area. https://github.com/billpg/CrossRequestTokenExchange https://github.com/billpg/CrossRequestTokenExchange
by billpg 3y ago
(Shameless plug.) I had some thoughts in this area.
https://github.com/billpg/CrossRequestTokenExchange https://github.com/billpg/CrossRequestTokenExchange
- buzer 3y agoOne big issue I see is that you will need to keep the connection open. Malicious client could make the Initiator endpoint to hold the connection open (or to be more exact, they could simply drop the connection after acking the HTTP request), essentially causing 2 long-lived open connections for Issuer (for whatever the timeout is on server).
- billpg 3y agoThank you just for reading it! I've opened an issue on the project at https://github.com/billpg/CrossRequestTokenExchange/issues/6 https://github.com/billpg/CrossRequestTokenExchange/issues/6 If I may rewrite your scenario to check I understand it... An attacker sets themselves up as an Initiator and registers https://evil.example/TimeOut/ https://evil.example/TimeOut/ as their URL to receive the TokenIssue POST requests. The attacker then makes a TokenCall request to which the Issuer responds by making the TokenIssue POST request to the malicious "time out" endpoint. As this never responds, that initial connection is kept open.
- buzer 3y agoYes, though as the "time out" endpoint does not respond, both the initial connection and the connection to "time out" endpoint are kept open.
- billpg 3y agoThank you, I think that's worth addressing in the questions section and I might have an idea on resolving the issue.
- billpg 3y agoIn case you're still reading this, I've updated this document to version 2, answering your comment directly and adding an alternative immediate response instead of keeping the connection open. As this is still a public draft and not an established standard, I hope discussion will bring a consensus that one way of responding is better and a future draft will only specify that way.
- Elucalidavah 3y agoThis seems quite similar to the XMPP's dialback: https://xmpp.org/extensions/xep-0220.html https://xmpp.org/extensions/xep-0220.html
- MattJ100 3y agoYeah, the old protocol we're phasing out in favour of mutual TLS auth :) I should attempt to gather some stats from the XMPP network, but I suspect that since Let's Encrypt made it easy to obtain certs, dialback is probably rarely used. We disable it entirely in Snikket and have had minimal complaints of interoperability issues with other servers.
- billpg 3y agoThank you. I'll have a read of that and see if there's any lessons I can learn for it that would apply to my proposal.