On Wed, 24 Aug 2022 at 12:19, Matthew Wild <[email protected]> wrote: > On Wed, 24 Aug 2022 at 07:56, Daniel Gultsch <[email protected]> wrote: > > > > > And yes we are currently implementing it. That's why I’m providing > > feedback on the XEP. And yes we are using it with compression and yes > > we do terminate TLS early and can’t use HT-* and yes we use PLAIN for > > regular logins too and therefor we don’t have an issue with the > > "downgrade" in security. > > I'm also looking at potentially implementing it in Prosody very soon, > as part of the modern auth project ( > https://docs.modernxmpp.org/projects/auth/ ). > > My main motivation is support for 2FA, which is impractical without a > way for devices to re-identify themselves (you don't want an OTP > prompt every time your mobile reconnects to the server). ISR seems to > be a good way to fill that gap, while providing other benefits. The > alternative on my radar is XEP-0399 (Client Key). > > I have implemented Client Key, of course. I have also sketched out an HT-* implementation.
While I like Client Key for all sorts of reasons - for one thing, the counter gives you a better binding to the client device - HT-* is way easier to implement and deploy. We might want XEP-0399's device list management at some point, for sure, but let's focus on what's easiest to get out and deploy. XEP-0400 works for enrolling and requiring a TOTP-based 2FA across an entire server - there is no optional enrollment, so if we want that we'll have to consider how. It might be the trigger needed to develop optional Post Auth Tasks in SASL2. > I do agree that while the goals of enforcing channel binding are > noble, it is impractical to enforce across the network. It excludes > web clients and a bunch of deployments that terminate TLS before the > XMPP server. What are thoughts on a HT- variant without channel > binding (and adding RFC 9266's tls-exporter while we're at it)? > Combined with ISR's mechanism pinning, I think this still provides > some advantages over just using PLAIN (which is icky, but the > alternative). > > Thilo Molinar has some thoughts around better negotiation of TLS channel bindings as part of SASL2. As for an HT-*-NONPLUS, I think that's reasonable. I also think - unverified by code or a recent reading of HT-* - that my suggestion of butchering HT-* into payloading an encrypted username/password pair works, so that covers that side, in which case we've a workable solution for most deployment cases. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
