[7004] in Kerberos
Re: Two realms served by a single daemon
daemon@ATHENA.MIT.EDU (Sam Hartman)
Wed Apr 3 17:52:25 1996
To: Alexandre Khalil <iskandar@EESUN2.tamu.edu>
Cc: Sam Hartman <hartmans@MIT.EDU>, kerberos@MIT.EDU,
ee sysadmin
<root@EESUN2.tamu.edu>
From: Sam Hartman <hartmans@MIT.EDU>
Date: 03 Apr 1996 17:43:41 -0500
In-Reply-To: Alexandre Khalil's message of Wed, 3 Apr 1996 09:49:59 -0600 (CST)
Alexandre Khalil <iskandar@EESUN2.tamu.edu> writes:
>
> On 3 Apr 1996, Sam Hartman wrote:
>
> > iskandar@eesun1.tamu.edu (Alexandre Khalil) writes:
>
> > > We would like to set up a server that would serve two realms.
>
> > This is not possible with Kerberos4, BTW.
>
> > > Is that possible on Kerberos 5? Would someone who has done it
> > > share his configuration with us?
>
> > Yes it is, and the next release of MIT Kerberos should sort of
> > support this. The current code doesn't.
>
> Thanks Sam
In the future , it might be better to make sure I'm right
before thanking me;-) As Barry points out, you can do this in Beta4; I
believe it will work fine in Beta5 as well. What I was discussing is
code to allow two different databases served by one daemon; that code will be mostly working by the next release.
>
> As long as I have you at the end of the line...
>
> We need Kerberos for authentication of a PPP modem pool on Xyplex hardware.
>
> Is it reasonable to run two daemons with different configuration files,
> ports and databases to simulate the two realms on one host?
Sure, that works fine; you might do that if you can't get two
realms working out of one database.
>
> Also, is it possible to replace the DES password encryption with a Unix
> crypt style one?
All things are possible. In this particular case, it isn't a
particularly good idea. The krb5_string_to_key routine produces a
56-bit DES key, while unix's crypt call produces several bytes of
encrypted output. You could probably rig something to use a Unix
password file to seed a Kerberos database, by defining a new
krb5_string_to_key function that would take a password, crypt it,
then run it through the old string2key function. This actually
wouldn't help you much, because you would have to change your terminal
server software to use the new string2key function.
It is important to note that I have no idea how much harder or
easier it would be to perform cryptanalysis on this proposed scheme.
Also, probably better schemes for dealing with the output of crypt can
be proposed; you might even be able to convert it to a DES key by
adjusting parity. It is almost certain that you will lose some degree
of security by basing string2key on crypt. Since it requires
modifying all programs like kinit that attempt to get a ticket
granting ticket, it is of only theoretical interest anyway.
>
> alex
--Sam
