HTTP is a hero, a superman, our savior. We all love it. But like every good action hero, it has also a dark side. A weaker side. Where it is vulnerable and not so shiny. Its authentication.
There are efforts underway to improve HTTP in that area. Everyone feels the limitations. The latest victim is the Atom Protocol Party (APP), a fine group of the best of the best it is, and it is struggling with what to write in regard to authentication into their spec. So what is so difficult about it?
First of all, the IETF requires every protocol specification to take security into account. That is well and good, but since the general HTTP issues are not solved, each and every HTTP extension faces the same problem. The WebDAV RFC 2518, published in 1999, had that problem and now Atom still has it. Obviously, authentication needs to be addressed in its own specification so that others only need to reference it. That might not immediately help Atom (since there is nothing to reference yet), but it is also reasonable to expect that Atom will not remain the only protocol using HTTP.
I still have not told what the problem really is. There are two authentication schemes defined in RFC 2617 which are supported by virtually all clients: Basic and Digest. Basic was invented when the Internet was a friendly place, everyone had flowers in their hair and Bill Clinton was president. Basic transmits password in clear text. Everyone seeing the protocol packets knows your password. So the IETF decided to get rid of Basic and push for Digest.
Digest Authentication has much better security properties: your password cannot be seen, your requests cannot be misused for doing something else, etc. Nice. The drawback is that it is far more complicated than Basic and, reportedly although I cannot say that from experience, the bad stepmother named Interoperability has cursed it. One other drawback is that the server needs to store the passwords either in clear texts or in a specific way usable to Digest. Not all user stores do that and not all users want passwords in clear text on a server (there are reports of server break ins...). Yep, bad guys are out there.
As a consequence, people who want interoperability and who do not control client or server software (so basically everyone except intranet applications) do not like Digest. There are WebDAV servers who are not able to provide Digest, so according to RFC 2518 they are not WebDAV implementations at all. This is silly.
So the IETF paddled back a bit and said that Basic used over HTTPS (or SSL/TLS whatever) is also fine. To the surprise of no one, the big players serving thousands of authenticated users do not want to enable HTTPS for each and every request. And some smaller providers do not want to have the hassle with server certificates (you need a separate IP address for every domain name, yuk)...
Therefore the impassè. Yes, there are two ways to do secure authentication. No, they are not suitable for everyone. So what is a HTTP based protocol spec supposed to do?
The way out, which comes to my mind, is to quickly come up a spec describing the current state of affairs regarding HTTP authentication. Very short, nothing new, nothing inventive. And then let Atom reference that and let it focus on what the group really is about: making the Atom protocol. Then another working group can obsolete the first spec with a super duper superior safe and whatnot HTTP authentication framework. Should that not work, Atom can also put in the official IETF requirements in the spec and everyone swears a holy oath to support it while crossing their fingers behind their back.
Maybe. Perhaps. Just a thought by silly me.
Technorati Tags: authentication, basic, digest, atom, http, security