[7201] in Kerberos
Re: Kerberos and JAVA
daemon@ATHENA.MIT.EDU (Sam Hartman)
Thu May 2 17:00:44 1996
To: dennis.glatting@plaintalk.bellevue.wa.us
Cc: Sam Hartman <hartmans@MIT.EDU>, jwk3@acpub.duke.edu (Jay Kamm),
kerberos@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 02 May 1996 16:30:51 -0400
In-Reply-To: Dennis Glatting's message of Thu, 2 May 96 08:50:02 -0700
>>>>> "Dennis" == Dennis Glatting <dennisg@plaintalk.bellevue.wa.us> writes:
Dennis> From: Sam Hartman <hartmans@mit.edu>
Dennis> Date: 02 May 1996 11:32:58 -0400
>> >>>>> "Dennis" == Dennis Glatting <dennisg@plaintalk.bellevue.wa.us> writes:
>>
Dennis> With the potential of tens of thousand clients, how would
Dennis> you handle upgrades or bug fixes to the native code?
>>
>> The same way you handle upgrades to the native SSL code.
>>
Dennis> What is that?
Netscape and some other web browsers have support for a
public-key server authentication system called SSL. To upgrade it,
you upgrade your web browser.
>> Security is something that you don't want to be leaving up
>> to content providers, because without native security
>> code, you can't verify the authenticity and integrity of
>> any additional security code downloaded from a content
>> provider.
>>
Dennis> You do not want to leave it up to the client too. Many people
Dennis> use computers every day who are not knowledgeable of
Dennis> security matters, much less capable of upgrading their
Dennis> word processor. Should they be less secure because
Dennis> computer matters are not their forte?
No, but they will be less secure, no matter how you try and
avoid it. If a user is not trained in security-concious thinking,
they will likely not choose good passwords, will not think of
potential problems, and will be open to social attacks. Just as
consumers who are not concious of the ways they can be defrauded are
more open to various schemes that *appear at first glance* to profit
them.
Dennis> The authenticity of modules could be verified if the
Dennis> run-time system has a rudimentary method of doing so. For
Dennis> example, transfer of a module tagged "security thingy"
Dennis> would have to be accompanied by a MD5 checksum of the
Dennis> module signed by the provider, whose signature is signed
Dennis> by the Java god.
Without getting into specific issues involved in the design of
this scheme, you are basically admitting my point: you need security
hooks inside the native code on the user's computer for security to
work. 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> -dpg
