Subject: Authentication and TCP Connection State

From: Michael B Allen <[email-masked]>
Date: Fri, 3 Oct 2014 12:10:55 -0400

An HTTP authentication sequence looks something like:

    C: GET /some/thing/6678
    S: 401 Unauthorized
       WWW-Authenticate: MyAwsomeAuth XlwYXNzd29yZA...

    C: GET /some/thing/6678
       Authorization: NTLM MyAwsomeAuth bGxXwYXbxXlYX...
    S: 200 OK

The way this is implemented on the server is to create some
authentication state and associate it with the client TCP connection
using the client's IP and remote port as an index into a map of
ongoing authentication state objects.

My question is, can HTTP/2 clients submit multiple requests on the
same TCP connection without waiting for responses?

If yes, how could HTTP authentication possibly work when there would
be no way to lookup the correct authentication state object associated
with the submitted auth token?

To be more specific, authentication almost always involves sending the
client some random data (let's call it a "challenge") that the client
must then transform using a shared secret and submit that to the
server (let's call it a "response"). So if the server gets two
authentication "response" tokens in sequence, how can the server know
which authentication state object matches the supplied response.
Meaning it is not possible to match the "response" with it's "ch
allenge".

Mike

---

From: Matthew Cox <[email-masked]>
Date: Fri, 3 Oct 2014 16:22:49 +0000

It doesn't work, but we had a proposal a couple years ago to address this: http://tools.ietf.org/id/draft-montenegro-httpbis-multilegged-auth-01.txt.

Matthew

-----Original Message-----
From: Michael B Allen [mailto:[email-masked]] 
Sent: Friday, October 03, 2014 9:11 AM
To: [email-masked]
Subject: Authentication and TCP Connection State

    C: GET /some/thing/6678
    S: 401 Unauthorized

    C: GET /some/thing/6678

The way this is implemented on the server is to create some authentication state and associate it with the client TCP connection using the client's IP and remote port as an index into a map of ongoing authentication state objects.

My question is, can HTTP/2 clients submit multiple requests on the same TCP connection without waiting for responses?

If yes, how could HTTP authentication possibly work when there would be no way to lookup the correct authentication state object associated with the submitted auth token?

To be more specific, authentication almost always involves sending the client some random data (let's call it a "challenge") that the client must then transform using a shared secret and submit that to the server (let's call it a "response"). So if the server gets two authentication "response" tokens in sequence, how can the server know which authentication state object matches the supplied response.
Meaning it is not possible to match the "response" with it's "ch allenge".

Mike

---

From: Michael B Allen <[email-masked]>
Date: Fri, 3 Oct 2014 13:31:15 -0400

On Fri, Oct 3, 2014 at 12:22 PM, Matthew Cox <[email-masked]> wrote:
> It doesn't work, but we had a proposal a couple years ago to address this: http://tools.ietf.org/id/draft-montenegro-httpbis-multilegged-auth-01.txt

Rats. This is absolutely going to block HTTP/2 in the enterprise. And
even after clients are updated (and we're not just talking about
browsers), how will the client even know it needs to serialize
requests?

Only the server knows if authentication is required. I think the
server should provide a TCP-level option that makes the server
serialize until the first 200 status is reached. I can imagine there
are numerous instances where it logically and conceptually should
block to the first 20x to "negotiate" something. I suspect it already
does (TLS/SSL).

This whole "HTTP is stateless" business is just false. HTTP is NOT
stateless. Cookies and sessions are hacks to work-around this fact.

Mike

---

From: David Morris <[email-masked]>
Date: Fri, 3 Oct 2014 11:06:21 -0700 (PDT)

I don't see any difference here between multiple TCP
connections and multiple streams within a single HTTP/2
TCP connection.

This typically works in practice because the user experience
starts by requesting a single URL, the web page. The user's
client doesn't know about other required requests until
after receiving the first page after authentication is
complete.

I would think a server would be able to mitigate the
issue by setting expiration/revalidate on the basic
page to some fraction of the authentication valid
interval.

I frequently encounter expired sessions in the real
world and have never had a case where the client/server
seemed lost and unable to sort out the re-authenticate
step.

As I stated at the top, I don't see how HTTP/2 streams
make this better or worse.

David Morris

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 3 Oct 2014 21:01:29 +0200

> stateless. Cookies and sessions are hacks to work-around this fact.

No this is wrong. HTTP *is* stateless, it's just that people didn't
know it and invented a crappy insecure authentication mechanism which
authenticates the TCP connection instead of the requests. Result:
anybody behind a proxy can share anyone else's connection, and I guess
that all subscribers on this WG have already done it at least for fun
in such enterprises.

The HTTP/1 spec is very clear on this : requests are independant. So
there's nothing in the first request that precludes what will happen
to the second request, and it's perfectly legit to transport multiple
users between a proxy and a server over the same TCP connection.

Problems are already very common when using NTLM which expects
keep-alive to be granted when some components close the connection
after a response (which is perfectly valid as well). I think that
HTTP/2 will take more time to be deployed in enterprises because
of this, but at the same time it will incite admins to finish their
migration to get away from this total security and interoperability
failure which has lasted more than a decade.

Regards,
Willy

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 3 Oct 2014 22:22:39 +0300

> with the submitted auth token?

Basically, most authentication methods are associated with the request,
but some (the most well-known one is Negotiate) is associated with
connection.

Request-associated authentication work with both HTTP/1.1 and HTTP/2.

Some of these methods are stateful (authentication state is carried
between requests).

Connection-associated authentication is not reliable in HTTP/1.1 and
things are even worse in HTTP/2. Heck, there is a note in the IANA
registration about Negotiate about breaking assumptions and specs.

> stateless. Cookies and sessions are hacks to work-around this fact.

Browsers assume HTTP is stateless. And when one secretly breaks that
assumption (e.g. cookies) security holes result (and this has nothing
to do with bearer nature of cookies).

And even cases where browser knows things are stateful (e.g. HTTP
authentication), that information is not really used, so pretty much
the same secuirity holes are still there.

And attacks targetting these holes do happen in the real world.

-Ilari

---

From: Michael B Allen <[email-masked]>
Date: Fri, 3 Oct 2014 15:27:14 -0400

> connections and multiple streams within a single HTTP/2

Ok. Then the server auth module just needs a unique id for that stream.

So is there an HTTP/2 header that uniquely identifies the stream?

If not, I think there should be one. And it should be generic like
"Stream-ID" (as opposed to "Auth-ID").

Of course this all assumes that clients will use streams like they
currently use TCP connections. Meaning only one multi-legged auth per
stream.

And clients would have to minimize and reuse the set of Stream-IDs they use.

Mike

---

From: Mike Bishop <[email-masked]>
Date: Fri, 3 Oct 2014 20:15:59 +0000

You don't reuse streams -- they're one stream per request-response.  That's the problem the draft attempts to solve, that there's no correlation between the previous 401 and the new request.

-----Original Message-----
From: Michael B Allen [mailto:[email-masked]] 
Sent: Friday, October 3, 2014 12:27 PM
To: David Morris
Cc: [email-masked]
Subject: Re: Authentication and TCP Connection State

On Fri, Oct 3, 2014 at 2:06 PM, David Morris <[email-masked]> wrote:
>
> I don't see any difference here between multiple TCP connections and 
> multiple streams within a single HTTP/2 TCP connection.

If not, I think there should be one. And it should be generic like "Stream-ID" (as opposed to "Auth-ID").

Of course this all assumes that clients will use streams like they currently use TCP connections. Meaning only one multi-legged auth per stream.

Mike

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Oct 2014 13:21:12 -0700

> You don't reuse streams -- they're one stream per request-response.  That's the problem the draft attempts to solve, that there's no correlation between the previous 401 and the new request.

...apart from what might be included in the request itself.

---

From: Michael B Allen <[email-masked]>
Date: Fri, 3 Oct 2014 16:31:52 -0400

> that all subscribers on this WG have already done it at least for fun

I appreciate that someone who gets into an HTTP proxy can possibly
hijack a conventional TCP connection and any identity associated with
it.

But any application that is not largely read-only uses state all over
the place which makes the whole "HTTP is stateless" commandment ring
flat.

But, more important, if the network is assumed to be hostile, isn't
that a job for transport security?

Wouldn't TLS or IPsec or IPv6 thwart this kind of proxy problem?

If yes, HTTP is unecessarily forcing everthing running through it to
effectively compute and send a potentially large encrypted blob with
every single request. That's a drag (literally).

Mike

---

From: Michael B Allen <[email-masked]>
Date: Fri, 3 Oct 2014 19:58:59 -0400

> Request-associated authentication work with both HTTP/1.1 and HTTP/2.

Really?

And what do you mean by "Request-associated authentication" exactly?

Like I said, there would be no way to lookup something and match it to
something the client supplied. So there would be no way for a server
to say "here's some random data, now do something to it that proves
you have the secret". This mechanism is elementary and it is found in
every authentication protocol worth it's weight in bytes.

Correct me if I'm wrong but it seems to me that HTTP/2 will
effectively *guarantee* that sites will submit non-challenged
credential information (probably plaintext) AND use a cookie to track
authentication state.

So can someone please explain to me precisely how proper
authentication could work with HTTP/2.

Mike

---

From: Julian Reschke <[email-masked]>
Date: Sat, 04 Oct 2014 11:02:59 +0200

On 2014-10-03 18:10, Michael B Allen wrote:
> ...

Hm, no. HTTP authentication is stateless, the server doesn't need to 
associate it with a life connection. Unless you're talking about the 
weirdo NTLM, which never should have been approved as HTTP 
authentication scheme.

Best regards, Julian

---

From: Michael B Allen <[email-masked]>
Date: Sat, 4 Oct 2014 14:03:11 -0400

On Sat, Oct 4, 2014 at 5:02 AM, Julian Reschke
<[email-masked]> wrote:
> associate it with a life connection. Unless you're talking about the weirdo
> NTLM, which never should have been approved as HTTP authentication scheme.

What's more "weirdo":

a) Use IPsec or TLS to get a secure TCP connection and then HTTP
clients and servers just have to authenticate the TCP connection (and
they can skip TLS if they're satisifed that clients are not being
directed through a compromised proxy).

OR

b) Require HTTP clients and servers build security on top of HTTP
which involves peforming authentication using the Auth-ID mechanism in
draft-montenegro-httpbis-multilegged-auth and then separately either
compute and submit a crypto token for every single request or get a
secure TCP connection so that you can safely store auth state in the
session.

Outside of corporate IntrAnets people are not going to do option b. So
everyone on the Internet is just going to continue to construct their
own auth scheme on top of HTTPS and process plaintext passwords on the
server. That is bad.

And now with multiplexing the client could submit multiple requests
only to find authentication is required which could lead to some at
least awkward if not highly inefficient scenarios.

Note that Kerberos doesn't actually do authentication entirely over
HTTP. The client authenticates separately with a 3rd server using an
entirely different protocol and then it only submits a service ticket.
It is only because of this that Kerberos does not require Keep-Alive.

And the "nonce" in Digest authentication serves the same function as
the Auth-ID in multilegged auth so Digest is really multilegged.

So I suppose my point is that since HTTP is stateless, it cannot
support any kind of real authentication at all without the Auth-ID
mechanism.

Maybe everyone understands this already and I'm just now realizing
that HTTP has totally punted authentication.

I suppose it could be thought of as a positive thing because it will
create a lot of work and jobs.

---

From: Yutaka OIWA <[email-masked]>
Date: Sun, 5 Oct 2014 13:09:00 +0900

Dear Michael,

such properties are only true for "some" set of HTTP authentications,
and NTLM is one of them, unfortunately.
It's against the HTTP/1.1 spec and will be broken in HTTP/2.

Some multi-hop HTTP authentications,
especially all of those currently discussed in HTTPAUTH WG
are not associated with any TCP connections,
and will work well with both HTTP/1.1 and HTTP/2.

Workaround for NTLM in HTTP/2 is proposed by
Montenegro's draft, as mentioned in other replies.

-- 
Yutaka OIWA, Ph.D.
          Planning Officer, Research Planning office for IT and Electronics
           (also: Senior Researcher, Research Institute for Secure Systems)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Yutaka OIWA <[email-masked]>
Date: Sun, 5 Oct 2014 13:26:48 +0900

Dear Michael,

> Really?

Yes.

> And what do you mean by "Request-associated authentication" exactly?

Short answer is "all non-broken authentication on HTTP/1.1", but
it will not answer your true question, I guess.

As HTTP/1.1 has already required that each request/response pair are
independent regardless of how it is carried on an underlying stream
(TLS or TCP), "properly-designed" authentication schemes
caries its own "session" identifiers on a HTTP header.
Examples are Digest authentication (1.5 hops, server-generated
nonce serves for it), currently-proposed Mutual (2 hops, "sid" parameter)
and SCRAM (multi hops, "sid" parameter) authentication schemes too.

Unfortunately, NTLM is widely used,
and it's designed as "session-associated".
It depends on Keep-alive connection of HTTP/1.1 and
ties its authentication state with the TCP connection
without any explicit session identifiers on HTTP headers.
Such design is not allowed in HTTP/1.1 spec.

So, all your questions should be directed to NTLM and
other "special" designs of HTTP authentications,
not to generic HTTP authentications.

Of course, most of us are aware that some existing
deployment of "so-called HTTP authentication" will be
completely broken in HTTP/2, although it was actually
already broken on HTTP/1.1.
All authentication schemes which strictly comply to
HTTP/1.1 will probably work on HTTP/2 without any
modifications (at least on session management aspects).

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 05 Oct 2014 17:58:35 +1300

On 5/10/2014 5:09 p.m., Yutaka OIWA wrote:
> Dear Michael,
> 
> such properties are only true for "some" set of HTTP
> authentications, and NTLM is one of them, unfortunately. It's
> against the HTTP/1.1 spec and will be broken in HTTP/2.

Lets put it this way.

NTLM auth assumes a single-connection environment. NTLM is expecting
to securely authenticate *THE* TCP connection, when HTTP in fact uses
2, 3, 4 ... N connections to deliver the single message. With
potentially different set of N connections on each message emitted by
the client.

Software allowing NTLM to happen in HTTP/1.1 has an annoyingly large
amount of hacks and workarounds to pervert or outright disable many of
the desirable high-performance features of HTTP/1.1 protocol.
 The same/equivalent workarounds and disabling can be done in HTTP/2,
but will make HTTP/2 run just a slow as HTTP/1.1 does with NTLM.

Amos

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 5 Oct 2014 08:18:06 +0200

On Sat, Oct 04, 2014 at 02:03:11PM -0400, Michael B Allen wrote:
> Outside of corporate IntrAnets people are not going to do option b.

And inside intranets, people are already abusing option a. It's only
clueless admins which continue to trust it. In every large place I have
been in, there were rogue proxies installed on end-users PCs to offer
free internet connectivity to other users, and the user with the highest
access class would authenticate once, then the proxy would pass everyone
in the same connection. What a great design! HTTP requests are independant
over a single TCP connection, NTLM is just a design mistake which happens
to work well enough to exist. But it's still a mistake given that it
authenticates something irrelevant to HTTP : the underlying TCP connection,
so it's neither reliable nor secure.

> So

Why ? *If* we stop thinking like NTLM, *then* we can design something
working to replace it. If there are few alternatives, it's likely because
of clueless admins which continue to deploy NTLM.

> least awkward if not highly inefficient scenarios.

Cookie-based auth works well for servers, it's just not suited to proxies,
which have to perform a redirect dance. We could have an auth scheme
explicitly designed for proxies.

> It is only because of this that Kerberos does not require Keep-Alive.

Then what's the problem ?

> support any kind of real authentication at all without the Auth-ID

I don't see your point. Provided that the client is able to show the
challenge that was submitted to it and the result, I don't see why
it cannot work.

> create a lot of work and jobs.

What's certain is that if pipelining and multiplexing had been in use
earlier, NTLM would probably never have been designed this way due to
incompatibilities, and a correct auth scheme would have been designed
instead, not causing all the mess we all know.

Willy

---

From: Michael B Allen <[email-masked]>
Date: Sun, 5 Oct 2014 12:37:11 -0400

> instead, not causing all the mess we all know.

My point is that it's not obvious to me that there is a good truly
stateless auth scheme at all - including the Auth-ID method.
Presumably the Auth-ID header must be routed back to the server
instance that issued it which means it's not truely stateless. At
least it seems to me proxies are going to have to use hard server
stickyness when processing Auth-ID requests / responses.

Could it be that the reason NTLM is still so popular is *because* it's stateful?

And as a result it blows the doors off of Kerberos which is the only
other enterprise SSO mech?

Kerbeors is fickle as hell. Clients have to have access to KDCs. It's
bound very tightly to DNS. Time has to be exactly correct on all 3
machines. Tickets become stale. Tickets are submitted with every
single request and they can be HUGE.

And BTW I never said anything about NTLM. I don't know why everyone
keeps mentioning it like it's THE problem. I'm not concerned with
NTLM. I have a generic "Security Provider" API. So I will just
implement whatever gets the job done. I pretty much have Kerberos 5
provider but I don't feel the pressure to roll it out because right
now, performance wise, NTLM is kickn' ass. And AFAIK it is secure if
NTLMv2 is used and there's no hijacked proxy in between.

My concern is with what will *replace* NTLM?

It's not obvious to me that "stateless authentication" is really
possible in practice.

Digest only works because it carries the nonce with it and that is a
pretty significiant constraint on the authentication mechanism itself.

Kerberos only works because it's not actually doing a complete
authentication - only a "ticket" is submitted.

NTLM will break with HTTP 2.

I don't know much about PKI / HTTP authentication methods but it
sounds like it's effectively what Kerberos is doing.

So there is no stateless complete HTTP-only authentication mechanism
in existence today that will work with HTTP 2.

I'm just saying - the whole "stateless authentication" thing is a
little dubious. The Auth-ID will need to be routed back to the server
that issued it.

Mike

---

From: Robert Collins <[email-masked]>
Date: Mon, 6 Oct 2014 07:51:21 +1300

> NTLM will break with HTTP 2.

NTLM is entirely broken with HTTP/1.x - I say this as one of the
primary authors in Squid of the pluggable authentication framework,
and the ntlm module we wrote at the same time. We had to do bizarre
things to tunnel ntlm properly through the core of Squid. As Amos said
- all the features of HTTP/1.x that were concerned with performance
improvements are turned off when NTLM is detected. And subsequently to
that folk(I forget who, but I want to say Henrik Nordstrom) added
logic to turn Squid into little more than a TCP proxy when NTLM is
detected from an origin server: we stop multiplexing requests from
different clients onto one server connection.

HTTP + NTLM != HTTP. It is TCP with a vague resemblence to HTTP. And
when it works on the internet its just damn luck. Country wide
intercepting proxies (e.g. Thailand, New Zealand), and firewalls
(China and perhaps more) play havoc with it.

> in existence today that will work with HTTP 2.

The exact same hacks that made NTLM work can be done with HTTP/2:
refuse to carry traffic for multiple users, authenticate the TCP
connection, serialise all request processing until authentication is
complete.

I'm sure that Microsoft will have little choice, given backwards
compatibility concerns, but I for one would be delighted if they were
to sunset all the non-Kerberos tunnelled authentications schemes in
their HTTP/2 support, and find a good way to do tickets per request.
(Perhaps a very short lifespan limited-use ticket with less bits in
it).

Transport security + an appropriately sized bearer token would be a lot saner.

> little dubious. The Auth-ID will need to be routed back to the server

So Auth-ID is from the "Multi-legged Authentication for HTTP
Multiplexing" draft - its not part of HTTP yet, and I suspect a great
deal of work is needed to sanely support that - I've just re-read it
and its got  (IMHO) holes you could drive a bus through. [Such as
Auth-ID being redundant with the persistent-auth marker,  the failure
to reconcile the impedance mismatch between request and connection
authentication, and permitting some auth schemes to be 'well known as
session based' which pushes complexity onto proxies - they have to be
updated for every scheme that has that characteristic even if the
proxy is only forwarding traffic, not doing the authentication itself.

Digest works today, even in AD environments - enterprises
(http://msdn.microsoft.com/en-us/library/aa292114(v=vs.71).aspx) -
though they claim it is replayable which says to me that the IIS
implementation isn't handling nonces correctly. But the big issue is
this: "Note   After configuring Active Directory to store passwords
using reversible encryption, all users must change their passwords for
Active Directory to store each password in this manner." - which I
expect to freak out every sysadmin on the planet - both because of the
reversible encryption (which digest doesn't actually require - though
you are sharply limited on the encryption possible) and because of the
need to reset every users password.

SCRAM is better but suffers from exchanging the salt in clear text,
which is where its dependency on transport layer security comes in.
Sadly it seems designed to encourage the use of channel binding, which
is precisely as hostile to HTTP as NTLM and SPNEGO were. Any HTTP/2
forward proxy will result in channel binding failing. And - unless MS
integrate SCRAM into AD+IIS, enterprises will still likely prefer
kerberos - SSO is a powerful thing.

If I may suggest, working with MS on per-request kerberos based auth
is probably the single most useful thing to do to encourage HTTP/2
adoption in the enterprise.

-Rob

-- 
Robert Collins <[email-masked]>
Distinguished Technologist
HP Converged Cloud

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 6 Oct 2014 08:07:53 +0200

> Could it be that the reason NTLM is still so popular is *because* it's stateful?

No, simply because users don't have to enter a password a second time,
that's the *only* argument that was given to me by people who break
their network with it. It exists, is convenient, and is safe *enough*
for what admins think their network looks like.

> keeps mentioning it like it's THE problem.

Simply because the mechanism you described was as broken as NTLM and
we already know that it does not work.

> I'm not concerned with
> implement whatever gets the job done.

So you want to start with something which every HTTP implementer knows
does not work and is insecure by design ?

> My concern is with what will *replace* NTLM?

Then better not keep the concepts that make people want to replace it.

> NTLM will break with HTTP 2.

And so what ? It already broke HTTP/1 and that didn't prevent admins
from deploying it. They'll simply do the same horrible hacks as they
did in v1 and it will work as in v1 : authenticate whoever is on the
other side of the connection and serialize all requests. And their
auth will continue to be broken by users installing proxies on their
PC or their VMs, so nothing will change.

> little dubious. The Auth-ID will need to be routed back to the server

I'm sorry if I don't know the details of all the auth schemes you're
describing, but I'm still not seeing the problem in defining a new one
if needed. There is a need for an auth scheme for proxies and for
applications. Anything involving a challenge is fine as long as the
client repeats the challenge in future requests. New challenges may
be emitted in responses and the client will have to break them before
the current one becomes too old (timestamp or request counter). That's
just *one* possibility, many are possible.

Willy

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 06 Oct 2014 19:44:51 +1300

On 6/10/2014 7:07 p.m., Willy Tarreau wrote:
> No, simply because users don't have to enter a password a second
> time, that's the *only* argument that was given to me by people who
> break their network with it. It exists, is convenient, and is safe
> *enough* for what admins think their network looks like.

FYI, I have seen one other re-occuring "reason".

That NTLM can be used even by machines not attached to the domain.

Apparently they like the fact that it degrades silently down to a
8-bit encoding wrapper around username+password auth. A little
different from Basic in ways that make it far less secure.

Amos

---

From: Michael B Allen <[email-masked]>
Date: Mon, 6 Oct 2014 12:22:11 -0400

> That NTLM can be used even by machines not attached to the domain.

Right.

A stand-alone complete authentication [1] is required if the client
doesn't have access to or knowledge of an authentication server like a
KDC in a Kerberos domain.

Note that this is not specific to NTLM. It is a generic concept that
is at the center of what I keep trying to say and I will keep saying
it until someone proves me wrong:

Any "challenge" will have to be directed back to the server that generated it.

This is probably the problem Rob mentioned about Digest being
replayable. Specifically, if the "nonce" in Digest auth is sent to a
different server from the one it was generated (such as because you're
load balancing requests between two servers), it could not prove that
the nonce wasn't used before. So it would just have to trust the nonce
the client supplied. That is the critical flaw in Digest auth.

I can see you guys really want to just direct requests like you're
routing packets around on an IP network. Sadly I don't think that day
will ever come. It is simply not possible to perform authentication
unless there is some state somewhere in which case all auth requests
must be routed back to the location of that state. So a proxy would
have to create an index of Auth-IDs and corresponding TCP connections
and route those requests to the corresponding TCP connection.

The alternative is to just say "HTTP does not support stand-alone
complete authentication". And that is pretty much where you claim your
at right now. Clients would have to use a 3rd party service using a
completely different protocol (that could not be based on HTTP and
thus would have to run on a different port and probably on a different
machine entirely). And that has all the problems Kerberos has of just
getting the client to find that service.

And so Internet users will still be processing plaintext passwords (or
password-equivalent hash) on the server and hanging auth state on the
session.

If HTTP had a built-in stand-alone complete authentication mechanism
that browsers could build a little secure form element around,
security breaches would drop like a led zeppelin (queue "Heartbreaker"
... ♩♩♩♩).

Mike

[1] An authentication that occurs entirely between only the client and
the server and that proves the user knows the shared secret and not
just a product of a previous authentication step.