Re: Insecure WWW Access Authorization Protocol?

"Peter Lister, Cranfield Computer Centre" <P.Lister@cranfield.ac.uk>
Errors-To: listmaster@www0.cern.ch
Date: Tue, 8 Mar 1994 18:30:09 --100
Message-id: <9403081725.AA04857@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: Re: Insecure WWW Access Authorization Protocol?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 7120

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

I have never suggested "sticking service name or realm information in urls"; I 
have agreed with others that the Kerberos principal should be derived from the 
URL's server name, not the Authentication field return by an untrusted HTTP 
server. I shall continue to worry until the protcol adequately addresses this 
problem, thanks all the same.

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

Neither "clients" nor "servers" are registered with the Kerberos server, 
principal/instances are. Kerberos servers happily provide encrypted tickets to 
anyone who asks, safe in the knowledge that only a client in possesion of the 
correct key can decrypt the ticket. It doesn't have to be "registered" at all. 
Whether a principal/instance is a client or server depends solely on who asks 
for a ticket to authenticate to whom.

BTW I use "client" to mean running instance of a client program such as a WWW 
browser, not the system on which it's running. Likewise a server is a running 
instance of a program which responds to requests from the net.

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

The service name is http. That's a given. All the client knows is a URL. From 
that it knows the server's hostname and port number, it's already tried to get 
the document and been told it needs to authenticate via Kerberos. Think about 
your last sentence. How did the client get this far without knowing the 
service name?

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

OK. How does the client know

a) which Kerberos server to ask (it needs to know the realm beforehand)
b) which instance of the principal to ask for (since a single Kerberos realm 
can quite legitimately have multiple HTTP servers)

..given that it can't trust the server yet? All it knows is the URL, so we 
have to agree on how to get this info out of the URL, OK? That's what we're 
saying.

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

No it isn't. Look, at this point the client *CAN'T TRUST THE SERVER*, yes? It 
might be talking to the right server, it could be talking to a spoofer which 
tells the client to authenticate to the spoofer's principal. How does the 
client know? In normal Kerberos interaction, the service's principal is known 
beforehand because the application has conventions defining to which principal 
the client should authenticate.

If you phone up a small company which you suspect might be crooked, or where 
there is no accepted way of checking their bona fides, and the guy on the 
other end said "Phone this number, and they'll tell you we're genuine", you 
have no way of telling whether the number in question is the conman's partner, 
or a very satisfied and upright member of the community who will testify to 
years of excellent service. If the guys says "Contact this bank, they'll vouch 
for us", and names a respected institution which you then approach 
independently via the well-known information contained in the phone book, 
you're as sure as you can be.

> 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
> ;-)

But (sigh) services and clients are not registered by the Kerberos server!! 
And how does it learn the server name and realm (and instance), if not from 
the URL? The whole point is that a spoof HTTP server provides a reference to 
any principal the spoofer knows about (so any student at Cranfield, MIT, CMU 
etc has this power). A naive client happily authenicates. It doesn't have to 
be the *right* server principal if the client is stupid enough to believe 
everything it's told from an untrusted source, because the stupid client 
doesn't know what the right server *is*.

I don't know what you imagine that Kerberos client code does, but it 
definitely does *not* check that the reverse IP address translation matches 
the principal name, which is what you seemm to imply. And, anyway, the 
authentication has succeeded, so, Kerberos wouldn't notice anything wrong, 
anyway!

I think this this is confusing because you have a misconception about how 
Kerberos works. Don't worry. I've been managing a Kerberos site for 3 year, 
and it took me about 18 months to handle it, and I still don't regard myself 
as an expert.

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

Here, at least, we are in agreement. But if you read the preceding exchanges, 
you will have noticed that no-one is accusing Kerberos of being at fault; the 
problem is down to the conventions used by HTTP to determine it needs to do 
with Kerberos. These must be sorted out *before* any exchanges take place on 
the wire.

I you have anything further to say, let's take this off-line. I'm sure we're 
boring the pants off www-talk.

Peter Lister                             Email: p.lister@cranfield.ac.uk
Computer Centre, Cranfield University    Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL UK        Fax: +44 234 750875
--- Go stick your head in a pig.  (R) Sirius Cybernetics Corporation ---