Subject: Re: patch to add rfc2228 support to ftpd
To: Tomas Svensson <firstname.lastname@example.org>
From: Aidan Cully <email@example.com>
Date: 03/26/2002 20:44:41
On Tue, Mar 26, 2002 at 09:22:35PM +0100, Tomas Svensson wrote:
> Tuesday, March 26, 2002, 4:02:45 PM, you wrote:
> JD> Tomas Svensson <firstname.lastname@example.org> writes:
> >> I think it adds a lot of kerberized obfuscation that may not be
> >> needed for other security methods.
> JD> What do you mean by that?
> Too much stuff taken from crypto/dist/heimdal/appl/ftp/ftpd and it
> assumes that every security method works like it, but 2228 doesn't
> require authentication nor data transport to be like that.
2228 doesn't require one to use protection buffers to transmit data
if the client doesn't request it. If data_prot == PROT_CLEAR, we
go through the "socket" layer, but no encryption/decryption, and
there's no size header prepended to any data units. Similar for
cmd_prot. In any event, it's up to the client how much or how little
of rfc2228 to use.
I'd also like to point out that the introduction of these I/O layers
made it fairly easy to solve those XXXLUKEMs about rate-limit on
ASCII transfers, so it's not just a win for kerberos.
> >> It also assumes that the data is always encrypted by a function then
> >> sent with write() which isn't the case with TLS.
I didn't put in TLS, which is why I'm transferring the data with
read()/write(). If TLS gets hacked in, the read()/write() calls
can be replaced with whatever TLS calls would be necessary to
decrypt/encrypt the data (I'm not familiar with the TLS APIs). I
hope this would be easy...