[7065] in Kerberos
Re: login.krb5 problem
daemon@ATHENA.MIT.EDU (Doug Engert)
Thu Apr 11 09:10:09 1996
Date: Thu, 11 Apr 1996 08:00:50 -0500
From: Doug Engert <DEEngert@anl.gov>
To: joek@CyberSafe.com (Joe Kovara)
Cc: kerberos@MIT.EDU
In-Reply-To: <4ki7mg$kpj@kerby.ocsg.com>
Joe Kovara writes:
>
> 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...
I agree with you Joe, but I think we can come a lot closer to
completely solving the problem.
> 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).
There is a solution here as well. What you need is a terminal server
which requires you to authenticate via presenting the appropriate
ticket for its service. There is a catch-22 here, how can you get to
the KDC if the terminal server will not let you in?
The terminal server needs to allow SLIP or PPP connections to be made
only to the KDC, so you can authenticate, get your TGT, get a ticket
for the terminal server, and authenticate your self to the terminal
server. This require changes on the terminal server, and on the
terminal, i.e. Kerberos on the terminal, but is do-able.
The same approach could be used with dumb terminal servers and a
firewall. The terminal gets you to the firewall, and the firewall
lets you access only the KDC until you authenticate to the firewall.
When (not if) we get the the point of single sign-on at the workstation
or PC, using passwords, we will have infrastructure in place to be
able to effectively use the Kerberos preauthentication capabilities with
smart cards and other authentication devices. If we can't do it with
software, how can we ever do it with hardware.
Douglas E. Engert
Systems Programming
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(708) 252-5444
Internet: DEEngert@anl.gov
