Insecure WWW Access Authorization Protocol?

wa@mcc.com (Wayne Allen)
Errors-To: listmaster@www0.cern.ch
Date: Tue, 8 Mar 1994 17:00:34 --100
Message-id: <9403081554.AA16170@coyote.mcc.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: wa@mcc.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: wa@mcc.com (Wayne Allen)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Insecure WWW Access Authorization Protocol?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2528

All of this Kerberos discussion is perpetrating a lot of
misconceptions. There's no need to stick service name or realm
information in urls, or worry about instance names and all that.

Here's the big picture.  A client is registered in a Kerberos realm.
For that realm, there are one or more Kerberos servers which provide
service tickets to the registered clients. Likewise, a service is
registered in a Kerberos realm. The realm servers know how to encrypt
ticket data for all of the registered clients and servers. This is
because each client and service has a secret key, which the realm
servers know about.

A client identifies a service it wishes to use. The minimum
information needed for this identity is a host name or IP address, a
port number, and a service name. It does *not* matter whether the
client knows the service name beforehand, or, as in the case of the
HTTP protocol, learns it *after* connecting to the service (the first
time).

Given no other information, the client attempts to obtain a ticket for
the service by making a request to it's Kerberos realm server. If the
service is correctly registered in that same realm, a ticket will be
granted and athentication will proceed.

If the service is registered in a *different* Kerberos realm than that
of the client, the client must provide that realm name with the ticket
request it makes to it's own realm. If the client's and server's
realms have a pre-existing cross-authentication agreement,
athentication can proceed. In the case of the HTTP protocol, the
client learns the realm of the service *after* connection. Again, this
is perfectly ok.

Here's the point. It does not matter *when* or *from whom* the client
learns the service name or registration realm of the server. A rogue
server cannot spoof a client by providing misleading information of
this kind.  If the service is correctly registered in the client's realm
or in a valid cross-authenticating realm, authentication will succeed,
otherwise the client cannot obtain a valid ticket for the service, and
will recieve an "unknown service" error.  The Kerberos protocol and
client-code take care of things like reverse look-up and all that.  I
know all this is confusing, but that's just because it's complicated
;-)

The major security problems with Kerberos have to do with the humans
and human procedures used in adminstering the realms, not the code and
protocol.

Cheers,
--
 wa | Wayne Allen, EINet - wa@einet.net
    | MCC/ISD, 3500 West Balcones Center Dr, Austin, Tx 78759