jdev - 2019-12-07

hm can you "login" to an existing anonymous account?

Gajim has the anonymous checkbox, in its login dialog and on the create new account dialog

so im not sure for what that is

i always thought anonymous is when i ask the server to give me some throw away jid

and the jid is gone after i end the session

"lovetox> hm can you "login" to an existing anonymous account?" < that's a server impl. detail no?

I don't think a client can request it

How would you login to an existing account without any credentials?

yeah makes not much sense

there is no username specified anywhere in the flow

so even if i wanted i couldnt tell the server a preferred jid

You can pass something as data tho, but that's probably ignored

no fixed jid is a bit of a problem client impl wise

this means i cant add a account in a traditional way, as the jid was my account identifier

But that's sorta the case for normal accounts too. The username you enter in SASL doesn't have to be your JID localpart.

yeah what else can it be?

and where should i as client get that value

Anything

You get your JID in resource binding

yeah but looking at IBR

there is no way the server can communicate a username that is not the localpart of the jid

it cant say, hey you registerd a@a.at, but your username is lovetox

but i hear you, its not a must in theory that sasl username == localpart ✏

https://xmpp.org/rfcs/rfc6120.html#sasl-rules-username

username == localpart is recommended and the most common I imagine, outside some rare special deployments

Hm, there are some authentication backends for Prosody that use the database of some web forum software, which allows usernames that aren't valid JID nodeparts, so there's some mangling going on there.

funny IBR does not even return the jid registered

so the server could register another localpart and tell me while binding

And the email ecosystem often use the entire email address as username, which makes it a massive pain to use

Does IBR2 fix that?

Hm, https://xmpp.org/extensions/xep-0389.html looks kinda unspecified in that area

this also fails at almost any xmpp client

almost any client specifices a jid and pass field

Sure

obviously the client can never guess the username from the jid if its not the localpart

True

so it would need to be a username field

and a second field specifing the server

in a walled garden the second field would not be needed

funny that gajim has exactly that UI right now

which most people feel is a pain

Can you type user@host as username?

no, because Gajim puts both username and server together afterwards and it would yield an invalid jid

It's probably okay to not support username ≠ localpart deployments, or hide away the connection details for that in some advanced settings section

Gajim Enterprise Edition? 😀

what really hurts is that the jid is our main key for everything account related

and with anonymous this changes on every connect

maybe i just make the domain the key for anon accs

and just allow one anon acc per domain in Gajim

we dont have any XEP for password resets or?

we should really get IBR2 going

Everything2 😀

0389?

Or a new one?

XMPP2

yes 0389

though actually 0389 is missing the mutli stage functionality

lovetox, can I interest you in poking Sam or possibly taking over as author? 🙂

ah i see its a little sentence at the end

the server MAY send another challenge.

> If the client successfully completes the challenge, the server MAY return an empty <success/> element qualified by the 'urn:xmpp:register:0' namespace, MAY? What else would it do?

yeah it seems a bit weird, it seems like this is a XEP that is reused by other XEPs

SASL2, IBR2 and .. BIND2?

and it lacks examples

and Zash now i know why IBR uses IQ before bind

because all libs support callbacks on IQ responses, which you dont have with nonzas

Hack 🙁

so implementing the whole process with nonzas is a bit harder

But they need to for SASL

at least it would be nice to have ids on these nonzas

so we can add callbacks for these in the future

I don't see the point. Pre-resource binding shouldn't have more than one thing anyways.

There should be no async or out of order events.

The point of id attrs are that you can send many requests and the answers can come back in any order.

hm true

but the same thing must work in a after-bind situation also

hm or does it

ah yes, for the change-password flow

though this is maybe excluded here

and should rightfully excluded out of IBR

as it mixes, pre-bind and after-bind use cases

agree

Hm

change password should be just a adhoc flow

there is no need to invent something new here

adhoc has everything you would ever need for a change password flow

You might need some way to signal that a password change is mandatory tho

adds too much complexity in my opinion

Like, right after password recovery

just send a email out to your users

or a xmpp message with a weblink

but if you would do this

this would also be a pre-bind deal for me

right after auth

present a must change password flow

yeah its under 2.6.3

so yes SASL2 would support that

Hm

ok so we have multistage pre-bind ibr with ibr2

If password change can be either required or optional, then an user-initiated password change could be done by logging out and logging in+changing password

we have pre-bind password changes with sasl2

leaves a simple xep that has after-bind password changes via adhoc

I wonder if that makes things easier for servers, as you rather want to kill/reset other sessions when the password is changed.

problem is migration

i was just thinking about 2FA

but servers could offer both SASL as long as no 2FA is set

and afterwards only SASL2

Sure

ah no

the server does not know the account before SASL :D

so it cant just leave SASL2 out

Hm

so you can always make a downgrade attack

except for server who only support SASL2, which makes migration a pain

Hm, like the problem of upgrading stored hashes to SCRAM-SHA-256 or so

So you can't enable 2FA until everyone supports SASL2

or someting

I started on a SASL2 impl but I don't think it's complete

Would be good to have a client to test with tho

its not an attack i misspoke

after enabling 2FA server has to fail the SASL1 flow obviously

so no its not that big of a problem i guess

users just have to be warnded if they activate 2FA they can only connect with clients that support 2FA

obvious

But it affects everyone on the server

Or does it?

no, 2FA can be set per account i guess

could be a simple option in the register flow

So SASL1 would succeed for those

yes

.. .that hasn't enabledit

I suppose you can make it so that the server doesn't let you enable 2FA from a client that used SASL1

Then they can't lock themselves out as easily, and there's some incentive to upgrade

how would you activate 2FA

Dunno

only via IBR2

so that must be a client that does support IBR2 but not sasl2

in normal ibr there is no multistage

which you need for any 2fa setup

Not being able to upgrade an existing account to 2FA seems like meh tho?

yeah i guess there needs to be a own xep for that

You'd want to do that in connection to password change or something

XEPlosion!

😀

2FA upgrade can be done again via adhoc

no need to invent something there

great

SASL2 offer a stream feature of <mechanisms/>, qualified by the "urn:xmpp:sasl:1" namespace

fits

heh

Well if you come up with a reason to bump the namespace, and then never again...

or it could be ...:sasl2:1

hm theoretically it should be easy to implement SASL2 in nbxmpp

as SASL1 is already writte like a plugin