Using the PLAIN mechanism will send the password in cleartext, only protected by TLS itself, the server will always see your cleartext password and channel- binding isn't supported by PLAIN, too. That's fine, if you deem TLS to be always secure and your server to never be evil or compromised.
Yes, really, that's fine. But you'll loose another layer of security. Having multiple layers of security is always beneficial. RFC 6120 discourages the use of PLAIN in section 13.8.3. We merely added a pointer to this RFC into SASL2 to stress that more. That doesn't mean one couldn't still use PLAIN. It may well be that the deployment (LDAP etc.) makes it impossible to use something else than PLAIN. Let me stress that again: SASL2 does still allow that, even when pointing to RFC 6120 (which would already be normative on that subject, even without the additional pointer in SASL2). Why did we add the pointer nonetheless? Because supporting PLAIN, *even if the deployment doesn't warrant it*, weakens security. As soon as the client does support PLAIN, a MITM able to break into the TLS channel could downgrade the used SASL mechanism to plain by manipulating the server advertised mechanism list to only include PLAIN. Channel-binding would be a technique to detect such a MITM, but channel- binding is only possible with SCRAM (or OPAQUE), not when using PLAIN. In my opinion removing support for PLAIN in clients would be the best thing to do. But I see, that some deployments require the use of PLAIN. In a private discussion with Holger, we came up with a solution, that could help solving that deadlock using a compromise: Use a security profile in a well-known path on a webserver serving the same domain as the xmpp server, similar to the well-known path used for POSH (RFC 7711). This profile would tell the client, if the domain in question needs PLAIN turned on or off. The default in case such a profile is absent would be "on". (This could even eventually switched to "off" if all major clients support such a profile. But that's for another discussion in several years.) This security profile could even contain other security relevant settings our community comes up with. Maybe, just speculating, this profile could be also part of POSH. There is one other mitigation possible: SASL mechanism pinning. But while pinning is a valid approach it has some downsides, too. It does not cover the first connection and depends on ordering of mechanisms. If you upgrade the pinning to stronger mechanisms as soon as the server advertises them, you'll permanently break authentication for your client if the server operator just briefly activated these stronger mechanisms and deactivates them again (for various reasons). If, on the other hand, you don't upgrade your pinning as outlined above, your client will remain on a sort of security baseline that eventually will be outdated over the years and virtually be as good as no pinning at all. Pinning is the best solution we currently have at hand. In my opinion the proposed security profile above would be an even better solution worth writing a ProtoXEP for. And those solutions could be even combined. As for now, nothing in the SASL2 XEP does forbid to use PLAIN. All I wanted was to add awareness of the security implications of PLAIN (especially without pinning) and I think I've reached that goal. -tmolitor _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
