[Standards] Account Management protoXEP
jehan.marmottard at gmail.com
Wed Nov 9 14:46:19 UTC 2011
On Wed, Nov 9, 2011 at 11:14 PM, Dave Cridland <dave at cridland.net> wrote:
> On Wed Nov 9 13:52:06 2011, Jehan Pagčs wrote:
>> Re-reading a little this topic before passing to council vote, I add
>> my voice to this point too! That's another good reason why ad-hoc
>> commands are probably not adapted. The more I think about it, the less
>> I think ad-hoc fits password modification (or account creation).
>> Ad-hoc is a great feature but is too generic for being secure (in its
>> current state in particular, but in general too) and credentials are
>> typically a part of the protocol which needs special care
> I'd be willing to entertain this, except that account registration in
> particular is highly variable from site to site.
I do agree and my XEP definitely took this into account! In the
extensibility logics of XMPP, my proto XEP is highly extensible by
default and even allow creation of "sub-XEPs" to add new kind of
authentication storage and mechanisms or various extensions (if really
some new usage come that were not thought of first).
For instance, I explain how to ask for additional informations (name,
email, address, whatever your particular service may wish) with Data
forms, or add out-of-band data (which can even allow for additional
process steps through other protocol if needed, by instance asking to
validate something through HTTP/phone/physically/whatever if really
you don't want/can't use XMPP on some part of your process), add
various instructions and informations, add any kind of captcha form,
and so on. All these either before or after entering credentials. And
these are the 4 kind of additional data which can be optionally
queried to the user and defined in this XEP but while leaving the XEP
opened to other XEPs extending this default protocol.
And even for the kind of credentials themselves, my protocol is
extremely flexible and allow all kind of mechanisms (I defined in the
XEP how to store data for PLAIN, but also for SCRAM, which are the 2
XMPP default, and even for non-password based auth mechanism like
X.509 certificates; and the XEP expects other extensions for new
On the other end, the current XEP-0077 is extremely rigid and does not
allow any kind of additional steps to the account registration process
(this was one of the remarks on limitation of XEP-0077 on section #2).
So I definitely think your remark is in favor of my XEP which is
flexible from the start.
> For changing passwords, on the other hand, I don't see a need to change from
I don't know if this is because servers or clients (or both?) do not
implement this part of XEP-0077 but I personally never saw any client
where I could change my password with XEP-0077 (only with ad-hoc
command that several servers implement).
And even if some did, all the reasons are the one I listed, mainly for security.
>> (not showing
>> the password in the GUI for anyone overseeing over the user's
>> shoulder; specific processing and encryption before passing through
>> the wire from client to server; never be actually known, if possible
>> like for SCRAM, not even to the user's server, because users tend to
>> have the bad habit of using the same password everywhere, etc.).
> We can't do this here. It's not an impossible concept, but the place to
> define such a standards would be in the IETF's Kitten working group, not
> here. (In case anyone wonders, Kitten = "Son of Cat"; Cat = "Common
> Authentication Technologies".)
> If this were to happen, then (and only then) there's be a compelling reason
> for password changes to run through something different.
I don't really understand your remark. This is what and how this is
implemented in SCRAM (indeed defined by the IETF in the Kitten Working
Group). SCRAM already allows this kind of features (never sending
anything other than encrypted data over the wire, server never having
the actual password, etc.). This is actually what is based my XEP on
and why I thought now was the right time for a change, as we passed to
SCRAM as a mandatory-to-implement technology.
Note that the XEP being flexible, it won't give any issue to any other
server (even not using SCRAM), and I explain how to have something
similar to XEP-0077 with the PLAIN storage, but at least gives
security to all recent servers.
>> I really think we need a specific protocol. I am ready to accept a lot
>> of remarks and edit the XEP, we can discuss how to improve and
>> simplify/secure/enhance/modify the protocol accordingly, or even
>> divide whole part of the XEP if really needed (for instance some
>> people wondered whether we should not split registration and
>> management part; I could make 2 XEPs for this). But let's have a
>> secure approach and not stay in our current "all in plain text,
>> without any precaution nor specific GUI" approach.
> Registration I think has to be highly flexible, and that to me suggests a
> well-known ad-hoc command.
As said above, the proto XEP is highly flexible and designed for this.
By default I already defined many use cases and any other use cases
are welcome to be defined in extensions. So it has both the advantages
to be flexible AND dedicated to security. All advantages in one. Why
should we choose between flexibility and security when we can have
> Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
> - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
> - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards