HTTP Authentication Options
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
Re: HTTP Authentication Options
Julian Reschke [EMAIL PROTECTED] wrote: thanks for the good summary (with which I agree). Obviously it's a good idea for IETF specs that are based on HTTP to talk about authentication options. What's really not clear to me why it is expected that this exercise should be repeated for each and every application of HTTP. Wouldn't it make a lot more sense if there'd be a single BCP about the (currently) best way to do HTTP authentication (understanding that this may be a moving target), and let other specs such as AtomPub reference it? This seems like a reasonable option to me, but of course it would hold up every HTTP draft until such document existed... :) -Ekr
Re: HTTP Authentication Options
On 7/17/06, Eric Rescorla [EMAIL PROTECTED] wrote: In most such systems, the passwords are stored in the password database as a one-way hash of the password. Systems that use forms will often do this as well... 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. ...which makes it impossible to use the existing auth database with Digest. Digest's more extensive protection options are basically unimplemented. Digest is extremely underspecified wrt to encoding of non-ascii characters. Some implementations respect the charset parameter specified in SASL Digest (RFC 2831). Others use the encoding of the page. No one is quite sure what IE does.* Mozilla uses UTF-8 all the time. * http://www.agileprogrammer.com/eightytwenty/archive/2006/05/04/14280.aspx The only thing we can reasonably say is Basic+TLS, but that's sort of silly, since many servers and some clients won't implement it. I'd rather skip the collective game of pretend. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: HTTP Authentication Options
Doh. Fat-fingered my reply Resending to the list. On 7/17/06, Eric Rescorla [EMAIL PROTECTED] wrote: In most such systems, the passwords are stored in the password database as a one-way hash of the password. Systems that use forms will often do this as well... Yes, the heading Plaintext Passwords was intended to cover both Basic and Forms. 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. ...which makes it impossible to use the existing auth database with Digest. If by existing auth database you mean the basic or form database, this is generally correct--though one could in fact implement an auth database that would work for both. Digest's more extensive protection options are basically unimplemented. By more extensive protection options do you mean the auth-int mode? I'm not familiar with what HTTP implementations do, but I'll note that SIP implementations will do auth-int. In any case, from the perspective of password capture, any form of digest is better than basic. Digest is extremely underspecified wrt to encoding of non-ascii characters. Some implementations respect the charset parameter specified in SASL Digest (RFC 2831). Others use the encoding of the page. No one is quite sure what IE does.* Mozilla uses UTF-8 all the time. * http://www.agileprogrammer.com/eightytwenty/archive/2006/05/04/14280.aspx Right. This could obviously be the subject of a clarifying draft. The only thing we can reasonably say is Basic+TLS, but that's sort of silly, since many servers and some clients won't implement it. I'd rather skip the collective game of pretend. Feel free to take this point up with the IESG. I doubt you'll find them very sympathetic, however. -Ekr
Re: HTTP Authentication Options
On 7/17/06, Eric Rescorla [EMAIL PROTECTED] wrote: If by existing auth database you mean the basic or form database, this is generally correct--though one could in fact implement an auth database that would work for both. Right. But some of our server implementers couldn't implement it if they wanted to. Digest's more extensive protection options are basically unimplemented. By more extensive protection options do you mean the auth-int mode? Yes, but I believe some clients even screw up auth mode, and only work with 2069-style. Container-managed security in Java Servlet implementations often doesn't work with Digest, at least with the vendor-provided authentication classes. I'm not familiar with what HTTP implementations do, but I'll note that SIP implementations will do auth-int. Mozilla doesn't do it. Apache (mod_auth_digest) doesn't do it. Opera does. I don't know what MS libraries do these days. Feel free to take this point up with the IESG. I doubt you'll find them very sympathetic, however. Well, I'd like the document to reflect reality, but I suspect that will be no match for the IESG rules in combination with some WG members that want Basic+TLS enshrined in the document because that is what they are going to deploy. -- Robert Sayre
Re: HTTP Authentication Options
Robert Sayre wrote: Some implementations respect the charset parameter specified in SASL Digest (RFC 2831). Others use the encoding of the page. No one is quite sure what IE does. From Microsoft's SSP docs [1]: Digest SSP uses the charset directive for both HTTP and SASL mode. This directive allows the use of UTF-8 in HTTP mode. To maintain backwards compatibility with clients that do not understand the charset directive, the realm in the challenge is encoded in the standard ISO 8859-1 (Latin-1) character set. If the client understands the charset directive, then the username and realm (and password) can be encoded in UTF-8 in the challenge response sent back to the server. If the client does not understand the charset directive, then the standard ISO 8859-1 (Latin-1) must be used. I would have thought this applied to IE as well as IIS, but reading Gordon's post it looks like the .NET implementation might be borked. If anyone really cares it's probably not too much effort to put together a few tests. Regards James [1] http://technet2.microsoft.com/WindowsServer/en/Library/717b450c-f4a0-4cc9-86f4-cc0633aae5f91033.mspx?mfr=true
Re: HTTP Authentication Options
Added atom-protocol to the Cc: line Robert Sayre [EMAIL PROTECTED] wrote: On 7/17/06, Eric Rescorla [EMAIL PROTECTED] wrote: I'm not familiar with what HTTP implementations do, but I'll note that SIP implementations will do auth-int. Mozilla doesn't do it. Apache (mod_auth_digest) doesn't do it. Opera does. I don't know what MS libraries do these days. Right. My point was merely that it's doable as a matter of programming. Feel free to take this point up with the IESG. I doubt you'll find them very sympathetic, however. Well, I'd like the document to reflect reality, but I suspect that will be no match for the IESG rules in combination with some WG members that want Basic+TLS enshrined in the document because that is what they are going to deploy. I'm not arguing for any particular outcome. I'm merely informing you of my understanding of the rules of the game. -Ekr
Re: HTTP Authentication Options
On 7/17/06, Eric Rescorla [EMAIL PROTECTED] wrote: Right. My point was merely that it's doable as a matter of programming. That's debatable, from an HTTP server's perspective, because the server must check (and temporarily store) the whole request before it can tell if the client knows the password. Not a good way to handle video uploads. Other authentication protocols, such as Amazon S3 auth, include the Content-MD5 header in the digest calculation so the server only has to check message body integrity after it has verified that the client knows the password. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: HTTP Authentication Options
Robert Sayre [EMAIL PROTECTED] writes: On 7/17/06, Eric Rescorla [EMAIL PROTECTED] wrote: Right. My point was merely that it's doable as a matter of programming. That's debatable, from an HTTP server's perspective, because the server must check (and temporarily store) the whole request before it can tell if the client knows the password. Not a good way to handle video uploads. Other authentication protocols, such as Amazon S3 auth, include the Content-MD5 header in the digest calculation so the server only has to check message body integrity after it has verified that the client knows the password. Sure. But then you don't *have* to use auth-int for this application. Note that TLS doesn't have this problem. -Ekr