[2554] in Kerberos

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

Kstream / Rlogin and Kerberos V4 Patchlevel 10

daemon@ATHENA.MIT.EDU (Doug Engert)
Fri Feb 5 10:13:04 1993

Date: Fri, 05 Feb 93 08:45:07 CST
From: "Doug Engert" <DEEngert@anl.gov>
To: <KERBEROS@Athena.MIT.EDU>

Last week I sent out the following question:

> I am running Kerberos V4 at patch level 10 on SunOS 4.1.2. When I
> run rlogin with the -x option to get encrypted transmissions, and I
> change the size of a window, rlogin uses sendwindow() to send the
> window size information "via the magic escape",
> 0377,0377,s,s,..... this appears on my screen as ^?^?ss..... and
> it goes in as standard input.
>
> If I use rlogin at patch level 9 with the rlogind at patch level
> 10, window size events work correctly.
>
> It appears that some one (kstream-des.c?) has converter the 0377
> to 0177 or has divided up the message so the control() routine in
> rlogind does not see the full message in a buffer.
>
> Any ideas?

I did not receive any comments or suggestions.

I have looked at it closer. The window change size information
consists of a 12 byte packet.

It looks like the kstream-des.c routine "encrypt" will break up
requests into two packets the first with length 8, and the second
with the 4 leftover bytes. The patchlevel 9 code does not do this
but sends only a single packet. The rlogind.c protocol routine
issues a kstream_read request and looks for the magic 0377, and
calls control. Control checks the length of the data in the
buffer to see if there are 12 bytes. But there are only 8 so it
does not get change the window size, but instead passes this on
as data.

My next question is:

 Does anyone use this kstream routines? They look slick, but
 they also look like a lot of additional overhead for rlogin.
 They were introduced with patchlevel 10, and the comments
 all imply that the code is not complete.

 Is anyone using patchlevel 10 and either fixed this or removed
 the kstream code from the "r" commands?

 Why does the kstream code need to break up the encryption
 into two packet for packets which are not a multiple of 8?
 If this could be done as a single packet with padding on the right
 as done in the previous mode, and as implied in the comments,
 this would solve the window size problem.
 (I am leaning towards this last solution.)


           Douglas E. Engert
           Systems Programming
           Argonne National Laboratory
           9700 South Cass Avenue
           Argonne, Illinois  60439
           (708) 252-5444

           Internet: DEEngert@anl.gov

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