home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.protocols.kerberos
- Path: sparky!uunet!stanford.edu!ATHENA.MIT.EDU!bjaspan
- From: bjaspan@ATHENA.MIT.EDU ("Barry Jaspan")
- Subject: Local password validation (was: kerberizing xlock)
- Message-ID: <9211051538.AA12053@portnoy.MIT.EDU>
- Sender: news@shelby.stanford.edu (USENET News System)
- Organization: Internet-USENET Gateway at Stanford University
- References: <9211050649.AA24026@Athena.MIT.EDU>
- Date: Thu, 5 Nov 1992 15:38:32 GMT
- Lines: 29
-
-
- Date: Wed, 04 Nov 92 22:44:07 -0800
- From: Greg Wohletz <greg@duke.cs.unlv.edu>
-
- In our environment ... I'm not particularly
- concerned if an imposter gains access to a workstation cpu since all
- he would not actually be able to do anything useful (nfs, pop, etc.
- all require kerberos authentication)
-
- **PRECISELY**
-
- 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. :-)
-
- Barry
-