[2342] in Kerberos
Re: Local password validation (was: kerberizing xlock)
daemon@ATHENA.MIT.EDU (Ravi Ganesan (301) 595-8439)
Thu Nov 5 14:34:57 1992
From: bf4grjc@socrates.MIT.EDU (Ravi Ganesan (301) 595-8439)
To: bjaspan@Athena.MIT.EDU (Barry Jaspan)
Date: Thu, 5 Nov 92 14:00:50 EST
Cc: kerberos@Athena.MIT.EDU
In-Reply-To: <9211051538.AA12053@portnoy.MIT.EDU>; from "Barry Jaspan" at Nov 5, 92 10:38 am
Barry,
> We have now come full circle. Notice that the subject line in this
> message contains "was: kerberizing xlock." This entire conversation
> began because people were discussing using Kerberos for local password
> authentication, when it was not designed for that purpose.
>
> With public workstations (like those you described, and those at MIT's
> Athena) the spoofability of public workstations is irrelevant.
> However, when people start talking about using Kerberos for xlock, it
> is clear that they *do* care about an imposter gaining access to a
> workstation (particularly given that another user's credentials are
> already available there). In that case, the spoofing issue becomes
> highly relevant.
>
> So now, I think, the point has been made and everyone understands the
> issues better. That is, after all, part of the purpose of this
> mailing list. :-)
>
As per my earlier note (perhaps sent only to you), I just want to re-emphasize
the ground realities of maintaining multiple 'systems' for network
authentication and host authentication - kerberos WILL end up being used for
both, and subtelities about which environment it was designed for (anonymous
workstations - MIT Athena) is nice to know, but is of little pracitcal
consequence.
I feel that getting a ticket and then getting a service ticket and using that
service - under the condition the service is on the same machine, is a
theoretically messy, but practically convenient solution. (To recap a
hyper-kludgy hyper-quick and hyper-dirty way of doing this would be to
replace login with a combination of a kinit, a chown on the ticket, and then
a quick rlogin into the same machine. Naturally in practice you would set
up a dummy server that does something trivial like retun a YES/No
repsonse to your login program.
Ravi
--
*******************************************************************************
Ravi Ganesan e-mail: ravi@socrates.bell-atl.com
IS SAS Corporate Network Planning v-mail: (301) 595-8439
Bell Atlantic Fax: (301) 595-1341
Note: If your e-mail reply to me bounces, try sending it explicitly to
ravi@socrates.bell-atl.com instead of using the 'reply' feature.
******************************************************************************
