Subject: HTTP Authentication Options

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 Jul 2006 09:47:09 -0700

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 17 Jul 2006 19:13:17 +0200

Eric,

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?

Best regards, Julian

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 Jul 2006 10:15:26 -0700

Julian Reschke <[email-masked]> wrote:
> 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.
> 
> (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

---

From: "Robert Sayre" <[email-masked]>
Date: Mon, 17 Jul 2006 13:49:12 -0400

On 7/17/06, Eric Rescorla <[email-masked]> wrote:
> database as a one-way hash of the password.

Systems that use forms will often do this as well...

> 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."

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 Jul 2006 10:58:45 -0700

Doh. Fat-fingered my reply.... Resending to the list.

> Systems that use forms will often do this as well...

Yes, the heading "Plaintext Passwords" was intended to cover both
Basic and Forms.

> 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

Right. This could obviously be the subject of a clarifying draft.

> 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

---

From: "Robert Sayre" <[email-masked]>
Date: Mon, 17 Jul 2006 14:30:32 -0400

> an auth database that would work for both.

Right. But some of our server implementers couldn't implement it if
they wanted to.

> 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.

> 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.

> 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

---

From: "James Holderness" <[email-masked]>
Date: Mon, 17 Jul 2006 19:35:14 +0100

Robert Sayre wrote:
> Some implementations respect the charset
> 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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 Jul 2006 11:45:26 -0700

Added atom-protocol to the Cc: line

> 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. 

> 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

---

From: "Robert Sayre" <[email-masked]>
Date: Mon, 17 Jul 2006 14:54:52 -0400

> Right. My point was merely that it's doable as a matter of

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 Jul 2006 12:20:08 -0700

> check message body integrity after it has verified that the client

Sure. But then you don't *have* to use auth-int for this application.
Note that TLS doesn't have this problem.

-Ekr