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 <tsn@gbdev.net> 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...

--aidan