[1631] in Kerberos-V5-bugs
Re: V4 telnet to V5 (Beta 5) telnetd (NCSA Telnet)???
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Sat Sep 16 02:23:01 1995
Date: Sat, 16 Sep 1995 02:21:58 -0400
From: Theodore Ts'o <tytso@MIT.EDU>
To: John Bien <jsb@gumby.dsd.TRW.COM>
Cc: krb5-bugs@MIT.EDU, j.bien@pokey.sp.trw.com
In-Reply-To: "[1627] in Kerberos-V5-bugs"
[1627] daemon@ATHENA.MIT.EDU (John Bien) Kerberos-V5-bugs 09/14/95 00:31 (62 lines)
Date: Wed, 13 Sep 1995 21:30:59 -0700
From: John Bien <jsb@gumby.dsd.TRW.COM>
Since this is a V4 application, I have (on the server) an /etc/srvtab
file with the singe entry for "rcmd/pokey.sp.trw.com".
V4 service names do not contain fully qualified domains. (This is one
of V4's limitations that was addressed in V5.) But for V4 service
principals you need to have a srvtab entry for "rcmd/pokey".
The V5 equivalent of rcmd/pokey is "host/pokey.sp.twm.com" and it is
this principal which you need to add to the database with a random key.
Kerberos will handle the automatic translation between the V5 and V4
principal names (see the file src/lib/krb5/krb/conv_princ.c).
There is a bug in Beta5's kdb5_edit extract_v4_srvtab in that it does
not call the V4 to V5 principal name conversion routines. A workaround
is to use the V5 style name:
extract_v4_srvtab pokey.sp.twm.com host
and then edit the resulting srvtab using an editor to change host to
rcmd, and to delete the ".sp.twm.com".
In krb5_edit, why is there an "add_v4_key"? I made my user
ticket with this option (jbien). I can "kinit" from both
Version 4 and Version 5 clients (if I used add_new_key, Version 4
clients couldn't log in).
I also tried adding my server with this option.
In V5, the key salting algorithm was changed to include the realm name
into the salting process. This provides an additional measure of
security for users that have principals in more than one Kerberos
realm, and who might have the same passwords in multiple realms. By
including the realm information in the salting algorithm, the keys in
the various realms will be different even if the user used the same
password.
Unfortunately, this salting scheme is not compatible with the V4 salting
scheme (obviously). The "add_v4_key" means to set the user's password
using the V4 salt, which is required for V4 backwards compatibility to
work.
(Note that the user interface to kdb5_edit in beta 5 is quite horrible,
and I apologize for that. We're working on improving it somewhat for
the enxt release.)
Good luck! I hope these suggestions help you out.
- Ted
