Re: [Standards] Proposed XMPP Extension: Pre-Authenticated In-Band Registration
I missed this statement about 0389 last time. This is incorrect, 0389 does not use stanzas pre-auth, it just has the ability to use stanzas to do the same thing post-auth because I wanted to be able to register with something other than the server. For example, you might want an admin console that exists post-auth if you're an admin that lets you register accounts on a MUC component (which requires stanzas to be routable). The IQs are not to be used pre-auth. I will clarify this in the XEP; sorry for the confusion. —Sam On Wed, Nov 4, 2020, at 03:09, Georg Lukas wrote: > 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. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Pre-Authenticated In-Band Registration
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. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Pre-Authenticated In-Band Registration
Hi Dave, * Dave Cridland [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: https://mail.jabber.org/pipermail/standards/2020-January/036848.html Council discussion at "6) AOB": https://mail.jabber.org/pipermail/standards/2020-January/036913.html The discussion of the original extended-IBR is here: https://mail.jabber.org/pipermail/standards/2018-February/034323.html 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 https://docs.modernxmpp.org/client/invites/ 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 XEP-0401. 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 ___
Re: [Standards] Proposed XMPP Extension: Pre-Authenticated In-Band Registration
On Tue, 3 Nov 2020 at 15:59, XEP Editor Pipeline < xep-editor-pipel...@zombofant.net> wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Pre-Authenticated In-Band Registration > Abstract: > This document extends the In-Band-Registration protocol to use > invitation tokens, e.g. for registering accounts on non-public > servers. > > URL: https://xmpp.org/extensions/inbox/ibr-token.html This is a very comprehensively written XEP for an initial submission. 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. Also, this namespace happens to be the same as XEP-0379, which is a trivial fix (but, I think, blocking). Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Proposed XMPP Extension: Pre-Authenticated In-Band Registration
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Pre-Authenticated In-Band Registration Abstract: This document extends the In-Band-Registration protocol to use invitation tokens, e.g. for registering accounts on non-public servers. URL: https://xmpp.org/extensions/inbox/ibr-token.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
