Zashusername == localpart is recommended and the most common I imagine, outside some rare special deployments
ZashHm, 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.
strarhas joined
lovetoxfunny IBR does not even return the jid registered
kikuchiyohas left
lovetoxso the server could register another localpart and tell me while binding
ZashAnd the email ecosystem often use the entire email address as username, which makes it a massive pain to use
ZashDoes IBR2 fix that?
ZashHm, https://xmpp.org/extensions/xep-0389.html looks kinda unspecified in that area
Danielhas left
lovetoxthis also fails at almost any xmpp client
lovetoxalmost any client specifices a jid and pass field
ZashSure
lovetoxobviously the client can never guess the username from the jid if its not the localpart
ZashTrue
Danielhas joined
lovetoxso it would need to be a username field
pulkomandyhas left
lovetoxand a second field specifing the server
lovetoxin a walled garden the second field would not be needed
lovetoxfunny that gajim has exactly that UI right now
lovetoxwhich most people feel is a pain
ZashCan you type user@host as username?
lovetoxno, because Gajim puts both username and server together afterwards and it would yield an invalid jid
ZashIt's probably okay to not support username ≠ localpart deployments, or hide away the connection details for that in some advanced settings section
ZashGajim Enterprise Edition? 😀
lovetoxwhat really hurts is that the jid is our main key for everything account related
kikuchiyohas joined
lovetoxand with anonymous this changes on every connect
lovetoxmaybe i just make the domain the key for anon accs
lovetoxand just allow one anon acc per domain in Gajim
bhaveshsguptahas left
pulkomandyhas joined
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
debaclehas left
asterixhas left
asterixhas joined
Danielhas left
pulkomandyhas left
Danielhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
pulkomandyhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
bhaveshsguptahas left
kikuchiyohas left
bhaveshsguptahas joined
sonnyhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
pulkomandyhas left
pulkomandyhas joined
asterixhas left
asterixhas joined
kikuchiyohas joined
sonnyhas left
bhaveshsguptahas left
pulkomandyhas left
asterixhas left
asterixhas joined
pulkomandyhas joined
kikuchiyohas left
lovetoxwe dont have any XEP for password resets or?
kikuchiyohas joined
lovetoxwe should really get IBR2 going
rionhas left
ZashEverything2 😀
pep.0389?
pep.Or a new one?
ZashXMPP2
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
lovetoxyes 0389
lovetoxthough actually 0389 is missing the mutli stage functionality
Zashlovetox, can I interest you in poking Sam or possibly taking over as author? 🙂
lovetoxah i see its a little sentence at the end
lovetoxthe server MAY send another challenge.
Zash> 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?
lovetoxyeah it seems a bit weird, it seems like this is a XEP that is reused by other XEPs
ZashSASL2, IBR2 and .. BIND2?
lovetoxand it lacks examples
lovetoxand Zash now i know why IBR uses IQ before bind
lovetoxbecause all libs support callbacks on IQ responses, which you dont have with nonzas
ZashHack 🙁
lovetoxso implementing the whole process with nonzas is a bit harder
ZashBut they need to for SASL
lovetoxat least it would be nice to have ids on these nonzas
lovetoxso we can add callbacks for these in the future
ZashI don't see the point. Pre-resource binding shouldn't have more than one thing anyways.
ZashThere should be no async or out of order events.
asterixhas left
asterixhas joined
rionhas joined
ZashThe point of id attrs are that you can send many requests and the answers can come back in any order.
lovetoxhm true
lovetoxbut the same thing must work in a after-bind situation also
lovetoxhm or does it
lovetoxah yes, for the change-password flow
lovetoxthough this is maybe excluded here
lovetoxand should rightfully excluded out of IBR
lovetoxas it mixes, pre-bind and after-bind use cases
Zashagree
ZashHm
lovetoxchange password should be just a adhoc flow
lovetoxthere is no need to invent something new here
lovetoxadhoc has everything you would ever need for a change password flow
ZashYou might need some way to signal that a password change is mandatory tho
lovetoxadds too much complexity in my opinion
ZashLike, right after password recovery
lovetoxjust send a email out to your users
lovetoxor a xmpp message with a weblink
lovetoxbut if you would do this
lovetoxthis would also be a pre-bind deal for me
lovetoxright after auth
lovetoxpresent a must change password flow
Zashwas just looking for that in https://xmpp.org/extensions/xep-0388.html
pulkomandyhas left
lovetoxyeah its under 2.6.3
lovetoxso yes SASL2 would support that
ZashHm
lovetoxok so we have multistage pre-bind ibr with ibr2
ZashIf 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
lovetoxwe have pre-bind password changes with sasl2
lovetoxleaves a simple xep that has after-bind password changes via adhoc
ZashI wonder if that makes things easier for servers, as you rather want to kill/reset other sessions when the password is changed.
asterixhas left
asterixhas joined
pulkomandyhas joined
lovetoxproblem is migration
lovetoxi was just thinking about 2FA
lovetoxbut servers could offer both SASL as long as no 2FA is set
lovetoxand afterwards only SASL2
ZashSure
lovetoxah no
lovetoxthe server does not know the account before SASL :D
lovetoxso it cant just leave SASL2 out
ZashHm
lovetoxso you can always make a downgrade attack
lovetoxexcept for server who only support SASL2, which makes migration a pain
ZashHm, like the problem of upgrading stored hashes to SCRAM-SHA-256 or so
ZashSo you can't enable 2FA until everyone supports SASL2
Zashor someting
ZashI started on a SASL2 impl but I don't think it's complete
ZashWould be good to have a client to test with tho
kikuchiyohas left
lovetoxits not an attack i misspoke
lovetoxafter enabling 2FA server has to fail the SASL1 flow obviously
lovetoxso no its not that big of a problem i guess
lovetoxusers just have to be warnded if they activate 2FA they can only connect with clients that support 2FA
lovetoxobvious
ZashBut it affects everyone on the server
ZashOr does it?
lovetoxno, 2FA can be set per account i guess
lovetoxcould be a simple option in the register flow
ZashSo SASL1 would succeed for those
lovetoxyes
Zash.. .that hasn't enabledit
ZashI suppose you can make it so that the server doesn't let you enable 2FA from a client that used SASL1
Alexhas left
Alexhas joined
ZashThen they can't lock themselves out as easily, and there's some incentive to upgrade
lovetoxhow would you activate 2FA
ZashDunno
lovetoxonly via IBR2
lovetoxso that must be a client that does support IBR2 but not sasl2
lovetoxin normal ibr there is no multistage
lovetoxwhich you need for any 2fa setup
ZashNot being able to upgrade an existing account to 2FA seems like meh tho?
lovetoxyeah i guess there needs to be a own xep for that
ZashYou'd want to do that in connection to password change or something
ZashXEPlosion!
Zash😀
lovetox2FA upgrade can be done again via adhoc
lovetoxno need to invent something there
lovetoxgreat
lovetoxSASL2 offer a stream feature of <mechanisms/>, qualified by the "urn:xmpp:sasl:1" namespace
lovetoxfits
Zashheh
ZashWell if you come up with a reason to bump the namespace, and then never again...
Zashor it could be ...:sasl2:1
pulkomandyhas left
pulkomandyhas joined
lovetoxhm theoretically it should be easy to implement SASL2 in nbxmpp