[krbdev.mit.edu #2726] Output control statements lose final character when encrypted.

[donn@u.washington.edu via RT]

On Tuesday, September 28, 2004, at 04:48 PM, Tom Yu via RT wrote:

> Donn> 	FTP protocol control lines lose the last character when 
> encrypted.
> Donn> 	For example, we'll get "215 UNIX Type: L\r\n" when we should get
> Donn> 	"215 UNIX Type: L8\r\n".
>
> Is this the debugging output of the client (presumably not the MIT
> krb5 ftp client?), or actual output captured from gss_unseal?  If you
> have a third-party client that forcibly null-terminates strings from
> gss_unseal with the assumption that they will have been sent with a
> null character, you might run into this behavior.  Our ftpd doesn't
> send "\r\n" in the gss_sealed message, nor does it send terminal null
> characters in the gss_sealed message.

Yes, I have had a chance to look at it more carefully and
I apologize for mischaracterizing the problem.  It is actually
that ftpd doesn't send the terminal NUL byte in a gss_sealed
message -- in krb5-1.3.xx, when it used to in krb5-1.2.xx.

The application is a GSSAPI FTP proxy, that relays FTP protocol
from a localhost port to the remote FTP port and inserts GSSAPI
authentication and control channel encryption.  We use it with
Microsoft Windows applications that do their own FTP, particularly
web development tools.  The code certainly could have been written
to anticipate this change, but of course it wasn't and eventually
it uses the returned length when it appends the "\r\n".

	Donn Cave, donn at u.washington.edu