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 13:31:57 --100
Message-id: <9403081225.AA02507@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: 4779

My apologies for trying to teach michael.shiplett@umich.edu or anyone else to 
suck eggs about Kerberos. Kerberos admins regularly have to explain to the 
inexperienced that, no, they haven't discovered a new loophole, so I tend to 
assume that all claims of loopholes are based on misunderstanding. The problem 
definitely lies with the HTTP Authentication protocol as stated, not with 
Kerberos. Mea culpa. Here follow my rambings on how I now understand the 
problem, and my favoured solutions.

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