On Thu, 12 Sep 2019 at 11:49, Andrew Nenakhov <
andrew.nenak...@redsolution.com> wrote:

> чт, 12 сент. 2019 г. в 13:43, Dave Cridland <d...@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.
>
>
OK. Personally I like the resumption path, but that's irrelevant to much of
this discussion. XEP-0397 concentrates on that, but XEP-0399 is entirely
neutral, and neither CLIENT-KEY nor HT-* need to be done one way or the
other.


> 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
> all:
>

You're welcome to help finish it.


> - a user is not protected against password leak, authenticated user
> session can't be broken with suggested mechanics
>

I'm not sure why you think a user isn't protected with '399 and CLIENT-KEY
against a password leak - the client doesn't need to persist the password
(or any generic account credential), just the client key data. To my eyes,
this looks like exactly the same situation as your proposal - could you
explain where you think the differences lie?

In particular, you might want to note
https://tools.ietf.org/html/draft-cridland-kitten-clientkey-00#section-4.2,
which describes what state is held where - you might note that there's no
password involved, and moreover, the server's storage doesn't include
anything sufficient to authenticate. This means the security properties are
at least those of your approach (and, given the additions such as mutual
auth, channel binding, and a counter, much higher).


> - concurrent devices do not receive any notification on newly issued tokens
>

That's a trivial addition if you want it. In fact, we could just to a
"current tokens" PEP node if we wanted, though it'd need to be private of
course.


> - key revocation does not result in session cancellation
>

This is a more difficult addition - from a protocol standpoint it's
trivial, but the implementation means storing long-term information about
the key used. This is no harder or easier than your proposal though.


>
> 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, )
>

In CLIENT-KEY, keying material comes from both client *and* server. Reading
https://tools.ietf.org/html/draft-cridland-kitten-clientkey-00#section-5.1
might
help.


> - a session is linked to a client and can be revoked at any time
>

No reason that cannot be done with CLIENT-KEY. It's not specified just
because this would be a radical departure for most servers - we don't do
similar things with other SASL mechanisms, such as terminate sessions when
passwords are changed.


> - it is forbidden to connect with one toked using different devices
>

In CLIENT-KEY, this is not only forbidden, it's actually impossible, since
it's a one-time password generator mechanism - once the keying material is
fixed, a counter prevents replay or concurrent use in multiple clients.

In your proposal, on the other hand, a leak of the keying material is
trivially reused.


> - forbid connections without auth tokens
>

You can't do that, since otherwise a user cannot authenticate initially.
But this is merely a deployment concern - if you've some way of
pre-provisioning a CLIENT-KEY, you can just offer only CLIENT-KEY or HT-*
as the SASL mechanism and you're done.


>
> > 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.


I respectfully disagree, and suggest you may have misunderstood both
CLIENT-KEY and HT-* if you think that.

That said, I do think that your token management suggestions are valid, and
incorporating them in XEP-0399 (or XEP-0397) would be useful.

Dave.
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to