[7062] in Kerberos
Re: login.krb5 problem
daemon@ATHENA.MIT.EDU (Joe Kovara)
Thu Apr 11 06:08:41 1996
To: kerberos@MIT.EDU
Date: Thu, 11 Apr 1996 06:08:18 GMT
From: joek@CyberSafe.com (Joe Kovara)
donn@u.washington.edu (Donn Cave) in comp.protocols.kerberos wrote:
>[...] 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?
Hard question; short answer: No qualms. Moving the end-point to a PC
helps, but doesn't completely solve the problem. (We provide both
solutions.) But we can never completely solve the problem, so at what
point can we say we have satisfactorily solved the problem? Harder
question; longer answer...
Kerberos lives in a world populated by other security solutions, very
few of which come close to Kerberos in the level of security that they
provide. Extreme example: the greatest (non-technical) threats are
totally outside the scope or control Kerberos. Does this mean we
should put Kerberos only in those environments in which all other
security elements (e.g, physical security and employee checks) are
bullet-proof? I doubt it; most PC's would certainly fail the physical
security test.
The answer also depends on the reason a site is using Kerberos--or to
be more precise, using a solution that incorporates Kerberos. Those
reasons may or may not have anything to do with network security.
That may sound odd, but consider:
1) Kerberos can provide an effective single signon solution. However,
look at non-Kerberos single signon solutions in the market--most do
not provide anywhere near the level of security that a Kerberos-based
solution provides. People still buy other solutions, because security
is not at the top of their agenda. Even a Kerberos-based solution
usually requires additional components for some parts of the network
that are not as secure as a "pure" Kerberos environment.
2) Kerberos can provide a single point of administration for "network
users". When used in this manner, secure end-to-end authentication,
encryption, etc. (the benefits we usually associate with Kerberos)
take second seat. The number of people using Kerberos to authenticate
dial-in users on terminal servers is testimony to this; these people
obviously consider clear-text passwords over phone lines a risk they
can live with (and Kerberos is obviously a better solution than TACACS
or RADIUS for solving this problem).
Purists may view these applications as misuses of Kerberos, or that we
are reducing the security provided by Kerberos. I won't argue the
point; they can keep theirs in the box--I'm going to take mine out and
use it. At the end of the day, the relevant questions are: Did we
solve the problem? Did we improve security? If the answers are "yes"
(even if not perfect), then we have done something worthwhile. In the
case of a kerberized login, the answer is almost universally "yes".
Joe Kovara / Director of Engineering / CyberSafe Corp.
1605 NW Sammamish Road, Suite 310 / Issaquah, WA 98027
joek@cybersafe.com / 206-391-6000 (phone) / 206-391-0508 (fax)
