[Standards] Proposed XMPP Extension: Authorization Tokens
andrew.nenakhov at redsolution.com
Thu Sep 12 10:49:01 UTC 2019
чт, 12 сент. 2019 г. в 13:43, Dave Cridland <dave at cridland.net>:
> There is nothing particularly wrong about this. Some of it (the token management stuff) does belong in a XEP, though we have ways of doing this already (XEP-0399, and to some extent, XEP-0397), that I think are sufficiently close as to not really need anything radically different.
> The token mechanism itself, being a SASL mechanism, is however entirely out of scope for the XSF to standardize - that would need to go through the IETF. In this instance, it's a straightforward copy of PLAIN - whether it needs a different mechanism at all is an interesting question and one I do not have the capability to answer, but the Kitten group at the IETF might well have opinions.
This is not so. This proposal is not a 'copy of PLAIN', it just uses
PLAIN and is built on top of it.
We do not consider XEP-0397 as a viable alternative to this because
this XEP is about managing sessions and revoking access from
lost/compromised devices, and for removing the necessity to store the
password on the device. Also, we have different views on all this
'stream resumption' stuff - we're generally going in an orthogonal
direction with 'state restoration' approach.
As for XEP-0399, well, in all honesty, it looks to be just a vague
unfinished sketch of a badly needed XEP with key issues not solved at
- a user is not protected against password leak, authenticated user
session can't be broken with suggested mechanics
- concurrent devices do not receive any notification on newly issued tokens
- key revocation does not result in session cancellation
Differently to 399, we suggest:
- a token is issued by a server, not by a client (that also removes
risks associated with using a malicious client, )
- a session is linked to a client and can be revoked at any time
- it is forbidden to connect with one toked using different devices
- forbid connections without auth tokens
> But I'm entirely sold on the need for "something like this", and would be very grateful if you look at '399 and '397, as well as CLIENT-KEY and HT-* over at the IETF, and if you'd like to take over '399 I'd appreciate it.
We did look at these. 397 has a very different intent, and 399 suffers
from key issues described above. Fixing these will result in a XEP
identical to the current proposal.
CEO, redsolution, OÜ
More information about the Standards