Subject: Ftp-WG: FTP over SSL

From: Jeffrey Altman <[email-masked]>
Date: Fri, 24 Aug 2001 08:40:43 -0500

> The HOST draft is stuck in limbo while I (1) find a job and (2) figure out
> how to sanely allow HOST in the context of RFC 2228 and the Murray draft.
> 
> The only (unacceptable) solution I've found so far is to state the HOST
> command MUST NOT be used in sessions using RFC 2228.  Which leads to the
> other reason I set it aside for a while; I found myself sidetracked toward a
> massive revision of RFC 2228.  (And, by reference, the Murray draft.)

Why would HOST have to be a MUST NOT for sessions using RFC 2228?

As far as I can tell, the HOST command would be an optional command
that would simply be ignored by a FTP server if it was not required.
AUTH KRB4 and AUTH GSSAPI might use the advisory information provided 
by HOST to determine which service key table to use.  AUTH SRP might 
use it to determine which SRP password file to use.  Of course, AUTH
TLS would use it to determine which Server certificate to send to the 
client.

I do not see why it would be a MUST NOT for RFC 2228.  Can you please
elaborate? 

> If you want a HOST draft, the quickest solution would be to first have RFC
> 2228 moved from Standards Track to Experimental (in which case I'll ignore
> it for the purposes of the HOST command other than to say HOST won't work
> with it).  What I have works well when we don't want to secure the
> communications channels, but leads to the "chicken and the egg" question
> when we do.

RFC 2228 is widely implemented and should not be changed to
experimental.   That is not to say that it could or should not be
updated and refined while remaining on the standards track.
 
> The other option is to could follow the example of RFC 2228 and cobble
> together something which looks like it might work, and wait for the smoke to
> blow off so we can see who got burned.  But I don't like that approach (and
> wish RFC 2228 hadn't taken it).

Unfortunately it is too late for starting over from scratch.  

 Jeffrey Altman * Sr.Software Designer      C-Kermit 8.0 Beta available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to follow.

---

From: "Gregory A Lundberg" <[email-masked]>
Date: Fri, 24 Aug 2001 09:07:39 -0500

> Can you please elaborate?

RFC 2228 is incomplete in and of itself.  It leaves a lot of possible cases
up to the reader.  This is not a big problem taken alone, but when adding a
new authentication/authorization command like HOST it falls apart.

Your reasons why RFC 2228 can't be eliminated are why I set the mess aside.
I'm hoping, when I get back to the draft that some time away will allow me
to see a "punt" .. some way to ignore RFC 2228's problems and come up with a
HOST command which will work fine for clear-text and _might_ work _if_ you
do everything correctly (without telling you what to do) if you're using
2228.

I'm sorry if I seem short on this.  The fact of the matter is my priorities
are to find a job first.  Then I'll have the time to take the days/weeks it
will take to point out all the shortcoming of RFC 2228.  At this point, all
I really want to say is it's incomplete and seemed logically inconsistent
(some internally, but mainly with respect to the way the rest of the FTP
works).

Frankly, since you say it's widely deployed, I'm scared.  To me that means
that there are a lot of differing and probably incompatible implementations
out there.  That's mainly an emotional reaction: I've not seen ANY RFC 2228
implementations other than the Murray-draft contribution to WU-FTPD and ONE
other implementation (which, IIRC, was WS_FTP).  But it's not totally
emotional: one of the positions I'm looking at is for a VERY security
conscious organization and, if there were a working RFC 2228 implementation
out there, I am absolutely POSITIVE they would be using it.  The fact they
are not tells me either there are none, or their research showed that what
was there had some reason for not using it (either there was nothing, or
there were servers but no clients, or clients but no servers, or the (my
guess) clients for some servers could not inter-operate with servers for
other clients).

Frankly, the ONLY reason I sponsored including the contribution of
Murray-draft implementation into WU-FTPD was because it needs a second,
independent implementation to proceed to RFC status.