[1054] in Kerberos-V5-bugs
Gripe about apparent braindamage in krb5b4.3 kdb_edit xst4
daemon@ATHENA.MIT.EDU (Jonathan Stone)
Thu Jan 26 23:31:25 1995
Date: Thu, 26 Jan 1995 20:31:14 -0800
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
To: krb5-bugs@MIT.EDU
Cc: kjd@dsg.stanford.edu, jonathan@dsg.stanford.edu
First, I'd like to express my gratitude for having usable krb5
snapshots at all!
But I've also run, again, into what I beleive is a bug in the
kerberosIV compatibility. What I'm trying to do is to build a V5
database, with user entries added using the V4 string-to-key
algorithm so I can continue to support users with V4-only clients
(e.g., Macintoshes with NCSA Telnet).
The bug is that kdb_edit xst4 doesnt' do anything sensible for
the above scenario. More precisely, xst4 produces a srvtab
which uses "host" (instead of "rcmd") and uses fully-qualified
domain names, instead of "short" hostnames.
Suppose one adds a random key for some sensible name/instance pair,
such as host/Some.Server.Name. The intent here is, clearly, to
extract a srvtab for klogin/telnet for the machine called
Some.Server.Name.
If one _also_ wishes to use KRB4 backward compatibility, the
xst4 command in kdb_edit does a good job of constructing a KRB4
srvtab. But, it produces a srvtab with a FQDN, and with the
V5 service names, not the V4 service names.
For example, suppose I have a valid database entry and V5 srvtab
for a host called Pescadero.Stanford.EDU. Then I try and extract a version
4 srvtab, for those users who are stuck with V4-only clients.
The kdb5_util ``xst4'' command produces a v4 srvtab with an
entry starting
host^@pescadero.stanford.edu^@DSG.STANFORD.EDU^@
(keys removed for paranoia, and ASCII NUL transposed to ^@) which
doesn't work as I want. If, however, I manually edit that srvtab to
instead start with
rcmd^@pescadero^@DSG.STANFORD.EDU^@
then the V4 clients with V4 rcmd instances -- provided by the V5
server with backward compatbility -- happily authenticate themselves
to Pescadero, after I install the edited srvtab.
I believe the correct thing for a krb5 utility that creats
V4-compatible srvtabs to do is this: to special-case the principal
name `host' in exactly the way that KRB4 backwards compatiblity does
(i.e., map `host' to `rcmd'); and also to (perhaps optionally) strip
anything following a period out of an instance.
I hope that's a clear and consise description.
If there's something dumb I'm doing, or some other way of
achieving what I describe above, I'd be glad to hear it.
thanks
--Jonathan Stone
Stanford DSG