[1637] in Kerberos-V5-bugs
Re: V4 telnet to V5 (Beta 5) telnetd (NCSA Telnet)???
daemon@ATHENA.MIT.EDU (John Bien)
Wed Sep 20 21:56:10 1995
To: Theodore Ts'o <tytso@MIT.EDU>
Cc: John Bien <jsb@gumby.dsd.TRW.COM>, krb5-bugs@MIT.EDU
In-Reply-To: Your message of "Sat, 16 Sep 1995 02:21:58 EDT."
<9509160621.AA28926@dcl.MIT.EDU>
Date: Wed, 20 Sep 1995 18:55:52 -0700
From: John Bien <jsb@gumby.dsd.TRW.COM>
Thanks for the help, though I still can't get the NCSA telnet
to authenticate. Is there anywhere I can look to see if
the NCSA telnet is broken? When I run the telnetd in debug
mode, I get the following data back:
>>>TELNETD: I support auth type 2 2
>>>TELNETD: I support auth type 2 0
>>>TELNETD: I support auth type 1 0
>>>TELNETD: Sending type 2 2
>>>TELNETD: Sending type 2 0
>>>TELNETD: Sending type 1 0
>>>TELNETD: in auth_wait.
>>>TELNETD: Got NAME [jbien]
Got 96 bytes of authentication data
CK: -1136878845: 04 06 01 53 50 2e 54 52 57 2e 43 4f 4d 00 30 20
Kerberos failed him as
>>>REPLY:2: [1] (39) 43 61 6e 27 74 20 64 65 63 6f 64 65 20 61 75 74
Can any of this data be used to debug (What does the "CK: -1136..." line show?)
I think I've tried every permutation of /etc/srvtab entries.
The way it sits now is (as per your suggestion):
kdb5_edit: add_rnd_key host/pokey.sp.trw.com
kdb5_edit: extract_v4_srvtab pokey.sp.trw.com host
kdb5_edit: quit
emacs pokey.sp.trw.com-new-v4-srvtab
(change "host" to "rcmd", delete the ".sp.trw.com")
copy the file to /etc/srvtab on pokey
On the NCSA client, I do get the following tickets:
jbien@SP.TRW.COM krbtgt.SP.TRW.COM@SP.TRW.COM
jbien@SP.TRW.COM rcmd.pokey@SP.TRW.COM
So the V5 server is translating the "host/pokey.sp.trw.com" --> "rcmd/pokey"
and giving a ticket back to the client. But the telnetd just doesn't seem
to like what it gets.
Is there another Kerberos Client for the MAC that has been known to work
with this? Is there a list of clients that are known to work with krb5?
Thanks for any help
-John
John Bien (310) 814-8546
TRW Space and Electronics Group, Network Services
j.bien@gumby.sp.TRW.COM (Internet)
> [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
