[3170] in Kerberos

home help back first fref pref prev next nref lref last post

Re: Kerberized FTP

daemon@ATHENA.MIT.EDU (michael shiplett)
Sun Apr 24 19:20:48 1994

To: kerberos@MIT.EDU
Date: 24 Apr 1994 19:58:30 GMT
From: walrus@enchanter.ifs.umich.edu (michael shiplett)
Reply-To: michael.shiplett@umich.edu

"sm" == Shawn Mamros <mamros@ftp.com> writes:

sm> walrus@enchanter.ifs.umich.edu (michael shiplett) writes:
>> I've successfully installed a (the?) kerberized telnetd/telnet
>> programs for SunOS 4.1.3 & NeXTSTEP 3.0. I have been trying
>> unsuccessfully for a couple hours now to get the Bellcore kerberized
>> ftpd/ftp working. I'm using the modified BSD ftp & have used both the
>> modified WU & BSD ftpd. All of this is for K4.
>> 
>> This is the client-side error I'm seeing [long lines split]:
sm> [remainder of session deleted for brevity]
>> Kerberos V4 krb_rd_safe failed: Message integrity error (krb_rd_req)

sm> Hmm... This looks an awful lot like the "classic" V4 krb_rd_safe() bug
sm> in the MIT code.  What happens is that, when you exchange a safe message
sm> between two machines that use different byte orderings (Suns are
sm> big-endian, while NeXTSTEP runs on Intel-based (little-endian) PCs, right?),
sm> krb_rd_safe() has to byte-swap the 16 byte checksum in the safe message
sm> before it can successfully compare it vs. the checksum it calculates itself.
sm> Problem is, krb_rd_safe() uses the swap_u_16() macro to do this, but if
sm> you take a close look at the des_quad_cksum() routine, you'll see that
sm> the checksum is actually constructed as four-byte blocks concatenated
sm> together.  swap_u_16() swaps the entire 16-byte value end over end, but
sm> what you really want to do is to swap each four-byte piece *in place*.

sm> A simple patch to rd_safe.c should fix the problem - basically you want
sm> to use swap_u_long() four times rather than swap_u_16() once.

  Actually I'm running the kftp client on an m68k (msb) NeXTstation
from when NeXT was still in the hardware business. I just successfully
running the ftp client from the sun to the sun.

  You may still be correct in suggesting the problem's related to the
krb_rd_safe(). The Sun uses MIT-distributed kerberos source, which
calls swap_u_16(), and the NeXT uses the Cygnus Network Security
product, which has the fix you mention and which I recommend due to
it's use of `configure' and knowledge/requirement of GNU cc.

  Now that kerberos works, I guess it's time to modify ftpd to get an
AFS token.

thanks for your help,
michael

home help back first fref pref prev next nref lref last post