[966] in Kerberos-V5-bugs
krb4 srvtab constructed with kdb5_edit xst4 needs compat glue!
daemon@ATHENA.MIT.EDU (Jonathan Stone)
Wed Nov 16 03:59:24 1994
Date: Wed, 16 Nov 1994 00:59:19 -0800
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
To: krb5-bugs@MIT.EDU
To: tytso@MIT.EDU
Cc: kjd@dsg.stanford.edu
>The krb_rd_req which should be used is the one that's in the V4 Kerberos
>library. You'll also need to use the V4 DES library, or the des425
>library, which provides the V4 des library interfaces while using the V5
>DES core. Using the V4 des library doesn't hurt --- it just means that
>two versions of the DES code will be pulled in.
I tried that and put the CNS KerberosIV libraries at the end of the
link command. It works for me.
And I hand-constructed a v4 srvtab, with the v4 ksrvutil, that
``does the right thing'', still using a hand-entered V4 secret key.
Then the CNS v4 rlogin client can successfully authenticate itself
to the v5 krlogin.
I think the krb5_edit xst4 should do the glue translation from "host"
to "rcmd" and strip off any domain name. Anything else seems, well,
broken.
For example, if I use the KerberosIV klist on a (V4) srvtab
constructed by hand, using the kIV ksrvutil and knowledge of
the (not yet randomized) secret password, I get
Server key file: /etc/krb-srvtab-handmade-with-krb4-ksrvutil
Service Instance Realm Key Version
------------------------------------------------------
rcmd lahaina DSG.STANFORD.EDU 1
which seems to work as I wish.
Whereas if I do the same thing on a srvtab constructed with
the kdb5_edit xst4, I get
Server key file: /etc/lahaina.stanford.edu.new-v4-srvtab.from-krb5-edit
Service Instance Realm Key Version
------------------------------------------------------
host lahaina.stanford.edu DSG.STANFORD.EDU 1
which just isn't useful to a V4 client.
I believe that having, in KRB5 syntax, ``host/some.FQD.Name''
in a KerberosIV srvtab, instead of ``rcmd/some'' -- is a bug.
