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
