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