[4] in WWW Security List Archive
[hallam@dxal18.cern.ch: Re: Kerberos authentication for X-Mosaic 2.4 and NCSA HTTPD]
daemon@ATHENA.MIT.EDU (yandros@MIT.EDU)
Fri Aug 12 14:43:26 1994
From: yandros@MIT.EDU
Date: Fri, 12 Aug 1994 14:43:23 +0500
To: www-security.discuss@charon.LOCAL
From: hallam@dxal18.cern.ch
To: www-security@ns1.rutgers.edu, Lei_Tang@gs59.sp.cs.cmu.edu
Cc: hallam@dxal18.cern.ch
Subject: Re: Kerberos authentication for X-Mosaic 2.4 and NCSA HTTPD
In-Reply-To: Your message of "Mon, 08 Aug 94 09:52:05 EDT."
<1705.776353925@GS59.SP.CS.CMU.EDU>
Date: Fri, 12 Aug 94 12:21:53 +0200
X-Mts: smtp
Hi,
>If the xmosaic cleint and the httpd server are in the same realm.
>KerberosV4 can handle the mutual authentication very well.
>If the xmosaic client and the httpd server are in different realms,
>KerverosV4 can handle the mutual authentication only if the
>two kerberos servers of the two different realms know each other's secret key.
I think this demonstrates precisely why we need different authentication
systems. Public key is slow. Kerberos is fast but requires a trusted
intermediary. For many security scenarios this is OK. Especially if you
have already set up kerberos.
> By the way, do you think encode kerberos ticket into the MIME head is a good
>method? Why not do some kerberos authentication before the client and the server
>sends information with each other. If you modify the httpd server,
>I think using cern_httpd codes will save you a lot of work.
If anyone wants to work on security, the Shen mods to libwww would be the
things to take. We will be folding them into the common release fairly soon,
they need to work on little endian machines first.
The idea is to modularise the library so that a person with a proverbial
good idea can easily fing a hook to fasten it to - in any area. So a person
with a new transformer - encryption, compression, image handling, formatting,
etc can just call a routine to slot something in.
Of course we are not there now but that is where we want to be :-)
Phill.
