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