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

Sam Whited sam at samwhited.com
Wed Nov 4 13:22:51 UTC 2020


TL;DR IMO we should be stricter about the sync/async separation and not
add more IQs before the session is established.

I'd like to second this, but not from a security perspective but from a
general dev / separation of concerns prospective (which I suppose is
also a security perspective). An XMPP session in general can be divided
up into the synchronous session establishment and the async session that
you establish. IQs are meant to be used in the async part and their
semantics only make sense in an async context (eg. they have IDs used to
track responses, but this is not needed if the response will always be
the next thing received). With the exception of the resource binding IQ,
this distinction holds and I normally write my code to assume this
distinction, then have to find a way to piggy back IQ semantics (which I
had written tied into async code requiring a session) onto the binding
IQ. This normally means duplicate logic and more places in the code for
bugs when the parts I had to rewrite (mirroring an ID and the like)
aren't even necessary.

—Sam

On Tue, Nov 3, 2020, at 16:51, Dave Cridland wrote:
> 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.
>
> 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.


More information about the Standards mailing list