[6635] in Kerberos
Re: krlogin/krlogind usage of OOB data is broken
daemon@ATHENA.MIT.EDU (Mark W. Eichin)
Sat Feb 10 19:30:27 1996
Date: Sat, 10 Feb 1996 19:11:03 -0500
From: "Mark W. Eichin" <eichin@cygnus.com>
To: jik@annex-1-slip-jik.cam.ov.com (Jonathan Kamens)
Cc: kerberos@MIT.EDU
In-Reply-To: "[6634] in Kerberos"
(I'm seeing this by email, so I guess the bsd list misses this one:)
I wish someone would find an RFC that gives any justification for out
of band data in tcp. There is mention of an urgent data *pointer* (not
value) but nothing that indicates that one can queue up successive
values. If you can find an RFC that explains the mechanism in use, I
would be happy to read more closely...
>in des_read() in krlogin. When des_read() reads the length of the next
>encrypted data block off the net, and that length is absurd, it checks to see
>if the first byte of the length contains a valid OOB message. If it does, it
Yep, CNS V4 started doing something like that a year or two ago (along
with some hacks to figure out the error return -- since klogind can
indicate failure in 3 different "partially completed" stages of the
response.)
_Mark_
