* Jonas Schäfer <jo...@wielicki.name> [2019-09-11 17:34]: > The XMPP Extensions Editor has received a proposal for a new XEP. > Title: Authorization Tokens
thank you very much for writing this up. Indeed, this is some badly
needed functionality. However, I have mixed feelings regarding this
specific way to tackle it.
As was said before, you are introducing a new SASL mechanism without
going through the official Kitten WG. I'm not sure if just using PLAIN
with tokens abused as device-specific passwords would work out. As you
are not telling the server in advance _which_ token you are going to
use, it needs to match the submission against all stored tokens anyway.
Regarding the merit of your approach vs. HT-* and CLIENT-KEY, I'm
actually split. I like the simplicity of just replacing the password
with a token, and also that restoring a client application from a backup
would not automatically lead to problems, as compared to the Counter
value check of CLIENT-KEY. On the other hand, this is a security
regression in comparison to the existing SCRAM-SHA1 authentiation. I'm
not knowledgeable enough to say whether you could drop-in your tokens
into SCRAM-SHA1 as well.
There were rumors of a server implementation that was simply maintaining
per-client passwords without any protocol changes (you had to enter a
specific per-device password when onboarding a new device), so I suppose
there is a sweet spot for this kind of solution.
That said, I'm +0 regarding its acceptance.
Regarding the details of your XEP, I see some issues:
1. Pre-Bind vs. Post-Bind
I didn't understand the significance of performing certain steps before
vs. after bind. I can see how the actions must not be performed prior to
authentication, but I'm not sure what the merit of the pre-bind phase
is.
2. Authentication Failure
You don't provide an explanation or examples of what should happen if
the client authentication attempt is rejected. Naively, I would assume
that the user is asked to enter an account password, but this doesn't
become clear. Should the client fall back to PLAIN then? Also this is
probably something that should belong inside of SASL.
3. Refreshing a token
A client should probably be able to refresh a token that it uses, to
extend its expiration time (if allowed by administrative controls),
without causing a new notification to other devices.
4. Token management
I'm not sure why we are not using PEP here; obviously only exposing the
IDs, not the token secrets.
5. Element semantics
I'm not sure whether <device> is meant to describe the device model
('MacBook 15"') or the device name ('Andrew's MacBook'). In the end,
this is probably not that relevant. The <client> element shouldn't be in
there at all and instead come from the client's disco#info identity or
XEP-0092.
6. Notification semantics
The notification message should contain all data in a structured format,
allowing a modern client to display the data in a nicer markup / form.
The <body> should be just a legacy element. Also a client could append
two buttons to [Reject] or [Accept] the new device, allowing a timelier
reaction.
Kind regards,
Georg
--
|| http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++
|| gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ ||
|| Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? ||
++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
