Kerberos authentication for HTTP/1.0

Tony Sanders (sanders@bsdi.com)
Mon, 24 May 1993 13:55:30 -0500


> As to job control, line mode browsers start telnet happily enough, so
> they can run kinit the same way.
This is fine, I only said the browser should detect failure due to Payment
Required (code 402) and initiate a dialog that requests the password, I
didn't say you couldn't exec kinit to do the work. I just don't want the
user to have to type in the kinit request by hand each time he changes
realms (even if only once, the browser and its helpers are free to deal
with this however is best, including caching TGT's for different realms).
If a user is already kinit'ed to the required realm the browser should
not have to do anything, again it's up to the browser and its helpers
to do the right thing. You also need a way to generate the additional
headers on each request using some external program (because you can't
keep sending the same headers and avoid replay).

It is up to the browser writers to do this in a generic way so they can
support multiple authentication schemes. It would probably help if the
server returned a header like Accept-Authentication: with a list of the
authentication protocols it accepts. Tim BL, do you want to address this
in the HTTP spec?

Another way to attack the problem is just inject the raw authentication
protocol in the stream at some point (hand off the socket to an
external program and let it do all the work). Tim: is this allowed? What
do you think about it? I don't think it would break anything since it
would only happen if both the client and server agreed on the
Authentication: protocol. Comments?

I hope to do some prototyping at some point in the next few weeks.

FYI: the problem I'm trying to solve is not so much local access to
documents (you could simply check IP address for that and get most of what
you need) but rather the purchasing of books and other services over the
Internet.

--sanders