Authentication *before* GET?

"Peter Lister, Cranfield Computer Centre" <P.Lister@cranfield.ac.uk>
Errors-To: listmaster@www0.cern.ch
Date: Fri, 11 Mar 1994 13:54:40 --100
Message-id: <9403111241.AA02582@xdm039.ccc.cranfield.ac.uk>
Errors-To: listmaster@www0.cern.ch
Reply-To: P.Lister@cranfield.ac.uk
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: "Peter Lister, Cranfield Computer Centre" <P.Lister@cranfield.ac.uk>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Authentication *before* GET?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Mailer: exmh version 1.3beta 2/17/94
X-Mailer: exmh version 1.3beta 2/17/94
X-Mailer: exmh version 1.3beta 2/17/94
X-Mailer: exmh version 1.3beta 2/17/94
X-Mailer: exmh version 1.3beta 2/17/94
Content-Length: 4899

Apart from the current "can Kerberos be spoofed" thread both on and off 
www-talk, I notice from "WWW Access Authorization protocol examples" that 
Authentication info is exchanged only *after* a GET request has resulted in an 
Authorisation header.

>  When a browser gets an Unauthorized status code or otherwise figures
>  authorization is needed, it sends authorization information along with the
>   next request to the server. 
>
>
>          GET whatever HTRQ/V1.0
>          Authorization: Basic KDENfKdifwekFD23nf==
>          ...

Michael Shiplett noted that the first part of the exchange (GET ...) is in 
clear; while I don't that this causes a problem for spoofing, it does of 
course mean that that anyone can read "whatever". If instead of "GET whatever" 
the method is "PUT <credit card number>", it's pointless 
authenticating/encrypting afterwards. I would like HTTP to be able to 
authenticate with Kerberos right from the start; client and server can use 
encrypted comms based on the Kerberos session key which they both now know.

OK, this begs the question - how does the browser know that Kerberos should be 
used for this request? Kerberos is intended to be the first exchange between 
client and server over an untrusted link. In a solely Kerberised environment, 
this is no problem. Where several authentication protocols (of which the most 
basic is "none") are mixed, browsers which know only a URL talking to an 
untrusted server need to know whether they should demand Kerberos 
authentication to prove the server's identity. Obviously, this extends to the 
question "of the several authentication mechanisms I know, which is 
appropriate?".

So may I throw the following idea into the air and stand well back while 
everyone else savages it.

When a browser makes a request - especially in the case of a fill-out form - 
the first action is not GET/PUT, etc but something like

[SERVER sez]  Can-authenticate: KerberosIV,None
[CLIENT sez]  WWW-Authenticate: KerberosIV <client's ticket for server>
[SERVER sez]  WWW-Authenticate: KerberosIV <servers mutual auth reply>
              Key-info: KerberosIV-session-key
[CLIENT and SERVER then perform a normal HTTP exchange via an encrypted 
channel]

The point is that the browser establishes that it can trust the server 
immediately. As soon as it knows that it can trust the server, it displays a 
big green tick "Yes, the documents you're reading are genuine" (along with a 
note on which authentication mechanism was used). If it can't, a big red 
cross; you *can't trust* this. Similarly, when a form is submitted, the client 
will say "There is no authentication, do you really want to submit this?". And 
similarly, A client should be able to force encryption (under the user's 
control), and prompt for confirmation if this can't be done. On the server 
side, files and script can use ACLs to control whether only authenticated 
users should access, Access Control Lists to specify limited groups of 
readers, and also an "eyes only" flag where the server will insist on using 
encryption and refuse to send the output where this is not possible.

Zephyrgrams are tagged on a similar basis - the fact that a message is 
unauthenticated doesn't mean it isn't useful, simply that there's no evidence 
that you can trust it. After all, if the parish magazine comes through my 
letterbox, I don't worry that it isn't security printed, as it's highly 
unlikely that anyone wants to forge it; I would be suspicious of a letter 
purporting to be from my bank manager which was obviously churned out on a 
low-quality photocopier, especially if it asked me for personal information.

Where multiple documents are obtained via one call, then the whole call (not 
just each request) can be trusted.  Also, since I believe that HTTP can 
identify that multiple calls are one session, client and server can continue 
to use encrypted communications with that session key, and do not need to 
reauthenticate. Where it is established that the server can use PGP for 
documents, it uses PGP (conceivably, on top of an already Kerberos encrypted 
comms channel!). Where the client doesn't speak Kerberos, it will simply not 
send the WWW-Authenticate: KerberosIV, and everything proceeds exactly as if 
Kerberos doesn't exist.

Kerberos allows a client to trust a server, the *process* that we are talking 
to. As I understand PEM and PGP, they are oriented toward the individual 
*document*, and hence there is no point in authentication processing until 
after the doc has been requested. Lets ensure that HTTP can cope with either 
case.

I would also recommend that "None" is a registered authentication type, which 
can be explicitly left out of a Can-authenticate: list to say to browsers, "I 
will not talk to you without authentication", so that a browser can tell the 
user immediately that they won't get anywhere.