Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Thu, 09 Nov 95 14:37:14 -0500
Received: from nora.stanford.edu
(nora.Stanford.EDU [36.95.0.209]) by
lists.Stanford.EDU (8.6.12/8.6.6) with SMTP id
LAA08101 for ; Thu, 9 Nov 1995 11:07:02 -0800
Date: 9 Nov 1995 11:05:02 -0700
From: "Sid Conklin"
To: "java-kerberos@lists.Stanford.EDU"
Errors-To: mail-errors@lists.Stanford.EDU
Message-Id: <199511091907.LAA08101@lists.Stanford.EDU>
Subject: Re: How it works?
Here are some quick comments.
>From earlier emails:
1) Java-Kerberos archives?
I'm new to list servers so I'll have to look into it but there has been
little traffic on this list.
2) How I've integrated Kerberos into Java?
I've built a dynamic link library on Solaris that includes the Kerberos V4
library and a glue C file, for munging data from C to Java. I then load the
library in Java and make native method calls. So far I have KInit and
KDestroy working and will soon have KList. The only hard part of all this was
exploring the unknow interfaces and munging the data.
3) How are we going to use this technology?
We want to do secure net look-ups and transactions in applets and
applications. So our first step was to prove we could manage tickets. Next,
we want to user sendauth and receiveauth inside of Java.
All provide more information soon, just no time today.
Sid Conklin
Stanford University
Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Thu, 09 Nov 95 14:37:48 -0500
Received: from nora.stanford.edu
(nora.Stanford.EDU [36.95.0.209]) by
lists.Stanford.EDU (8.6.12/8.6.6) with SMTP id
LAA08498 for ; Thu, 9 Nov 1995 11:23:47 -0800
Date: 9 Nov 1995 11:20:36 -0700
From: "Sid Conklin"
To: "Bjoern Kvande" ,
"java-kerberos@lists.Stanford.EDU"
Errors-To: mail-errors@lists.Stanford.EDU
Message-Id: <199511091923.LAA08498@lists.Stanford.EDU>
Subject: Re> Re: How would it work?
As long as the dynamic library is on the platform and the firewall in not in
the way, you can make calls from Java to C libraries via native methods. And
that is how I'm doing kerberos since it is a know API and the libraries exist
on all common platforms (UNIX, WindowsNT/95/3.1 and Macs).
See ya,
Sid Conklin
Stanford University
------ From: Bjoern Kvande, Thu, Nov 9, 1995 ------
This client has to do authentication and encryption using kerberos. As
you probably know, an applet can not call other programs/libraries on the
local computer.
Do I need to implement the kerberos libraries in Java, or can I use
native methods, or is this the same as calling library functions ??
Does anyone have a suggestion of how this would be done.
Cincerely,
Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Thu, 09 Nov 95 18:26:30 -0500
Received: from cygnus.com (cygnus.com
[140.174.1.1]) by lists.Stanford.EDU
(8.6.12/8.6.6) with ESMTP id PAA22282 for
; Thu, 9 Nov 1995 15:02:23 -0800
Received: from tweedledumber.cygnus.com
(tweedledumber.cygnus.com [192.80.44.2]) by
cygnus.com (8.6.12/8.6.9) with ESMTP id PAA27523;
Thu, 9 Nov 1995 15:01:53 -0800
Received: from localhost (eichin@localhost) by
tweedledumber.cygnus.com (8.6.4/8.6.4) id
SAA27616; Thu, 9 Nov 1995 18:01:22 -0500
Date: Thu, 9 Nov 1995 18:01:22 -0500
From: Mark Eichin
To: winans@aps.anl.gov
Cc: sid.conklin@nora.stanford.edu, kvande@cs.odu.edu,
java-kerberos@lists.Stanford.EDU
Errors-To: mail-errors@lists.Stanford.EDU
Message-Id: <199511092301.SAA27616@tweedledumber.cygnus.com>
In-reply-to: <9511092239.AA21217@phoebus> (winans@aps.anl.gov)
Subject: Re: Re> Re: How would it work?
> My specific needs are to have an encrypted connection. Doing kerberos and
> the DES in java will probably not be reasonable for this. I am keeping my
I recall that there is already a "jcrypt" package for java that has
DES and other encryption mechanisms implemented. Given that, kerberos
is just pushing some bits into UDP packets. (Well, and quad-checksum,
but there are *two* kerberos library ports to pure perl 4 (no C assist
or libraries or anything) which shows that it's feasible even in a
language without a 32 bit integer type...)
I'm just waiting for a useful multi-platform java release.
Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Thu, 09 Nov 95 19:00:55 -0500
Received: from nora.stanford.edu
(nora.Stanford.EDU [36.95.0.209]) by
lists.Stanford.EDU (8.6.12/8.6.6) with SMTP id
PAA23015 for ; Thu, 9 Nov 1995 15:28:31 -0800
Date: 9 Nov 1995 15:28:07 -0700
From: "Sid Conklin"
To: "Bjoern Kvande" ,
"java-kerberos@lists.Stanford.EDU" ,
"winans@aps.anl.gov"
Errors-To: mail-errors@lists.Stanford.EDU
Message-Id: <199511092328.PAA23015@lists.Stanford.EDU>
Subject: Re> Re: Re> Re: How would it work?
I took the tact that Kerberos is on most platforms with a well-know API,
therefore, I could use build dynamic libraries for each know platform and
make native methods calls from Java.
After pelling off the layers off Java, I realized that is how Java is
implemented. They've taken a core functions for each platform (e.g., add) and
written them in C(?) and built dynamic libraries. They then meld these
libraries to Java in a platform neutral way and bang you've platform
independence. If you check the low-level classes, like Math, you will notice
that all the methods are native calls.
So I'm going to follow there lead and not rewrite Kerberos in Java but rather
just interface them together. I plan on doing this for Kerberos V5 too.
Comments?
Sid Conklin
Stanford University
------ From: winans@aps.anl.gov, Thu, Nov 9, 1995 ------
>Do I need to implement the kerberos libraries in Java, or can I use
>native methods, or is this the same as calling library functions ??
I would think that using a library is the same as a native method.
I would, however, like to see the stuff done in Java itself. It looks like
more than I care to deal with myself, but it would probably have the most
value.
>Does anyone have a suggestion of how this would be done.
My specific needs are to have an encrypted connection. Doing kerberos and
the DES in java will probably not be reasonable for this. I am keeping my
bits crossed... meanwhile a one-time-pad is doing things pretty well, but
it is rather annoying to dealing with the megabyte keys.
Have fun,
- --John Winans
Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Thu, 09 Nov 95 20:44:24 -0500
Received: from citi.umich.edu (citi.umich.edu
[141.211.128.16]) by lists.Stanford.EDU
(8.6.12/8.6.6) with SMTP id RAA28566 for
; Thu, 9 Nov 1995 17:29:07 -0800
Received: from orpheus.citi.umich.edu by
citi.umich.edu for sid.conklin@nora.stanford.edu
kvande@cs.odu.edu
java-kerberos@lists.Stanford.EDU
winans@aps.anl.gov with SMTP; Thu, 09 Nov 95 20:28:01 -0500
Date: Thu, 09 Nov 95 20:28:00 -0500
From: David R Richardson
To: "Sid Conklin"
Cc: "Bjoern Kvande" ,
"java-kerberos@lists.Stanford.EDU" ,
"winans@aps.anl.gov"
Errors-To: mail-errors@lists.stanford.edu
Message-Id: <199511100129.RAA28566@lists.Stanford.EDU>
Subject: Re: How would it work?
In-reply-to: Your message of 09 Nov 95 15:28:07 -0700.
<199511092328.PAA23015@lists.Stanford.EDU>
This tack sounds like a good way to get the Kerberos functionality --
quickly -- on any platform that can run full java "applications," but
not on platforms that run java "applets." Unfortunately, I think the
latter, which includes the Netscape Navigator, is the most
interesting. Applets aren't allowed to load native methods, so
netscape wouldn't be able to use Kerberos.
I don't know if there is anyway to bless native methods so that
applets can use them; maybe an administrator can install them somehow.
Otherwise, it seems that Kerberos would have to be implemented in
java.
David Richardson,
University of Michigan
I took the tact that Kerberos is on most platforms with a well-know API,
therefore, I could use build dynamic libraries for each know platform and
make native methods calls from Java.
After pelling off the layers off Java, I realized that is how Java
is implemented. They've taken a core functions for each platform
(e.g., add) and written them in C(?) and built dynamic libraries.
They then meld these libraries to Java in a platform neutral way
and bang you've platform independence. If you check the low-level
classes, like Math, you will notic e that all the methods are
native calls.
Comments?
Sid Conklin Stanford University
Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Fri, 10 Nov 95 01:12:21 -0500
Received: from nora.stanford.edu
(nora.Stanford.EDU [36.95.0.209]) by
lists.Stanford.EDU (8.6.12/8.6.6) with SMTP id
WAA08104 for ; Thu, 9 Nov 1995 22:02:07 -0800
Date: 9 Nov 1995 21:57:44 -0700
From: "Sid Conklin"
To: "David R Richardson"
Cc: "Bjoern Kvande" ,
"java-kerberos@lists.Stanford.EDU" ,
"winans@aps.anl.gov"
Errors-To: mail-errors@lists.stanford.edu
Message-Id: <199511100602.WAA08104@lists.Stanford.EDU>
Subject: Re> Re: How would it work?
Is this true? Is there any documentation to this? This sounds crazy! This
severely limits applets and I can't see why Netscape would want to only take
a subset of Java technology.
There are some Sun/Java people on this list do you know anything about this?
Sid Conklin
Stanford University
------ From: David R Richardson, Thu, Nov 9, 1995 ------
Applets aren't allowed to load native methods, so
netscape wouldn't be able to use Kerberos.
Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Fri, 10 Nov 95 12:28:44 -0500
Received: from phoebus (phoebus.aps.anl.gov
[164.54.8.167]) by lists.Stanford.EDU
(8.6.12/8.6.6) with SMTP id JAA05055 for
; Fri, 10 Nov 1995 09:08:54 -0800
Received: from xray by phoebus (5.x/SMI-SVR4)
id AA04534; Fri, 10 Nov 1995 11:08:43 -0600
Date: Fri, 10 Nov 95 11:08:42 -0600
From: winans@aps.anl.gov
To: mike@fionn.lbl.gov
Cc: eichin@cygnus.com, wrote@fionn.lbl.gov,
"java-kerberos@lists.Stanford.EDU"
Errors-To: mail-errors@lists.Stanford.EDU
Message-Id: <9511101708.AA04534@phoebus>
Subject: Re: How would it work?
In-Reply-To: Your message of "Fri, 10 Nov 95 07:53:09 PST."
<199511101553.HAA12631@fionn.lbl.gov>
Well, I realizerd bjust after my last post that I should have checked
archie first... the answer is that there is file called jcrypt-alpha0.1.tar.gz
on a few servers. I used the following:
Host ftp.univie.ac.at (193.170.56.40)
Last updated 13:22 19 Oct 1995
Location: /security/crypt/mirrors/ftp.dsi.unimi.it/code
FILE -r--r--r-- 186038 bytes 10:03 2
Sep 1995 jcrypt-alpha0.1.tar.gz
Location: /systems/unix/security/crypt/mirrors/ftp.dsi.unimi.it/code
FILE -r--r--r-- 186038 bytes 10:03 2
Sep 1995 jcrypt-alpha0.1.tar.gz
...and was less than thrilled to see that it uses native methods for
everything. The bright side (I guess) is that the source for all the nate
code is in the same tar file.
What I may do is change my OTP code to use the same API that this package
has so that I could buy into it in the future. It looks reasonable to me.
- ---
Sid, you might wanna take a peek at it. It looks like it has a bunch of
RSA stuff with it and the writer is trying to create a standard API for the
encryption routines.
Have fun,
- --John Winans
Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Sat, 11 Nov 95 15:00:36 -0500
Received: from newton.ncsa.uiuc.edu
(newton.ncsa.uiuc.edu [141.142.2.2]) by
lists.Stanford.EDU (8.6.12/8.6.6) with ESMTP id
LAA12816 for ;
Sat, 11 Nov 1995 11:48:48 -0800
Received: from snapple.ncsa.uiuc.edu
(snapple.ncsa.uiuc.edu [141.142.22.91]) by
newton.ncsa.uiuc.edu (8.6.11/8.6.12) with SMTP id
NAA20758 for ;
Sat, 11 Nov 1995 13:48:47 -0600
Received: by snapple.ncsa.uiuc.edu (4.1/NCSA-4.1)
id AA13731; Sat, 11 Nov 95 13:52:59 CST
Date: Sat, 11 Nov 1995 13:52:55 -0600
From: "Adam Cain"
To: java-kerberos@lists.Stanford.EDU
Errors-To: mail-errors@lists.Stanford.EDU
Message-Id: <9511111352.ZM13729@snapple.ncsa.uiuc.edu>
In-Reply-To: Roland Schemers
"Re: How would it work?" (Nov 10, 9:39pm)
References: <199511110539.VAA19482@slapshot.Eng.Sun.COM.>
X-Mailer: Z-Mail (3.2.0 06sep94)
Subject: How java apps get krb tickets?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
First, to address a previous question/concern:
The Kerberized Mosaic certainly does check the ticket cache before
it asks for a kerberos password. Obviously, we put in the capability
to klogin from within Mosaic so that things are easier to use, especially
for the somewhat kerberos-naive user. We feared that simply displaying
a message like "sorry, you must klogin to get a TGT" and then expecting
the user to go off into some other shell to do "kinit" might be considered
too laborious or cryptic by "normal" users. Yet, I can certainly appreciate
the spirit of keeping the password/TGT functions only in kinit/klog. I'll
discuss this also with people on the www-kerberos list and if enough people
object to this feature (really, we worked hard on this particular "bug"),
then we'll take it out.
But back to the orginal question of how the kerberized java app gets
its tickets. Let me summarize my understanding of the last couple notes
from Mark and Roland, with respect to this question (and again, please
forgive my relative unfamliarity with the details of java's security
mechanisms). It seems there are two basic approaches for this:
1. The java applet could get the user's kerberos password and then get a TGT.
From that point on, it gets its own tickets from the KDC, as needed.
2. The java applet could get tickets using the user's ticket cache. Assuming
the cache has a TGT, the applet can also get tickets from the KDC.
As Mark mentioned, #1 makes security people nervous, as it is quite risky and
somewhat contrary to the intent of kerberos.
As for #2, Roland points out that the applet probably can't (and should not
be able to) access the user's ticket cache.
I also wonder about the applet's abililty to cache tickets -- can it save to a
file, or must it keep everything it needs in memory? Also, what does the
user have to do in order to allow java applets to open their own network
connections (for getting a ticket from the KDC)?
Of these two approaches, I don't see one as being clearly superior to the
other. In either case, the user probably will (and should) have to make
an acknowledgement of trusting the applet before it can do anything with
kerberos. With #2, there would probably be some explicit mechanism for
granting the applet access to the user's ticket cache. For #1, the user is
putting significantly more trust in the applet (by giving it the kerberos
password), though there may be ease-of-use reasons for doing it this way.
Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Fri, 10 Nov 95 17:07:06 -0500
Received: from yucca.cs.odu.edu (yucca.cs.odu.edu
[128.82.4.6]) by lists.Stanford.EDU
(8.6.12/8.6.6) with ESMTP id NAA15309 for
; Fri, 10 Nov 1995 13:42:03 -0800
Received: from daffodil.cs.odu.edu
(kvande@daffodil.cs.odu.edu [128.82.6.134]) by
yucca.cs.odu.edu (8.6.4/8.6.4) with SMTP id
QAA06310 for ;
Fri, 10 Nov 1995 16:37:50 -0500
Date: Fri, 10 Nov 1995 16:36:29 -0500 (EST)
From: Bjoern Kvande
Cc: java-kerberos@lists.Stanford.EDU
Errors-To: mail-errors@lists.Stanford.EDU
Subject: Re: How would it work?
In-Reply-To: <199511102048.MAA19193@slapshot.Eng.Sun.COM.>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 10 Nov 1995, Roland Schemers wrote:
> The issue of native and non-native methods is an interresting one. On one
> hand using native methods saves time (its easier to wrap a thin java layer on
> top of an existing library) and performance, on the other hand it defeats
> the purpose of having Java be able to download applets to any Java client
> and run them.
There is a big need/demand for Kerberos encrytion and authentication for
client programs written in java. What do you need
java-applets for if you can't
do that :-)
I am writing a java client for a distributed privilige management system,
which needs to use kerberos authentication and encryption. I chose Java
because of its hardware independense, and its ease of distribution.
The hardware independense is kept intact, but the ease of distribution is
lost if you can't call any libraries on the local machine, and that
defeats most of my purpose, and a lot of other guys' purposes to I think.
It would be nice if there was a kerberos package for java written out
there, and downloaded whenever you needed it.
> Security is also an issue. Do you want your users downloading
> an app that pulls over Kerberos Java code that prompts for a password and/or
> is used for encryption? Seems like a security risk...
There has to be mutual authentication. If you need to give a password,
you need to know that the guy asking for it is not an imposer, and
of course the password should never be sent across the network.
> I was messing around with Java a few weeks back
and ported some of the Kerberos
> V5 DES code to Java as an exercise. I got encryption to work, but after
> running some tests I think I was only getting about 1000 8-byte block
> encryptions a second on a SPARC 20, which isn't very fast. Its probably
> fast enough for decrypting tickets though...
Have difficult, how much, and how timeconsuming is it to port this code
to java. I think its worth the effort, big time. They are talking about
optimizing the jvm later on. Do you think it will be fast enough ??
> roland
Thank you,
Bjorn J. Kvande
Secure Group
Old Dominion University
Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Fri, 10 Nov 95 18:35:30 -0500
Received: from cygnus.com (cygnus.com
[140.174.1.1]) by lists.Stanford.EDU
(8.6.12/8.6.6) with ESMTP id PAA22043 for
; Fri, 10 Nov 1995 15:21:43 -0800
Received: from tito.cygnus.com (tito.cygnus.com
[192.80.44.39]) by cygnus.com (8.6.12/8.6.9) with
SMTP id PAA13351; Fri, 10 Nov 1995 15:21:15 -0800
Received: by tito.cygnus.com (4.1/SMI-4.1)
id AA05746; Fri, 10 Nov 95 18:20:25 EST
Date: Fri, 10 Nov 95 18:20:25 EST
From: eichin@cygnus.com
To: schemers@Eng.Sun.COM
Cc: winans@aps.anl.gov, normanb@citi.umich.edu, sid.conklin@nora.stanford.edu,
kvande@cs.odu.edu, java-kerberos@lists.Stanford.EDU
Errors-To: mail-errors@lists.Stanford.EDU
Message-Id: <9511102320.AA05746@tito.cygnus.com>
In-Reply-To: <199511102048.MAA19193@slapshot.Eng.Sun.COM.> (message from
Roland Schemers on Fri, 10 Nov 1995 12:48:37 -0800 (PST))
Subject: Re: How would it work?
Certainly my intent was to provide something that the a user could get
working without any local administrative help; after all, it's more
likely to actually catch on that way.
As for the argument about giving passwords to the code -- not strictly
necessary. If the user is somewhere that already has a kerberos server
then they've probably got a local kinit to use to get tickets (really,
kerberos (CNS anyway) works on *far* more platforms than java) and
then the java code need only *use* those tickets. There is still some
exposure, but it is limited to attacks from that host, and is
time-limited. If they *don't* have a realm, then they're probably
getting their keys from my kdc in the first place... in which case it
is OK if my code sees the password too. Not a completely general
answer, but without signed applets, there isn't much you can do (and
with kerberos you could *do* signed applets, but you've got a
bootstrapping problem in any security system...)
I consider it a bug that the kerberized-Mosaic prompts for a password,
though it may be the case that it only does that if it can't already
find tickets, I haven't checked closely enough (anyone have Mosaic
building with Lesstif yet? there was once an incomplete Xaw-Mosaic,
but that never quite worked.) It is certainly an important kerberos
concept that the password *not* be repeatedly exposed.
(note that what I refer to below as an ss20 is actually an clone which
identifies itself on bootup as "SUNW,AXIL-311"...)
8000 bytes/second for DES in java? Not too bad, after all, tickets fit
in UDP packets... My *elisp* DES code gets 40 blocks (320 bytes) per
second on a 486DX at 40Mhz; about 105 (840 bytes) per second on an
SS20. Note that this is (1) byte compiled (2) had extensive hand
tuning done to it. [Elisp doesn't have 32 bit integers, typically it
can only handle 24 or sometimes 26, which is a severe handicap.]
My perl code does 1000 blocks in 23 seconds (SS20) so that's about
350 bytes per second. It hasn't had *any* speed work done on it; it's
just a port of Ferguson's DES code (fairly fast 32 bit code) that was
done for correctness, since I actually needed the kerberos part for
something else, and speed wasn't an issue. [you realize, of course,
that perl doesn't have 32 bit integers *either* -- it works in
doubles -- which wouldn't matter, except that the quad_cksum code
(long may it rot) *depends* on having that implicit mod 2^32...]
As for the availability of the perl kerberos code (and yes, it is V4
only, I'm *really* not looking forward to the ASN.1 stub generators
for V5) -- I haven't released mine due to ITAR hassles, but the second
port I mentioned is probably in the CPAN perl archives somewhere, and
was done by Eric Young (the Australian who did eBones and other DES
work.) I may have some details wrong there, but it should be enough
for you to find it. I expect (more from the Java TIFF code that was
mentioned a few months ago) that Java has totally different
bottlenecks than either perl or elisp. Having integer operations take
place in integers will surely help...
I'll probably do a Guile binding as well, scheme is a lot more real
than elisp -- but then again, scheme doesn't have any standardized bit
manipulation operations, so who knows how performance will be. There
is, in general, more hope for an optimizer for a high level language
than a C-like one, though DES is enough raw bit twiddling that high
level constraints may not make a difference.
_Mark_
Cygnus Support
Cygnus Network Security
http://www.cygnus.com/data/cns/
Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Sat, 11 Nov 95 01:07:31 -0500
Received: from mercury.Sun.COM (mercury.Sun.COM
[192.9.25.1]) by lists.Stanford.EDU
(8.6.12/8.6.6) with ESMTP id VAA09877 for
; Fri, 10 Nov 1995 21:43:54 -0800
Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM)
id VAA18123; Fri, 10 Nov 1995 21:43:23 -0800
Received: from updoc.Eng.Sun.COM
(updoc-39.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
id AA04301; Fri, 10 Nov 1995 21:43:19 -0800
Received: from slapshot.Eng.Sun.COM. by updoc.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id VAA18108; Fri, 10 Nov 1995 21:42:48 -0800
Received: (from schemers@localhost) by
slapshot.Eng.Sun.COM. (8.6.12/8.6.12) id
VAA19482; Fri, 10 Nov 1995 21:39:38 -0800
Date: Fri, 10 Nov 1995 21:39:37 -0800 (PST)
From: Roland Schemers
To: eichin@cygnus.com
Cc: schemers@Eng.Sun.COM, winans@aps.anl.gov, normanb@citi.umich.edu,
sid.conklin@nora.stanford.edu, kvande@cs.odu.edu,
java-kerberos@lists.Stanford.EDU
Errors-To: mail-errors@lists.Stanford.EDU
Message-Id: <199511110539.VAA19482@slapshot.Eng.Sun.COM.>
Subject: Re: How would it work?
In-Reply-To: <9511102320.AA05746@tito.cygnus.com>
from "eichin@cygnus.com" at Nov 10, 95 06:20:25 pm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
> As for the argument about giving passwords to the code -- not strictly
> necessary. If the user is somewhere that already has a kerberos server
> then they've probably got a local kinit to use to get tickets (really,
> kerberos (CNS anyway) works on *far* more platforms than java) and
> then the java code need only *use* those tickets.
I was talking about the case where you are only using "pure" Java code
that wouldn't have access to your ticket cache. Of course it is much easier
if you can use native methods. I also wouldn't allow any java code
downloaded from the net to have access to my ticket file, unless
you did have signed applets and a way to trust them...
> I consider it a bug that the kerberized-Mosaic prompts for a password,
> though it may be the case that it only does that if it can't already
> find tickets, I haven't checked closely enough (anyone have Mosaic
> building with Lesstif yet? there was once an incomplete Xaw-Mosaic,
> but that never quite worked.) It is certainly an important kerberos
> concept that the password *not* be repeatedly exposed.
I certainly agree there. I think its a bad idea for any app other then
login/kinit to prompt for passwords. We (SunSoft) are working on something
called PAM (Pluggable Authentication Modules) which will make it much
easier for vendors and ISVs to add new authentication mechanisms to
system entry apps without modifying them. Its looking like other vendors
will pick up PAM and hopefully it will be come widely available. I've already
written PAM modules for V5, DCE, and S/Key.
>
> 8000 bytes/second for DES in java? Not too bad, after all, tickets fit
> in UDP packets... My *elisp* DES code gets 40 blocks (320 bytes) per
Its not a problem for tickets. I was more concerned about large amounts
of data, although I haven't really been able to envison someone needing
to transfer large amounts of data. More like tickets and small chunks of
data, like on a simple form.
roland
Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Fri, 10 Nov 95 16:10:48 -0500
Received: from mercury.Sun.COM (mercury.Sun.COM
[192.9.25.1]) by lists.Stanford.EDU
(8.6.12/8.6.6) with ESMTP id MAA13745 for
; Fri, 10 Nov 1995 12:52:34 -0800
Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM)
id MAA25424; Fri, 10 Nov 1995 12:52:03 -0800
Received: from updoc.Eng.Sun.COM
(updoc-60.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
id AA08178; Fri, 10 Nov 1995 12:51:51 -0800
Received: from slapshot.Eng.Sun.COM. by updoc.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id MAA10093; Fri, 10 Nov 1995 12:51:41 -0800
Received: (from schemers@localhost) by
slapshot.Eng.Sun.COM. (8.6.12/8.6.12) id
MAA19193; Fri, 10 Nov 1995 12:48:37 -0800
Date: Fri, 10 Nov 1995 12:48:37 -0800 (PST)
From: Roland Schemers
To: winans@aps.anl.gov
Cc: normanb@citi.umich.edu, sid.conklin@nora.stanford.edu, kvande@cs.odu.edu,
java-kerberos@lists.Stanford.EDU
Errors-To: mail-errors@lists.Stanford.EDU
Message-Id: <199511102048.MAA19193@slapshot.Eng.Sun.COM.>
Subject: Re: How would it work?
In-Reply-To: <9511101445.AA01652@phoebus> from
"winans@aps.anl.gov" at Nov 10, 95 08:45:42 am
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
> I am with Sid on the questioning of the native methods. But at the same
> time, I am not interested in having to deal with the native stuff. Getting
> native DES for win95 would PROBABLY require a sane individual at the
> client's keyboard to install it (low probability there.) I like the idea
> of it comming in along with the rest of my applet stuff (if necessary.)
>
The issue of native and non-native methods is an interresting one. On one
hand using native methods saves time (its easier to wrap a thin java layer on
top of an existing library) and performance, on the other hand it defeats
the purpose of having Java be able to download applets to any Java client
and run them. Security is also an issue. Do you want your users downloading
an app that pulls over Kerberos Java code that prompts for a password and/or
is used for encryption? Seems like a security risk...
I was messing around with Java a few weeks back and ported some of the Kerberos
V5 DES code to Java as an exercise. I got encryption to work, but after
running some tests I think I was only getting about 1000 8-byte block
encryptions a second on a SPARC 20, which isn't very fast. Its probably
fast enough for decrypting tickets though...
roland
Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Tue, 14 Nov 95 11:41:10 -0500
Received: from interlock.ustreas.gov
(interlock.ustreas.gov [198.83.2.2]) by
lists.Stanford.EDU (8.7.1/8.7.1) with SMTP id
IAA16392; Tue, 14 Nov 1995 08:13:14 -0800 (PST)
Received: from emmo.indy.cr.irs.gov by
interlock.ustreas.gov with SMTP id AA24602
(InterLock SMTP Gateway 3.0); Tue, 14 Nov 1995 11:12:35 -0500
Received: (from lsbart35@localhost) by
emmo.indy.cr.irs.gov (8.6.9/8.6.9) id LAA13890; Tue, 14 Nov 1995 11:27:43 -0500
Date: Tue, 14 Nov 1995 11:27:42 -0500 (EST)
From: "Larry S. Bartz"
To: Adam Cain
Cc: java-kerberos@lists.Stanford.EDU, www-kerberos@lists.Stanford.EDU,
java-interest@java.sun.com
Subject: Re: How java apps get krb tickets?
In-Reply-To: <9511111352.ZM13729@snapple.ncsa.uiuc.edu>
Message-Id:
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 11 Nov 1995, Adam Cain wrote:
> Date: Sat, 11 Nov 1995 13:52:55 -0600
> From: Adam Cain
> To: java-kerberos@lists.Stanford.EDU
> Subject: How java apps get krb tickets?
>
> First, to address a previous question/concern:
>
> The Kerberized Mosaic certainly does check the ticket cache before
> it asks for a kerberos password. Obviously, we put in the capability
> to klogin from within Mosaic so that things are easier to use, especially
> for the somewhat kerberos-naive user. We feared that simply displaying
> a message like "sorry, you must klogin to get a TGT" and then expecting
> the user to go off into some other shell to do "kinit" might be considered
> too laborious or cryptic by "normal" users. Yet, I can certainly appreciate
> the spirit of keeping the password/TGT functions only in kinit/klog. I'll
> discuss this also with people on the www-kerberos list and if enough people
> object to this feature (really, we worked hard on this particular "bug"),
> then we'll take it out.
Take it out?
Don't you dare! Your initial notions on this subject are the correct ones.
We'll never be able to implement the Kerberized Web if we make it too
clunky for Joe Average User. A large part of the beauty of putting our
applications up on the Web (and kerberizing the authentication and
authorization) is that we are providing the potential for unprecedented
levels of wide scale integration; making the matrix (uh, the Web) look
like it is "all one thing" to our customers.
There is tremendous value in this integration. Anything which detracts
from it will naturally detract from its potential beauty (for us), and
its usability (for our customers).
Adam continued:
>
> But back to the orginal question of how the kerberized java app gets
> its tickets. Let me summarize my understanding of the last couple notes
> from Mark and Roland, with respect to this question (and again, please
> forgive my relative unfamliarity with the details of java's security
> mechanisms). It seems there are two basic approaches for this:
>
> 1. The java applet could get the user's kerberos password and then get a TGT.
> From that point on, it gets its own tickets from the KDC, as needed.
>
> 2. The java applet could get tickets using the user's ticket cache. Assuming
> the cache has a TGT, the applet can also get tickets from the KDC.
>
> As Mark mentioned, #1 makes security people nervous, as it is quite risky and
> somewhat contrary to the intent of kerberos.
>
> As for #2, Roland points out that the applet probably can't (and should not
> be able to) access the user's ticket cache.
Ken Arnold (addressing an unrelated issue for the java-interest@java.sun.com
list members) also drives Roland's point home. This point was
also described by David R Richardson for the
java-kerberos list last week. Because the applets are not allowed to load
native methods, #1 will be the only way to go.
So the java kerberos applet can't share its ticket cache with other apps?
Tough applets, I say; a small price to pay.
>
> I also wonder about the applet's abililty to
cache tickets -- can it save to a
> file, or must it keep everything it needs in memory? Also, what does the
> user have to do in order to allow java applets to open their own network
> connections (for getting a ticket from the KDC)?
I'd prefer to see the cache simply in applet-managed memory. This way,
it wouldn't conflict with any other cache and they'd go away
when the user terminates the browser session without requiring any
other explicit kdestroy action on their part.
>
>
> Of these two approaches, I don't see one as being clearly superior to the
> other. In either case, the user probably will (and should) have to make
> an acknowledgement of trusting the applet before it can do anything with
> kerberos. With #2, there would probably be some explicit mechanism for
> granting the applet access to the user's ticket cache. For #1, the user is
> putting significantly more trust in the applet (by giving it the kerberos
> password), though there may be ease-of-use reasons for doing it this way.
>
>
Yes, certainly the ease of use issue is important. Else, why would we
bother adapting our applications to the Web? Else, why would we bother
to use Kerberos to provide a "single login" access to multiple services?
- --
#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz | |
# lbartz@infostream.cr.irs.gov | Ooo, ooo, |
# | Ooo, ooo, oooooo! |
# | I've got a gnu attitude! |
# voice (317) 226-7060 | |
# FAX (317) 226-6378 | |
#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Wed, 15 Nov 95 15:09:34 -0500
Received: from citi.umich.edu (citi.umich.edu
[141.211.128.16]) by lists.Stanford.EDU
(8.7.1/8.7.1) with SMTP id LAA10593 for
; Wed, 15 Nov 1995 11:37:11 -0800 (PST)
Received: from citi.umich.edu by citi.umich.edu
for lsbart35@emmo.indy.cr.irs.gov
acain@snapple.ncsa.uiuc.edu
java-kerberos@lists.Stanford.EDU
www-kerberos@lists.Stanford.EDU
java-interest@java.sun.com mrm@puffin.eng.sun.com
with SMTP; Wed, 15 Nov 95 14:36:52 -0500
Date: Wed, 15 Nov 1995 14:36:51 -0500
From: David R Richardson
To: "Larry S. Bartz"
Cc: Adam Cain , java-kerberos@lists.stanford.edu,
www-kerberos@lists.stanford.edu, java-interest@java.sun.com,
mrm@puffin.eng.sun.com
Message-Id: <199511151937.LAA10593@lists.Stanford.EDU>
Subject: Re: How java apps get krb tickets?
X-Mailer: exmh version 1.6.1 5/23/95
In-reply-to: Your message of Tue, 14 Nov 95 11:27:42 -0500.
Mime-Version: 1.0
Content-Type: multipart/mixed ;
boundary="===_0_Wed_Nov_15_14:34:50_EST_1995"
This is a multipart MIME message.
- --===_0_Wed_Nov_15_14:34:50_EST_1995
Content-Type: text/plain; charset=us-ascii
A few more comments about kerberos access through java applets.
I think we still have some confusion about which resources applets will be
able to access; I've included a security summary by Marianne Mueller
of Sun and added her to this message in hope that she might be able
to clarify a few things.
> Date: Sat, 11 Nov 1995 13:52:55 -0600
> From: Adam Cain
> To: java-kerberos@lists.Stanford.EDU
> Subject: How java apps get krb tickets?
>
[information about Kerberized Mosaic and importance of single login/
ease of use elided]
>
> But back to the orginal question of how the kerberized java app gets
> its tickets. Let me summarize my understanding of the last couple notes
> from Mark and Roland, with respect to this question (and again, please
> forgive my relative unfamliarity with the details of java's security
> mechanisms). It seems there are two basic approaches for this:
>
> 1. The java applet could get the user's kerberos password and then
> get a TGT. From that point on, it gets its own tickets from the KDC,
> as needed.
>
> 2. The java applet could get tickets using the user's ticket cache.
> Assuming the cache has a TGT, the applet can also get tickets from
> the KDC.
>
> As Mark mentioned, #1 makes security people nervous, as it is quite risky
> and somewhat contrary to the intent of kerberos.
>
> As for #2, Roland points out that the applet probably can't (and should
> not be able to) access the user's ticket cache.
Ken Arnold (addressing an unrelated issue for the
java-interest@java.sun.com
list members) also drives Roland's point home. This point was
also described by David R Richardson for the
java-kerberos list last week. Because the applets are not allowed to load
native methods, #1 will be the only way to go.
While I think Adam has a good summary and the issue is probably still true,
access to local files is different from using native methods. The choice
of whether or not an applet can use the file system is somewhat browser
dependent, but access to native methods seems much less likely. In addition
to file access though, we also have to worry about socket connections to
hosts other than the orriginating web server (contacting the kdc and
potentially a third server if the endpoint is different from the web
server). These connections are almost as problematic as the file access.
But in short, I think we're more likely to be able to do file and
socket access than native method access.
It seems to me that we are either going to have to implement the whole
thing in java, plus the sort of certified class loader described by Marianne,
or hope that it is included in the browser or standard java distribution.
As a side note, while I've seen descriptions like the following of the
sorts of things java can and can't do, I haven't seen any descriptions
of how java applets can take advantage of browser security features.
For example, is it possible for java applets to utilize the
RSA certificates that a netscape user might have?
David Richardson
University of Michigan
- --===_0_Wed_Nov_15_14:34:50_EST_1995
Content-Type: message/rfc822
Content-Description: java security
From: mrm@puffin.Eng.Sun.COM (Marianne Mueller)
Newsgroups: comp.lang.java
Subject: Re: PRINCETON STUDENTS FIND HOLE IN INTERNET SECURITY SOFTWARE
Date: 9 Nov 1995 00:50:27 GMT
Organization: Sun Microsystems, Inc. Mt. View, Ca.
Lines: 180
Distribution: world
Message-ID: <47rj8k$6fd@handler.Eng.Sun.COM>
Reply-To: mrm@puffin.Eng.Sun.COM (Marianne Mueller)
NNTP-Posting-Host: puffin.eng.sun.com
Keywords: alpha3 hotjava security
Originator: mrm@puffin
The paper written by the two students at Princeton describes possible
attacks on the alpha3 HotJava browser, which have all been fixed in
JDK beta. Granted, until this week, the source code for JDK beta
wasn't available, so it's understandable that they analyzed the alpha3
source base.
We understand people need more information on the security model, and
we're taking time right now to document the security story more
rigorously. A security FAQ, an updated whitepaper, detailed user
documentation and detailed implementor's documentation are all being
worked on.
The Java security mechanisms include:
Java langugage mechanisms
* no pointers
* private interfaces, classes and methods
* class loader that enforces namespace divisions
* runtime byte code verifier that enforces language
type rules and name space divisions
Browser mechanisms, used by JDK beta appletviewer and by
Netscape Navigator 2.0beta
* AppletSecurity: extends java.lang.SecurityManager; strict
applet checks
* AppletClassLoader: extends java.lang.ClassLoader; strict
class loading
The goal for JDK beta is to enable browsers to run untrusted applets
in a trusted environment. The approach is to be conservative at
first, and to add functionality when it can be added securely.
So, JDK beta applets (and Netscape 2.0beta applets) may not do the
following.
1. Files:
Access Control Lists are greatly restricted in beta,
as compared to the situation in the alpha3 HotJava browser.
ACLs are initialized - only once - by the applet security
manager, and are not user configurable.
For a file not on the access control list, an applet cannot
- check for the existence of the file
- read the file
- write the file
- check the file type
- check if the file is a directory
- check the timestamp when the file was last modified
- check the file's size
- create a directory
- rename the file
- list the files in this file (as if it were a directory)
Applets cannot
- create a FileInputStream
- create a RandomAccessFile, either for reading or writing
- Open file descriptors
2. Sockets:
Applets cannot
- Create socket connections other than to its own host
- Create a socket factory
3. Loading/linking:
Applets cannot
- Create class loaders
- Access a package in the sun.* hierarchy
- Define a new class in the java.* hierarchy
- Link dynamic libraries using System.loadLibrary()
- Disable or override the AppletSecurityManager
4. Process control:
Applets cannot
- Define native methods
- Fork processes
- Manipulate threads or thread groups outside of the
applet's thread group
- Exit the virtual machine (eg the browser or the
appletviewer)
5. awt:
Applets cannot
- Create toplevel windows that don't have a warning banner
Applets can use network connections only to connect to the host they
originate from, to download files that are part of the applet's
implementation. Those files might be java bytecode class files, or
they might be input files used by the applet (GIF, JPEG, audio, other
data files.)
Taking a look at the specific attacks mentioned in the paper -
alpha3 HotJava JDK
---------------------- ---
1. socket accept() and applets cannot use
listen() aren't protected accept() and listen()
adequately, allowing a
browser to eavesdrop
2. applets can connect to applets cannot connect
the SMTP (mail) port on to the SMTP port on
some web server and use the computer the applet
that as a covert channel is visiting
3. InetAddress.getByName() applets cannot use
is public and does not InetAddress to inquire
check the security mode about hosts they are
before making DNS request not already allowed to
connect to
4. applets can use DNS to applets may not get the
create a covert channel internet address of any
host
5. Access Control Lists (ACLs) ACLs are greatly restricted
for reading and writing in JDK beta.
files are not strict enough Reading/writing files is
disabled for web browsers,
such as Netscape Navigator 2.0.
6. applets can use the System.getenv() is obsolete
System.getenv() method and is not part of the JDK
to gather information about API
the computer that it is
running on
7. applets can change the applets cannot read or alter
property manager database client properties
8. applets can change the The fields that hold the
HTTP and FTP proxy server HTTP and FTP proxy names are
private. The values are stored
in a property manager database
that an applet cannot read or
write.
It's very difficult, if not impossible, for a web browser to
completely prevent denial of service attacks. The JDK applet API
doesn't claim to prevent denial of service attacks. A "denial of
service" attack is where someone writes an applet whose goal is to
consume all available resources on your computer, forcing you to kill
the browser you're running. For example, someone could write an
applet that creates a million popup windows. The windows don't do
anything, but creating a million of them might use up all the virtual
memory on your computer and you'd have to kill the web browser to
reclaim the virtual memory.
Before people engage in too much wailing and gnashing of teeth about
how applets have been too severely restricted -
We want to enable applets to do interesting things, including making
socket connections, and reading and writing to the file system. One
way to enable that is to used a signed class loader. When a trusted
applet is loaded, then the applet could be granted permission to do
some of the things they are prevented from doing by default.
The goal is to ensure that untrusted applets can't steal or damage
information on a computer running a Java-enabled browser. Later, we
can allow trusted applets to do things that untrusted applets are not
allowed to do. Since an implementation bug in a trusted applet could
open a loophole that could be exploited by an untrusted applet, design
matters.
Marianne
Java Products Group
http://java.sun.com/people/mrm/
- --===_0_Wed_Nov_15_14:34:50_EST_1995--
Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Wed, 15 Nov 95 15:39:04 -0500
Received: from mercury.Sun.COM (mercury.Sun.COM
[192.9.25.1]) by lists.Stanford.EDU (8.7.1/8.7.1)
with SMTP id MAA15401; Wed, 15 Nov 1995 12:11:47 -0800 (PST)
Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM)
id MAA02485; Wed, 15 Nov 1995 12:11:04 -0800
Received: from puffin.Eng.Sun.COM by Eng.Sun.COM (5.x/SMI-5.3)
id AA17937; Wed, 15 Nov 1995 12:10:55 -0800
Received: by puffin.Eng.Sun.COM (5.x/SMI-SVR4)
id AA27526; Wed, 15 Nov 1995 12:10:54 -0800
Date: Wed, 15 Nov 1995 12:10:54 -0800
From: mrm@puffin.Eng.Sun.COM (Marianne Mueller)
To: normanb@citi.umich.edu
Cc: lsbart35@emmo.indy.cr.irs.gov, acain@snapple.ncsa.uiuc.edu,
java-kerberos@lists.Stanford.EDU, www-kerberos@lists.Stanford.EDU,
java-interest@java.Eng.Sun.COM
Message-Id: <9511152010.AA27526@puffin.Eng.Sun.COM>
In-Reply-To: David R Richardson's message of Wed,
15 Nov 1995 14:36:51 -0500 <199511151937.LAA23399@mercury.Sun.COM>
Subject: Re: How java apps get krb tickets?
In JDK 1.0, an applet cannot read or write files on a remote client,
so I don't think it can get a Kerberos ticket in that way. (By
client, I mean a Java-enabled browser running on a desktop computer.)
What you could do is implement some style of server-side persistent
data, which applets can access. I guess for Kerberos, this isn't any
good, since the whole point is that you don't want to expose the
Kerberos private-ticket traffic to IP.
Maybe the problem of bootstrapping Kerberos security is similar to the
key management conundrum. Short term, people might could get around
some of the key management problems by keeping a set of public keys on
their local hard disks, and not attempting to get those over IP.
Physical devices like smart cards might also gain popularity as a way
to store and share public keys.
Marianne
Java Products Group
Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Wed, 15 Nov 95 17:19:38 -0500
Received: from MIT.EDU
(SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by
lists.Stanford.EDU (8.7.1/8.7.1) with SMTP id
NAA22507; Wed, 15 Nov 1995 13:59:21 -0800 (PST)
Received: from HODGE-PODGE.MIT.EDU by MIT.EDU with SMTP
id AA19499; Wed, 15 Nov 95 16:58:20 EST
Received: by hodge-podge.MIT.EDU (5.57/4.7) id
AA01944; Wed, 15 Nov 95 16:58:58 -0500
Date: Wed, 15 Nov 1995 16:58:55 EST
From: Marc Horowitz
To: gwz@geek.ocsg.com
Cc: mrm@puffin.eng.sun.com (Marianne Mueller),
java-kerberos@lists.stanford.edu, www-kerberos@lists.stanford.edu,
java-interest@java.eng.sun.com
Message-Id: <9511152158.AA01944@hodge-podge.MIT.EDU>
Subject: Re: How java apps get krb tickets?
In-Reply-To: Your message of "Wed, 15 Nov 1995 13:30:27 PST."
<9511152130.AA20629@geek.ocsg.com.ocsg.com>
You all seem to be overlooking an obvious solution to this problem.
Implement a set of native methods which are *installed by the user*
which does safe accesses to the credential cache. This class would
probably implement a reasonable subset of the kerberos api, or even
better, the GSS API.
Then, implement a class on top of that which implements safe
operations based on kerberos, implemented in java, and also locally
installed, not downloaded. Make *only these methods* available to
applets. Acceptable methods here (to me, at least) would be
- instruct the browser to get a tgt if none was present (this would
have to be via a "well-known" interface to prevent trojan initial
ticket applets).
- get a service key for a service on an appropriate server host
(probably the same host as the web server). Restrictions on what
services are available are probably appropriate. This does
potentially open up a covert channel in the service names, but if you
want a covert channel, you can always encode whatever you want in
http. Examples of covert use would be whitespace, ordering, time
delays, etc. You don't need to put the data in the clear. IMHO, the
1.0 JDK precautions are overkill.
- Authenticate to a server.
- Perform certain authentic or confidential operations, such as
encrypting valid http requests, etc.
More specific operations could be added, locally, as more kerberized
applications become available. For instance, you could have a method
available to applets which would do a secure ftp transaction under
certain circumstances (to a configured set of servers, for instance).
By restricting these methods enough, it will be safe to make them
available to applets. As long as all access to sensitive data (the
tgt and other kerberos tickets) were done in trustable, auditable,
locally-installed C code, this would not present a security risk.
Marc
Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Wed, 15 Nov 95 18:23:25 -0500
Received: from nora.stanford.edu
(nora.Stanford.EDU [36.95.0.209]) by
lists.Stanford.EDU (8.7.1/8.7.1) with SMTP id
PAA28231; Wed, 15 Nov 1995 15:00:37 -0800 (PST)
Date: 15 Nov 1995 14:57:48 -0700
From: "Sid Conklin"
To: "Marianne Mueller" ,
"normanb@citi.umich.edu"
Cc: "acain@snapple.ncsa.uiuc.edu" ,
"java-interest@java.Eng.Sun.COM" ,
"java-kerberos@lists.Stanford.EDU" ,
"lsbart35@emmo.indy.cr.irs.gov" ,
"www-kerberos@lists.Stanford.EDU"
Message-Id: <199511152300.PAA28231@lists.Stanford.EDU>
Subject: Re> Re: How java apps get krb tickets?
Marianne,
We plan on Applets access the Kerberos functionality via dynamic libraries by
native method callouts. We have this working under Solaris using Java instead
of HotJava. Do we lose this mechanism when we write an applet to take
advantage of this inside a Netscape browser and/or HotJava browser?
Someone already mentioned that applets won't have the ability to make native
calls to dynamic libraries, is this true? And if so why?
Thanks,
Sid Conklin
Stanford University
------ From: Marianne Mueller, Wed, Nov 15, 1995 ------
In JDK 1.0, an applet cannot read or write files on a remote client,
so I don't think it can get a Kerberos ticket in that way. (By
client, I mean a Java-enabled browser running on a desktop computer.)
What you could do is implement some style of server-side persistent
data, which applets can access. I guess for Kerberos, this isn't any
good, since the whole point is that you don't want to expose the
Kerberos private-ticket traffic to IP.
Maybe the problem of bootstrapping Kerberos security is similar to the
key management conundrum. Short term, people might could get around
some of the key management problems by keeping a set of public keys on
their local hard disks, and not attempting to get those over IP.
Physical devices like smart cards might also gain popularity as a way
to store and share public keys.
Marianne
Java Products Group
Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Wed, 15 Nov 95 18:37:43 -0500
Received: from mercury.Sun.COM (mercury.Sun.COM
[192.9.25.1]) by lists.Stanford.EDU (8.7.1/8.7.1)
with SMTP id PAA28558; Wed, 15 Nov 1995 15:12:04 -0800 (PST)
Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM)
id PAA16302; Wed, 15 Nov 1995 15:11:32 -0800
Received: from updoc.Eng.Sun.COM
(updoc-65.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
id AA14645; Wed, 15 Nov 1995 15:11:26 -0800
Received: from slapshot.Eng.Sun.COM. by updoc.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
id PAA15745; Wed, 15 Nov 1995 15:11:09 -0800
Received: (from schemers@localhost) by
slapshot.Eng.Sun.COM. (8.6.12/8.6.12) id
PAA26849; Wed, 15 Nov 1995 15:07:18 -0800
Date: Wed, 15 Nov 1995 15:07:18 -0800
From: Roland Schemers
To: gwz@geek.ocsg.com, marc@MIT.EDU
Cc: mrm@puffin.Eng.Sun.COM, java-kerberos@lists.stanford.edu,
www-kerberos@lists.stanford.edu, java-interest@hormel.Eng.Sun.COM
Message-Id: <199511152307.PAA26849@slapshot.Eng.Sun.COM.>
Subject: Re: How java apps get krb tickets?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Md5: QIkHI4SSM3KCY32jNPwrbA==
>
> You all seem to be overlooking an obvious solution to this problem.
>
> Implement a set of native methods which are *installed by the user*
> which does safe accesses to the credential cache. This class would
> probably implement a reasonable subset of the kerberos api, or even
> better, the GSS API.
I don't think anyone is overlooking that solution, there are people
with different requirements. The more that can be done with "pure" Java
code the better. Given the current state of Java though (no signed classes,
etc), I think secure native methods are the only way to go at this point if you
want Kerberos and/or other forms of security not included in the base.
roland
Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Mon, 27 Nov 95 11:14:22 -0500
Received: from citi.umich.edu (citi.umich.edu
[141.211.128.16]) by lists.Stanford.EDU
(8.7.1/8.7.1) with SMTP id HAA21282 for
; Mon, 27 Nov 1995 07:43:02 -0800 (PST)
Received: from citi.umich.edu by citi.umich.edu
for java-kerberos@lists.stanford.edu with SMTP; Mon, 27 Nov 95 10:42:07 -0500
Date: Mon, 27 Nov 1995 10:42:05 -0500
From: David R Richardson
To: java-kerberos@lists.stanford.edu
Message-Id: <199511271543.HAA21282@lists.Stanford.EDU>
Subject: native methods with netscape
X-Mailer: exmh version 1.6.1 5/23/95
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
I saw this in comp.lang.java; it sounds like a way we could install either
C-based implementations of kerberos, or java-based implementations that
can access files and network connections. The main drawback, as we mentioned
before, is that it has to be independently installed.
David
- ------- Forwarded Message
Date: Wed, 22 Nov 1995 22:12:48 GMT
From: jdart@netcom.com (Jon Dart)
Sender: jdart@netcom.netcom.com
Subject: Native methods in Netscape: truth vs. rumor
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Newsgroups: comp.lang.java
Message-ID:
Lines: 62
After much effort, I have gotten native methods to work under Netscape
2.0b2 on Windows NT.
I am grateful for the information I have gotten from this newsgroup
and via email from a couple of its participants. But some of the
information out there is wrong, so I want to try to clear things up
a little.
First of all, Marianne Mueller from Sun has recently stated that beta
applets "cannot link dynamic libraries using System.loadLibrary()" or
"define native methods". The JAVA FAQ also states that "... for
security reasons you can only call external code from an applica-
tion. You cannot call external code from an applet. (Otherwise
all the security would go out the window.)".
These statements may lead some to believe that native methods are
disallowed entirely except in stand-alone Java applications whose
class files reside entirely on a local disk (I know I interpreted them
this way).
However, in fact, the restrictions on native methods in Netscape 2.0b2
are very similar to those in HotJava alpha 3. Namely, an applet
loaded over the network cannot *directly* call System.loadLibrary or
invoke native methods. However, you can create instances of classes
within your applet that use native methods, provided that the .class
files for these classes and the DLL that implements that native
methods are both resident on the client machine. The applet class
itself can be loaded from the network. For an illustration of this,
see Michael St. Hippolyte's MIDI applet.
I don't know if this security policy will change, but I hope not!
Many, many useful applications of Java are going to need to combine
applets with native methods. This capability is essential for the
work I am doing with Java.
Netscape uses CLASSPATH to find Java classes. It uses the PATH
environment variable to find DLLs that implement native methods. It
is not necessary to set LD_LIBRARY_PATH under Windows NT (you do need
to set it on unix).
It is also not necessary to install your own classes in the java/class
directory under the Netscape installation directory, or to place your
own DLLS in the java/bin directory (although you could do so). If
your CLASSPATH and PATH variables are set correctly, you can put your
class files and binaries anywhere.
Finally, there is a bug in Netscape that apparently prevents native
methods from working with applets that implement the Runnable
interface and create a new thread in their start() method (e.g. for
animation). The symptom is an unnamed exception at the point where
System.loadLibrary is called. Take out the thread creation code and
your native method class will load. Appletviewer does not have this
bug, also I do not know if it is present in the unix versions of
Netscape. Hopefully Netscape will fix it soon - I have reported it to
them.
- - --
Jon Dart
jdart@netcom.com
- - --
"Put the boogie beat in it." -- John Lee Hooker
- ------- End of Forwarded Message
Received: from lists.acs.ohio-state.edu by
citi.umich.edu for jej@CITI.UMICH.EDU
MJG@CITI.UMICH.EDU KWC@CITI.UMICH.EDU with SMTP; Mon, 12 Feb 96 20:10:24 -0500
Received: from host (localhost [127.0.0.1]) by
lists.acs.ohio-state.edu (8.6.11/8.6.11) with
SMTP id UAA18968; Mon, 12 Feb 1996 20:09:45 -0500
Received: from postbox.acs.ohio-state.edu
(postbox.acs.ohio-state.edu [128.146.214.20]) by
lists.acs.ohio-state.edu (8.6.11/8.6.11) with
ESMTP id UAA18925; Mon, 12 Feb 1996 20:08:58 -0500
Received: from sanfilip2.arms.ohio-state.edu by
postbox.acs.ohio-state.edu (8.6.9/5.901231)
id UAA15274; Mon, 12 Feb 1996 20:08:59 -0500
Date: Mon, 12 Feb 1996 20:08:50 -0500
From: Tom Sanfilippo
Sender: owner-btjp@lists.acs.ohio-state.edu
To: btjp@lists.acs.ohio-state.edu, ba2develop@lists.acs.ohio-state.edu
Message-Id: <311FE4A2.72A9@osu.edu>
Reply-To: btjp@lists.acs.ohio-state.edu
Subject: [Fwd: Re: Native method support in 2.0 ?]
MIME-Version: 1.0
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Mailer: Mozilla 2.0 (Win95; I)
X-Listprocessor-Version: 7.2 -- ListProcessor by CREN
Path: secnews.netscape.com!rls@netscape.com
From: Tom Sanfilippo
Newsgroups: netscape.devs-java
Subject: Re: Native method support in 2.0 ?
Date: Mon, 12 Feb 1996 19:47:33 -0500
Organization: The Ohio State University
Lines: 28
Message-ID: <311FDFA5.6D50@osu.edu>
References: <311F7A43.44DD@vogon.rain.com>
NNTP-Posting-Host: sanfilip2.arms.ohio-state.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.0 (Win95; I)
Philip Peake wrote:
>
> Are native methods supported in Netscape 2.0 ?
>
> I seem to remember some discussion earlier about
> it not being avialable - at least in beta versions.
>
> Philip
Native methods seem to work in Navigator 2.0 on NT. I was so happy
about this I almost broke into tears. To use native methods via an
applet the applet must load the class with the native methods from
a local CLASSPATH directory. Additionally, the dll library for the
native method class needs to be in the Navigator\Programs\java\bin
subdirectory with the awt dll and others. Finally, the nsjava32.dll
library implements the functions such as "makeJavaString", etc.
Linking your native library dll with javai.lib does not work. You
need to link with the import library for nsjava32.dll instead.
Netscape does not seam to ship this. You can construct one by using
dumpbin, link, and a lot of editing. But it works if you do this.
Long term Netscape needs to conform to the javai.dll exports list
and module name; likewise the Java SDK needs to ship a version of
javai.lib for javai.dll. The javai.lib in the Java SDK 1.0 seems
to be a static library only.
Tom Sanfilippo
The Ohio State University
sanfilippo.1@osu.edu
Received: from lists.Stanford.EDU by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu with SMTP; Mon, 12 Feb 96 16:08:27 -0500
Received: (from daemon@localhost) by
lists.Stanford.EDU (8.7.1/8.7.1) id MAA19208 for
java-kerberos-out551918; Mon, 12 Feb 1996 12:41:05 -0800 (PST)
Received: from nora.stanford.edu
(nora.Stanford.EDU [36.95.0.209]) by
lists.Stanford.EDU (8.7.1/8.7.1) with SMTP id
MAA19203 for ;
Mon, 12 Feb 1996 12:41:03 -0800 (PST)
Date: 12 Feb 1996 12:41:58 -0800
From: "Sid Conklin"
Sender: owner-java-kerberos@lists.Stanford.EDU
To: "java-kerberos@lists.stanford.edu"
Message-Id: <199602122041.MAA19203@lists.Stanford.EDU>
Subject: Java Encryption
Precedence: bulk
Check out URL for Java based encryption.
http://www.cs.utexas.edu/users/achou/JCrypt/packages.html
Sid Conklin
Stanford University
Received: from truelies.rs.itd.umich.edu by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu andros@citi.umich.edu with
SMTP; Wed, 06 Mar 96 14:21:45 -0500
Received: by truelies.rs.itd.umich.edu (8.7.4/2.2)
with X.500 id OAA19423; Wed, 6 Mar 1996 14:21:35 -0500 (EST)
Received: by truelies.rs.itd.umich.edu (8.7.4/2.2)
with X.500 id OAA19369; Wed, 6 Mar 1996 14:21:23 -0500 (EST)
Received: from tron.rs.itd.umich.edu by truelies.rs.itd.umich.edu (8.7.4/2.2)
with ESMTP id OAA19353; Wed, 6 Mar 1996 14:21:22 -0500 (EST)
Received: from bprichard.uis.itd.umich.edu by tron.rs.itd.umich.edu (8.7.1/2.2)
id OAA19464; Wed, 6 Mar 1996 14:21:21 -0500 (EST)
Date: Wed, 6 Mar 1996 14:23:56 +0000
From: "Bret Prichard"
To: web.security@umich.edu
Message-Id: <199603061921.OAA19464@tron.rs.itd.umich.edu>
Comments: Authenticated sender is
Subject: Re: More Java security
Priority: normal
X-mailer: Pegasus Mail for Windows (v2.23)
The URL below talks about a new patch for Netscape 2.0 that addresses the
Java problems:
http://home.netscape.com/newsref/std/java_security.html
- - Bret
=-=-=-=-=-=-=-=-=-=-=-Bret Prichard=-=-=-=-=-=-=-=-=-=-=-=
University of Michigan --- Information Technology Division
Web/Gopher Development Team
http://www-personal.umich.edu/~bretp/
=-=(313) 764-8151=-=-=-=-=-=-=-=-=-=-=-=bretp@umich.edu=-=
Received: from redheat.rs.itd.umich.edu by
citi.umich.edu for normanb@citi.umich.edu
mjg@citi.umich.edu andros@citi.umich.edu with
SMTP; Fri, 15 Mar 96 11:58:08 -0500
Received: by redheat.rs.itd.umich.edu (8.7.4/2.2)
with X.500 id LAA01450; Fri, 15 Mar 1996 11:57:38 -0500 (EST)
Received: by redheat.rs.itd.umich.edu (8.7.4/2.2)
with X.500 id LAA01377; Fri, 15 Mar 1996 11:57:17 -0500 (EST)
Received: from tempest.rs.itd.umich.edu by redheat.rs.itd.umich.edu (8.7.4/2.2)
with ESMTP id LAA01352; Fri, 15 Mar 1996 11:57:12 -0500 (EST)
Received: from bprichard.uis.itd.umich.edu by
tempest.rs.itd.umich.edu (8.7.1/2.2)
id LAA28461; Fri, 15 Mar 1996 11:57:11 -0500 (EST)
Date: Fri, 15 Mar 1996 11:57:08 +0000
From: "Bret Prichard"
To: web.security@umich.edu
Message-Id: <199603151657.LAA28461@tempest.rs.itd.umich.edu>
Comments: Authenticated sender is
Subject: Java Security Problems
Reply-to: bretp@umich.edu
Priority: normal
X-mailer: Pegasus Mail for Windows (v2.23)
I found this article at an online magazine called 'Java World' and
thought since it was something that has been discussed alot of late I
would forward it here.. it has links to explinations of the problem
from various sources and what they are doing to correct it..
Address of this article:
http://www.javaworld.com/jw-03-1996/jw-03-newsbriefs.html
- - Bret
==========================================
Java-related security bug being patched
Researchers at Princeton University recently discovered that due to a
problem that lies partially in a loophole in the Internet Domain Name
Server (DNS) system, and partially in the Java security manager, a
malicious applet could attack any host on the Internet. Netscape is
making available a patched version of the Java classes used in
Netscape Navigator 2.0; JavaSoft says its patch for the JDK will be
available shortly.
See the recent news article in JavaWorld magazine's sister IDG
publication, MacWorld Online:
http://www.macworld.com/exclusive/javsec.html
See also the Princeton researchers' report at
http://www.cs.princeton.edu/~ddean/java
And see Sun's description of the problem at
http://java.sun.com/sfaq/dns.html
=-=-=-=-=-=-=-=-=-=-=-Bret Prichard=-=-=-=-=-=-=-=-=-=-=-=
University of Michigan --- Information Technology Division
Web/Gopher Development Team
http://www-personal.umich.edu/~bretp/
=-=(313) 764-8151=-=-=-=-=-=-=-=-=-=-=-=bretp@umich.edu=-=
Received: from judgmentday.rs.itd.umich.edu by
citi.umich.edu for drh@citi.umich.edu
jjm@citi.umich.edu mjg@citi.umich.edu with SMTP; Mon, 25 Mar 96 09:34:57 -0500
Received: by judgmentday.rs.itd.umich.edu (8.7.4/2.2)
with X.500 id JAA22864; Mon, 25 Mar 1996 09:34:55 -0500 (EST)
Received: by judgmentday.rs.itd.umich.edu (8.7.4/2.2)
with X.500 id JAA22795; Mon, 25 Mar 1996 09:34:39 -0500 (EST)
Received: from madidinou.ifs.umich.edu by
judgmentday.rs.itd.umich.edu (8.7.4/2.2)
with ESMTP id JAA22790; Mon, 25 Mar 1996 09:34:39 -0500 (EST)
Received: from localhost by madidinou.ifs.umich.edu (8.7.5/2.2)
id JAA15157; Mon, 25 Mar 1996 09:34:38 -0500 (EST)
Date: Mon, 25 Mar 1996 09:34:35 -0500
From: Sarr Blumson
To: umich-systems@umich.edu
Message-Id: <199603251434.JAA15157@madidinou.ifs.umich.edu>
X-Mailer: exmh version 1.6.1 5/23/95
Subject: GSSAPI for Java
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
And therefore for Netscape?
- ------- Forwarded Message
Date: Mon, 25 Mar 1996 09:20:51 -0500
From: Sushila R Subramanian
To: backrow@citi.umich.edu, dlk@eecs.umich.edu
Message-Id: <199603251420.JAA06948@ginger.cmf.nrl.navy.mil>
Subject: ANNOUNCE: Generic Security Services Package for Java
- - ------- Forwarded Message
From: tfraser@cs.uiuc.edu (tim fraser)
Newsgroups: comp.lang.java
Date: 25 Mar 1996 07:12:53 GMT
Organization: University of Illinois at Urbana-Champaign
The University of Illinois Systems Software Research Group has
released the first alpha version of their JGSS java package. This
package provides Java programs access to the Generic Security Service API
defined in RFC-1508 and implemented by MIT's Kerberos system. The package
is available for download for personal, educational, and research use at:
http://choices.cs.uiuc.edu/Security/JGSS/jgss.html
- - ------- End of Forwarded Message
- ------- End of Forwarded Message
Received: from scrooge.ifs.umich.edu by
citi.umich.edu for mjg@citi.umich.edu with SMTP; Wed, 10 Apr 96 13:48:42 -0400
Received: by scrooge.ifs.umich.edu (AIX 3.2/UCB 5.64/4.03)
id AA10328; Wed, 10 Apr 1996 13:48:43 -0400
Date: Wed, 10 Apr 1996 13:48:43 -0400
From: mjg@citi.umich.edu (Mike Graham)
To: mjg@citi.umich.edu
Message-Id: <9604101748.AA10328@scrooge.ifs.umich.edu>
Reply-To: Mike.Graham@umich.edu
Subject: ANNOUNCE: New v0.2a JGSS package with
kerberized applet support. [comp.protocols.kerberos #6305]
- ------ Forwarded Article
- ------ From tinq@cs.uiuc.edu (Tin Qian)
Now try kerberized applets directly from netscape!!
The University of Illinois Systems Software Research Group has
released the second alpha version of their JGSS java package. This new
package enhances the v0.1a version with support for applets' access to
JGSS classes. It has been tested with netscape 2.0 and appletviwer in
JDK 1.01. The package is available for download for personal, educational,
and research use at:
http://choices.cs.uiuc.edu/Security/JGSS/jgss.html