That's right DIGEST-MD5, your job is done here. Now it's time for the new kid to take up your place.
Those of you who ever tried to actually implement the DIGEST-MD5 SASL mechanism for authentication know that it suffers from quite a few problems, including but not limited to a variety of different implementations with a variable level of compliance to the DIGEST-MD5 RFC 2831. These interoperability problems make it quite hard to get a new implementation working with most of the already existing implementations.
SASL mechanisms are designed to be protocol-independent. That's basically the whole idea about SASL; to abstract the authentication part out of the application protocols, and standardize it. However DIGEST-MD5 already started off on the wrong foot.
Intending to interoperate with digest authentication used for HTTP, the requirement for ISO 8859-1 encoding support was added. However XMPP for example, designed internationally and using latest developments in the DNS area, supports UTF-8 usernames, passwords and IDNs. This makes it hard to store a hashed version of the password since you need to be prepared for either encoding, ISO 8859-1 and UTF-8.
Here comes SCRAM to the rescue. So far I have implemented the basic parts of it in my SASL library which is written in Lua and is a part of Prosody. In the SCRAM draft you can read about the design considerations which are clearly more modern and focused on more international usage.
- Usernames and password are Unicode and are to be string prepped before usage; a feature DIGEST-MD5 doesn't have.
- You can now easily store the user relevant authentication information in a database which isn't by itself sufficient to impersonate the user; this might be possible somehow with DIGEST-MD5 but it clearly hasn't been made easy for the developers (leading to XMPP servers storing plaintext passwords).
- You can simply swap out the basis, the hashing algorithm used, in SCRAM. This makes the mechanism more future proof and secure, unless design issues are found in the protocol itself.
- SCRAM has been designed to be easier to implement than DIGEST-MD5. I totally agree with this. Message parsing has been made easier by using no quotes on values; DIGEST-MD5 used them but only on some values.
One last note on interoperability: I've continuously tested my implementation against Simon Josefsson's implementation for GSASL, which was quite easy to set up thanks to GSASL's command line interface. Shortly after, I also did interoperability testing against the SCRAM implementation by Paul Aurich for Pidgin, in which we both fixed some bugs. A Prosody instance is still running for interoperability testing at scram-interop.ayena.de. Last but not least, we're working nicely against Swift; however no end-users can be happy about that currently;).
So client and server developers, get ready for SCRAM and implement support for it for a more interoperable future; not to forget its being the MTI mechanism for the next XMPP RFC iterations.
Version 0.2.0 has been released just one month after version 0.1.0 and four months after development began. With currently nearly one month between a release and the next we have a good release frequency which is fairly important for a project, especially for one which focuses on ease of prototyping new features in and a protocol around it like XMPP with is evolving pretty fast.
With consent of all the other developers, Waqas and my humble self, Matt dictated the use of Lua for the server which has quite some advantages.
Since it's an interpreted language you don't have to wait for building to test some changes you made or don't need stuff like autoconf to build your project cross-platform. However we have some binary modules for encryption and more low-level stuff.
The resulting server is pretty fast, already implements quite some XEPs while not being a memory beast like eJabberd. Not to forget the nice side affect of using Lua as implementation environment which is that you can easily add new protocols to it and test them. This should help us to push the interesting and important XEPs server side so that the client developers get in charge to implement them on their side.