Michael C. Burns writes:
> .. I'm curious if anyone on this list
> has made modifications to NCSA's httpd to use AFS/Kerberos authentication
> and if they can share those changes.
What *kind* of authentication are you talking about when you say
"AFS/Kerberos authentication"?
There are two "obvious" schemes you *could* use. The first would be to
take the user's cleartext password using "Basic" authentication, and
then yourself, in the server, try to get a kerberos ticket using that
password. It does have one advantage (which is nothing to sneeze about):
it will work with every browser out there in the sun.
The bad thing about that approach is that you are now sending your
kerberos passwords out in the clear, available for any network sniffer
to grab. This definitely weakens the secrecy of kerberos. If you have
a significant population of users who might access your web server from
one or more shared (``public'') computing labs or sites, then you can
certainly expect serious problems every so often, from people sniffing
on the wire and stealing passwords.
The second "obvious" approach is to use what I believe is called
"Columbia University" kerberos (or CUkerb) authentication. The basic protocol
works this way: a client requests a protected page. The server
sends back "WWW-Authenticate: KerberosV4". The client retries
the request, but inserts two more fields, the first is
"AuthType: Kerberos", and the second reads
"Authorization: KerberosV4 who hex-encoded-kerberos-stuff".
The hex-encoded-kerberos-stuff includes a service ticket for
khttp.<host>@realm. If the server can successfully decode the service
ticket, it processes the request, and returns an extra field:
"WWW-Authenticate: KerberosV4 [more-kerberos-stuff] User who authenticated".
If the server invokes a cgi script (and this is where kerberos
authentication is most useful), it passes in these extra environment
variables: KERB4_USER, KERB4_INSTANCE, KERB4_REALM, and KERB4_PRINCIPAL.
The client should of course check the WWW-Authenticate field to verify
that the response came from the expected server.
This is not the world's greatest protocol. It produces very
confusing results when used with a browser that doesn't
understand kerberos authentication. There are also a number
of obvious active attacks that work against it. Nevertheless, it's
probably the most widely spread solution around at present,
and it definitely illustrates some of the more serious problems
with coming up with a good solution to the whole problem.
The most serious problem has nothing to do with the technical
issues, but rather, with client support. By far the most popular
browser, Netscape, doesn't work with this scheme at all. The
two browsers that do suport this scheme are Lynx and Mosaic
and even then, only on Unix workstations. The ugly claws of
ITAR also get involved in this, in that it's difficult for people
who have an interest in this kind of stuff, to readily share
code. This gives an interesting advantage to people in foreign
countries.
Having said all that,
I have seen and worked with an implementation of CUkerb for NCSA httpd
1.3. Some other people at the UofM were responsible for bringing it up
here - but I believe they just acquired code somewhere else and brought
it up here. I don't recommend this fix, primarily because NCSA 1.3 is
kind of a mess, the kerberos code consists of a series of patches onto
the messes, and because 1.3 is almost certainly not a good thing to run
on a secure web server.
At the UofM, we recently switched from using NCSA 1.3 to using
Apache. Apache is definitely *much* nicer. The version we
modified is StrongHold 1.3b4. You can find out more about
stronghold at http://www.us.apache-ssl.com/. I did the actual
modifications to apache, and the nifty thing is, that it only
takes one self-contained module (532 lines) to do the equivalent of
CUkerb. I would love to put it up for anonymous ftp, the only thing
is, ITAR scares me. I need to check out some minor code
ownership issues, but provided there are no surprises there,
I am very willing to provide source to the module, to anyone
who is willing to put it up for "free" public distribution
in the USA.
To find client side support, probably the easiest solution is
to ftp to ftp.psy.uq.oz.au, go to /pub/Crypto/SSL, and get
SSLapps. The Mosiac-2.7b2 that's in there (perhaps it's updated
now) should support kerberos authentication. You might as
well build it with SSL - actually, you can increase the security
of CUkerb server by only using it over "anonymous" SSL (the
session is encrypted, but not authenticated.) It is easy enough
to look at how the CUkerb logic is implemented in Mosaic, and do
the same thing to the libwww library that comes with Lynx.
Some other people here at the university are working on a real
cool something called "KLP", which looks like it could be a *much* better
solution than CUkerb. I'm sure they'll announce something once they
have something worth sharing with others.
-Marcus Watts
UM ITD PD&D Umich Systems Group
