[7064] in Kerberos
Re: login.krb5 problem
daemon@ATHENA.MIT.EDU (Doug Engert)
Thu Apr 11 08:44:13 1996
Date: Thu, 11 Apr 1996 07:36:36 -0500
From: Doug Engert <DEEngert@anl.gov>
To: donn@u.washington.edu (Donn Cave)
Cc: kerberos@MIT.EDU
In-Reply-To: <donn-1004961009010001@xceed.cac.washington.edu>
Donn Cave writes:
> 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.
That was what I understood as well.
But you only want "login" at the local workstation accepting
passwords, NEVER from over the network. What you want to use there is
the Kerberized telnet or rlogin, with forwarded tickets as well.
> 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.
I strongly disagree. Yes you can make this happen!
If they want access to your systems, you can insist on Kerberized
access only. The bare minimum number of files on a workstation to do
this is: krb5.conf, kinit, krlogin. (klist and kdestroy would be
helpfull, but not nessesary.) They don't even have to be installed. A
user can set the KRB5_CONFIG environment variable to point to the
krb5.conf file, and run everything out of his home directory.
You can even use a forwarded K5 ticket to get a DCE context, and/or an
AFS token.
> 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,
This is a problem, but we are so close at the moment. I have a
modified WinQVT program that does K5, WRQ Reflections have a K5
Telnet, Cygnus and CyberSAFE must have products, you can build the MIT
Kerberos 5.5 on a PC. (The next version is better, and should work on
MAC as well.) But there are problems with all of these, either they
have all the Kerberos features, forwarding, encryption but have a
lousy terminal emulation, or good terminal emulation, but not all the
K5 features.
> and then there are X terminals and so forth
X is the big missing piece. X11R6 has some old K5 support, but needs
updating. The user-to-user K5 protocol is the key to this, and OSF/DCE
is implementing that too.
> In a few years, it may be a more attractive market for this kind of
> software, but for now even vaporware would be encouraging.
Are you willing to get involved, and condense that vaporware into
real software? Push those vendors, try the Kerberos code yourself.
>
> 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.
We too want DCE and DFS, and are using the DCE security server as the
KDC and running the MIT Kerberos clients. And with you help, the
vendors will be providing it with their systems. OSF has promised in
DCE 1.2.2 to have a kerberized rlogin which will interoperate with the
MIT version.
So it is coming. Don't give up now, it can be done.
Douglas E. Engert
Systems Programming
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(708) 252-5444
Internet: DEEngert@anl.gov
