Paul Hoffman asked me to reprise my remarks on HTTP Authentication options from IETF 66 on the mailing list, so here goes.
At the present moment, there are three HTTP authentication schemes in reasonably wide use: - Basic raw passwords in the HTTP headers. - Digest a challenge/response handshake in the HTTP headers - Forms raw passwords filled in a form and then passed in the GET arguments or more usually the POST body. Any of these mechanisms can be run over HTTPS. IESG Policy The IESG Policy, as I understand it, is that plaintext password systems must not be used on non-encrypted transport (in this case, TLS). Here's the relevant section from RFC 3552: The most common access control mechanism is simple USERNAME/PASSWORD The user provides a username and a reusable password to the host which he wishes to use. This system is vulnerable to a simple passive attack where the attacker sniffs the password off the wire and then initiates a new session, presenting the password. This threat can be mitigated by hosting the protocol over an encrypted connection such as TLS or IPSEC. Unprotected (plaintext) username/password systems are not acceptable in IETF standards. Note that this is a BCP but reflects my understanding of current IESG policy. This leaves the following three viable options: - Basic over HTTPS - Digest over HTTPS or in the clear - Forms over HTTPS The topic of MUST implement versus MUST deploy came up. Getting a definite answer to this requires input from the IESG, but my understanding is that standards MUST specify an acceptable authentication algorithm and MUST make it a MUST implement. I don't believe that at present it's a MUST NOT implement passwords in plaintext, but I could be wrong about this. Again, ask the IESG. SECURITY OF THE SYSTEMS A rough overview of the security of these systems can be found below. For more details, see S 4 and S6 of draft-iab-auth-mech-05.txt. Plaintext Passwords: Any password in the clear system is susceptible to password sniffing: an attacker on the wire can capture the password and use it to impersonate the user to the original server and to any server on which the user has used the same password.[0] If the authentication is run over TLS, then passive attacks no longer work. Active attacks may still be possible if the rules in RFC 2818 about certificate validation are not followed. In most such systems, the passwords are stored in the password database as a one-way hash of the password. This allows the server to check the password without storing the plaintext password. If the password file is compromised, the attacker can try to mount a dictionary attack to recover the original password. This generally works if the passwords are weakly chosen, which is common. Note that an attacker who wholly compromises the server can capture passwords in flight as they are used. Digest: Challenge-Response systems are not directly susceptible to the sniffing attack mentioned above. However, an attacker who captures the challenge-response exchange can potentially mount a dictionary attack, as above, to recover the original password. This is, of course, much harder than just sniffing the password off the wire. Challenge-Response systems require the password to be stored in the clear on the server (password equivalence). This means that someone who recovers the password file can use it directly to impersonate any user to the server. There are two mitigating factors. The first is that Digest is constructed so that the "password" you store is first hashed with the Realm name, so that you can only use it to impersonate to the same server, rather than to any server on which the user has used the same password. (You can of course still mount a dictionary attack). The second factor is that in most OSes, privilege escalation is so easy that in general an attacker who captures the password file could have simply captured plaintext passwords directly, as noted above. IMPLEMENTATION ISSUES I'm given to understand that there are ways in which the Digest spec is unclear and that implementation and interoperability is fairly spotty. I don't know much about this, but it's clear it can be made to work since SIP uses Digest. RECOMMENDATIONS Given that AtomPub is an automated protocol, I think Forms is out. That means either Basic (or Digest) over HTTPS or Digest over HTTP. In general, I tend to recommend HTTPS since it provides other security benefits. This is especially true since password enrollment is a fine time to record the server certificate fingerprint and thus bypass the PKI issue. However, if you can't tolerate HTTPS, then Digest also meets IESG reqts as I understand them. [0] There are ways to design these systems so that the password that goes over the wire are different for different systems even if the original password is the same (see Boneh's PwdHash) but these don't apply to the standard implementations. -Ekr