[Standards] Proposed XMPP Extension: Pre-Authenticated In-Band Registration

Georg Lukas georg at op-co.de
Wed Nov 4 08:09:41 UTC 2020

Hi Dave,

* Dave Cridland <dave at cridland.net> [2020-11-03 22:55]:
> This is a very comprehensively written XEP for an initial submission.

Thank you very much for your review!

> My main concern here is the addition of a further IQ during unauthenticated
> state. In the case of every server I've worked with, the IBR (and '78 auth,
> if supported) is hard-coded into the server. This generally feels like a
> security nightmare lurking.

Yeah, I agree with that, and I suppose that the proposed ibr-token
approach needs to be hard-coded in the same way. This is already the
second iteration of a protocol that initially tried to piggy-back the
token as a dedicated element in the original IBR.

The longer-form motivation for ibr-token can be found here:

Council discussion at "6) AOB":

The discussion of the original extended-IBR is here:

My overall hope is that adding a pre-IBR unauthenticated IQ is not going
to increase the attack surface compared to the IBR unauthenticated IQ,
and this was an approach to move forward and implement the principal
idea with the minimum amount of new protocol.

> I would rather move in the other direction, and place the entirety of
> registration inside non-stanza TLEs or (possibly) opting for a
> registration-only authentication before exchanging stanzas.

Well, I'm not an expert on authentication and registration mechanisms,
and I didn't want to become one just for solving an urgent practical
problem, but it looks like there is XEP-0389: Extensible In-Band
Registration, which *also* relies on unauthenticated IQs, that can be
moved into the right direction in the long term, and also some ongoing
work around SASL2.

For now however, I wanted to document the in-the-wild protocol under the
XSF umbrella instead of the already existing inofficial docs at

Once somebody has stepped up to implement registration tokens The Right
Way, I'm not going to oppose moving this proposal to Historical.

> Also, this namespace happens to be the same as XEP-0379, which is a trivial
> fix (but, I think, blocking).

This was a deliberate decision, because both XEPs make use of an
invitation token, and the same token could be used either for account
creation (ibr-token) or for subscription (XEP-0379) as defined in

|| 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 ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20201104/a6034f2a/attachment-0001.sig>

More information about the Standards mailing list