[7060] in Kerberos
Re: login.krb5 problem
daemon@ATHENA.MIT.EDU (Richard Basch)
Thu Apr 11 01:12:16 1996
Date: Thu, 11 Apr 1996 00:58:08 -0400
To: donn@u.washington.edu (Donn Cave)
Cc: kerberos@MIT.EDU
In-Reply-To: <donn-1004961009010001@xceed.cac.washington.edu>
From: "Richard Basch" <basch@lehman.com>
At Lehman, we face a similar problem, with a twist. We want to create a
single authentication system, but the education cost and inconvenience
that would be imposed on our users by adding another "password" prompt
will be met with resistance. I am hoping we can do a moderate amount of
user education to improve their use of screen locks and protecting their
passwords. Other than that, I am integrating Kerberos into the screen
locks and the login so as to minimize user-visibility as we switch over.
Also, by reducing the number of passwords one has to type, there is less
chance that they will poorly utilize them (such as over the network).
Additionally, by making the system easier to use with fewer passwords,
and hiding the underlying authentication system, it may be easier to
raise security awareness by addressing it at the source -- improving the
user's conscious protection of the data that they manage.
Personally, I'd rather make a system usable without sacrificing security
and obtain buy-in from the users rather than trying to educate users who
are hating the system. After all, the purpose of technology is to solve
people's problems, not to have people spending their time addressing the
technology's problems.
-Richard Basch
On Wed, 10-April-1996, "Donn Cave" wrote to "kerberos@MIT.EDU" saying:
> Taking the opposite tack, I'm interested in people's perspectives
> on whether this is a good idea, or a bad idea.
>
> If I understand Tom right, he's asking "login" to get and save Kerberos
> credentials, like "kinit" would.
>
> I think one of my colleagues here did something like that for DCE,
> before he left, and I expect that this concept will be appealing to
> my group. We're survivors from the mainframe era, still running
> centralized computer services for the campus, and this central
> facility is all we control and support.
>
> In theory, the ideal Kerberos environment obviously reaches outside
> our domain, to desktop workstations, terminal servers and so forth,
> and the kinit authentication step belongs out there, rather than on
> our central hosts. Unfortunately, though, in practice we can't make
> that happen, since we have no control over and little involvement
> with this area. And even if we did have some influence, it's hard to
> be optimistic about the software support for it - it does not seem
> that DCE/K5-ized environment (kinit), and applications - web browsers,
> mail clients, ftp, etc. - are particularly abundant for even the most
> common PC platforms, and then there are X terminals and so forth
> In a few years, it may be a more attractive market for this kind of
> software, but for now even vaporware would be encouraging.
>
> Yet we want DCE, mainly for DFS at the moment, and we can make
> an internally kerberized environment on our central hosts. So that's
> what I suppose we're likely to do, make the best of a ``single-login''
> environment on our UNIX computers. My concern is that we could
> undermine what was already the really tricky part. By making the
> the best of this essentially inappropriate model - hiding a kinit in
> our login, stripping the Kerberos warnings out and so forth, we'd
> sugar-coat its inadequacies and actually obscure the role that their
> own PC Kerberos environment could play, if they could find one.
>
> So, what do you think - any qualms about putting kinit into login?
>
> Donn Cave, University Computing Services, University of Washington
> donn@u.washington.edu
--
Richard Basch
Sr. Developer/Analyst URL: http://web.mit.edu/basch/www/home.html
Lehman Brothers, Inc. Email: basch@lehman.com, basch@mit.edu
101 Hudson St., 33rd Floor Fax: +1-201-524-5828
Jersey City, NJ 07302-3988 Voice: +1-201-524-5049
