[6182] in Kerberos
Re: Kerberos as alternative to NIS/Yellow Pages
daemon@ATHENA.MIT.EDU (gwz@geek.ocsg.com)
Wed Nov 8 14:59:47 1995
From: gwz@geek.ocsg.com
To: brian@nothing.ucsd.edu (Brian Kantor)
Cc: kerberos@MIT.EDU
In-Reply-To: Your message of "Wed, 08 Nov 1995 08:02:52 PST."
<199511081602.IAA23437@nothing.ucsd.edu>
Date: Wed, 08 Nov 1995 11:17:07 -0800
> >Is anyone out there using Kerberos as an alternative to NIS/Yellow Pages
> >(i.e. for centralised password management).
>
> We are.
>
> >One of my main concerns is that I understand that Kerberos uses it's own
> >way on encypting passwords on the server. This may be a problem for us,
> >as we have 10,000+ users with UNIX crypt()-based passwords, and we are
> >not able to reissue them with new passwords. Can Kerberos be set to use
> >standard UNIX password encryption (even at the cost of slightly lower
> >security)?
>
It's _possible_, but the cost is higher than you think, if certain conditions
are not met (see below).
> No, it can't, as I understand it. That is because Kerberos, in its
> current form, must use a type of encryption which is symmetrical - the
> encrypted data can be decrypted. Unix password crypt can't be decrypted
> in this way.
>
The first and second statements are false, the third is true. Kerberos
principal keys are derived from passwords by means of a (theoretically)
one-way
function and stored in the Kerberos database in that form. This is very
similar (in principal) to the transform done by crypt(3). Neither the
Kerberos nor the Unix plaintext passwords can be recovered from their
encrypted versions.
> What we did was to simply Trojan-Horse our login routines for a while -
> if the person's password was valid according to the old scheme, it
> invoked a hacked-up version of kdb-edit
I hope you mean kadmin, not kdb_edit -- these users weren't logging to the
KDC, were they?
> to insert that same password
> into the Kerberos database. Ditto the password-change routine. After
> we'd run that way for a while, we had most everybody's password in the
> Kerberos database and the exceptions are few enough that we handle them
> manually.
>
This would work OK (for Unix users -- what about all those networked Macs and
PCs?), as long as you were certain that none of your passwd files had been
compromised. It would be convenient if you could just import (with suitable
preprocessing) the Unix passwords directly into the Kerberos database, using
crypt instead of string_to_key(3) as the one-way function; unfortunately, this
would be _extremely_ dangerous if the passwords in question had been
previously stored in a standard /etc/passwd file or in NIS. To see why,
remember (all in V4, part in V5) of the KDC's response to an initial ticket
request is encrypted under principal's secret key, which in this case would be
the crypted password. But /etc/passwd in world-readable on every Unix system
with which I'm familiar, so anybody could know what that key is, and be able
to decrypt and steal TGTs all day long.
> >Also, do all applications which check the password file have to be modified,
>
> Yes. We made a subroutine which simply does the same as a 'kinit' but
> doesn't bother to write the ticket file to disk. That's how we validate
> the password. It's used inside of 'login' and other places where the
> password file used to be checked for the password.
>
I hope that your subroutine does a little more than kinit. Since you are
using Kerberos to control access to a machine, you need to check that the TGT
obtained is valid; the classic way to do this is to try to use it to get
another ticket (e.g., an rcmd/localhost or host/localhost ticket), the check
the validity of _that_ ticket by using the keytab. kinit doesn't need to do
this, since the TGT will be validated (or vice-versa) the first time the
principal tries to use it.
> NB: We still retain the password file entries to control login - if
> you're not in the password file, you can't log in, etc. We just don't
> check the contents of the password field in that entry any more, so the
> only code that changes in the various programs is the single place where
> the strcmp was done to check the encrypted password field - it's now a
> call to the Kerberized subroutine.
>
> - Brian
~ gwz
Glen Zorn Senior Scientist Voice: 206-883-8721
gwz@cybersafe.com CyberSAFE Corporation FAX: 206-883-6951
Since I was forced to write it by the alien parasite which attached itself to
my brain stem during my recent visit to an isolated area of Northern Arizona,
it could hardly be construed that this message would reflect either the
opinions or the policies of my employer.
