[3499] in java-interest
Re: How java apps get krb tickets?
daemon@ATHENA.MIT.EDU (Drew Dean)
Tue Nov 14 21:12:55 1995
To: lsbart35@emmo.indy.cr.irs.gov
Cc: acain@snapple.ncsa.uiuc.edu, java-kerberos@lists.Stanford.EDU,
www-kerberos@lists.Stanford.EDU, java-interest@java.sun.com,
dwallach@CS.Princeton.EDU
Reply-To: ddean@CS.Princeton.EDU
In-Reply-To: Your message of "Tue, 14 Nov 1995 11:27:42 -0500 (EST)"
Date: Tue, 14 Nov 1995 15:30:11 -0500
From: Drew Dean <ddean@CS.Princeton.EDU>
From: "Larry S. Bartz" <lsbart35@emmo.indy.cr.irs.gov>
Subject: Re: How java apps get krb tickets?
Date: Tue, 14 Nov 1995 11:27:42 -0500 (EST)
> On Sat, 11 Nov 1995, Adam Cain wrote:
>
> > Date: Sat, 11 Nov 1995 13:52:55 -0600
> > From: Adam Cain <acain@snapple.ncsa.uiuc.edu>
> > 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.
From a user's point of view, I agree 100%. However, I think it would
be better for this to be built in to the browser, and not a Java
applet, to make it harder to spoof this dialog. (That is, this dialog
needs to be a trusted path to the authentication code.)
> 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.
I meant to reply to this message, but never got around to it. I think
I see a real problem with #1, at least for multi-user machines.
Forgive me for a lack of Kerberos knowledge, but if I recall
correctly, if I can login to your machine, and I have your TGT, then
Kerberos will authenticate me as you. If this is how life works, I
wouldn't let a Java applet get a TGT for me because anything a
Java applet learns it can leak, as the Java runtime system has _not_
been analyzed for covert channels (at least acccording to any
documents I've seen), and there are tons of them. It would take a lot
of work to build a Java-enabled browser, running on a multi-user OS,
that I'd trust to make a TGT available to an applet.
Drew Dean
<ddean@cs.princeton.edu>
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
