In a nutshell, the problem is the HTTP server saying to the client "I'm foo,
you must provide me with authentication for service foo". A malevolent server
can persuade the client that it is genuine, and plant false information or
obtain secret information in a query. The (reasonable) assumption of Kerberos
is that the client knows with which prinicpal it must mutually authenticate
*before* making the connection. Since the only information known beforehand is
the URL, we must map the URL to a Kerberos principal.
> [NOTE: Alice ignores any non-protocol ``WWW-Authenticate''
> information. In this case, she gets a ticket for & creates an
> authenticator for k4-http.bob_foo_com@FOO.COM.]
I think we're agreed that only the server name is relevant (we are
authenticating to the server, not the document). Current Kerberos practise
seems to be to use dots in the instance, which can be touch confusing, since
the instance is generally separated from the name with a dot, but it's
liveable with, and I'd be happier with dots than underscores. I also reckon
that "k4-" is redundant. So my preference in your example would be
"http.bob.foo.com@FOO.COM", where the instance is "bob.foo.com".
> I'm not familiar enough with HTTP to know what information the
> browser is ``allowed'' to get from the URL, but the browser needs to
> get the authentication identity from someplace other than the
> server. The advantage of using the URL is that it is already there and
> should contain all the necessary authencation identity information.
Hmm. Interesting point. The principal consists of three parts
The principal name is unique to the service. I suggest we use "http", the URL
type, but it doesn't matter as long as everyone agrees and we stick to one.
Protocol versions are irrelevant. Logically, the scheme extends to other URL
types, e.g. gopher,ftp. Anyone know what the URL/URN people feel about this?
Typical Kerberos apps (with exceptions, e.g Zephyr) obtain the server name via
a Hesiod service location entry (which we assume can be trusted), so the
client sees the actual machine name, not just the alias (unlike a WWW client,
unless it asks the dns for the reverse transalation of the IP address). The
instance is conventionally the name of the server machine, either the short
form or fully qualified domain name. At Cranfield, POP uses pop.xdm001; AFS
uses afs.pegasus.cranfield.ac.uk (the fully qualified cell name). My
preference is to use the URL server name verbatim as the instance, e.g.
http://www.cranfield.ac.uk/ => http.www.cranfield.ac.uk. This does mean that
if the same alias applies to several machines, their servers must all have the
identical srvtab. No big deal, though it makes changing the service key harder
in traditional Kerberos if it has to be done simultaneously on multiple
machines.
We have to hand the server name in the URL to Kerberos and leave it to Do The
Right Thing to work out the realm. Typically, a local (hence trusted) file
e.g. krb.realms (or Transarc's CellServDB) maps remote domain names to realm
(e.g. cranfield.ac.uk => PEGASUS.CRANFIELD.AC.UK, as is the case at
Cranfield). For the client to get a ticket, either the local server must be
capable of cross-realm authentication, or the user must have a principal in
the remote realm, but Kerberos should sort that out - all the client needs to
do is prompt for username/password when there's no ticket granting ticket yet
- probably the case for all realms other than the local realm, and those it
cross-authenticates with.
So I reckon the only info we need from the URL is just the server name, and
I'm sure we're allowed to extract that.
> Use of the URL means that the client, of course, needs to get the
> URL from a trusted source (widely available documentation, an HTML
> document acquired through a secure channel, etc.).
Would a trusted URN -> URL translations service satisfy this? Have the URN
guys considered this?
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 ---