[7207] in Kerberos

home help back first fref pref prev next nref lref last post

Re: Kerberos and JAVA

daemon@ATHENA.MIT.EDU (Sam Hartman)
Fri May 3 02:22:45 1996

To: dennis.glatting@Cybersafe.com
Cc: Sam Hartman <hartmans@MIT.EDU>, dennis.glatting@plaintalk.bellevue.wa.us,
        jwk3@acpub.duke.edu (Jay Kamm), kerberos@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 03 May 1996 02:12:39 -0400
In-Reply-To: Dennis Glatting's message of Thu,  2 May 96 14:38:13 -0700

>>>>> "Dennis" == Dennis Glatting <dennisg@pinky.cybersafe.com> writes:

    Dennis> From: Sam Hartman <hartmans@MIT.EDU> Date: 02 May 1996
    Dennis> 16:30:51 -0400


    >> ...  I would prefer some sort of fully functional
    >> system--Kerberos within an organization large enough to justify
    >> it, some sort of public key system for consumers--than an over
    >> simplistic approach that allows me to download security-related
    >> class files.
    >> 

    Dennis> My thought is a minimalist thing -- like PGP -- used to
    Dennis> boot-load more sophisticated systems. Since the
    Dennis> boot-loader "verifies" the system, the system could be
    Dennis> cached in a privileged directory.

	
	I will assume your original proposal was for the purposes of
conversation, and not a complete design; it leaves a few issues open.
I will admit you could design reasonable hooks into Java or another
system to allow remote downloading of trusted code.

	I like my approach better because it doesn't trust some
central authority to "sign" Java security modeules.  More importantly,
it doesn't trust random content providers to establish security code.
I agree that a good consumer solution would provide an easy update
hook, but I see no reason why a local GSSAPI implementation couldn't
provide hooks to download new versions of itself.  (I personally would
never trust security code to automagically upgrade itself, but I am
not the average user.  It is reasonable for the average user to have
this option.)

	Another advantage to native support is the ability to use C
rather than Java to implement the encryption logic.

	However, this is an area where reasonable people can disagree;
both solutions can be done well.



    Dennis> -dpg



home help back first fref pref prev next nref lref last post