jdev - 2019-12-07


  1. lovetox

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

  2. lovetox

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

  3. lovetox

    so im not sure for what that is

  4. lovetox

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

  5. lovetox

    and the jid is gone after i end the session

  6. pep.

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

  7. pep.

    I don't think a client can request it

  8. Zash

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

  9. lovetox

    yeah makes not much sense

  10. lovetox

    there is no username specified anywhere in the flow

  11. lovetox

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

  12. Zash

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

  13. lovetox

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

  14. lovetox

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

  15. Zash

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

  16. lovetox

    yeah what else can it be?

  17. lovetox

    and where should i as client get that value

  18. Zash

    Anything

  19. Zash

    You get your JID in resource binding

  20. lovetox

    yeah but looking at IBR

  21. lovetox

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

  22. lovetox

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

  23. lovetox

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

  24. lovetox

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

  25. Zash

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

  26. Zash

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

  27. Zash

    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.

  28. lovetox

    funny IBR does not even return the jid registered

  29. lovetox

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

  30. Zash

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

  31. Zash

    Does IBR2 fix that?

  32. Zash

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

  33. lovetox

    this also fails at almost any xmpp client

  34. lovetox

    almost any client specifices a jid and pass field

  35. Zash

    Sure

  36. lovetox

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

  37. Zash

    True

  38. lovetox

    so it would need to be a username field

  39. lovetox

    and a second field specifing the server

  40. lovetox

    in a walled garden the second field would not be needed

  41. lovetox

    funny that gajim has exactly that UI right now

  42. lovetox

    which most people feel is a pain

  43. Zash

    Can you type user@host as username?

  44. lovetox

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

  45. Zash

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

  46. Zash

    Gajim Enterprise Edition? 😀

  47. lovetox

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

  48. lovetox

    and with anonymous this changes on every connect

  49. lovetox

    maybe i just make the domain the key for anon accs

  50. lovetox

    and just allow one anon acc per domain in Gajim

  51. lovetox

    we dont have any XEP for password resets or?

  52. lovetox

    we should really get IBR2 going

  53. Zash

    Everything2 😀

  54. pep.

    0389?

  55. pep.

    Or a new one?

  56. Zash

    XMPP2

  57. lovetox

    yes 0389

  58. lovetox

    though actually 0389 is missing the mutli stage functionality

  59. Zash

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

  60. lovetox

    ah i see its a little sentence at the end

  61. lovetox

    the server MAY send another challenge.

  62. 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?

  63. lovetox

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

  64. Zash

    SASL2, IBR2 and .. BIND2?

  65. lovetox

    and it lacks examples

  66. lovetox

    and Zash now i know why IBR uses IQ before bind

  67. lovetox

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

  68. Zash

    Hack 🙁

  69. lovetox

    so implementing the whole process with nonzas is a bit harder

  70. Zash

    But they need to for SASL

  71. lovetox

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

  72. lovetox

    so we can add callbacks for these in the future

  73. Zash

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

  74. Zash

    There should be no async or out of order events.

  75. Zash

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

  76. lovetox

    hm true

  77. lovetox

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

  78. lovetox

    hm or does it

  79. lovetox

    ah yes, for the change-password flow

  80. lovetox

    though this is maybe excluded here

  81. lovetox

    and should rightfully excluded out of IBR

  82. lovetox

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

  83. Zash

    agree

  84. Zash

    Hm

  85. lovetox

    change password should be just a adhoc flow

  86. lovetox

    there is no need to invent something new here

  87. lovetox

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

  88. Zash

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

  89. lovetox

    adds too much complexity in my opinion

  90. Zash

    Like, right after password recovery

  91. lovetox

    just send a email out to your users

  92. lovetox

    or a xmpp message with a weblink

  93. lovetox

    but if you would do this

  94. lovetox

    this would also be a pre-bind deal for me

  95. lovetox

    right after auth

  96. lovetox

    present a must change password flow

  97. Zash was just looking for that in https://xmpp.org/extensions/xep-0388.html

  98. lovetox

    yeah its under 2.6.3

  99. lovetox

    so yes SASL2 would support that

  100. Zash

    Hm

  101. lovetox

    ok so we have multistage pre-bind ibr with ibr2

  102. Zash

    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

  103. lovetox

    we have pre-bind password changes with sasl2

  104. lovetox

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

  105. Zash

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

  106. lovetox

    problem is migration

  107. lovetox

    i was just thinking about 2FA

  108. lovetox

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

  109. lovetox

    and afterwards only SASL2

  110. Zash

    Sure

  111. lovetox

    ah no

  112. lovetox

    the server does not know the account before SASL :D

  113. lovetox

    so it cant just leave SASL2 out

  114. Zash

    Hm

  115. lovetox

    so you can always make a downgrade attack

  116. lovetox

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

  117. Zash

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

  118. Zash

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

  119. Zash

    or someting

  120. Zash

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

  121. Zash

    Would be good to have a client to test with tho

  122. lovetox

    its not an attack i misspoke

  123. lovetox

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

  124. lovetox

    so no its not that big of a problem i guess

  125. lovetox

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

  126. lovetox

    obvious

  127. Zash

    But it affects everyone on the server

  128. Zash

    Or does it?

  129. lovetox

    no, 2FA can be set per account i guess

  130. lovetox

    could be a simple option in the register flow

  131. Zash

    So SASL1 would succeed for those

  132. lovetox

    yes

  133. Zash

    .. .that hasn't enabledit

  134. Zash

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

  135. Zash

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

  136. lovetox

    how would you activate 2FA

  137. Zash

    Dunno

  138. lovetox

    only via IBR2

  139. lovetox

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

  140. lovetox

    in normal ibr there is no multistage

  141. lovetox

    which you need for any 2fa setup

  142. Zash

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

  143. lovetox

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

  144. Zash

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

  145. Zash

    XEPlosion!

  146. Zash

    😀

  147. lovetox

    2FA upgrade can be done again via adhoc

  148. lovetox

    no need to invent something there

  149. lovetox

    great

  150. lovetox

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

  151. lovetox

    fits

  152. Zash

    heh

  153. Zash

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

  154. Zash

    or it could be ...:sasl2:1

  155. lovetox

    hm theoretically it should be easy to implement SASL2 in nbxmpp

  156. lovetox

    as SASL1 is already writte like a plugin